Slashdot Mirror
The Law of Leaky Abstractions
Joel Spolsky has a nice essay on the leaky abstractions which underlie all high-level programming. Good reading, even for non-programmers.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I looked down in suprise to find a leaky abstraction. Had to change pants.
Because the first step to solving any problem is always to create more problems.
-E
http://almostsmart.com
Great! I'll print off a hardcopy and stick it on my refrigerator! I'm sure my wife will love it!
There is no magic. TCP is reliable even using IP because there are timeouts. If your data cannot be transmitted for a certain time limit, you will get timeout wich is perfectly legal result.
Although I used to program as a hobby, my eyes bugged out when I saw this article. It's actually quite interesting; I finally realize why the hell people program in lower level languages.
One point that I think could be addressed is backward compatibilty. I really know nothing about this, but don't the versions of the abstractions have to be fairly compatible with each other, especially on a large, distributed system? This extra abstraction of an abstraction has to be orders of magnitude more leaky. The best example I can think of is Windows.
I'm of the idea that the whole premise that high-level tools and high level abstraction coupled with encasulation are the biggest bane of the software industry. We have these high level tools which most programmers really don't understand and are taught that they don't need to understand in order to build these sophisticated products.
Yet, when something goes wrong with the underlying technology they are unable to properly fix their product because all they know is some basic java or VB and they don't understand anything about sockets or big-endian/little endian byte alignment issues. It's no wonder todays software is huge and slow and doesn't work as advertised.
The one shining example of this is FreeBSD, which is based totally on low level C programs and they stress using legacy program methodologies in place of the fancy schmancy new ones which are faulty. The proof is in the pudding, as they say, when you look at the speed and quality if FreeBSD, as opposed to some of the slow ponderous OS's like Windows XP or Mac OSX.
Warmest regards,
--Jack
Wagner LLC Consulting Co. - Getting it right the first time
This guy made my day. He's a good writer, and even people who don't know the Way Things Work with computers can understand his article. Moreover, he explains why the world needs and will always need wizards, which gives me an argument for why employers should hire me. Thanks man!
Please correct me if I got my facts wrong.
Imagine that we had a way of sending actors from Broadway to Hollywood that involved putting them in cars and driving them across the country. Some of these cars crashed, killing the poor actors.
Unlike TCP, though, we don't have the ability to re-send copies of Hollyweird actors. Or do we?
All I want is a kind word, a warm bed and unlimited power.
How is this news? All technologies, on some level, are inherently unreliable. Therefore, in order to obtain reliability, it is always by adding some kind of redundancy to an unreliable tool.
I've never seen a technology touted as "reliable" that didn't achieve that reliability without some kind of self-checking or redundancy somewhere. Maybe that's the author's point, but he makes it sound as TCP/IP is unique in this regard.
This is what programming is all about. It seems pretty obvious to me.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Is our own bodies.
I'm studying to be a bioinformatics guy with the university of melbourne and have just had the misfortune of looking into the enzymatic reactions that control oxygen based metabolism in the human body.
I tried to do a worst case complexity analysis and gave up about half way through the krebs cycle.
When you think about it, most of basic science, some religeon and all of medicine has been about removing layers of abstraction to try and fix things when they go wrong.
So the abstractions save us time working, but they don't save us time learning.
At last I know what is really bothering me about all these new kids learning C++ and leaving plain C out. It is not that I am lazy or against change. Next time I give advice to the undergrads working in my office I'll make sure to quote this.
Thank you very much...
ato
...to start with, or at least be competent with, the basics.
Any good programmer I've ever known started with the lower level stuff and was successful for this reason. Or at least plowed hard into the lower level stuff and learned it well when the time came, but the first scenario is preferable.
Throwing dreamweaver in some HTML kiddie's lap, as much as I love dreamweaver, is not going to get you a reliable Internet DB app.
vk.
The mechanical, electrical, chemical, etc, engineering fields all have various degrees of abstractions via object hiding. It just isn't called "object hiding" because these are in fact real objects and there is no need to call them objects because it is natural to think of them that way. When debugging a design in any of these fields, it is not unusual to have to strip down layers and layers of "abstraction" (ie, pry into physical objects) to get to the bottom of a real tough problem. Those engineers with the broadest skills are usually the best at dealing with such problems. There isn't really anything new in the article.
Great article, but don't throw out the high level tools and go back to coding Assembler.
Brevity is the soul of wit
-- Polonius
Unfortunately, his Slashdotted server is proving that to us right now.
Maybe someone out there prefers to program without any abstraction layers at all, but they inherit so much complexity that it will be impossible for them to deliver a meaningful product in a reasonable time.
As a VB programmer, I've *lived* leaky abstractions. Nowhere has it been more obvious than in the gigantic VB app our team is responsible for maintaining. 262 .frm files, 36 .bas modules, 25 .cls classes, and a handful of .ctl's.
Much of our troubles, though, come from a single abstraction leak: the Sheridan (now called Infragistics) Grid control.
Like most VB controls, the Sheridan Grid is designed to be a drop-in, no-code way to display database information. It's designed to be bound to a data control, which itself is a drop-in no-code connection to a database using ODBC (or whatever the flavor of the month happens to be).
The first leak comes in to play because we don't use the data control. We generate SQL on the fly because we need to do things with our queries that go beyond the capabilities of the control, and we don't save to the database until the client clicks "OK". Right away, we've broken the Sheridan Grid's paradigm, and the abstraction started to leak. So we put in buckets -- bucketfuls of code in obscure control events to buffer up changes to be written when the form closes.
Just when things were running smoothly, Sheridan decided to take that kid with his finger in the dike and send him to an orphanage. They "upgraded" the control. The upgrade was designed to make the control more efficient, of course... but we don't use the data control! It completely broke all our code. Every single grid control in the application -- at least one and usually more in each of 200+ forms -- had to have all-new buckets installed to catch the leaks.
You may be wondering by now why we haven't switched to a better grid control. Sure enough, there are controls out there now that would meet 95% of our needs... but 1) that 5% has high client visibility and 2) the rest of the code works, by golly! No way we're going to rip it out unless we're absolutely forced to.
By the way, our application now compiles to a svelte 16.9 MEG...
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
This is one the best essays on software engineering I've read in a while. As a programmer and CS educator, it's really served to crystallize for me why (a) it seems so much harder for students to learn programming these days, and (b) why I've grown unhappy over the years with the series of new engineering paradigms that are in use. Extremely helpful for putting my own thoughts in order.
The law statement itself, "all non-trivial abstractions, to some degree, are leaky" may possibly get included in my personal "top 10" aphorisms manifesto.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
google cache
Yes it would be nice to get back to 'first principles' and address machine resources directly, but its impossible to deliver a product to the marketplace in a meaningul timeframe using this method, particularly when Moore's law blurs the gains anyway - crap runs fast enough.
FIne it's relaibale becasue of acks, timeouts, adaptive re-transmit timeouts that take statistical averages of RTT times, exponential back-off and slow start, window acks which keep track of what bytes are received, etc.
So in your case of timing out N, re-tx'ing N, and then getting the repsonse to the first N back after sending the second N, you do two things:
1) Good! You got yr packet!
2) keep track of how many bytes you have received thsu far (TCP is not sending messages, it is sending a stream)
3) when you get the response from your second request, discard it, becuase you already received those bytes from the stream.
4) since you timed out, DON'T use the Round TRip Time for that reponse: slow down your expected RTT time, and THEN start measuring.
And guess what? If I unplug the NIC of the other machine, there is no reliable way of transmitting that data (assuming your destination machine isn't dual homed)- so I keep streaming bytes to a TCP socket and I don't find out my peer is gone for approx. 2 minutes.
WOW. There's nothing reliable about that boundary condition!
my point is TCP is reliable ENOUGH. But I wouldn't equate it with a Maytag warranty. It is not a panacea. Infact, for a closed homogenous network I wouldn't even consider it the best option. But if the boundary conditions fall within the acceptible fudge range (remember Real Time human grade systems are not 100% reliable, only 99.99999% and much of that is achieved through redundancy) your leaks are ok.
In the future, I would want to not be isolated from my friends in the Space Station.
I think that term ooze would suite better in this case. It's possesses a kind of dirtiness to itself and the fealing the word 'ooze' gives me fits good with the matter of described problem. :o)
Back to the article. To be serious, i think that Joel mixed all things as examples of 'Leaky abstraction' to no purpose. Too different situations make concept to fall apart. Here what i mean:
In case of tcp/ip it denotes limits of abstraction. And regardless of programmer background every sane man should now those limits do exist.
In case of page faults it's a matter of competence - there is no abstraction at all. You either do know how your code is compiled and executed or you don't. It's the same when you know what the phrase in a given language do realy mean or you don't. I simplify here.
In the case of C++ strings i saw the only good example. What in my opinion the experience of STL and string class usage tells in this case is: one should understand the underlying mechanics fully before rely on abstraction behaviour.
In programming it is realy simple to tell will the given 'abstraction' present you with an easter egg or not: if you can imagine FSM for the abstraction you will definitely know when to use it.
I'm not a brake. I'm an accelerator. Just a slow one...
> Huh? You can't retransmit cabbages or actors or hard copies of badly researched
> essays . . . but you can retransmit freaking TCP packets!
He does go on to say that "retransmission" in this case means sending an identical twin of the actor. Your criticism really isn't fair in ignoring this. The metaphor of identical twins for copies of information is not perfect, but as a teaching tool for explaining TCP to a non-technical type, I'm not sure I could come up with another metaphor which matches this one for its intuitive value.
Joel should write an article about his leaky hosting company... or maybe his leaky colo-ed box.
Since I can't get to the site and read the article, I'll tell some jokes.
"Leaky Abstractions?! Is this guy talking about Proctology??"
"Leaky Abstractions?! Someone get this guy a plumber!"
"Leaky Abstractions?! I knew we should have used the pill!"
-gerbik
you can send ip packets without using the udp or tcp protocol nyet?
My company, Fog Creek Software, has just released FogBUGZ 3.0, the latest version of our innovative system for managing the software development process. Check it out now!
I don't really see that as helping the issue of having problems with "leaky abstractions."
The issues really seems to be several fold:
1.) Our current abstractions are not good enough.
2.) Many code generation tools are subject to errors, deriving from the underlying implementation they are abstracting.
3.) People don't know the underlying structure, and depend upon the abstractions.
I think that this is over simplifying where the problems are. Our current abstractions are obviously limited by thier underlying impelementations. What we need are better base level tools, this means better object oriented programming languages, that aren't merely an abstraction of existing languages, because again they fall victim to resting on top of a faulty abstraction. What we also need is better documentation. I hate to say it, but often times example code looks like a train wreck.
Abstractions are important to computer science, if it were not for them, we wouldn't have any high level languages. Without those higher level languages, we wouldn't have complex applications. We need abstraction, it's the only way to handle complexity. Where does that leave us? What we need are tools designed from the ground up to be cross platform, object oriented, robust core data types, and useful error/exception handling.
It seems like he's talking about a lot of problems, but not presenting any solutions, other than his little advertisement at the bottom, which helps us abstract our development team, but little for the developers...how very constructive. Try again with some constructive criticism, not just criticism.
C-out
- Sighuh?
The market rewards abstractions because they help create high level tools that get products on the market faster. Classic case in point is WordPerfect. They couldn't get their early assembler-based product out on a competitive schedule with Word or other C based programs.
heh.
cyn, free software and *nix operating systems enthusiast.
"Wah? Is this serious? Does he mean UDP?"
No, read the book again. TCP is a reliable protocol that is built on top of IP, which is an unreliable protocol. UDP, which is also an unreliable protocol, is also built on top of IP.
Are YOU a troll?
(hmm. Am I?)
Karma: Poor (Mostly affected by lame karma-joke sigs)
Isn't "leaky abstraction" a leaky abstraction of the leaky abstractions?
-... ---
This author obviously doesn't understand TCP/IP.
It doesn't, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can't do anything about it and your message doesn't arrive.
What an idodic statement...different layers.
eMelody Web Directory add your site today!
Go refresh your TCP and IP knowledge.
TCP is implemented on top of IP
UDP is implemented on top of IP
The comparison between TCP and IP is a valid one in this article. He does not mean UDP.
You cannot retransmit TCP packets. You can retransmit TCP segments or the IP packets comprising these TCP segments.
It seems that your response was more crap than the essay.
Cheers
For something like IP packets, leaky is acceptable, but for many of those other abstractions, constipated might be a better adjective. Some of the tools and technologies out there (remember 4GL report-writers?) were big clogging masses that just won't pass.
The first thing I do when I start in on a new technology (VBA, CGI, ASP, whatever) is to start digging in the corners and see where the model starts breaking down.
What first turned me on to Perl (I'm trying hard not to flamebait here) was the statement that the easy things should be easy, and the hard things possible.
But even Perl's abstraction of scalars could use a little fiber to move through the system. Turn strict and warnings on, and suddenly your "strings when you need 'em" stop being quite so flexible, and you start worrying about when it's really got something in it or not.
On the HTML coding model breaking down, my current least-fave is checkboxes: if unchecked, they don't return a value to the server in the query, making it hard to determine whether the user is coming at the script the first time and there's no value, or just didn't select a value.
Then there's always "This space intentionally left blank.*" Which I always footnote with "*...or it would have been if not for this notice." Sure sign of needing more regularity in your diet.
Design for Use, not Construction!
Sure, the author points out a few examples of leaky abstractions. But his conclusion seems to be that you always will have to know what is behind the abstraction.
I don't think that's true. It depends on how the abstraction is defined, what it claims to be.
You can use TCP without knowing how the internals work, and assume that all data will be reliably delivered, _unless_ the connection is broken. That is a better abstraction.
And the virtual memory abstraction doesn't say that all memory accesses is guaranteed to take the same amount of time, so I don't consider it to be leaky.
So I don't entirely agree with the author's conclusions.
No, he really (and rightly) means "IP".
Proper abstractions avoid unintended side-effects by presenting a clean view of the intent and function of a given interface, and not just a collection of methods or structures.
When I read what Joel wrote about "leaky abstractions" i saw a peice complaining about "unintended side-effects". I don't think the problem is with abstractions themselves, but rather the implementation.
He lists some examples:
1. TCP - This is a common one. Not only does TCP itself have peculiar behavior in less than ideal conditions, but it is also interfaced with via sockets, which compound the problem with an overly complex API.
If you were to improve on this and present a clean reliable stream transport abstraction is would likely have a simple connection establishment interface and some simple read/write functionality. Errors would be propagated up to a user via exceptions or event handlers. But the point I want to make is that This problem can be solved with a cleaner abstraction.
2. SQL - This example is a straw man. The problem with SQL is not the abstraction it provides, but the complexity of dealing with unknown table sizes when you are trying to write fast generic queries. There is no way to ensure that a query runs fastest on all systems. Every system and environment is going to have different amounts and types of data. The amount of data in a table, the way it is indexed, and the relationship between records is what determines a queries speed. There will always be manual performance tweaking of truly complex SQL simply because every scenario is different and the best solution will vary.
3. C++ string classes. I think this is another straw man. Templates and pointers in C++ are hard. That is all there is too it. Most Visual Basic only coders will not be able to wrap their minds around the logic that is required to write complex c++ template code. No matter how good the abstractions get in C++, you will always have pointers, templates, and complexity. Sorry Joel, your VB coders are going to have to avoid c++ forever. There is simply no way around it. This abstraction was never meant to make things simple enough for Joe Programmer, but rather to provide an extensible, flexible tool for the programmer to use when dealing with string data. Most of the time this is simpler, sometimes it is more complex (try writing your own derived string class - there are a number of required constructors you must implement which are far from obvious) but the end result is that you have a flexible tool, not a leaky abstraction.
There are some other examples, but you see the point. I think Joel has a good idea brewing regarding abstractions, complexity, and managing dependencies and unintended side-effects, but I do not think the problem is anywhere near as clear cut as he presents. As a discipline software engineering has a horrible track record of implementing arcane and overly complex abstractions for network programming (sockets and XTI) generic programming (templates, ref counting, custom allocators) and even operating systems API's (POSIX).
Until we can leave behind all of the cruft and failed experiments of the past, start new with complete and simple abstractions that do not mask behavior, but rather recognize it and provide a mechansim to handle it gracefully, we will run into these problems.
Luckily, such problems are fixable - just write the code. If joel were right and complex abstractions were fundamentally flawed, that would be a dark picture indeed for the future of software engineering (it is only going to grow ever more complex from here kids - make no mistake about it).
Somewhere in there, he posits the availability of an unlimited supply of identical twins of each actor. With that, the analogy holds up better.
Well designed abstractions are useful the majority of the time. My microwave is an abstraction. I stick my TV dinner in, push some buttons, and my food comes out hot. I don't need to know how a magnetron works, but if it breaks and I want to fix it myself I'm going to have to learn. I don't have to know that it runs on 120V and 60Hz. But if I move to Japan I'm going to have to know that.
Without abstractions we would constantly be solving the same problems over and over. They may `leak' sometimes, but these leaks are to be the exceptional cases, otherwise the abstraction is useless. Therefore a characteristic of a useful abstraction is one that leaks infrequently.
By reading this post you have agreed to my end-reader license agreement. Please send check or money order to...
I enjoyed the article. But it is really nothing new. This is what all engineering is about. For an in depth study into the art of engineering and how failures play a role in advancing the art, read Petroski's "To Engineer is Human". Written way back in the early 80s (?).
6 79 734163-12
http://www.powells.com/cgi-bin/biblio?inkey=1-0
All things old are made new again.
UncleBri
I think the key point is that this article is an abstraction (and a leaky one at that) of the truth :)
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
The problem that this article points to is a byproduct of large scale software development primarily being an exercise in complexity management. Abstraction is the foremost tool available in order to reduce complexity.
In practice a person can keep track of between 4 and 11 different concepts at a time. The median lands around 5 or 6. If you want to do a self-experiment have someone write down a list of twenty words, then spend 30 seconds looking at them without using memnonic devices such as anagrams to memorize them then put the list away. After thirty more seconds write down as many as you can recall.
This rule applies equally when attempting to manage a piece of software - you can only really keep track of between 4 and 11 "things" at the same time, so the most common practice is to abstract away complexity - you reduce an array of characters terminated by a null characters and a set of functions designed to operate on that array to a String. You went from half a dozen functions, a group of data pieces, and a pointer to a single concept - freeing up slots to pay attention to something else.
The article is completely correct in its thesis that abstractions gloss over details and hide problems - they are designed to. Those details will stop you from being productive because the complexity in the project will rapidly outweigh your ability to pay attention to it.
This range of attention sneaks into quite a few places in software development:
other schemes exist for managing complexity, but abstraction is decided human - you don't open a door, rotate, sit down backwards, rotate again, bend legs, position your feet, extend left arm, grasp door, pull door shut, insert key in iginition, extend right arm above left shoulder, grasp seatbelt, etc... you start the car. Software development is no different.
There exist peopel that can track vast amounts of information in their heads at one time - look at Emacs - iirc RMS famously wrote it as he did because he could keep track of what everythign did, no one else can though. There also exist memnonic devices aside from abstraction for managing complexity - naming conventions, taxonomies, making notes, etc.
-Frums
Strangely, despite complaining about all the leaky abstractions he has to know to program, he uses all of them up to the highest level possible. So this is less of a serious complaint and more of a whine: why can't the abstractions at each layer be made better? ( A legitimate whine, but when you're complaining about ASP and VB and C++ in specific, you have to just get over the fact that they leak... they just don't deal with their additional complexity as well as, say, C deals with its much smaller complexity. )
Of course, what he doesn't say here but obviously knows is that the higher level tools are worth learning because you can be much more productive in them, both in terms of code written and bugs not written, despite all their flaws. So really he's just being whiny. Which is odd, because usually his essays are more sensible. Must have been a bad week at the office.
Joel Spolsky often grates on me (especially when he falls into, "here's how Microsoft solved the problem with near infinite access to manpower, so clearly you should do the same thing."), but this article really rang true. People might also be interested in a similar article published in 1998 on Salon, "The dumbing-down of programming." The author comes from a slightly different point of view, but comes to a similar conclusion: we need to be wary of becoming too detached from the low level details.
Search 2010 Gen Con events
Abstractions are just that: abstractions. They are not real. They are pretend, they are fantasy, an illusion we create because they are useful. Nobody said they are concrete.
That abstractions leak are the nature of abstractions. This ludicrousness is exemplified by his last car example. Nobody EXPECTS to not have to pay attention to the road and weather conditions. In fact, I'm not even sure of what he is implying a car is an abstraction.
Most of his rant is preoccupied with performance. Non-uniform performance is one of the REASONS for abstractions. You don't want your developer doing wonky ad hoc things for performance because 1) it generally leads to code which is harder to maintain 2) it breaks when your fragile silly assumptions are broken. That is the beauty (or utility for the less romantic) and nature of abstractions. They are simply useful constructs.
His C/C++ comments seem a bit more on topic, because in that case, he is illustrating a broken abstraction. Abstractions whose implementation cannot live up to their specification are, well, broken. There are many things we can't universally abstract. The point of abstraction is to find those essential shared qualities among many different things. This doesn't guarantee that you will expose all qualities (on the contrary, it implies you CANNOT), and doesn't guarantee you can expose idiosynchrasies that you could exploit.
I'm not sure what Joel's point is. Is it that we should just go back to flipping switches? I don't know about him, but I am typing this into a "string text area" "widget" in a "browser" "window" on my "desktop" and for all of the metaphor shear, it is still a hell of a lot better than flipping switches and turning knobs.
It's 10 PM. Do you know if you're un-American?
During my first Microsoft internship, I wrote string libraries to run on the Macintosh. A typical assignment: write a version of strcat that returns a pointer to the end of the new string. A few lines of C code.
...and a few bewildered looks from your boss,
who wanted you to implement strcat(3), not some
crazy function that sets the pointer "to the end
of the new string."
Stick to armchair coding, Joel, and leave the real work to men who don't leak.
We have examples of massively complex systems that work very reliably day-in and day-out. Jet airplanes, for one; the national communications infrastructure, for another. Airplanes are, on the whole, amazingly reliable. The communications infrastructure, on the other hand, suffers numerous small faults, but they're quickly corrected and we go on. Both have some obvious leaky abstractions.
The argument works out to be pessimism, pure and simple -- and unwarrented pessimism to boot. If it were true that things were all that bad, programmers would all _need_ to understand, in gruesome detail, the microarchitectures they're coding to, how instructions are executed, the full intricacies of the compiler, etc. All of these are leaky abstractions from time to time. They'd also need to understand every line of libc, the entire design of X11 top to bottom, and how their disk device driver works. For almost everyone, this simply isn't true. How many web designers, or even communications applications writers, know -- to the specification level -- how TCP/IP works? How many non-commo programmers?
The point is that sometimes you need to know a _little bit_ about the place where the abstraction can leak. You don't need to know the lower layer exhaustively. A truly competant C programmer may need to know a bit about the architecture of their platform (or not -- it's better to write portable code) but they surely do not need to be a competant assembly programmer. A competant web designer may need to know something about HTML, but not the full intricacies of it. And so forth.
Yes, the abstractions leak. Sometimes you get around this by having one person who knows the lower layer inside and out. Sometimes you delve down into the abstraction yourself. And sometimes, you say that, if the form fails because it needs JavaScript and the user turned off JavaScript, it's the user's fault and mandate JavaScript be turned on -- in fact, a _good_ high-level tool would generate defensive code to put a message on the user's screen telling them that, in the absence of JavaScript, things will fail (i.e. the tool itself can save the programmer from the leaky abstraction).
What Ian Malcolm says, when you boil it all down, is that complex systems simply can't work in a sustained fashion. We have numerous examples which disprove the theory. That doesn't mean that we don't need to worry about failure cases, it means we overengineer and build in failsafes and error-correcting logic and so forth. What Joel Spolsky says is that you can't abstract away complexity because the abstractions leak. Again, there are numerous examples where we've done exactly that, and the abstraction has performed perfectly adequately for the vast majority of users. Someone needs to understand the complex part and maintain the abstraction -- the rest of us can get on with what we're doing, which may be just as complex, one layer up. We can, and do, stand on the shoulders of giants all the time -- we don't need to fully understand the giants to make use of their work.
I know it wasn't the point but its simple enough to code adding two char pointer you just have to cast one of them to a string. its ugly and I never do it this way but here's something i coded int 3 mins...
#include <string.h>
class String {
char * m_str;
String(char * str, bool) {
m_str = str;
}
public:
static String operator+(const char* str , const String & s) {
return String(str) + s;
}
String(const String & str ) {
m_str = new char[strlen(str.m_str) + 1];
strcpy(m_str,str.m_str);
}
String(const char * str) {
m_str = new char[strlen(str)+ 1];
strcpy(m_str,str);
}
virtual ~String() {
if(m_str != 0)
delete [] m_str;
}
String operator+(const char*str) const {
char * tmp = new char[strlen(m_str) + strlen(str) + 1 ];
strcpy(tmp, m_str);
strcat(tmp,str);
return String(tmp,true);
}
String operator+(const String & str) const {
char * tmp = new char[strlen(str.m_str) + strlen(m_str) + 1];
strcpy(tmp,m_str);
strcat(tmp,str.m_str);
return String(tmp,true);
}
};
int main(int argc , char ** argv) {
String str = (String)"abc" + "foo";
}
We are talking about Windows, right?
(I didn't read the whole article, so my analysis may be leaky.)
It is true that every abstraction is but an imperfect representation of the concrete things it was abstracted from. It is true, and worth noting, that the degree to which the abstraction breaks down in certain situations can cause large problems.
I would like to nit-pick the Katzian "It's dragging us down" doomsday prediction at the end. Abstraction itself has lifted us, tremendously. The fact that abstraction is not perfect is a limitation to how much it can lift us, true. But it's like taxes to support military spending or highways--yes, they do "drag down" our paychecks, but they also make what we do to get that paycheck possible.
One other concept that doesn't seem to be considered is the fact that, even with the imperfections, there is a very powerful and important benefit to having done the abstraction in the first place. One people are using the abstraction instead of interfacing with the concrete target directly, then fixing a leak in the abstraction can be done at the abstraction, and everyone, potentially millions or billions, can benefit from it. Yes, there is a cost to rolling that out and ensuring compatibility, etc, but it's an advantage of abstraction that is a powerful tool to deal with inherent "leakiness" of abstracting anything.
Finally, I want to point out one thing that is implied but not stated, and that is how important it is to do your abstraction well. Once you have completed your abstraction, it's likely that thousands or millions will build things on top of it. Code that exists to be used by other code is more important than a one-off script. If you mess it up, you are messing it up for a lot of people. Just something to keep in mind, and something well illustrated by the article.
Liberty uber alles.
agnosticism of implementation is a FEATURE of abstractions...not a bug
It's 10 PM. Do you know if you're un-American?
The reason we have the leaky abstraction problem is because we are clueless about computers.
We are at the stage with computers where medicine was when the guy who set your bones was the same guy who cut your hair.
50 years from now they're gonna look back on us and feel pity.
It's Christmas everyday with BitTorrent.
What is a string library? It's a way to pretend that computers can manipulate strings just as easily as they can manipulate numbers.
Computers can manipulate strings more easily than numbers, and a computer's notion of "numbers" and "arithmetic" are abstractions on manipulating strings of symbols.
The notion that computers were generalized symbol string manipulators rather than numerical and arithmetical by nature was realized by Ada Lovelace in the 19th century.
You have a technical lead to solve sneaky problems that come up, and a bunch of vb/java/.net humps to crank out the business logic. We can't all be Einstein, can we?
love is just extroverted narcissism
Neal Stephenson talks about something similar in In the Beginning was the Command Line. He calls it interface shear; he's specificially referring the the UI as an abstraction (an interesting idea in itself). His take on it was that abstractions are metaphors, and that "interface shear"/"leaky abstractions" occur in regions where the metaphors break down.
Interesting stuff...
So just to get this straight, next time I want to sort some data from a text file and output it, instead of using Perl, I should carve the algorithm into a block of silicon with a chisel instead? Good abstraction is good, because it lets people ship reliable products quickly. Bad abstraction is bad, but not as bad as bad C programming with pointers. And the 'knowing how it works' argument for low-level is generally spurious, because of emergent complexity: even if you know what every line of code in the Linux kernel does, predicting how a network of 100 LInux boxes will perform when running a particular mix of applications, for example, is impossible in practice.
Virtually serving coffee
So, the metaphor is fundamentally broken, but it is intuitive, which is more important.
-Peter
Just wondering, because he has the same ability to provide blinding insight into the obvious.
Damn, idealistic programmers need to get a clue. There's no such thing as abstraction.
The leaky abstraction is actually a good thing. We understand that as we layer programming code, inherently, the lower-layers are never going to be perfect. Hence, why we "bubble-up" error-handling.
I don't want abstraction to be universal constant. If problems occur in the abstraction, I want to be able to diagnose that. Just because the abstraction "leaks", that's a good thing. Sometimes a client-server app breaks because the network layer breaks, but we can make modifications, adjustments to fix the problem. If we couldn't, and this "leak" were permanent, we would throw up our hands and quit.
The author somehow is attempting to suggest that this imperfect-abstraction is hurting..something. But where is there perfect abstraction? I have yet to see one: the sky abstracts the universe from my environment, yet I still can get a sunburn.
Even God himself, tried to abstract human beings from evil, and that "leaked" as well.
So we shouldn't define this as "leaky" abstraction, but rather as "flexible" abstraction.
"This isn't a study in computer science, its a study in human behavior"
A couple of the "leaky" abstractions he lists don't. A defining characteristic of a non-leaky abstraction is that it takes the limitations of the underlying devices / protocols / whatever into account. For example, I'll take his TCP analogy: it does NOT guarantee reliable transmission. What it guarantees is that the data the arrives will be in the correct order, and byte-correct, OR that the transmission will time out. The abstraction that leaks is the human (e.g., Joel) thinking that TCP guarantees reliable communication.
I think the article is great. And this principle can also be applied to Math. Theorems are much like library function calls. You can use them in your own proofs, without caring about how they are proved, because someone has already taken care of that for you. You prove that the hypothesis are true, and you get a result which is guaranteed to be true.
The problem is that in real Math, you often need a slightly different result, or you cannot prove that the hypothesis are true in your situation. The solution often involves understanding what's "under the hood" in the theorem, so that you can modify the proof a little bit and use it.
Every professional mathematician knows how to prove the theorems that he/she uses. There is no such thing as a "high-level mathematician", that doesn't really know the basics, but only uses sophisticated theorems in top of each other. The same should be true in programming, and this is what the article is about.
The solution? Good education. If anyone wants to be considered a professional programmer, he/she should have a basic understanding of digital electronics, micro-processor design, assembly language (at least one), OS architechture, C, some object oriented language, databases... and should be able to understand the relationship between all those things, because when things go wrong, you may have to go to any of the levels.
It's a lot of things to learn, but there is no other way out. Building software is a difficult task and whoever sells you something else lies.
In physics the abstractions leak. Newton's laws leak like crazy. Einstein's theories leak. Presently there are no fundamental theories in physics which don't leak like crazy when quantum mechanics and gravity interact.
In sports the abstractions leak. That's how we get players like Gretzky and pay a lot of money to watch what they do.
And how about the reason why didn't C++ didn't define a native string type. Because there isn't any way to implement a string class that serves all possible applications. The premise of C++ is not being stuck with someone else's choice on what part of the abstraction should leak. Because C++ doesn't define a native string type, the user is free to replace the default standard string implementation with any other string implementation and have it integrate with the language on an equal footing with the standard string type.
If a language is imposes standard abstractions it only takes one abstraction you can't live with to make that choice of language untenable. Which is how C++ has been so successful despite being the worst of all possible languages (except for all the others).
He mistakenly confuses a generally accepted "definition" of TCP with a true abstraction.
The example of the array iteration is nonsense. Or tell me where I have to deal with page faults in e.g. my Java programs.
Speed has _nothing_ to do with abstractions. What is he talking about ? Hide SQL behind an abstraction, and use something else when SQL is dogslow.
NFS and Samba, same as TCP. That happens when you work with networks Joel, things can go wrong !
Then he discovers that C++ isn't the perfect language. In other news, scientists discovered that grass is green sometimes. He simply assumes that strings in C++ are good abstractions and the says they suck. Well yeah, they sucks, simply because they aren't good abstraction.
Can somebody please teach this guy what an abstraction is ?????
No matter how high-level your picture, that devil is stil lurking below in the details to bite you when he can.
In fact, the quote "the devil is in the details" sums up the entire article.
... is whot bwings os tugevza tsuzay.
Interesting that this article hit #1 on the blogdex a few days ago, and has since fallen off the chart.
Interesting links there now are Republican commentary from The Onion and a frightening NY Times article on the "virtual, centralized grand database" the new Homeland Security Bill the House just passed would create.
I agree with Joel, but some people seem to be taking it as a call to stop abstracting. That's silly.
Humans form abstractions. That's what we do. If you abstractions are leaking with detrimental consequences, then it could be because the programming language implementation you're using is deficient, not because you shouldn't be abstracting.
Try a high-performnce Common Lisp compiler some time. Strong dynamic typing and optional static typing, macros, first class functions, generic-function OO, restartable conditions, first class symbols and package systems make abstraction much easier and less prone to arbitrary decisions and problems that are really:
(i) workarounds for methods-in-once-class-rule of "ordinary" single-dispatch OO
(ii) workarounds for the association of what an object is with the name of the object rather than it itself (static typing is really saying "this variable can only hold this type of object", dynamic typing is saying "the object is of this type". Some languages mix these issues up, or fail to recognise the distinction.
(iii) workarounds for the fact that most languages, unlike forth and lisp, are not themselves extensible for new abstractions
(iv) workarounds for the fact that one cannot pass functions as parameters to functions in some languages (doesn't apply to C, thanks to function pointers - here's where the odd fact that low level languages are often easier to form new abstractions in comes in)
(v) workarounds for namespace issues
(vi) workarounds for crappy or nonexistent exception processing
Plus, Common Lisp's incremental compile cycle means faster development, and it's defined behaviours for in place modifications to running programs makes it good for high-availability systems
I liked the article, but I followed the link to strings are hard and I wasn't so impressed with the guy. To quote"
As every compiler writer knows, lexing and parsing are the slowest part of compiling.
How about optimizing compilers? I find I get performance hits when I turn on optimizations in gcc when I specify -O3 as opposed to -O0. Somehow, I doubt it's a result of lexing or parsing.
It's a gross generalization and I strongly suspect that sort of thing permeates all his writings, given that he spouts off on XML in the aforementioned article as well.
Woz
I think "fundamentally broken" is an overstatement. TCP/IP and the "actor transportation" metaphor have the following in common:
-The low-level transfer is unreliable: things might come thru damaged or not at all, and things might not arrive in the order they were sent.
-A higher level management system deals with transmission failures by requesting retransmissions as needed. It also deals with ordering problems by holding onto things and putting them in the right order.
No metaphor is ever a perfect fit, but this one is a pretty good one, if you ask me. I think that even non-technical types generally understand that you can make arbitrarily many copies of information (they understand Xerox machines, for example), so I don't think this one failing greatly compromises the overall teaching usefulness of the metaphor.
Back in the '70s, there was a BBC series called "Connections", created by a man called James Burke. The premise of the series was that we live in a technological society in which most people do not understand the technology upon which it is based.
What the author of this article is stating is a specialized case of James Burke's "technology trap". From the outside, the technological device seems to work like magic, until it breaks. A code abstraction can break just like an elevator, and leave you stuck.
All technology derives from earlier breakthroughs. The elevator is an abstraction of pullys, electrical circuits, software, and what not. In a simular fashion, software models are built upon other models. Like the technology of day to day life, it is no longer possible to know everything. The elevator repair person can fix an elevator, but he cannot fabricate an electric motor (within a reasonable amount of time).
Developers are in the same world. Your average developer can create GUIs, business objects, models of complex business processes, but it is impractical to know the whole interworking of the OS, of COM, or even the compilers.
As software engineers, we should understand the principals involved. Know the high level design and opperation of the system. Become experts in the systems that we utilize daily. It's not important for every programmer to know how to the Windows messaging system works, or the CLR works. It is important that they have an understanding of the way it works, and that there are people who know the true compexities.
I alway try to be the one who knows the inner complexities. That information can get you out of a lot of trouble quickly, and help one's colleagues who don't have the same depth of knowlege. However, I cannot hope to know everything, but I know other people have experience in things I may have trouble with.
Within an organization, we are a society. Like people in day to day life, everyone specializes in something different. Our society works because we cooperate to build something greater than the sum of its parts; however, we have enough routing in the fundamental principals to dig ourselves out of the technological trap if we need to.
"1) Good! You got yr packet!"
It seems like your keyboard keeps dropping packets. Could we have a repost of this comment?
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I submit that your "foo" + "bar" example, or variations on that theme, will continue to separate the wheat from the chaff in IT for the foreseeable, pre-Terminator, ante-dystopian apocalyptic meltdown future.
Resistance is feudal.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
This is a concept or insight that I think trancends computer programming, and could also be applied to human social systems (ie, economics, democracy, insurance,international relations).
The main point is, these concepts that we think of as 'real' are abstractions, models that we use to order and simplify reality. But models are never perfect, and when reality pokes through, the model breaks down, people that are too slavishly loyal to thinking within the confines of the model will not be able to perceive reality, and act accordingly to fix the problem.
I would submit to you as an example the New Deal. The abstraction of
economics is useful inasmuch as it keeps people happy and satisfied, gives them goals in life, and a unit by which to measure themselves. But when the system breaks down, and people are starving, staying loyal to the
dictates of the model as it was understood (the Republicans of the 30's) misses the point. The model doesnt have any inherent worth, it is good only in how it makes people better able to live stable lives. Rosevelt saw this, and gave people jobs doing public works even though the market would not allocate any resources to it. People became happier, but the Republicans went berserk because they were loyal to the model, it was reality to them, and it was blasphemy to violate the tennants of their abstraction. I think it is important that people
realize the ephemeral nature of all the abstractions that too often dominate our thoughts and lives.
When told to convert Fortran code over to C (over a million lines) I knew it was going to take me forever. f2c doesn't work in this case since the code is soooo messed up to begin with. So, I found myself doing repetitive conversions over and over again that are specific to the code base.
Solution:
Created a perl script that translates parts of it for me and highlights the rest that has to be hand changed and looked over.
So, to solve one probem I created a slew of more problems with the script freaking out and messing up code.
So far though, it's saved me every bit of that time that I would have spent working on tedious simple stuff. Which in turn allows me to post to Slashdot more!!!!
Hey, thinking about it, the Baldwin family *is* a cluster of Hollywood actors. Try sending them from East to West coast. I bet that at least one of them will arrive.
Signatures are for stupids.
Don't fix what ain't broke. You would have saved even more time (And bugs!) if you just let the Fortran be. Seriously.
Reading the article, I get the feeling that Joel has gotten used to more leakiness in his tools (Visual Basic, MFC, C++ AFAIK) than he should have. Let me explain:
Consider two imaginary libraries: Really Nice Library (RNL) and Mostly Crufty Functions (MCF).
Both expose some unavoidable leakiness when a) the abstractions don't fit your problem, or the really *is* at that lower level, or b) you are forced to consider the performance characteristics of the lower level, which the abstractions cannot hide.
In addition to that, MCF adds some more leakiness of its own: buggy implementation, bad assumptions, a badly designed interface, common cases not covered by abstractions etc. etc.
When there's leakiness of the first kind, Joel is right: the programmer should be capable of solving the problem at the lower level (and the tools should make it easy for him to do so).
But when you keep experiencing a lot of leakiness of the second kind, maybe you should go looking for a better set of tools. Life's just too short...
Stupidity is mis-underestimated.
While I usually like Joel's work, I'm pissed about the random jab at C++. For those he didn't read the article, he says something along the lines of
"A lot of the stuff the C++ committe added to the language was to support a string class. Why didn't they just add a built-in string type?"
It's good that a string class wasn't added, because that lead to templates being added! And templates are the greatest thing, ever!
The comment shows a total lack of understanding of post-template, modern C++. People are free not to like C++ (or aspects of it) and to disagree with me about templates, of course, and in that case I'm fine with them taking stabs at it. But I get peeved when people who have just given the language a cursory glance try to fault it. If you haven't used stuff like Loki or Boost, or taken a look at some of the fascinating new design techniques that C++ has enabled, then you're in no place to comment about the language. At least read something like the newer editions of D&E or "The C++ Programming Language" then read "Modern C++" before spouting off.
PS> Of course, I'm not accusing the author of being unknowledgable about C++ or anything of the sort. I'm just saying that this particular comment sounded rather n00b'ish, so to speak.
A deep unwavering belief is a sure sign you're missing something...
Loved this article. Sent it on to my manager and a co-worker.
.NET effectively. Unless one understands some of the underpinnings of this NEW technology, you actually can't take advantage of it. Throw in the generated code issues and the IDE, an abstraction of an abstraction, really is disadvantageous.
One thing I liked especially is the danger of the Shiny New Thing. It may be neat and cool and save time, but knowing how to use it does not mean that you can do anything else - or function outside of it.
Right now I'm on an ASP.NET project - and some ASP.NET stuff I actually like. But the IDE actually makes it harder to program responsibly, and even utilize
A friend of mine just about strangled some web developers he worked with as they ONLY use tools (and they love all the Shiny New Ones) and barely know what the tools produce. This has led to hideous issues of having to configure servers and designs to work with their products as opposed to them actually knowing how they work. The guy's a saint, I swear.
I think managers and employers need to be aware of how abstract things can get, and realize good programmers can "drill down" from one layer to another to fix things. A Shiny New Thing made with Shiny New Things does NOT mean the people who did it are talented programmers, or that they can haul your butt out of a jam when the Shiny New Thing looses its shine.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Almost all C++ string classes overload the + operator so you can write s + "bar" to concatenate. But you know what? No matter how hard they try, there is no C++ string class on Earth that will let you type "foo" + "bar", because string literals in C++ are always char*'s, never strings.
I found out that some PHP library functions (empty, isset, etc.) are not really functions, but "language constructs". They ONLY take variables as arguments. You cannot pass function results, constants, and IIRC expressions.
Appearently they married something to C or C++, ruining the "substitutability rule" of programming.
I couldn't believe my eyes. PHP is supposed to be a "scripting language", not a C++ preprocessor. That kind of shit just makes ASP look competative. Please don't completely kill MS because OSS will then feel free to expose and force-feed even more archaic C-family ugliness in its languages.
If it is done for speed purposes, then perhaps have an interpreter switch somewhere that lets one choose between "normal acting" functions and a crippled-but-fast option. (Normal being the default.)
Table-ized A.I.
The problem that Joel talks about is not really a problem with abstraction, it is a problem with teamwork. When I program I simply can not do all of it myself for all but trivial projects. By everything I mean write the compilers, write the OS etc. Instead I must rely on other programmers to write large portions of the code that I run. Whether it is the guy across the hall who wrote the search contact Stored Procedure in SQL or a programmer at microsoft writing a windows Disk IO function, I am relient on their code working as I think it should. This is the problem with teamwork but there is no other solution to programming modern applications. Martin
Maybe I'm an old fashioned has-been but people doign software development should understand the fundamentals of how computers work. That means that they should understand things like memor management, they should understand what a pointer is, they should undertsand about how tight loops versus unrolled loops might affect the performance of the caches on their system. I meet so many "programmers" that have no understanding that there are architectural constraints on what they can and can't do. Software runs on hardware. If you're going to write software and treat the hardware as a black box, you're not going to write it as well, or as efficiently as you could be doing it.
From the article, he talks about all of these software tools that he knows: All high level tools compared to the old K&R stuff, but I still have to know the K&R stuff or I'm toast.
(By K&R stuff he is referring to C and pointers.) This is a very good point. Many universities are choosing to teach Java as the first programming language- even to CS majors. This is fine, but it might be very important to learn C++ before becomming an expert in Java, otherwise there could be a tremendous hole in your knowledge, and you won't even realize it. So, if the first language or tool you ever learn is one that does not include all the fundamentals, such as pointers or memory management, make sure you learn these before embarking into the real world. It would be a sad day indeed if an advanced or expert programmer does not understand pointers.
I can't drive as fast when it's raining... Life's not fair!
Now I always consider performance when designing/writing code, but programmers are WAY more expensive than hardware, so eeking out performance can often be a wasted effort. Everyone knows that C will smoke Java in most operations, but having its so hard to manage at the enterprise level that you are much better taking the 50%+ performance hit and writing in a "leaky" language.
This is not the greatest sig in the world, this is just a tribute.
Looks like he just discovered and renamed the basic idea that "all models are incomplete". Any scientist could tell you that one! I remember a quote that goes something like this: The greatest scientific accomplishment of the 19th century was the discovery that everything could be described by equations. The greatest scientific accomplishment of the 20th century is that nothing can be described by equations.
That's all an abstraction is: a model. Just like Newtonian physics, supply and demand under perfect competition, and every other hard or soft scientific model. Supply and demand breaks down at the low end (you can't be a market participant if you haven't eaten in a month) and the high end (if you are very wealthy, you can change the very rules of the game). Actually, supply and demand breaks down in many ways, all the time. Physics breaks down at the very large or very small scales. Planetary orbits have wobbles that can only be explained by more complex theories. Etc.
No one should pretend that the models are complete. Or even pretend that complete models are possible. However, the models help you understand. They help you find better solutions (patterns) to problems. They help you discuss and comprehend and write about a problem. They allow you to focus on invariants (and even invariants break down).
All models are imperfect. It's good that computer science folks can understand this, however, I don't think Joel should use a term like "leaky abstraction". Calling it that implies the existence of "unleaky abstraction", which is impossible. These are all just "abstractions" and the leaks are unavoidable.
Example: if I unplug the computer and drop it out of a window, the software will fail. That's a leak, isn't it? Think of how you would address that in your model: maybe another computer watches this one so it can take over if it dies..etc..more complexity, more abstractions, more leaks....
He also points out that, basically, computer science isn't exempt from the complexity, specialization, and growing body of understanding that accompanies every scientific field. Yeah, these days you have to know quite a bit of stuff about every part of a computer system in order to write truly reliable programs and understand what they are doing. And it will only get more complex as time goes on.
But what else can we do, go back to the Apple II? (actually that's not a bad idea. That was the most reliable machine I've ever owned!)
However, the best abstractions are those that plug the leaks or at least keep them to a drip rather than a stream. Automatic garbage collection for plugging memory leaks is a good example. Perhaps this is the main reason why I like Perl and Java. Of course, you still get into trouble, but the programs are much easier to debug without all the code tracking and freeing up storage.
But you know what? No matter how hard they try, there is no C++ string class on Earth that will let you type "foo" + "bar", because string literals in C++ are always char*'s, never strings.
WTF? Has he never heard of temporaries? I don't understand this point at all.
Dahlmann tightly grips the knife, which he may have no idea how to use, and steps out into the plain.
The law of insubstantial software development paradigms.
haha! It also seems like the messages from the keyboard are arriving out of order! (read the first 5 words of the original post... you see what I mean)
No, unfortunately, that is simply my brain dropping packets destined for my fingers.
Tis a shame, really.
In the future, I would want to not be isolated from my friends in the Space Station.
Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn't, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can't do anything about it and your message doesn't arrive. If you were curt with the system administrators in your company and they punished you by plugging you into an overloaded hub, only some of your IP packets will get through, and TCP will work, but everything will be really slow.
This is what I call a leaky abstraction.
On the surface it looks like an almost reasonable way to describe the situation, but when you look closer, you realize it's mish-mash written to look smarter than it is.
Imagine, addign to teh example above, you were to flip off your computer, or pour a cola directly on the motherboard... at that point ALL programming would cease to function. All computer code exists at a level of abstraction, even when you are programming in machine language you are still abstracted to some degree away from the hardware...
But that is actually the POINT of computers. Abstraction is what gives computers thier strength. It's what allows machines to be programmed to do vastly complex things without requiring a vastly complex piece of code.
All his examples are simply whining that X program can't function when Y event happens. Javascript can't run when JS is turned off in the browser, c++ won't let you add two string literals together, some SQL queries are slower than others...
None of these are inherant faults with abstraction, they are specific instances of poor implementation, instances that can and probably should be fixed. Instead of looking at one flawed analogy and saying that analogies as a argumentative tool are all inherently unusable, you should fix the flaw in that one analogy and use it.
"Your superior intellect is no match for our puny weapons!"
While you are slamming ``liberal arts'' -- a term you seem not to understand -- you highlight the need for it. Liberal arts does not imply a non-scientific, non-technological education. It implies a broad education, including science, mathematics, and engineering along with the ``traditional'' topics of history, literature, languages, politics, economics, and arts. For politics, governance, and management, I want people who are conversant in all of those topics.
Unfortunately, the subjects you list have all grown to the point that no human can obtain even a BASIC understanding of all of them before he's too old to have a useful carreer left.
It was once possible to be a "Rennisance Man" - a master of ALL the sciences and arts reduced to teachability. No more. It's just too bloody large. (I say this as someone who attended a univerdity that claims to try to produce such people - centuries after the last of them is dead. B-) )
Unfortunately, "Liberal Arts" schools have, over much of the last century, been filled with the mathematically and technically illiterate - both because the students without the necessary skills gravitated there, and because the faculties themselves were so disabled, and in turn disparaged the skills they were incompetent to teach.
The engineering/scientific/biologic/technical cirriculum had constant feedback from the real world about what was true and what was false. But the "Arts Schools" taught classes where what was "right" was ONLY a matter of opinion - and grades solely a measure of how well you could regurgitate your Prof's pet bonnet-bees. (This DESPITE the fact that SOME of these theories could be TESTED - if only the academics understood, and/or believed in, things like the scientific method, statistics, and sampling methods.)
Yes the "Social 'Sciences'" are hard. But the bulk of their credentialed practitioners used this as an excuse to drop "science" from their methodologies. (This despite that fact that mathematics departments were generally part of the art, rather than the engineering, side of the school organization.)
I've been out of academia for a while now. I can hope that things have improved, as you seem to claim. But I have not personally seen any sign of such from the outside (other than your claim).
In my school days, too, many students on the Arts side of the wall knew tech, math, and the like. (Students are generally young, and still hunting for their muse.) But they would generally transfer out to some field more conducive to clear thought, drop out to use it in the real world, or (if they stayed in LS&A) suppress it or flunk out.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
No one would cut a lawn with scissors
:)
You'd be surprised what people will cut lawns with. In Brasilia (Capital of Brasil) the standard method of trimming lawns is to use a machete. No, I'm not talking about hacking down waist-high grass, I'm talking about trimming 3-inch high grass down to two inches by hacking repeatedly at it with a machete, trying to swing parallel to the ground as best you can. No, you don't do this yourself, you hire someone to do it. And if you're a salaried groundskeeper, it makes sure that you always have something to do - you woldn't want to be found slacking off during the day. On rare occasions I've seen people using hedge trimmers (aka big scissors) instead. My family was the only one I knew about in our neighborhood that even owned an American-style lawn mower. My parents were too cheap to hire a full-time groundskeeper, and I have lots of brothers and sisters who work for free
Moral of the story; if it works and fits the requirements better, someone will do it.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
The map is not the territory?
This is not a pipe?
Besides which East Africans robbed what? Remember, East Africa is near India or Palestine, depending on where you live...
I know we shouldn't hold this against this guy, that he worked for Microsoft -- I myself could have made such mistake when was younger, but please, no new names for old things, ok? Don't innovate the way M$ does.
And get a new shirt -- that one is disgusting!
As a techwriter, this article is of immediate use to me. Among the companies at which I've worked, there's been a growing movement away from providing explanatory documentation, and a movement towards procedural documentation. I've been running into particular problems documenting our API, which is intended to be used by relatively novice programmers working for law offices or large companies with legal departments. It's been difficult trying to convince the developers why we need to explain the interaction between our UI layers, our functional layers, and our security layers; they are of the opinion that the whole point of our providing these APIs is to prevent clients from having to examine our system's architecture. But what if the client wants to add a non-standard UI component, or impersonate a different user with different rights?
So the question is, is documentation the answer to the abstration problem? If we always present a cohesive view of the reasoning and implementation of the abstraction in documentation, can this forgive any leaks we may produce?
If you want to talk, your ability to think abstracts all the individuals motions required to talk, such as moving your lips and your mouth, and exhaling from your lungs to generate the sound. If you have a lot to say, and you don't take a deep enough breath, you can't finish your sentence. If you haven't drunk any water for the entire day, and your mouth is parched, you can't talk properly. THIS ABSTRACTION IS LEAKY!!!
OF COURSE IT'S "LEAKY"!!! AN ABSTRACTION ISN'T MEANT TO BE A COMPLETE SUBSTITUTION FOR WHAT YOU ARE TRYING TO ABSTRACT!!!
As long as your abstraction is based on something else, of course there's going to be dependencies.
If you drive a car, the car is an abstraction, but when you run out of fuel, you need to deal with the fuel system, ie. fill up the gas tank. Oh no! Now ordinary humans have to not only worry about driving, but have to understand that engines need gasoline to power the engine! THIS ABSTRACTION IS LEAKY!!!! Of course it is, idiot, but who cares?
Basically, what this author wants is for the interface or abstraction to always work, no matter what. He wants a car, when it's running out of gas, to automatically fill it up itself, so that we don't have to worry about this leaky abstraction. When the TV cable gets cut, he wants the TV to remotely attach another cable, or possible switch over to a backup satellite signal so that we don't have to worry about the details.
When Homo erectus used a stone to create tools and weapons, the tool became an abstraction. But what if he used the wrong type stone, and it broke when he used it? OH NO!!! IT'S A LEAKY ABSTRACTION!!! How will Homo erectus ever survive the weight of all these leaky abstractions??? Surely having to worry about the details of what type of stone he uses, or what type of wood to create shelter, or what animals to hunt because of their particular nutrients, will be so great that he won't be able to survive and pass on his genes!!!
WHAT WILL WE DO BECAUSE ALL THESE LEAKY ABSTRACTIONS ARE DRAGGIN US DOWN!!!!
Fucking deal with it, asshole, that's what. How stupid do you think we are?
That's the sort of mentality people around have kept and I'm paying for it now as well as they are through their pockets.
Becuase it is broke! We're migrating over to 64 bits and using an integer the way they used them causes the system to crash
Very interesting story. It seems anything you could call a tool is an abstraction. The very nature of language is abstraction. Only God can accomplish something without abstractions, although even he might not want to go to all that effort.
Donate background CPU time to fight cancer.
Apparently you never had a liberal arts education. A large part of its function is to teach you to baffle with bullshit and debate based on form and not substance.
That is to say, engineers are not in any way similar to liberal arts majors, as you can't fool mother nature.
many high level abstractions simply do not exist in assembly language.
Consider the following assembly language code:
Okay, so this is a little snippet of some assembly language I've just recently worked on. Here's the declaration for the input file:
That's it. Is this readable? Is it abstracted at a level high enough? The primary difference between assembly and a HLL is that in assembly one must invent their own logical abstractions for a real world problem, where languages such as C/C++ simply provide them.
You've probably noticed that I'm using a lot of macros. In fact, classes, polymorphism, inheritance, and virtual functions are all easily implemented with macros. I'm using NASM right now (though I'm using my own macro processor), and it works very well. Because I understand both the high-level concepts and low level details, I can code rather high-level abstractions in a relatively low level language such as assembler. I get the best of both worlds: the ease of HLL abstraction with the power of low level coding.
Please tell me what you think of this - I would honestly like to know. For the past few years, I've been working on macro sets and libraries that make coding in assembly seem more like a HLL. I've also set rules for function calls, like a function must preserve all registers, except those which are used to pass parms. With a well developed library of classes and routines, I've found that I can develop applications quickly and painlessly. Because I stick to coding standards, I'm able to reuse quite a bit (> 50%) of my assembly code.
You might be tempted to ask, "Why not just write in a HLL then?" I do. In fact, I prefer to write in C++. But when the need arises, it's nice to be able to apply the same abstractions of a HLL in assembly. It just so happens that the need has arisen - I'm working on a project that will last a few weeks, and my boss doesn't consider it fiscally responsible to buy a $1200 compiler that will be used for such a short time.
Interestingly, the use of assembly has made me a better programmer. Assembly forces one to think about what one is doing before coding the solution, which usually results in better code. Assembly forces me to come up with new abstractions and solutions that fit the problem, rather than fitting the problem into any given HLL's logical paradigm. Once I prove that the abstract algorithm will indeed solve the problem, I'm then free to convert the algorithm into assembly. Notice that this is the opposite of the way most HLL coders go about writing code - they find a way in which to squeeze a real world problem into the paradigm of the language used. Which leaves them at a loss when "leaky abstractions" occur. Assembly has the flexibility to adapt to the solution best suited to a problem, where as HLL's, while very good at solving the particular problem for which they were designed, perform very poorly for solving problems outside of their logical paradigms. While assembly is easily surpassed by C/C++, Java, or VB for many problems, there are simply some problems that cannot be solved without it. But even if one never uses assembly professionally, learning it forces one to learn to develop logical abstractions on their own - which in turn, increases their general problem solving ability, regardless of the language in which they write.
I see the key difference between a good assembly coder and a HLL coder is that an assembly language coder must invent high level abstractions, where as the HLL coder simply learns and uses them. So assembly is a bit more mental work.
The society for a thought-free internet welcomes you.
Spolsky's such a nob. He simply relays the water-downed thoughts of truly original thinkers.
If you really want to learn about "leaky abstractions" and a bunch of other topics, including human cognition, complexity, economics, and engineering design, read Herbert Simon's "The Sciences of the Artificial".
His abstraction of the world leaks, since all abstractions are not the same, and the world in which they are created dictates how much they must leak, at minimum.
Let me give an example: You want to use lazy evaluation, and you are using a strict language. You have two choices (given your language supports lambda-functions and closures); either you create a primitive to delay the evaluation of an expression, and one to force such a delayed evaluation, or you implement an interpreter for a little lazy language. The former abstraction definitely leaks, as you will have to remember to manually force values before acting uppon them with the primitive functions of your language. The latter one, though, does not leak (at least not in this respect), as the language you created is totally unaware of the language in which its interpreter is implemented.
--The knowledge that you are an idiot, is what distinguishes you from one.
Did anyone else read this and say "duh! oh course".
"Abstraction" does not mean "Perfect Model".
If that was what it pretended to be then this article would be a big deal.
I dont think anyone pretents that programming abstractions, or any of the many other models used in technical work, are perfect. A high percentage of the time they are easier and quicker than reinventing the wheel. But when the wheel that comes prepackaged just cant handle the job you need it to do, then you DO reinvent it.
Duh,
Scott.
Even if higher-level abstractions were perfectly bug-free and non-leaky, there is another tradeoff that would forever preserve the niche of lower-level development tools. The granularity of the abstraction is an inherent tradeoff not just in machine time/efficiency, but in programmer learning curve as well.
Geeky modern art T-shirts
Hey, you know the idea of "bits" is really an abstraction of the on/off electrical signals present in the cable. If the cable fails (My snake has chewed through it), then the abstraction leaks through (No cable means no electrical signals. No electrical signals means no bits!).
I am astonished at the number of people here who have either failed to understand Joel's point at all, or those who think the essay is about TCP and IP. You should all stop watching MTV and go back to High School. Seriously.
The software field is notorious for employing people working whose course of study has been analogous to learning Newton but not learning that there are conditions under which that isn't sufficient. I am not in favor of requiring licensing for all software developers, but there are reasons that states do not allow people to, for example, hire themselves out to do bridge design unless they have demonstrated certain minimum training and competences.
why the hell is he talking about TCP being 'reliable' and IP being 'unreliable' when TCP is a transport protocol and IP is a routing protocol? i kept wanting to plug in 'UDP' for every instance of 'IP' when i was reading his article, and couldn't get very far down it because he was driving me up a wall. i'm all for writing up easy to understand explanations of things, but that was a wildly inaccurate way to easily explain it.
< Today, I won't even go near a programming language lower than C and I like Python much better.
So if programmers don't need to know assembler any more what does this tell us? C's abstractions are not significantly leaky. And as compilers get better and better, higher and higher level abstractions will be leak resistant. A great example is OCaml: a very high-level language that still manages to perform [almost] as well as C.
My point: this article is good and all, but it's hardly the final word.
I take large issue with this article, primarily
because he almost completely ignores that some
abstractions work much better than others. I'll
allow that all abstractions are leaky, but certainly
to greater and lesser degrees. C++ is quite leaky
because it is so poorly designed; contrast it with
Eiffel or LISP. Microsoft's visual tools are so
leaky because they've done such a poor job of
creating the abstraction layers below them. Contrast
them with with NeXT/OSX's IDEs; there is no small
difference.
It's often been said that a good programmer is
able to think at multiple levels of abstraction
simultaneously. The cleaner the abstractions,
the fewer you need to grasp at once and the longer
you'll be able to stave off the effects of the
Haire (sp?) Limit (7+-2).
Abstractions might all leak, but there's a hell
of a difference between a drippy faucet and a
water main burst.
1. There is no spammer an existance who found it necessary to learn IP directly to optimize his/her "performance". Some abstractions are just good enough for everyone.
2. An abstraction may have many different implementations. Knowing details of just one doesn't solve the problem. For example, an associative array could use a hash table or a binary tree. Studying one implementation will not help me much to optimize performance under the other one.
3. When your pipes leak, you usually call a plumber. When you assumption leaks, you can call technical support of people providing it to you. This doesn't mean that it's worthwhile for most users of the assumption to know how to plumb themselves.
Why people need to know assembler then? Well, programming C/C++ is like having a model in which every car is missing major parts and no two are the same (different platforms/compilers). You are forced to "assemble" missing parts yourself. In addition, it crashes every time you make a wrong turn and the only way to find out why is to examine "parts" exposed during the crash.
On the other hand, I have written Java code that is reused between J2ME and J2EE (network protocols!). I don't know how the underlying OSes of various cell phones and app servers implement HTTP or threads and believe me, I don't want to know. If something doesn't work, I'll get on the phone and demand that the abstaction I use be freed of leaks and insects.
I'm not a professional SQL programmer, though I've dabbled, so I'd really like to know why this is true. Is it because in the first case, the interpreter can compare all three variables at once, instead of in two different steps in the second case?
Could someone please explain?
Jon Acheson
All opinions expressed herein are my own, and not those of my employers, who are appalled.
Its the only way to stay sane. If it helps, try to think of Slashdot as a Shakespearean Comedy.
That Joel! Always coming up with catchy phrases for concepts that his betters have already published papers on. See David Keppel's 1993 paper for a more thorough explanation, complete with lack of baby-talk.
Quit playing Monopoly with Bill. Switch to one of many non-Microsoft products today.
That guy has a strange idea of moral equivalece. I still don't see the magic, though.
It's called job security. What else do I have to do? I know that it will create hundreds of bugs. The best part is that it is part of an advanced and very touchy calculus system that I have no clue about. Oh, and I'm a first year employee. Mahahaahahahaha! Nothing like cutting your teeth the proper way.
I would prefer them to use C style expressions rather than wierd [] thingies.
And many of the bugs I have had in the last few weeks would just not appear in high level language, e.g. if you branch past an instruction that changes the CPU register sizes.
I'm not a big x86 fan, but don't they usually use ebx these days instead of bx?
The sole point of programming language abstractions is to let the programmer selectively forget things. The programming projects have grown in scope and size in recent decades (remember the old law: programs tend to grow in size until they can read mail). If modern large-sized applications (I'm speaking of tens of thousands LOCs in Java here) were written in assembly, no programmer on earth would be able to grasp the project. When a routine would be written in one part, two others would be lost in some other point in the program.
OO programming was made to deal with the problem. Strings or other "leaky abstractions" are meant to let the programmer concentrate on the real problems at hand without worrying about details. Same thing goes with capsulation: the programmer can forget the internal representation of an already done class, and use accessors to manipulate if. Thus more complex applications can be made. Think about programming an AI implementation in a low-level language instead of LISP/Prolog, and shudder.
Assembler and other low-level languages have still one function: optimization. One percent of code is run for 90 percent of program running time (think about 3D engine in a FPS), and optimizing this one percent can boost the performance a lot. However, with the advent of better compilers, the need of manual optimization diminishes, and many even argue that premature (pre-compiler) optimization is the root of all evil.
- Ismo
It's useful to distinguish between performance-related leaks and correctness leaks. SQL offers an abstraction for which the underlying database layout is irrelevant except for performance issues. The performance issues may be major, but at least you don't have to worry about correctness.
C++ is notorious for this; the language adds abstractions with "gotchas" inside. If you try to get the C++ standards committee to clean things up, you always hear 1) that would break some legacy code somewhere, even if we can't find any examples of such code anywhere in any open source distro or Microsoft distro, or 2) that only bothers people who arent "l33t".
Hardware people used to insist that everything you needed to know to use a part had to be on the datasheet. This is less true today, because hardware designers are so constrained on power, space, heat, and cost all at once.
Shouldn't a programmer that wanted to be most efficient start with the highest level of abstractions and work his/her way down as needed?
Abstraction brings effeciency (not in raw cycles but in programming time), portability, and other freedoms. In java, the hardware itself is abstracted so that buffer overflows and other security concerns aren't a problem. C programmers blame buffer overflows on poor programming. I have to ask myself who these people are. If they are so good, then they must have some popular program, right? A program like Bind or Sendmail, perhaps? Even the linux kernel has had buffer overflows.
Abstraction doesn't cost much by the way of performance. Java's abstraction is down from it's initial 1600% to 200% the speed of C. During that time C has went from it's 200% of assembler to closer to 100%. It's reasonable to foresee in the future that any abstraction, even those so severe as the JVM, will eventually aproach native speeds through optimized compilers/JIT/AOT.
The best thing about abstractions in the open source world is that a group of people who use these everyday will be the one's developing them. They will address the issues that matter to developers, and they will only need be addressed once. You don't have to reinvent the wheel when you design your car. If someone makes a better wheel, it's very likely that you will benefit from it if you use an abstraction.
Imagine the nightmare of converting to IPv6 if most people didn't use (at least portions of) the BSD TCP/IP stack??? Compare that to the trivial gains you get by not using it! What if all programers decided to use raw sockets to remove the leaky abstraction?
Fix the abstraction, don't abandon it. Have blocking TCP/IP sends (along side the others) for people that need to know if packets made it. You could just add a function to ask the system if the TCP packet had been sent yet (where sent really meant that an ack was recieved). You get to keep the interface. By the time the interface isn't leaky, you will have a large interface that performs all the tasks of the original, just in a more human comprehensible way.
Another advantage to abstractions is that they can be faster in the end. OpenGL is an abstraction. It's so popular that video card designers will work hard to make that abstraction as thin as possible. Now we have cards that support directly some or all of the functions. It's cross-platform as well because of it is an abstraction.
Don't abandon abstractions because they are slow or aren't all encompassing. Fix the leak, don't toss out the toilet.
Karma Clown
The subject of leaky abstractions applies to novice users as well.
I've felt for a long time that people are taught about computers the wrong way, and this article clarifies why this is true.
People are taught less and less about what the computer actually does, and instead focus on things like the desktop analogy, and task oriented training. The user must then remember all these seemingly strange things computers do that don't follow the abstraction they were taught. This makes them seem difficult and incomprehensable.
The problems created by abstractions intended for users can simply be solved with more complicated software that better models the analogy that the users are taught. Unfortunately, the opposite is probably true for programmers.
-Zaphod
As I see it, the problem with VB is not the high abstraction levels per se, but the fact that they are such lousy abstractions. Especially when it comes to controls. For example, look at the standard VB TreeView object. It becomes painfully clear that the VB derivation of this control was written with one narrowly defined purpose in mind, ignoring the fact that people might find many other uses for this control.
When using an OO language like C++, programmers move objects to a higher abstraction level all the time. That is why every good OO course teaches you to make your object's methods orthogonal and complete. In laymen's terms that means that the object operators should be sensible and generic. If you make an object which holds data that you wish to multiply by 5 and then add 2 to it, you don't make an operator that does just that. Instead, you make one operator that multiplies by x, and another that adds y.
Many VB objects ignore this rule, making operators for a specific purpose, that should have been generic instead, and not bothering to implement other possibly useful operators from a lower abstraction level.
When programming VB, I spend about 30% of my time programming around senseless limitations of and omissions from VB objects and controls.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Hear hear!
Not that Mr. Stephenson was the first to say it, but I _hate_ it when people make up their own 'laws' without checking to see if there's something equivalent out there.
I thought of one, I'll call it "Hubert's law":
"Entities should not be multiplied unnecessarily."
Oh wait.
Keep your packets off my GNU/Girlfriend!
TCP is an abstraction layer above IP, it sends IP packets, which the other side puts together to a TCP stream. UDP has nothing to do with TCP - it's just another protocol that uses IP to send packets.
Joel wanted to show IP as "one layer below" TCP, as TCP is based on IP. UDP has similar properties as IP, but TCP is not based on UDP.
The age old question (at least in the last few years), is abstraction really beneficial to software development? The answer is.......Yes.
Abstraction is good to an extent. The problems that most people bring up regarding abstraction I find to be more of problem with programmers rather than programming. There are always going to be more shitty programmers than good ones. It's the same in everything in life, there is always fewer good than bad.
Abstraction is awesome, it allows for me to think about things that can make my software better, faster, and rich with features while not having to concern myself with the nitty gritty bits and bytes all the time. I have no problem, actually I enjoy, digging into the code to fix obscure bugs and problems with a particular abstraction.
People always say programmers are lazy, I say it all the time. But the reality is good programmers aren't lazy. Good programmers take pride in their craft and are eager to learn everything about the language or environment they are working in. Good programmers benefit tremendously with good abstraction. Bad programmers use abstraction as a crutch to get things done, then complain when something breaks that they can't figure out.
One last point about abstraction. I have seen people take abstraction too far. There is a point at which abstracting any further handcuffs the programmer and creates too much overhead to make it worth it's while. I prefer to implement an abstraction only when I feel the cost of not implementing the abstraction is higher than implementing the abstraction.
Programming is an art, some are good some are not. Everyone has their own style that they prefer to work with and what works for some, can fails miserably for others. I fortunately work by myself most of the time so I have the freedom to almost always work in my world; so all is good.
Remember just because some people are out their abusing abstraction, as if it ever did anything to them, doesn't mean that abstraction is bad and we should never utilize that technique ever again.
LoRider
Good article. I'm reminded of a couple of bits of wisdom from The Pragmatic Programmer. The authors describe a condition they call "Programming By Coincidence", which occurs when a programmer somehow comes up with code that works, but doesn't understand the system well enough to be able to explain why it works, and is therefore unable to properly maintain or debug his code. Frequently, I tbink, it is the underlying abstractions that are misunderstood by the programmer.
The authors also refer to "Evil Wizards", which are code generators used by programmers who mindlessly employ the generated code, completely without understanding it. Personally, I consider various frameworks and libraries to be potentially "evil" in this sense as well.
Please donate your spare CPU cycles to help fight cancer and other diseases
I have never heard of Joel before, but he strikes me as an idiot. His premise is ridiculous. The logic he uses in criticizing TCP/IP, SQL, and C, C++ etc is not only flawed (TCP and IP perform different functions as a team approach to solving the networking problem, and have been doing a pretty good job at it for 30 odd years), but reflect a skewed perspective on computer science. Rather than have the due respect to the tools he uses to make a living, and their respective creators, he smugly suggests he could do it better. These tools are pretty neat and ingenious approaches to solving real world problems. They are not perfect, but have stood the test of time. Joel's article was nothing more than a press release about his new Foggy Creek Software product. He fails to mention that it too was built on at least some of these leaky abstraction layers. I tired of overly lubricated, intellectual masterbation from poseur arm chair quarterbacks of computer science. Sure he went out of his way to regale us with his credentials and unquestioned authority. Kind of reminded me Dennis Miller trying to be witty, wise, and urbane while feigning a passion for football. Computer science is not perfect, but attacking some of its truly most remarkable advances to promote some pussified bug tracking software makes it easy to be a consultant. I enjoy steering my clients away from hype and bullshit like this. Joel's nstead of writing weak articles or software to track the bugs of dumbshits who believe you should be able to develop software with wizards, why don't you try your hand at replacing TCP, IP, SQL, C, or C++ with a better solution?
I think leaky abstractions are why there are so many useless stupid java companies out there that build fancy-pants systems that supposedly make it easier for inexperienced programmers to generate applications. By the time you get their fancy pants software development system working, you realize you could've built your app just as quickly and easily without their crap, and with greater control, flexibility and customizability.
An acquaintance recently dissed me for saying it was important to understand SQL when building java information systems. He declared that any of the object-relational mapping tools on the market completely obviate the need to know SQL, a "low-level language". Yeah, RIGHT, junior.
Every now and then something actually useful like Ant comes along, but the truth is, the basic JDK has most of the great stuff built in. My destiny as a Java programmer is to build a minimum of clever reuseable tools, and a maximum of customized code for specific customer problems.
Some languages, such as Python, have language designers who prefer to plug leaks. They are very conservative about adding features to the core language. Most of the heavy lifting is done in the module and package libraries. One example of a seamless patch to a leak is the file abstraction in Python. The module provides and abstraction that allow the different formats for file names to be abstracted away. The differences between seperator characters on Windows, the Mac, and Unix are hidden from the programmer (They need to use the abstract interface to get this benefit, but the language design allows very portable programs to be written as a result of careful design such as this.) Another example of abstracting away problems is the work Tim Peters did on optimizing the sort function in Python. The python-dev email thread on the testing that went into making the function robusts is a facinating dialog between some very impressive programmers. The final result is a sort function that does not fail miserably and achieves very good performance when given almost sorted data.
While some leaks can still be found in Python, there plumbers are busy working on fixing them all. One of the current big headache is making Unicode characters appear to be a natural part of the Python language. There are some dark corners in the Unicode specification that makes it difficult to create an efficient implementation of a Unicode string abstraction, but the language developers are working hard to patch up the shortcomings of the underlying libraries and present a more pleasent experience to the Python language user.
The attention to detail by the language implementors is what make Python such a joy to use. Programming in the language is always fun and never a chore.
Here is my patch to the leaks in the article:
What i see in this article is a leaky abstraction of today's software enginering. As that it proves its content. I enjoyed it.
Damn straight! One of the biggest problems with Java is how types are arbitrarily built-in or not. I'm tired of wrapping my ints in Integers just so I can use them in collections and then getting their value when I need to do some math. Mind you, there'd be no problem if operators were overloaded so that I could just use Integer from start to finish. But of course with a built-in String class, there's less pressure for Java to support operator overloading (just as non-native strings encouraged the creation of C++ templates).
irony = metaphor == abstraction;
> I can be pretty sure that in my career I will never be required to develop in assembler.
Well if all you do is write Excel macros, that's probably true...
ActiveX is an important abstraction in the Windows world, and boy is it a leaky abstraction if there ever was one. I desperately want to know how ActiveX works at the low level, but Microsoft either doesn't want to explain it or won't explain it. Yeah, yeah, every Microsoft Press book starts with an explanation of IUnknown -- QueryInterface, AddRef, and Release -- but once they cover the basic mechanics of vtable interfaces the explanation is that some kind of miracle occurs and they you have have ActiveX containers and objects in their full glory, and don't worry your pretty little head worrying about how to roll your own, simply using the wizards (gosh how I hate that term for automatic code generation that obfuscates). Maybe Microsoft doesn't encourage going inside their abstraction because internally they are so baroque (i.e. ornate to no known functional purpose) or just plain broke. And yes, if you want to do one tiny little thing that is outside the scope (or perhaps the documented scope) of that abstraction, one spends hours banging one's head against the wall with Google and MSDN searches and software code experiments.
Nope. A 'hammer' is an abstraction of 'apply this amount of linear force to this surface area'.
Which itself is an abstraction of the entire network of force interactions between sets of interconnected particles, when force is transferred between them.
Which itself is an abstraction of the wave-particle duality of the universe.
Have fun!!!
-Hentai [in vita non pacem est]
"Did you know that the first Matrix was designed to be a perfect human world, where none suffered; where everyone would be happy. It was a disaster. No one would accept the program. Entire crops were lost. Some believed that we lacked the programming language to describe your perfect world, but I believe that as a species, human beings define their reality through misery and suffering. So the perfect world we dreamed, but your primitive cerebrum kept trying to wake up from. Which is why The Matrix was redesigned to this...the peak of your civilization." -- Agent Smith, The Matrix
The reliability of TCP is why every exciting email from embezzling East Africans arrives in letter-perfect condition
I assume this is a reference to the abundant "Nigeria scams", however, if you look on a map, you will see that Nigeria is actually in so-called "West Africa".
I just thought of another reason why abstractions are important. Take the famous MP3 -> Ogg conversion. Semantically, many aspects of the two types don't match, so the resulting conversion is less than perfect. Well, the Brain -> Machine Code conversion is something more akin to an MP3 -> PDF scenario. And for that reason, programming in a low level language (for scopes big enough to trash the mental cache, so to speak) has a similar conversion problem. Human beings things at an extremely high level, and can manipulate thousand-layer abstractions with ease (think of, for example, the abstraction of a 'cat'). Even something considered high-level in the programming world (objects and generic algorithms) are low-level to human beings. The ideal abstraction, would be, of course, natural language. Human beings think in natural language, and translating thoughts into natural language is trivially easy. For example, I'm writing a linker at the moment. I'd just like to be able to say:
Sort sections by name.
Remove all duplicate sections that have the LINK_ONCE parameter set.
Merge all other duplicate sections.
For each relocation in the relocation table, find the corresponding symbol and update the necessary address.
Merge string tables, and update all string references.
Write sections to this file.
There we go, six "lines of code." Very close mapping between my thoughts and the code. Assuming the compiler carries out my instructions faithfully, what are the chances of a bug in this code? Nearly zero. It's quite easy to verify that six lines of code is logically correct. Verifying that the thousands of lines of C++ that this translates to is both logically and semantically correct is much, much, harder.
A deep unwavering belief is a sure sign you're missing something...
... machine code itself is an abstraction in the first place. This is especially true for modern processors that reorder instructions, execute them in parallel, and in extreme cases convert them into an entirely different instruction set.
Let's assume that a, b and c are on three separate tables. One way this could be true would be for there to be a bug or weakness in the interpreter. If there were only an index on b, then a=b and b=c might resolve efficiently, but if the optimizer was given the three choices and chose the less optimal pair (a=b and a=c, for example), it might result in more work than a=b,c=b.
A non-flaw based explanation: Assuming that there are indexes on all tables, there's still the task of chosing which ones. The standard way that an RDBMS might resolve this query is to iterate over each table in succession, but there are six permutations of such a strategy (a->b->c, a->c->b, b->a->c, b->c->a, c->a->b, c->b->a). Only one may be chosen, but how it decides to do so will depend on how the system's optimizer is designed.
Some may strictly use "semantic" analysis - just look at the query & pick an option. Most will use statistics that are gathered by the system pertaining to the distribution of data & keys in the tables and attempt to estimate how much work each strategy will take based on row count & key cardinality. Depending on how accurately & frequently the system maintains these statistics, you can get different results, so even the same RDBMS might give multiple results depending on whether its statistics are up to date.
Optimizers generally don't infer equivalence relationships in order to allow the query writer to nudge the engine in one direction or another. With a=b,b=c, there are only two routes the most systems would take (a->b->c, c->b->a). By limiting the choices, you can coax the system to avoid a plan that may look attractive based on statistics but proves to be less practical for whatever reason.
Even if all the statistics are equivalent, two different systems may still produce different results. One plan for data retrieval might result in operations overall, but the may result in a long delay before you receive the first results (low throughput cost, high first row latency); conversely, another plan may do the opposite. Depending on your use of the data, you may prefer one over the other - for example, doing some summary financial report on a company's transactions would benefit from the low-throughput cost, since you need to look at all the data, but a Google type search where the user will scan the data in order and stop looking long before he or she reaches the end of the result set will benefit from a low first-row latency). One system may default to the first behavior, others to the second.
There are plenty of other reasons, but the main reason is that since optimizers have many ways of carrying out a request, and different performance characteristics may be desired from the same statement, they don't do 'simplification' in order to give the developer some control over the process (and also because simplification is not always simple to carry out & may unnecessarily consume CPU cycles).
-BbT
Says that all abstraction's are ultimately leaky because you never construct a logical system that is complete and consistent (but get close enough for government work). Program abstractions usually leak long before they reach Goedel's limit.
I know all that.
After explaining what TCP was, joel said:
By comparison, there is another method of transmitting data called IP which is unreliable.
My point, likely poorly made due to crankiness, was that TCP and IP are at different layers of the protocol stack, and TCP in fact assumes IP, and therefore you can't compare them. I do understand the analogy he was trying to make to abstraction layers, I was just trying to say that his language was tweaking the hell out of me.
marriage
maybe he uses this language to get a name on /.
well, he succeeded several times
Leaky abstractions....?
oh come on.... Nothing is fullproof... every element of computing is an abstraction of something else.... Even assembly code is an abstraction of processor commands...
Not trying to insult the guy, he wrote a great article... but every time you use any command in any language your using an abstraction of many more commands... all we do in coding is build yet more tools not in any way disimilar from the ones were already using... Classes and functions, even straightly scripted programs.
My sense of smell is an abstraction from my nose's ability to respond to chemicals... So when i smell shit i suppose thats a leaky abstraction because i dont want to smell it....
--Idiots, Every single one of YOU, A flaming mass of conglomerated morons, hey wait a second, isnt that how RAID works?
It's a good article for beginner programmers who are still trying to wrap thoir brains around the concepts, but it's hardly a new idea. Unfortunately, the author doesn't name the phenomena for what it is; it's not a problem with abstractions themselves, but is a result of logic and algorithms upon which programming is founded. Abstractions are based on assumptions, and when those assumptions are not true, the abstraction breaks. Take his example of TCP breaking when the network cable is unplugged: since TCP assumes the destination is reachable, it will abviously break when this assumption is violated. His "law of leaky abstractions" is simply the "law of violated assumptions" (see? I can come up with fancy labels too).
Higher Logics: where programming meets science.
Real programmers use C:>COPY CON PROGRAM.EXE
this lowercase text has been appended to fix the %$#!ing lameness filter
LOAD "SIG",8,1
LOADING...
READY.
RUN
This is why learning C with plain old vi and gcc is a good idea: You learn the basics first and then you can advance to an IDE later. Actually there's a saying for this: "You have to crawl before you can walk"
Now this is absolutely true...and the cool thing is, the analogy between (mechanical) engineering and software holds true. In a mechanical system, you NEVER, I repeat NEVER get an absolute sdescription; a good engineer knows to what level he can simplify (ie detail the mechanical efficiency, do some thermal calculations, then leave out the air friction because the effect is minimal and can be left out [in this case...in another situation it could well be the ayor factor] without dramatically changing the final strenght/elasticity calculations).
A slightly less proficient engineer will calculate the system, together with the next layer of the system (ie he will calculate the air friction), then discard it [or incorporate since he did the work anyway] because he found out the effect is not significant.
It seems the same thing goes with software development; you abstract to the propper level...but you need to know what level you can safely stop at.
-- Waht? Tehr's a preveiw buottn?
This article read like an ad, and it even ended with a plug for the guy's latest product. Boo. :P
I am one of the lucky guys who learned programming in machine code first - I actually hand assembled an interrupt driven program that would put the time on a memory mapped display back in 1979.
The schools mistakenly start out with a high level language. They for some reason think no one needs to get good at assembly language -(I would not advise learning Intel assembly first (It is a very poor design for humans to use - one of the reasons it took the intel world 10 years to catch up to the Amiga's OS) but alas Intel is the standard).
I also moved on to high-level programming - and wrote programs in both assembler and C - compiled them and counted machine cycles. Once you see where the compilers fail to produce good code, you can compensate where necessary.
A weird trend has happened where I find it most effective to write in the highest or lowest level and avoid anything in between.
Of course, when you've worked for a company like Microsoft, you've probably had to deal with so many extreme examples of his so-called "leaky abstractions". In this case, it's simply a buzzword phrase that dances around the more obvious and more appropriate term: bad design .
Please, no more articles from this guy. It's really insulting to the intelligence.
...just my 2 gil.
OK, I've been programming for almost 20 years, and yes, this is true to a point. There have been a few cases where I *had to* write some assembler. Only a few lines (embedded in Pascal or C), I'm not good at it (I dislike it), but it was the only way (PC/DOS bios / interrupt stuff).
.
I'd rather be working in Perl. But if I have to, I can write Java. But if I have to, I can write C. But if I have to, I can write assembler. Oops, I can't solder worth beans, oh well
Get it done quick (highest level practical), but get it done so it does what is needed (lowest level required for speed / access / stupid computer tricks).
I fully agree about the (NOT!) One Language to code them all attitude. People who only know the "script kiddie" or "Zimbu (tail-on-mouse) Wizard" tools make good / economical assistants, but don't put them in charge, or expect them to do Great Works all by themselves.
Yow! I'm supposed to have a plan?
The first programming class I took was C and it was a wretched experience. I had no idea what I was doing, what the teacher was talking about when he said "addresses", and why I should care. I had a VERY basic electronics background - capacitors, resistors, boolean algebra - but it didn't help. It wasn't until I had gotten further into electronics-type classes and learned about state machines and had taken 2 semesters programming in Intel assembly that I was truly ready to appreciate the wonders of C and C++! And then, I still wasn't ready until one of my teachers beat it into my brain that doing design and drawing flowcharts before coding a line can save you a ton of frustration. That's when I was ready to write good code. Any mistakes I make now are all my own fault, and I am usually able to find them.
-SheWhoWalksWithToesLikeCobras Please enter any 11-digit prime number to continue...
Wow. Now I have a term to describe Linux package management. Package managers, at least in my experience, are the epitome of leaky abstractions. I am now able to do the things that I want to do with my package system...but only after learning how the Debian packaging tools work (yeah, yeah, I'm sure Gentoo, RPM, Sorceror and BSD ports are all much easier). I've found that this is also true for Linux (probably Unix in general) configuration programs that try and add a later of abstraction above plain text files.
It is, in my opinion obviously, the most significant shortcoming of Linux distributions. We really need a comprehensive and airtight software/configuration management infrastructure for Unix-like systems. Um...and I nominate somebody else to do it :)
From the article:
During my first Microsoft internship, I wrote string libraries to run on the Macintosh. A typical assignment: write a version of strcat that returns a pointer to the end of the newstring. A few lines of C code.
If the author is who he claims to be, then he is responsible for thousands of buffer overflows that has not only sustained, but in essence CREATED the anti-virus industry (by creating the virus industry.)
If this is true, then death would probably be too kind a punishment.
"God is dead." - Frederik Nietzsche
Strangely enough, I was discussing this with a co-worker yesterday. We joked about the silly programmers who return pointers to local variables, or think "char *" is the same as "string".
char *s;
strcat(s, "Mary had a little lamb");
The result of the discussion was that everyone needs to understand at least one level down from the level of abstraction at which they will be working. For example, someone using sockets for TCP/IP will probably have a very hard time understanding what is going on unless he knows the general concepts of TCP. A C programmer really needs to understand a little bit about how the C code is going to look and work at the assembly level or she will never understand why the code above crashes
In addition to providing the details needed to make sense of the higher-level abstration layer, a basic understanding of the lower-level abstraction layer allows a good programmer to make educated guesses about potential trouble spots -- performance traps or feature limitations.
That is why I have always advocated an understanding of assembly language, computer architecture, TCP/IP protocols, etc. If you know TCP/IP, you can probably figure out what is wrong with your sockets code much more quickly. If you know how the Ethernet works, you will have much more success trying to wire your apartment. You might not technically need that knowledge, but it helps to be able to guess the answer to "can I just get better shielding to make the ethernet signal go farther?" rather than look it up.
Time flies like an arrow. Fruit flies like a banana.
If implemented properly, it shouldn't be necessary to go below your abstraction.
The examples he gives, to me, seem to come down to one of three things:
- The software that implements this level of abstraction is broken. e.g. things going wrong with Visual Studio
- The software that implements the abstraction doesn't do it well. Ideally an optimising compiler should notice the 'grain of the wood' type problems and correct them to give the better performance. (Ditto for SQL and a=b, b=c)
- There is misunderstanding about what the abstraction promises. TCP doesn't promise consistent performance, and doesn't promise to work when the connections broken.
As long as you understand what it promises, and the system that enables it is well crafted, you shouldn't need to climb under the layer provided by your abstraction of choice.
Of course, it's not a perfect world, and sometimes people don't understand the systems they use, or the systems don't work properly. I don't think this means that we should have to understand lower levels, though it can be fun and possibly necessary. Instead, the pressure should be to understand what we're promised, and for the enabling systems to deliver on those promises, and be smart about it.
bits and peace
Nicholas Daley
how much you abstract. Abstractions exist everywhere, there's no coming away from that. We can't reinvent the wheel everytime we go out for a ride on our bicycle. However, sometimes abstractions go too far, and make the process slow and unoptimized. That's the difference between an experienced programmer and a rookie, the experienced one knows where to take advantage of an abstraction, and where to go under the hood and get dirty.
...every so often discovers some minor details of things that he was supposed to know BEFORE starting any software-related work, and publishes his discoveries on his site with large amount of drivel, usually inspired by his troubled childhood at Microsoft.
Contrary to the popular belief, there indeed is no God.
The complex situation in the Middle East is abstracted to either "Palestinians are terrorists" or "innocent Palestinians are suffering at the hands of Israelis who illegally occupy their land".
...and so on...
The complex situation in Iraq is abstracted to "Saddam is evil".
Al Qaeda and their sympathizers have abstracted the multifaceted culture of the U.S. into "America is evil".
Ripping of CDs, regardless of the purpose, is abstracted to "piracy".
"misplaced concreteness" is when abstractions are thought to be water tight.
The subjects he lists, history, literature, languages, politics, economics, and arts, science, mathematics, and engineerin why would you disagree that it's possible for someone to obtain competency in these areas?
I believe you misunderstood me.
The point was not to obtain competence in these areas. It was to obtain MASTERY of ALL AREAS of human knowledge SIMULTANEOUSLY.
No longer possible.
(Of course it's even harder when the school systems don't even teach their students to SPELL it correctly. B-) )
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
In classical aerospace procurement, the specification rules. It's quite common to order the same part with the same specification from different suppliers. The units supplied must meet specified tests and be functionally interchangeable.
Software companies hate that. There were screams when DoD tried to force that on Ada compiler vendors. There was a test suite, acceptance testing, and some compilers flunked. DoD contractors couldn't use those compilers.
Software companies aren't used to getting products returned with a big red tag marked REJECTED - Does not conform to specification. And it doesn't end there. There's a follow-up from the quality department questioning their qualifications to continue as a supplier. Then there 's interchange of quality data between DoD buyers that puts the vendor on record as having quality problems. In the aerospace world, there's an organized process for hammering on vendors until their stuff works, or until the vendor gets replaced.
DoD lost that battle in software, though. That approach worked great at keeping aerospace machine shops from getting sloppy. But DoD doesn't buy enough software or computers any more. There was a time when DoD had real influence in computing (the Internet and BSD UNIX were all DoD-funded projects). But that influence declined in the 1980s as the PC sector, where consumers are weak.
And that's what this is all about. Nobody today is in the position to say to Microsoft "Make it work right or we pull the plug and you go out of business". Other vendors have picked up on this, and shipping crap has become a trade custom. Since consumers tend to buy on features rather than quality, we're not seeing pushback on this.
That's why our abstractions leak. Nobody is pushing back hard enough to insist that they don't. We know how to do it - overdesign inside, heavy testing, clear specifications, a willingness to reject for noncompliance, and the power to make that rejection stick. But nobody today is in a position to do that except for some very specialized procurements.