Wittgenstein is popularly credited with the idea that most philosophical controversies are due to confusions over language. I’m not sure how much credit to give him. I suspect a lot of people realized this, but reacted simply by not studying philosophy, rather than becoming philosophy professors.

I’ve said it before and I’ll say it again: While PG’s essays on startups are his most influential works, his more abstract writings are actually more incisive. They deserve a much wider readership.

Most people reading this will already be fairly tolerant. But there is a step beyond thinking of yourself as x but tolerating y: not even to consider yourself an x. The more labels you have for yourself, the dumber they make you.

From “Keep Your Identity Small.” Paul Graham deserves a broader audience than the startup tribe that frequents his site. It’s a pity that no one reads “essays” anymore.

The danger with grad school is that you don’t see the scary part upfront. PhD programs start out as college part 2, with several years of classes. So by the time you face the horror of writing a dissertation, you’re already several years in. If you quit now, you’ll be a grad-school dropout, and you probably won’t like that idea. When Robert got kicked out of grad school for writing the Internet worm of 1988, I envied him enormously for finding a way out without the stigma of failure.

On the whole, grad school is probably better than most alternatives. You meet a lot of smart people, and your glum procrastination will at least be a powerful common bond. And of course you have a PhD at the end. I forgot about that. I suppose that’s worth something.

From Paul Graham’s essay “Undergraduation.” The whole thing is worth reading.

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.”]

Ask anyone in academia about Lisp, and there’s a good chance that they’ll say it’s a great language for AI research, but not for industry. Paul Graham, on the other hand, calls it the “secret weapon” that allowed Viaweb to outdo their competitors at every turn. He adds a second datapoint: ITA Software, the company that powers Orbitz, also taps into the power of Lisp, which he believes was critical to the site’s success against Travelocity and Expedia.

Chapter 12, “Beating the Averages,” is all about what makes Lisp so great. He argues that it’s not just one of many high-level languages, but the highest-level language. Why don’t other programmers acknowledge this? He supposes that a programmer uses a language called Blub, which lies somewhere on the language spectrum near Java and Python. “As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.”

Following this line of reasoning to its conclusion, Graham writes, “the only programmers in a position to see all the differences in power between various languages are those who understand the most powerful one.” Which, in his mind, is Lisp. He’s confident of this fact because Lisp is the only language with macros, and whenever he looks at another language, he wonders how those programmers can get anything done without macros.

In the next chapter, “Revenge of the Nerds,” Graham claims that mainstream languages are gradually moving ever closer to the ideal, Lisp, which was invented by John McCarthy all the way back in the 1950s. (Fascinatingly, McCarthy invented the language only as a theoretical notation. He had no intent of actually “running” that notation until one of his grad students, Steve Russell, wrote the first Lisp interpreter.) Ruby, for instance, is very nearly Lisp with a prettier syntax. The chapter includes an appendix of code examples that demonstrate the superior brevity of Lisp and Ruby for a particular (contrived) task. To my mind, the JavaScript code, though slightly longer, is the most readable; but this is undeniably because I tend to think in JavaScript.

I feel as though I should be arguing against Graham—his fervor borders on the religious—but I’m in no position to do so. What little I know about Lisp, I’ve learned from reading Hacker News. And certainly, there are some languages (Python, Scala) are superior to their more popular rivals (PHP, Java). So it seems that I have no alternative: I’ll have to learn Lisp. Maybe I, too, will be able to gaze down at all the other hackers one day.

[Addendum: Graham revisits “Revenge of the Nerds” in his 2002 essay “Succinctness is Power.”]

I knew that Paul Graham felt strongly about dynamic typing. It is, after all, a critical feature of Lisp, a language Graham is so enamored with that he wrote his own dialect of it. Still, I was surprised to see him use the heading “Seat Belts or Handcuffs?” for a section weighing dynamic vs. static typing in the book’s tenth chapter, “Programming Languages Explained.” He grudgingly admits that “some smart people seem to like static typing, so the question must still be an open one.” (In the next chapter, he elaborates on his reasons: “…static typing seems to preclude true macros—without which, in my opinion, no language is worth using.”)

Graham’s passion for dynamic typing pales in comparison to this astonishing claim about open source software: “I’m certainly not against the idea of property, and yet I would be very reluctant to install software I didn’t have the source for.” Why? Because if he has the source, he can fix any bugs he encounters. And, more importantly, so can everyone else. “Lots of smart people have examined the source code of open source operating systems like Linux and FreeBSD and have already found most of the bugs. Whereas Windows is only as reliable as big-company QA can make it.” That’s a bold statement, and I’m told that PG is no hypocrite: He runs nothing but Firefox and vi on his machine. But he’s also a fan of closed-source webapps. The distinction being, I suppose, that bugs in a webapp can only affect your system if there’s a bug in your web browser as well. System crashes are unpleasant, but using them as the foundation for such a broad principle is rather eccentric. It’s a bit like becoming vegan to avoid salmonella.

