Hacking is like painting
Paul Graham has a fine new essay entitled Hacking and Painting. It's
very dense with ideas, and does a good job of describing the flavor of
creative programming, something difficult to get across to a mass
audience.
Hacking is like painting in some ways, but the analogy breaks down in
others. Here's my take on some of the points.
If you want to hack, or paint, get a day job. In hacking, as in
painting, it is very difficult to find a situation that rewards
artistic accomplishment directly. Business and academia reward
something that's different enough to be frustrating. I think that many
people had the hope that the explosion of "open source business" would
solve this problem, but it hasn't. The "day job" works for painters,
musicians, and other artists, and is a good model for hackers as well.
Studying works of art is vital to learn to do art. The great
painters learned by studying and copying other great painters, and
refining the ideas. One of the best criteria for being a good writer
is reading voraciously. Yet, as far as I know, it's rare to teach
computer programming by studying great programs. Historically, a big
part of the problem was the dearth of great programs available for
study. Free software fixes this problem. I considered myself a hotshot
programmer before getting involved in free software, but grew
enormously through reading other people's code. I'm not sure how much
code people study in academia; the Lions book is certainly one early
encouraging example.
But: paintings last a long time, code rots fast. In museums and
reproductions, we enjoy a body of work going back hundreds of years.
In many ways, these old paintings are better than the work of today.
Yet, with few exceptions, code that's hasn't been maintained for more
than a year or so is dead. One such exception is code that performs a
well-defined ask, and does it well (such as libjpeg). Another such
exception is "retrocomputing".
Getting the spec right is more important, and more interesting,
than implementing the spec. Once you've got a good spec, any
competent programmer can implement it. (this is a good working
definition of competence :) But coming up with a good spec is very
hard. Usually the best way to do it is to incrementally refine an
implementation. It's the same for painting - X-ray analysis frequently
reveals things painted over and reworked. Oil paints are good for this
kind of reworking. Analogously, dynamic languages are better than
static languages for this kind of process.
There's a lot of discussion
in blog land about static vs dynamic languages, and I expect to return
to the topic. I consider programming in C to be like sculpting in
marble, and programming in Python to be like sculpting in clay.
They're both worth doing, but for different kinds of work. Also,
giving a chisel and block of marble to a newbie sculptor produces
similar results to a newbie C programmer: a pile of marble chunks
covered in marble dust. Paul uses the similar analogy of drawing in
ink vs pencil.
Programmers envy mathematicians too much; they should aspire to be
more like artists. I see Paul's point here, but in the long run I
disagree. Paul uses the analogy of paint chemistry as a scientific
theory underlying painting, in much the same way that computer science
theory underlies programming. But I think the analogy breaks down.
Paint chemistry is obviously useful in predicting the appearance of
colors, the way they'll interact with each other, the brush and the
canvas, and other important stuff such as glossiness. But the
limitations of paint chemistry are equally clear - as a theory it
speaks not at all to composition, emotion, or the infinitely subtle
issues of aesthetics.
But where are the corresponding limits in the theory of computer
programming? This is an open question; certainly many attempts to
apply mathematics to real programming have been disappointing. But I
think this is because mathematicians aren't good at doing the kind of
mathematics needed for programming, the kind where the spec (or the
"theorem to be proved") is extremely complex. Indeed, the theorems
most highly valued in mathematics are those where the statement of the
theorem is very simple, but the proof is deep (Fermat's Last Theorem
is a shining example).
Fortunately, there are people exploring that edge, "proof hackers" if
you will. Metamath, HOL, and proof-carrying code represent some of the
most interesting work in that direction. If these people succeed in
expanding the useful scope of mathematical technique, then it will
dramatically change the way we do programming
In this distant future, the use of mathematics will depend greatly on
the type of programming being done. Aesthetics will still be important
(without question in any area that deals with human interaction), but
for well defined tasks and well defined properties (especially
security properties), the best programs will be provably correct.
tree ISA vehicle
I see yet another suggestion that Max has the hacker mind. The other
day, he discovered an undocumented feature in "Reckless Drivin'" - if
you press the Alt key while clicking on Start, it pops up a dialog box
that lets you choose a vehicle number.
So we started going through the numbers, and he enjoyed being able to
drive cars, buses, go-karts, helicopters, and so on. Then, we found a
vehicle code that corresponded to a tree. In a 2D driving game, it
makes sense to consider a tree as a type of vehicle; it's rendered the
same way, and even though it doesn't share all methods, it's probably
easier to just leave methods for motion unimplemented than to branch
out the class hierarchy.
Anyway, when Max saw the tree, he thought it was very funny, and
laughed out loud. Was this because he saw a glimmer of the design of
the program, and found the incongruity between the internal "tree ISA
vehicle" and the real world, or is he just a happy kid who likes to
laugh? Either way makes me feel good.
