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
<A HREF="http://www.testing.com/cgi-bin/blog/2005/01/06#joel-advice">
   just blogged</A>
on Joel Spolsky's
<A HREF="http://www.joelonsoftware.com/articles/CollegeAdvice.html">
   Advice for Computer Science College Students</A>.
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 <I>deja
vu</I>.  I looked back and found another article by Joel,
on
<A HREF="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">
   leaky abstractions</A>,
and then another, called
<A HREF="http://www.joelonsoftware.com/articles/fog0000000319.html">
   Back to Basics</A>.
There is is a long-term theme running through Joel's articles,
that programmers must understand both the abstractions they
deal in <EM>and</EM> how these abstractions are implemented.
In some ways, his repeated references to C are mostly pragmatic;
C is <EM>the</EM> 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
<A HREF="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">
   leaky abstractions</A>,
article, is [emphasis added]:

<BLOCKQUOTE>
<I>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.
<STRONG>So the abstractions save us time working, but they don't
save us time learning.</STRONG>

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.</I>
</BLOCKQUOTE>

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
<A HREF="http://www.joelonsoftware.com/articles/CollegeAdvice.html">
   Advice for Computer Science College Students</A>.
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!
-----