[ISN] Embracing the Art of Hacking

[InfoSec News]

http://www.wired.com/news/infostructure/0,1377,63506,00.html

[ 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 
artists. 

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 
design." 

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 
computer." 

"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 
paints. 

"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.