Graham once again runs into the audience problem: Is this book for hackers, or for the merely curious about hacking? The chapter is squarely aimed at the latter, explaining terms like “high-level language.” It seems to have been written primarily to bring the mass-market reader up to speed for the next chapter, “The Hundred Year Language.”

Having established that we are now living in a Renaissance of programming languages, he wonders what will happen over the next century. Some of his conclusions are uncontroversial: Mainstream languages will be more high-level than they are today, with more layers of abstraction between them and the machine. Processors will, after all, be many times more powerful than they are today, even if Moore’s law is indeed petering out. “Inefficient software isn’t gross. What’s gross is a language that makes programmers do needless work.”

He lambasts object-oriented programming, but predicts that it will stick around as an unfortunate legacy of the 20th century: “Though I don’t think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations.” This is a surprising stance. To most programmers, I would say, there is something intuitively very appealing about the clean separation of concerns that well-encapsulated objects provide so naturally.

But the most astonishing claim of the chapter is that “parallelism will be something that is available if you ask for it explicitly, but not ordinarily used. This implies that the kind of parallelism we have in a hundred years will not, except in special applications, be massive parallelism. I expect for ordinary programmers it will be more like being able to fork off processes that all end up running in parallel.” Really? There is, today, a resurgence in interest in functional languages because the number of cores in computers is increasing much more quickly than the power of individual cores is. In the year 2010, a popular word processor run on a single core seems rather pokey. Everyone is trying to build their applications for multiple cores. Future compilers will almost certainly be smart enough to provide us with parallelism automatically. Cores may be a million times faster, but text editors will have a billion times as much bloat.

I am a bit perplexed at “A Plan for Spam” (Chapter 8): In it, Graham describes Bayesian filtering, and his surprise at how effective it is compared to the more time-consuming alternative of building a complicated set of blacklists and whitelists. Because this method of spam protection requires a large corpus (ideally an individualized one for each user) of spam and non-spam messages, he writes, “each user should have two delete buttons, ordinary delete and delete-as-spam.” This is, of course, a feature familiar to anyone who’s used Gmail, Apple Mail or virtually any other recent e-mail client. I find it hard to imagine a world in which Bayesian spam filtering isn’t used, and I now receive very little spam in part because of it. So, this essay is completely right, but it feels like a relic from a bygone era when e-mail spam was a serious concern rather than a joke. Today, phishing is the much greater concern, and Bayesian filters are necessarily limited in their ability to stop e-mail designed to emulate missives from your bank or ISP. While “A Plan for Spam” may have been influential, it feels out of place in a book aimed at less transient concerns.

Yet taken as a complement to the following chapter, “Taste for Makers,” the spam essay conveys a subtle and important point: People tend to neglect a simple, elegant solution that requires a lot of thought up front (in this case, an understanding of Bayesian probability updating) when a more complicated, tedious, and less effective approach is available that requires little intellectual exertion (the blacklist-whitelist approach). The properties of the former solution are part of what Graham calls good design: “Good design is simple… Good design solves the right problem… Good design is hard… Good design looks easy… Good design resembles nature… Good design is often strange.” This last is interesting: “I’m not sure why,” Graham admits. “It may just be my own stupidity. A can opener must seem miraculous to a dog. Maybe if I were smart enough, it would seem the most natural thing in the world that e^iπ = -1. It is after all necessarily true.”

The best advice is at the end of the chapter. “Intolerance for ugliness is not in itself enough,” Graham warns, “You have to understand a field well before you develop a good nose for what needs fixing. You have to do your homework. But as you become expert in a field, you’ll start to hear little voices saying, What a hack! There must be a better way. Don’t ignore those voices. Cultivate them.”

[Update: After writing this, I came across “Filters that Fight Back,” an essay Graham wrote in 2003 yet chose not to include in H&P. In it, he claims that spam could be fought more effectively if our e-mail clients automatically crawled suspect links, thereby imposing harsh bandwidth costs on spammers. It is a scheme that seems just crazy enough to work, and I’m a bit surprised that I haven’t heard of it being used in practice.]

Why are so many programmers libertarians? Some have suggested that, as designers of complex systems, they naturally maintain a preference for simpler, more elegant legal frameworks. Others accuse them of lacking empathy, their aversion to the welfare state the result of a geeky semi-autism. To Paul Graham, in his essay “How to Make Wealth” (Chapter 6), the answer is simpler: Programmers, unlike most people, directly create wealth. What others learn from reading Greg Mankiw, programmers learn firsthand: “In our world, you sink or swim, and there are no excuses. When those far removed from the creation of wealth—undergraduates, reporters, politicians—hear that the richest 5% of the people have half the total wealth, they tend to think injustice! An experienced programmer would be more likely to think is that all? The top 5% of programmers probably write 99% of the good software.”

