That *is* really cool. When you really think about it, pretty much everything having to do with computers is an abstraction. Even programming languages are a way to pretend that you are coding a comprehensible language that both you and the system comprehend, rather than simply manipulating long strings of "1"s and "0"s.

Everything we deal with in computing is an abstraction, because it is too difficult to do everything concretely. If we had to do everything as direct assembler opcodes, computing would be orders of magnitude harder, orders of magintude less efficent, and orders of magintude more expensive.

I must note an error.

If you put users' home directories on NFS-mounted drives (one abstraction), and your users create .forward files to forward all their email somewhere else (another abstraction), and the NFS server goes down while new email is arriving, the messages will not be forwarded because the .forward file will not be found. The leak in the abstraction actually caused a few messages to be dropped on the floor.

Incorrect. The messages aren't dropped on the floor. They're in the user's spool on the machine (since it didn't see the .forward file) and they'll remain there. If you lose an NFS mount that has account homes, one of the things you do is check the spools. "Dropped on the floor" means "Gone and lost forever." In this case, it's not. Just restart the NFS server, when it is up, resubmit those messages to the queue.

Abstraction is good. Many of the problems the author notes (the Windows COM development wizards, SQL performance efficenices (which are real -- "SELECT INTO" == "Destroy Performance" on most RDMBSs) C++ string "handling") are poor designs. He's right that leaky abstractions are causing us problems. But I sense he thinks less abstraction would be good. I don't know if we can afford that. Better abstraction would be better.

He also conflates, a couple of times, "abstraction" and "mitigation." Wipers and headlights and heaters don't abstract away weather. They migitate the visibility and temperature effects of weather, to a certain extent. But they don't abstract weather away. Both abstraction and mitigation deal with complexities, but they're different things, and coflating them is, well, poor abstraction.

"All non-trivial abstractions, to some degree, are leaky."

Or, as the linguist Edward Sapir once famously observed, "All grammars leak." Of course, a grammatical system is itself a non-trivial abstraction.

I spent years as a computer worker who knew really nothing about how computers work. When I finally decided to go back to school and take actual CS courses, I was at first utterly intimidated. My Computer Architecture text was . . . terrifying. Lines and little symbols and bizarre tables.

As for C . . . yow! Pointers.

After a couple of weeks, I pushed my pointy noggin through the caul and the cold brilliant light flooded in. The key was understanding layers of abstraction and indirection.

"Wayward Broadway actors and UFO crashes"

Man, this sounds great. Kind of like the way Neal Stephenson worked power drills and gas stations into "In the Beginning was the Command line."

Computer science is a lot like building/construction projects. From a distance, it really does seem like alchemy, but the moment a reasonably smart person sits down, cracks open a how-to book and really starts to dig in, it's surprisingly easy as long as you are able to follow directions meticulously.

If a bona fide moron like me can gut/renovate his bathroom, and run a big enterprise network, then *anyone* can.

I wish writing were just as straightforward. The nice thing about computers is if you do A, you are pretty much guaranteed to get B. There's very little that's subjective.

He's missed one major point. Computers allow us to manipulate abstractions as easily as if they were data. If an abstraction of that string array doesn't work well for our purposes, just switch abstractions and deal with the memory as an array of numbers.

Erik: I don't think Joel wants to do away with abstractions. (He's a professional programmer, after all.) I think his point is just that it's dangerous not to know what's underneath the abstraction, that there is a difference between those who fundamentally understand and those who superficially understand.

Well, the way he missed twice on techinical points bothers me on how much we can trust his opinion. I'd forgive him for not understanding how email works -- he's a developer, not a sysadmin, but his comments about windshield wipers abstracting away weather show me that he really does not understand the difference between simplification, abstraction, and mitigation.

And, as we go along, we have to abstract more and more. From source to executed code now features three levels of abstraction, and in some cases more, in order to control the complexity.

I do agree that both SQL and C++ have real abstraction issues. But they've had real abstraction issues for years, and knowing how to get around them is part and parcel what a good developer does. Ideally, we wouldn't teach people how to work around the bad abstractions -- we'd build languages that didn't do such poor abstractions. Alas, we don't live in an ideal world.

I for one am grateful to him for articulating so well something I've known to be true since... hmm, since 1965 when I worked in 1401 Autocoder and RPG.

The 1401, for those too young to have heard of it, was an IBM computer from the time after transistors, but before integrated circuits. Autocoder was a one-for-one representation of the 1401's instruction set; Autocoder programmers would routinely punch patches on cards to insert into object decks, and had to write their own device I/O and error handling routines. RPG, back then in its first iteration, was an abstraction of plugboard accounting machines superimposed on the 1401 architecture -- a very, very leaky abstraction.

You could not be an RPG programmer at all without understanding quite a bit about the quirks of the way the abstraction had been implemented. You could be an RPG programmer without having all the skills needed to be an Autocoder programmer, but you couldn't be a good one because sooner or later you were sure to run into one of the places where hardware architecture poked through the abstraction.

Today's high-level languages are much better at shielding you from lower levels. In this respect C and its descendants are not good examples. C was originally designed for writing an operating system, not applications. Some of the design decisions made then for, really, quite era-specific reasons, have been locked into its structure, and continue to show up in C++ and even Java. Languages that aren't constrained by inheritance from C are free to do a better job of abstraction, and they mostly do.

Nevertheless, it's still true that knowing the underlying layers can come in handy at the oddest times.