From: Dave Long (dl@silcom.com)
Date: Fri Feb 02 2001 - 10:41:51 PST
> I sure wish there was a book that explained how to think like a
> programmer, e.g., what are the essential, non-language, non-platform
> truths about programming.
Tom Van Vleck sees truth:
"You learn something every day,
unless you're careful."
. . . . . . .
I tried to explain a bit about programming
to my girlfriend the other night, and wound
up resorting to Bobby Riggs' list:
Do it
Do it right
Do it right now
The first part seems easy. That, I think
is the seductive side of the art: all we
need do is build enough abstractions, or
for that matter, just brute code enough,
and building anything is a Simple Matter
Of Programming. (and God says to Noah:
"how fast can you type?")
Once we've had a bit of experience, the
second part becomes clear. Bugs live in
the complex parts of a system, so there's
a backpressure: don't hack willy nilly,
practice with some form and discipline.
Finally, there's the third part. Unless
one is fortunate, there will come a time
or two in one's career when the simple,
maintainably correct, solution doesn't
get the job done fast enough, or small
enough. It's best to find those elegant
solutions, both simple and efficient, but
usually we must add complexity to meet
requirements. Adding just enough to not
lose correctness (in the shippable sense)
is an exercise in balancing.
I compared that balancing to fencing, a
sport which is mostly about not being hit
while still being able to hit opponents.
For some tactics along Riggs' lines, see
Lampson's "Hints for Computer System Design" (1983)
<http://www.research.microsoft.com/~lampson/33-Hints/WebPage.html>
-Dave
> Reason #1: The navel-gazing, philosophy-of-programming books can't be
> essentials. Their relevance to programming is only clear for somebody
> who already knows how to program.
That is why they are the essentials. I
think programming is much like riding a
horse. There's very little a book can
do compared to actually hacking and
working, preferably in the company of
someone more experienced. (source goes
a long way to ameliorating lack of any
better contact with programmers)
Once one has a feel for it, the books
can give a name to that feeling, or give
that insight that was just beyond reach,
but they're not going to be much more
than annotations to process of learning.
(War stories might be an exception: it's
good to learn from other's mistakes, but
one must already have programmed enough
to understand what was attractive about
the mistakes at the time)
This archive was generated by hypermail 2b29 : Thu Feb 08 2001 - 04:06:40 PST