The economics lesson continues in the next chapter, “Mind the Gap,” in which Graham urges the reader to consider income disparities to be not only morally acceptable, but a cause for celebration: “Could it be that, in a modern democracy, variation in income is actually a sign of health?” His point is a familiar one: As the rich get richer, the poor also get richer (the exception being when the rich are the beneficiaries of government). The rich get to where they are by making products that other people enjoy. “I’m not talking about the trickle-down effect here,” Graham clarifies, distancing himself from one of the weakest economic arguments conservatives make, “I’m not saying that if you let Henry Ford get rich, he’ll hire you as a waiter as his next party. I’m saying that he’ll make you a tractor to replace your horse.”

These two chapters are reminiscent of the 1946 classic Economics in One Lesson, but with pithier prose. My favorite passage: “In a free market, prices are determined by what buyers want… To say that a certain kind of work is underpaid is thus identical with saying that people want the wrong things. Well, of course people want the wrong things. It seems odd to be surprised by that. And it seems even odder to say that it’s unjust that certain kinds of work are underpaid. Then you’re saying that it’s unjust that people want the wrong things. It’s lamentable that people prefer reality TV and corndogs to Shakespeare and steamed vegetables, but unjust? That seems like saying that blue is heavy, or that up is circular.”

I’ve often said that libertarianism needs a more relatable public face than Drew Cary, host of the frustrating reason.tv series. I wonder if the affable PG ever considered hosting his own political talk show. Of course, he’ll do no such thing, for the same reason that he doesn’t write essays like this anymore: He’s found a better way to influence the world. As an economist would say, funding and advising startups is his comparative advantage.

[Addendum: For more on PG’s motivations, see his more recent (and brief) essay “Why YC,” particularly the last two paragraphs.]

If you told the average man on the street that there’s a website called Hacker News, he’d assume that it’s a nefarious launchpad for cyberattacks, hosted on an ancient server deep in the frosted planes of Siberia. It is, in fact, very few of those things, and is widely beloved by the startup types who inhabit it.

Chapter 4 of Hackers & Painters, “Good Bad Attitude” (posted to Graham’s website as The Word “Hacker”) is a brief and digressive meditation that takes that etymological divide as its starting point. Graham looks closely at the two meanings of the word “hacker” and, for that matter, the root noun “hack.” One meaning is favorable, used to praise cleverness, while the other is damning. Why is this? “Ugly and imaginative solutions have something in common: they both break the rules. And there is a gradual continuum between rule breaking that’s merely ugly (using duct tape to attach something to your bike) and rule breaking that is brilliantly imaginative (discarding Euclidean space).” He then spends the remainder of the 6-page essay talking about smart hackers’ distrust of authority.

One of the pleasures of reading printed essays as opposed to web-based ones is that you can infer a lot about the intended audience from the references made. In a blog, you’re allowed to make all the obscure references you want as long as they’re hyperlinked to Wikipedia. This essay, by contrast, is clearly one hacker telling other hackers about hackers. He isn’t telling you anything you don’t already know; he’s just expressing it more clearly. “There is something very American about Feynman breaking into safes during the Manhattan Project,” he writes, evidently expecting his audience to have already absorbed Richard Feynman’s wonderful autiobiographical adventures. Across the page, he shows a picture with the subtitle: “Jobs and Wozniak with a circumvention device, 1975.” There is no corresponding text. He expects his readers to know enough about the founding of Apple for this picture to evoke the founders’ blue box shenanigans. Nor, when he describes the invention of Unix, does he feel compelled to add: And Unix is a really important operating system!

Graham missteps when he proposes, “It seems to me that there is a Laffer curve for government power, just as for tax revenues.” He then muses in a footnote that he would not object to having such a curve named for him, if only so that people could remember it more easily. The wonderful thing about the Laffer curve is that it captures, in a simple illustration, an important yet counterintuitive fact: Raising taxes can lower tax revenue. Most people don’t consider this possibility, and therefore believe that deficits can always be paid off later by raising taxes. By contrast, just about everyone realizes that an all-powerful government is not a recipe for a vibrant economy; nor, for that matter, is anarchy. We don’t need a Graham curve to express these beliefs.

I’m not sure whether to consider Chapter 5, “The Other Road Ahead,” to be prophetic or merely observant. It was written nearly a decade ago, and asserts that software will one day move en masse to the web. Well, of course! we now say. Whether this was so obvious at the time, in an age when broadband was rare and AJAX not yet invented, I can’t recall. Certainly, it would have been an astonishing essay in 1995, when Graham was developing one of the first webapps, Viaweb. There are some moments that feel especially prophetic—“Clients shouldn’t store data; they should be like telephones. In fact they may become telephones, or vice versa.”—but ultimately the essay is forgettable by virtue of being familiar and, in the year 2010, uncontroversial. The title is a reference to Bill Gates’ book The Road Ahead; with Windows Azure, even Microsoft is going down the other road now.

