This is the eighth and last in a series of posts about Paul Graham’s book Hackers & Painters.
One of the finest books ever written about the practice of programming is Dreaming in Code, the tale of the long delayed and now ignored Chandler. The project was, in principle, the best of all worlds: a group of talented hackers and designers building open-source software on a generous budget. The project leader? Mitch Kapor, himself a talented hacker best known for the innovative spreadsheet app Lotus 1–2-3. (There’s an excellent interview with him in Founders at Work.) The language? Python, probably the most hacker-friendly language there is with suitable libraries for building cross-platform graphical apps. Their competitor? Microsoft Outlook, a user-hostile piece of bloat.
In Graham’s view, which I’ll call “language determinism,” Chandler should’ve succeeded. Granted, they weren’t using Lisp, but Graham ranks Python just below Lisp in his language hierarchy. And, of course, Graham is mainly writing about webapps. (One of the recurring themes of Dreaming in Code is: Maybe Chandler should’ve been a webapp.) Still, Hackers & Painters and Dreaming in Code seem to occupy different planes of existence: In one, startups that bring smart, passionate hackers together always win against the lumbering mass that is Big Software. In the other, even the most promising projects can suffer setbacks, peter out, and eventually release version 1.0 to little fanfare. Graham knows full well that this can happen; as he put it in his “How Not to Die” talk to YC founders: “Half of you are going to die.” So I’m a bit puzzled. Are his wild claims about Lisp merely rhetorical exaggerations, or am I overlooking a critical piece of his theory?
Chapter 14 of Hackers & Painters, like the two that preceded it, is mostly about Lisp. In “The Dream Language” (a revised version of his 2001 essay “Being Popular”), he describes the properties a language needs in order to catch on among hackers, from the perspective of someone designing a language. The clear subtext is: “Why hasn’t Lisp caught on (yet)?” One property he suggests is very compelling: “The language is built in layers. The higher-level abstractions are built in a very transparent way out of lower-level abstractions, which you can get hold of if you want.”
I’m reminded of the only undergrad CS course I took, Data Structures. It doubled as an intro to Java (I’d taken the AP CS exam, which was in C++), and I remember when one of the test questions asked us to find an item in a particular kind of linked list, given the code for the LinkedList class. Now, there was a very natural and efficient way to do this, but it was impossible because the pertinent property was marked as private. So I figured out a kludge that let me find the item anyway, but with a lot of grossly unnecessary traversal. I felt rather pleased with myself, because I thought it was a trick question. I received only half credit. The private turned out to be a typo, and those who ignored the typo and used the obvious, efficient algorithm were given full credit. Needless to say, I was upset—my answer was the only one anyone gave that would’ve compiled! That experience was part of the reason why I stopped taking CS courses, and majored in Math instead while dabbling in programming as a hobby. In hindsight, perhaps I should’ve blamed my professor less and blamed Java more.
Graham’s final chapter, “Design and Research,” is what might be called an Ode to Agile: Focus on users, refine gradually, iterate rapidly. The most striking theme is respect for your users, which he justifies on practical grounds: “It’s hard to stay interested in something you don’t like yourself. To make something good, you have to be thinking, ‘wow, this is really great,’ not ‘what a piece of shit; those fools will love it.’” This is something that we don’t hear often enough in the coding/design world, and it makes for a pleasant conclusion.
Reflecting on the book as a whole, I think the most merit is in the early “Graham as Public Intellectual” chapters, rather than the later “Graham as Hacker King” ones. This is unexpected; surely Graham’s experiences better qualify him to write about programming than about deep philosophical questions? Yet somehow, “Why Nerds are Unpopular” and “What You Can’t Say” stand out as the most trenchant, original and subtle writings in the book. Graham’s essays on economics, “How to Make Wealth” and “Mind the Gap,” are also first-rate, and I’m surprised that they haven’t achieved broader traction in the libertarian community. His writings on programming languages, on the other hand, are intriguing but ultimately unpersuasive. Learning Lisp feels like something I should do, in the same sense that doing yoga every day is something I should do. It’s not something I need to do.
Is Hackers & Painters still relevant? Absolutely. While much has changed in the last six years, the only chapter that actually feels dated today is “A Plan for Spam.” Most of the essays have a timeless quality that, unfortunately, is less prevalent in Graham’s post-YC writings. He’s now writing for a fervent community that knows and loves him, and has certain expectations of him. That’s understandable. Still, I hope PG has another mass-market book left in him. Even as a startup founder, it’s nice to read something not related to startups (or English literature) from time to time.
[Addendum: Here is Graham himself giving a talk a few months after the book’s publication, entitled “Great Hackers.” In it, he clearly articulates how the libertarian themes connect with the hacker themes. It’s also worth reading for the simile: “At our startup we had Robert Morris working as a system administrator. That’s like having the Rolling Stones play at a bar mitzvah.”]
0 responses so far ↓
Comments are closed.