Book Review – Hackers & Painters

I wrote this review nearly three years ago, but never pulled the trigger to publish it to my blog. Maybe because it seems half written. I don’t think I’m going to ever go back to it, so what the heck.

Having skimmed part of the eponymous essay and having enjoyed other essays by Paul Graham, I bought a copy of Hackers & Painters: Big Ideas from the Computer Age without bothering to read any reviews. While I’m very glad I purchased it and read it, there were a few elements of the book that bothered me.

Most of my issues with the book revolve around Graham’s take on programming languages. Even then, I think he is mostly dead on. There are significant differences in the power of different programming languages. As he suggests, even if they are all Turing machine equivalent, who wants to waste their time reimplementing the abstractions provided by a more powerful language?

If your knowledge of programming languages stops at around Visual Basic, Graham’s book should be extremely enlightening. There are a lot of powerful languages out there, and Graham does a very good job of explaining why Lisp is one of the best of the best. But, sometimes he goes a bit too far. It’s hard to avoid getting the impression that Graham views anyone who doesn’t program in Lisp or a Lisp-like language to be a fool. While he seems to accept that there are a few acceptable reasons for using other languages, I don’t think he’s being very realistic about software development at most companies, as well as about the typical skill level of the people available to do development at many companies.

One of Graham’s explanations as to why Lisp isn’t used more frequently is that you have to have mastered Lisp to understand its power. If all you know is VB, JavaScript, Perl, or perhaps even C++, Java, C#, Python or Ruby, I think you might have a difficult time understanding the powerful abstractions provided by Lisp.

I was fortunate enough to have spent a few years doing commercial software development in Lisp. Working with the Lisp interpreter was a great pleasure, and even though I was by no means an elite Lisp hacker, I was frequently amazed by how much functionality I could implement in Lisp in a relatively short period of time.

However, there were several times when I found concepts in Lisp to be difficult to grok. One issue is that I don’t have a formal computer science degree, but rather degrees in physics and in philosophy and a lot of graduate work in electrical and computer engineering. A lot of the programmers in the IT departments of companies are going to have even less experience in computer science. I think you will see a lot of eyes glazing over if you drop into a typical IT shop and start trying to explain lexical closures. Of course, there will many IT developers who get it, but I’m talking about the average mainstream developer.

Graham echoes a common sentiment that the majority of great software is written by a very small percentage of the best developers (though I don’t remember him making an estimate as to what percentage of that code is written in one of the most powerful languages).