[Update: In assessing the prescience of “The Other Road Ahead,” I neglected to examine the footnotes in the 2004 book version. One is borderline mind-boggling: “If Apple were to grow the iPod into a cell phone with a web browser, Microsoft would be in big trouble.” However, he loses some foresight points when he later adds, “I would not even use Javascript, if I were you; Viaweb didn’t. Most of the Javascript I see on the Web isn’t necessary, and much of it breaks. And when you start to be able to browse actual web pages on your cell phone or PDA (or toaster), who knows if they’ll even support it?” Support for JavaScript on the iPhone’s browser was one of its most revolutionary features when it debuted three years later, and Graham acknowledges as much in a footnote to the version of the essay on his site: “In the original version of this essay, I advised avoiding Javascript. That was a good plan in 2001, but Javascript now works.”]

The second chapter of Hackers & Painters, the one that lends it title to the book, is easily condensed into a common aphorism: “Programming is more of an art than a science.”

The extended metaphor of the essay, how programs begin as sketches that morph and become filled in over time, is a bit overplayed. “In hacking, like painting, work comes in cycles. Sometimes you get excited about a new project and you want to work sixteen hours a day on it. Other times nothing seems interesting.” Well, isn’t that true of all endeavors? From studying economics to Quiz Bowl to building CarlWIki, I remember my entire undergraduate experience as an alternating series of bursts of interest. Even when I had a 9-to-5 job working at a college bookstore, there were days when I was excited about efficiently processing textbook returns (seriously!), and other days that were like watching grass grow.

There are also parts that ring hollow, perhaps simply because Graham and I are different kinds of hackers. He writes, “I like debugging: it’s the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you’re going to win in the end. It’s as relaxing as painting a wall.” Painting a wall is just one of many things I’d rather be doing than spending a whole day tracking down a bug. Walking slowly across a pit of hot coals is another. To me, the pleasure of hacking is the pleasure of turning a good design into a reality. I enjoy discovering unexpected subtleties—what I’d thought was a simple design might turn out to be quite intricate and delicate—but not outright bugs.

The highlights of the chapter to the people most likely to read Graham these days are the bits on business: “If you want to make money at some point, remember this, because this is one of the reasons startups win. Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low… So if you can figure out a way to get in a design war with a company big enough that its software is designed by product managers, they’ll never be able to keep up with you.”

Chapter 3 is a different kettle of fish. In “What You Can’t Say,” Graham starts by asking what heresies a time traveler from the future might be surprised by in our era. Then he broadens his scope: “I want to find general recipes for discovering what you can’t say, in any era.” This is not, of course, his true aim. As the chapter goes on, it gradually shifts away from being a how-to guide on identifying heresies toward being a combat manual for waging war on political correctness. It’s a deft tactical maneuver. Rather than standing up and shouting Larry Summers was right! (though he does mention him in passing), he merely suggests that smart people are more likely than others to “think unthinkable thoughts,” and advises that they be cautious in what they say.

As Graham allegorically explains: “Suppose in the future there is a movement to ban the color yellow. Proposals to paint anything yellow are denounced as ‘yellowist,’ as is anyone suspected of liking the color. People who like orange are tolerated but viewed with suspicion. Suppose you realize there is nothing wrong with yellow. If you go around saying so, you’ll be denounced as a yellowist too, and you’ll find yourself having a lot of arguments with anti-yellowists. If your aim in life is to rehabilitate the color yellow, that may be what you want. But if you’re mostly interested in other questions, being labeled as a yellowist will just be a distraction. Argue with idiots, and you become an idiot.”

At other times, he’s more explicit: “You can attack labels with meta-labels… The spread of the term ‘political correctness’ meant the beginning of the end of political correctness, because it enabled one to attack the phenomenon as a whole without being accused of any of the specific heresies it sought to suppress.” And: “What counts as pornography and violence? And what, exactly, is ‘hate speech’? That sounds like a phrase out of 1984.” And: “So when you see statements being attacked as x-ist or y-ic (substitute your current values of x and y), whether in 1630 or 2030, that’s a sure sign that something is wrong. When you hear such labels being used, ask why.”

Here Graham is advocating what countless smart people do but don’t talk about: Being iconoclasts internally without starting arguments wherever they go. They think outside of the box, but speak within it. “The problem is,” he sighs, “there are so many things you can’t say. If you said them all you’d have no time left for your real work. You’d have to turn into Noam Chomsky.” An awful fate for a hacker, indeed.