TITLE: Looking Under the Hood to Be a Better Programmer AUTHOR: Eugene Wallingford DATE: January 06, 2005 3:03 PM DESC: Programmers need to know how their abstractions work in order to use them effectively. That makes learning to program even harder. ----- BODY: Brian Marick just blogged on Joel Spolsky's Advice for Computer Science College Students. I had the beginnings of an entry on Joel's stuff sitting in my "to blog" folder, but was planning to put it off until another day. (Hey, this is the last Thursday I'll be able to go home early for sixteen weeks...) But now I feel like saying something. Brian's entry points that Joel's advice reflects a change in the world of programming from back when we old fogies studied computer science in school: C now counts as close enough to the hardware to be where students should learn how to write efficient programs. (Brian has more to say. Read it.) I began to think again about Joel's advice when I read the article linked above, but it wasn't the first time I'd thought about it. In fact, I had a strong sense of deja vu. I looked back and found another article by Joel, on leaky abstractions, and then another, called Back to Basics. There is is a long-term theme running through Joel's articles, that programmers must understand both the abstractions they deal in and how these abstractions are implemented. In some ways, his repeated references to C are mostly pragmatic; C is the lingua franca at the lowest level of software development, even -- Brian mentions -- for those of us who prefer to traffic in Ruby, Smalltalk, Perl or Python. But C isn't the key idea Joel is making. I think that this, from the leaky abstractions, article, is [emphasis added]:
The law of leaky abstractions means that whenever somebody comes up with a wizzy new ... tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." [...] tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.
Programming has always been hard, but it gets harder when we move up a level in abstraction, because now we have to worry about the interactions between the levels. Joel's article argues us that it's impossible to create an abstraction that doesn't leak. I'm not sure I willing to believe it's impossible just yet, but I do believe that it's close enough for us to act as if it is. That said, Brian's history lesson offers some hope that that the difficulty of programming isn't growing harder at an increasing rate, because sometimes what counts as the lowest level rises. C compilers really are good enough these days that we don't have to learn assembly in order to appreciate what's happening at the machine level. Or do we? Oh, and I second Brian's recommendation to read Joel's Advice for Computer Science College Students. He may just be one of those old fogies "apt to say goofy, antediluvian things", but I think he's spot on with his seven suggestions (even though I think a few of his reasons are goofy). And that includes the one about microeconomics! -----