[ISN] Embracing the Art of Hacking
isn at c4i.org
Wed May 19 08:20:05 EDT 2004
[ http://www.amazon.com/exec/obidos/ASIN/0596006624/c4iorg - WK]
By Michelle Delio
May. 19, 2004
The idea that every hacker is an artist and every artist is a hacker
isn't groundbreaking -- recent gallery and museum shows have focused
on the link between art and coding -- but a new book by programmer
Paul Graham gives the concept a fresh twist by advising hackers to
improve their skills by borrowing creative techniques from other
Billed as a guide into the minds and motivations of hackers, Hackers &
Painters, due to be released by O'Reilly Media later this month, is a
mixed bag of essays on topics ranging from aesthetics to high school
hazing, spam to startups, Microsoft to money.
It doesn't quite live up to the promotional promise that "if you want
to understand what hackers are up to, this book will tell you," since
it's unlikely that the mildly hacker-curious will wade through four
chapters on the pros and cons of programming languages. But, on the
whole, the book does provide some fascinating reading for anyone who
cares about making great things.
Graham certainly knows hacking: Currently working on a new programming
language called Arc, he developed the first Web-based application
(Viaweb, which was acquired by Yahoo in 1998) and created a simple but
effective Bayesian spam filter that inspired most of the current spam
busters. He also knows art; Graham studied painting at Rhode Island
School of Design and the Accademia di Belle Arti in Florence, Italy.
Unfortunately, Hackers and Painters gets off to a slow start with a
dull chapter on why geeks aren't popular in high school, a subject
that's been exhaustively covered elsewhere. Graham breaks no new
ground here -- we already know that young geeks care more about
learning than being popular, which can lead to social awkwardness, and
we also know that other kids are often mean to them.
It's a shame that Graham didn't offer some solutions to the problem of
keeping geek kids sane in school. He does mention some possibilities
in a one-paragraph addendum in the back of the book -- suggesting home
schooling and making high school more like college. Had these ideas
been the focus of the "Why Nerds are Unpopular" chapter the book might
have provided real options to suffering young school-bound hackers.
The chapters on general rules of good design as they apply to
programming, painting and any creative endeavor are by far the best in
the book. Graham slams the artistic conceit that all art is good and
taste is purely subjective, pointing out that if you aren't willing to
say that some creations aren't beautiful then you'll never develop the
aesthetic muscles necessary to define and develop good work.
Graham steers programmers, writers and other artists toward
simplicity, making the point that ornate stylistic embellishments
often cover up lack of substance, whether you are writing a computer
application or a novel. He urges anyone who is involved in creative
work not to get pretentious and to retain her or his sense of humor,
noting that "good design may not have to be funny, but it's hard to
imagine something that could be called humorless also being good
Graham also shares ideas on how to produce work from other creative
fields and advises hackers to apply these tools to their own
endeavors. Writers and painters know that good work is the result of
an enormous amount of reworking or rewriting and are taught to be
patient with the process of figuring out what they are trying to
create. But programmers, Graham writes, are taught that they should
"figure out a program completely on paper before even going near a
"I found that I did not program this way.... Instead of patiently
writing out a complete program and assuring myself it was correct, I
tended to just spew out code that was hopelessly broken, and gradually
beat it into shape. Debugging, I was taught, was a kind of final pass
where you caught typos and oversights. The way I worked, it seemed
like programming consisted of debugging.
"For a long time I felt bad about this, just as I once felt bad that I
didn't hold my pencil the way they taught me to in elementary school.
If I had only looked over at the other makers, the painters or the
architects, I would have realized that there was a name for what I was
doing: sketching. As far as I can tell, the way they taught me to
program in college was all wrong. You should figure out programs as
you're writing them, just as writers and painters and architects do."
Encouraging programmers to make what writers sometimes refer to as
sloppy first copies also has implications for programming languages,
Graham writes. "It means that a programming language should, above
all, be malleable. A programming language is for thinking of programs,
not for expressing programs you've already thought of.
"We need a language that lets us scribble and smudge and smear, not a
language where you have to sit with a teacup balanced on your knee and
make polite conversation with a strict old aunt of a compiler."
Taking inspiration from artists working in other media will also
improve software, Graham writes, comparing open-source development to
painting with oils, a flexible medium that allows for reworking and
overpainting, as opposed to the more fixed and rigid nature of tempera
"Open source software has fewer bugs because it admits to the
possibility of bugs ... and it helps to have a medium that makes
change easy," Graham writes.
Graham rounds out the book with chapters on programming language
politics (essentially: "yay" for Lisp and "boo" to Java), and an
excellent chapter on spam-filter technology. He predicts applications
will vanish from desktops shortly and will instead run via browsers
over the Web, says Microsoft is all but doomed and also provides some
hints to those who'd like to be the next Bill Gates.
The chapters on free speech and free thought contain little that's
new, but these subjects are so central to hacking philosophy that an
overview has to be included in any book on hackers.
Graham wraps up the book with a final excellent chapter on good
design, offering up more tools used by artists and writers that would
work equally well for programmers.
"Design must be for users, but I don't mean to imply that good design
aims at some kind of lowest common denominator," Graham writes in his
last chapter. "If you think you're designing something for idiots,
odds are you're not designing something good."
Hackers and Painters is not a masterpiece, but it's far from bland
match-your-couch art, either. It's a very personal, often
illuminating, rather jumbled and only occasionally tedious look at one
man's ideas about how to create good things.
More information about the ISN