Trevor Burnham

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 pro­gram­ming is Dreaming in Code, the tale of the long delayed and now ignored Chandler. The project was, in prin­ci­ple, the best of all worlds: a group of talented hackers and design­ers building open-​​source software on a generous budget. The project leader? Mitch Kapor, himself a talented hacker best known for the inno­v­a­tive spread­sheet app Lotus 1–2-3. (There’s an excel­lent inter­view with him in Founders at Work.) The language? Python, probably the most hacker-​​friendly language there is with suitable libraries for building cross-​​platform graph­i­cal apps. Their com­peti­tor? Microsoft Outlook, a user-​​hostile piece of bloat.

In Graham’s view, which I’ll call “language deter­min­ism,” Chandler should’ve suc­ceeded. Granted, they weren’t using Lisp, but Graham ranks Python just below Lisp in his language hier­ar­chy. And, of course, Graham is mainly writing about webapps. (One of the recur­ring themes of Dreaming in Code is: Maybe Chandler should’ve been a webapp.) Still, Hackers & Painters and Dreaming in Code seem to occupy dif­fer­ent planes of exis­tence: In one, startups that bring smart, pas­sion­ate hackers together always win against the lum­ber­ing mass that is Big Software. In the other, even the most promis­ing projects can suffer setbacks, peter out, and even­tu­ally 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 rhetor­i­cal exag­ger­a­tions, or am I over­look­ing 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 prop­er­ties a language needs in order to catch on among hackers, from the per­spec­tive of someone design­ing a language. The clear subtext is: “Why hasn’t Lisp caught on (yet)?” One property he suggests is very com­pelling: “The language is built in layers. The higher-​​level abstrac­tions are built in a very trans­par­ent way out of lower-​​level abstrac­tions, which you can get hold of if you want.”

I’m reminded of the only under­grad CS course I took, Data Struc­tures. 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 ques­tions asked us to find an item in a par­tic­u­lar kind of linked list, given the code for the LinkedList class. Now, there was a very natural and effi­cient way to do this, but it was impos­si­ble because the per­ti­nent property was marked as private. So I figured out a kludge that let me find the item anyway, but with a lot of grossly unnec­es­sary tra­ver­sal. 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, effi­cient algo­rithm were given full credit. Needless to say, I was upset—my answer was the only one anyone gave that would’ve compiled! That expe­ri­ence was part of the reason why I stopped taking CS courses, and majored in Math instead while dabbling in pro­gram­ming as a hobby. In hind­sight, perhaps I should’ve blamed my pro­fes­sor 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 grad­u­ally, iterate rapidly. The most striking theme is respect for your users, which he jus­ti­fies on prac­ti­cal grounds: “It’s hard to stay inter­ested in some­thing you don’t like yourself. To make some­thing good, you have to be thinking, ‘wow, this is really great,’ not ‘what a piece of shit; those fools will love it.’” This is some­thing that we don’t hear often enough in the coding/​design world, and it makes for a pleasant conclusion.

Reflect­ing on the book as a whole, I think the most merit is in the early “Graham as Public Intel­lec­tual” chapters, rather than the later “Graham as Hacker King” ones. This is unex­pected; surely Graham’s expe­ri­ences better qualify him to write about pro­gram­ming than about deep philo­soph­i­cal ques­tions? Yet somehow, “Why Nerds are Unpop­u­lar” and “What You Can’t Say” stand out as the most tren­chant, original and subtle writings in the book. Graham’s essays on eco­nom­ics, “How to Make Wealth” and “Mind the Gap,” are also first-​​rate, and I’m sur­prised that they haven’t achieved broader traction in the lib­er­tar­ian com­mu­nity. His writings on pro­gram­ming lan­guages, on the other hand, are intrigu­ing but ulti­mately unper­sua­sive. Learning Lisp feels like some­thing I should do, in the same sense that doing yoga every day is some­thing I should do. It’s not some­thing 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, unfor­tu­nately, is less preva­lent in Graham’s post-​​YC writings. He’s now writing for a fervent com­mu­nity that knows and loves him, and has certain expec­ta­tions of him. That’s under­stand­able. Still, I hope PG has another mass-​​market book left in him. Even as a startup founder, it’s nice to read some­thing not related to startups (or English lit­er­a­ture) from time to time.

[Addendum: Here is Graham himself giving a talk a few months after the book’s pub­li­ca­tion, entitled “Great Hackers.” In it, he clearly artic­u­lates how the lib­er­tar­ian 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 admin­is­tra­tor. That’s like having the Rolling Stones play at a bar mitzvah.”]

Tags:   hackers & painters   philosophyComments Off

This is the seventh in a series of posts about Paul Graham’s book Hackers & Painters.

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 com­peti­tors at every turn. He adds a second dat­a­point: 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 Trav­e­loc­ity 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 lan­guages, but the highest-​​level language. Why don’t other pro­gram­mers acknowl­edge this? He supposes that a pro­gram­mer uses a language called Blub, which lies some­where on the language spectrum near Java and Python. “As long as our hypo­thet­i­cal Blub pro­gram­mer is looking down the power con­tin­uum, he knows he’s looking down. Lan­guages less powerful than Blub are obvi­ously less powerful, because they’re missing some feature he’s used to. But when our hypo­thet­i­cal Blub pro­gram­mer looks in the other direc­tion, up the power con­tin­uum, he doesn’t realize he’s looking up. What he sees are merely weird lan­guages. He probably con­sid­ers them about equiv­a­lent 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.”

Fol­low­ing this line of rea­son­ing to its con­clu­sion, Graham writes, “the only pro­gram­mers in a position to see all the dif­fer­ences in power between various lan­guages are those who under­stand the most powerful one.” Which, in his mind, is Lisp. He’s con­fi­dent of this fact because Lisp is the only language with macros, and whenever he looks at another language, he wonders how those pro­gram­mers can get anything done without macros.

In the next chapter, “Revenge of the Nerds,” Graham claims that main­stream lan­guages are grad­u­ally moving ever closer to the ideal, Lisp, which was invented by John McCarthy all the way back in the 1950s. (Fas­ci­nat­ingly, McCarthy invented the language only as a the­o­ret­i­cal notation. He had no intent of actually “running” that notation until one of his grad students, Steve Russell, wrote the first Lisp inter­preter.) Ruby, for instance, is very nearly Lisp with a prettier syntax. The chapter includes an appendix of code examples that demon­strate the superior brevity of Lisp and Ruby for a par­tic­u­lar (con­trived) task. To my mind, the JavaScript code, though slightly longer, is the most readable; but this is unde­ni­ably 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 cer­tainly, there are some lan­guages (Python, Scala) are superior to their more popular rivals (PHP, Java). So it seems that I have no alter­na­tive: 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 “Suc­cinct­ness is Power.”]

Tags:   hackers & painters   philosophyComments Off

This is the sixth in a series of posts about Paul Graham’s book Hackers & Painters.

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 sur­prised to see him use the heading “Seat Belts or Hand­cuffs?” for a section weighing dynamic vs. static typing in the book’s tenth chapter, “Pro­gram­ming Lan­guages Explained.” He grudg­ingly admits that “some smart people seem to like static typing, so the question must still be an open one.” (In the next chapter, he elab­o­rates 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 com­par­i­son to this aston­ish­ing claim about open source software: “I’m cer­tainly not against the idea of property, and yet I would be very reluc­tant to install software I didn’t have the source for.” Why? Because if he has the source, he can fix any bugs he encoun­ters. And, more impor­tantly, so can everyone else. “Lots of smart people have examined the source code of open source oper­at­ing 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 state­ment, and I’m told that PG is no hyp­ocrite: He runs nothing but Firefox and vi on his machine. But he’s also a fan of closed-​​source webapps. The dis­tinc­tion 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 unpleas­ant, but using them as the foun­da­tion for such a broad prin­ci­ple is rather eccen­tric. 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, explain­ing terms like “high-​​level language.” It seems to have been written pri­mar­ily to bring the mass-​​market reader up to speed for the next chapter, “The Hundred Year Language.”

Having estab­lished that we are now living in a Renais­sance of pro­gram­ming lan­guages, he wonders what will happen over the next century. Some of his con­clu­sions are uncon­tro­ver­sial: Main­stream lan­guages will be more high-​​level than they are today, with more layers of abstrac­tion between them and the machine. Proces­sors will, after all, be many times more powerful than they are today, even if Moore’s law is indeed petering out. “Inef­fi­cient software isn’t gross. What’s gross is a language that makes pro­gram­mers do needless work.”

He lambasts object-​​oriented pro­gram­ming, but predicts that it will stick around as an unfor­tu­nate legacy of the 20th century: “Though I don’t think it has much to offer good pro­gram­mers, except in certain spe­cial­ized domains, it is irre­sistible to large orga­ni­za­tions.” This is a sur­pris­ing stance. To most pro­gram­mers, I would say, there is some­thing intu­itively very appeal­ing about the clean sep­a­ra­tion of concerns that well-​​encapsulated objects provide so naturally.

But the most aston­ish­ing claim of the chapter is that “par­al­lelism will be some­thing that is avail­able if you ask for it explic­itly, but not ordi­nar­ily used. This implies that the kind of par­al­lelism we have in a hundred years will not, except in special appli­ca­tions, be massive par­al­lelism. I expect for ordinary pro­gram­mers it will be more like being able to fork off processes that all end up running in parallel.” Really? There is, today, a resur­gence in interest in func­tional lan­guages because the number of cores in com­put­ers is increas­ing much more quickly than the power of indi­vid­ual cores is. In the year 2010, a popular word proces­sor run on a single core seems rather pokey. Everyone is trying to build their appli­ca­tions for multiple cores. Future com­pil­ers will almost cer­tainly be smart enough to provide us with par­al­lelism auto­mat­i­cally. Cores may be a million times faster, but text editors will have a billion times as much bloat.

Tags:   hackers & painters   philosophyComments Off

This is the fifth in a series of posts about Paul Graham’s book Hackers & Painters.

I am a bit per­plexed at “A Plan for Spam” (Chapter 8): In it, Graham describes Bayesian fil­ter­ing, and his surprise at how effec­tive it is compared to the more time-​​consuming alter­na­tive of building a com­pli­cated set of black­lists and whitelists. Because this method of spam pro­tec­tion requires a large corpus (ideally an indi­vid­u­al­ized 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 vir­tu­ally any other recent e-​​mail client. I find it hard to imagine a world in which Bayesian spam fil­ter­ing isn’t used, and I now receive very little spam in part because of it. So, this essay is com­pletely 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 nec­es­sar­ily 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 influ­en­tial, it feels out of place in a book aimed at less tran­sient concerns.

Yet taken as a com­ple­ment to the fol­low­ing chapter, “Taste for Makers,” the spam essay conveys a subtle and impor­tant point: People tend to neglect a simple, elegant solution that requires a lot of thought up front (in this case, an under­stand­ing of Bayesian prob­a­bil­ity updating) when a more com­pli­cated, tedious, and less effec­tive approach is avail­able that requires little intel­lec­tual exertion (the blacklist-​​whitelist approach). The prop­er­ties 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 resem­bles nature… Good design is often strange.” This last is inter­est­ing: “I’m not sure why,” Graham admits. “It may just be my own stu­pid­ity. A can opener must seem mirac­u­lous 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 nec­es­sar­ily true.”

The best advice is at the end of the chapter. “Intol­er­ance for ugliness is not in itself enough,” Graham warns, “You have to under­stand 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. Cul­ti­vate 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 effec­tively if our e-​​mail clients auto­mat­i­cally crawled suspect links, thereby imposing harsh band­width costs on spammers. It is a scheme that seems just crazy enough to work, and I’m a bit sur­prised that I haven’t heard of it being used in practice.]

Tags:   hackers & painters   philosophyComments Off

This is the fourth in a series of posts about Paul Graham’s book Hackers & Painters.

Why are so many pro­gram­mers lib­er­tar­i­ans? Some have sug­gested that, as design­ers of complex systems, they nat­u­rally maintain a pref­er­ence for simpler, more elegant legal frame­works. 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: Pro­gram­mers, unlike most people, directly create wealth. What others learn from reading Greg Mankiw, pro­gram­mers learn first­hand: “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 injus­tice! An expe­ri­enced pro­gram­mer would be more likely to think is that all? The top 5% of pro­gram­mers probably write 99% of the good software.”

The eco­nom­ics lesson con­tin­ues in the next chapter, “Mind the Gap,” in which Graham urges the reader to consider income dis­par­i­ties to be not only morally accept­able, but a cause for cel­e­bra­tion: “Could it be that, in a modern democ­racy, vari­a­tion 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 excep­tion being when the rich are the ben­e­fi­cia­ries of gov­ern­ment). 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 clar­i­fies, dis­tanc­ing himself from one of the weakest economic argu­ments con­ser­v­a­tives 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 rem­i­nis­cent of the 1946 classic Eco­nom­ics in One Lesson, but with pithier prose. My favorite passage: “In a free market, prices are deter­mined by what buyers want… To say that a certain kind of work is under­paid is thus iden­ti­cal with saying that people want the wrong things. Well, of course people want the wrong things. It seems odd to be sur­prised by that. And it seems even odder to say that it’s unjust that certain kinds of work are under­paid. Then you’re saying that it’s unjust that people want the wrong things. It’s lam­en­ta­ble that people prefer reality TV and corndogs to Shake­speare and steamed veg­eta­bles, but unjust? That seems like saying that blue is heavy, or that up is circular.”

I’ve often said that lib­er­tar­i­an­ism needs a more relat­able public face than Drew Cary, host of the frus­trat­ing reason​.tv series. I wonder if the affable PG ever con­sid­ered hosting his own polit­i­cal 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 influ­ence the world. As an econ­o­mist would say, funding and advising startups is his com­par­a­tive advantage.

[Addendum: For more on PG’s moti­va­tions, see his more recent (and brief) essay “Why YC,” par­tic­u­larly the last two paragraphs.]

Tags:   hackers & painters   philosophy1 Comment

This is the third in a series of posts about Paul Graham’s book Hackers & Painters.

If you told the average man on the street that there’s a website called Hacker News, he’d assume that it’s a nefar­i­ous launch­pad for cyber­at­tacks, 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 digres­sive med­i­ta­tion that takes that ety­mo­log­i­cal 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 favor­able, used to praise clev­er­ness, while the other is damning. Why is this? “Ugly and imag­i­na­tive solu­tions have some­thing in common: they both break the rules. And there is a gradual con­tin­uum between rule breaking that’s merely ugly (using duct tape to attach some­thing to your bike) and rule breaking that is bril­liantly imag­i­na­tive (dis­card­ing Euclid­ean space).” He then spends the remain­der of the 6-​​page essay talking about smart hackers’ distrust of authority.

One of the plea­sures of reading printed essays as opposed to web-​​based ones is that you can infer a lot about the intended audience from the ref­er­ences made. In a blog, you’re allowed to make all the obscure ref­er­ences you want as long as they’re hyper­linked 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 express­ing it more clearly. “There is some­thing very American about Feynman breaking into safes during the Man­hat­tan Project,” he writes, evi­dently expect­ing his audience to have already absorbed Richard Feynman’s won­der­ful autio­bi­o­graph­i­cal adven­tures. Across the page, he shows a picture with the subtitle: “Jobs and Wozniak with a cir­cum­ven­tion device, 1975.” There is no cor­re­spond­ing text. He expects his readers to know enough about the founding of Apple for this picture to evoke the founders’ blue box shenani­gans. Nor, when he describes the inven­tion of Unix, does he feel com­pelled to add: And Unix is a really impor­tant oper­at­ing system!

Graham missteps when he proposes, “It seems to me that there is a Laffer curve for gov­ern­ment 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 won­der­ful thing about the Laffer curve is that it captures, in a simple illus­tra­tion, an impor­tant yet coun­ter­in­tu­itive fact: Raising taxes can lower tax revenue. Most people don’t consider this pos­si­bil­ity, and there­fore believe that deficits can always be paid off later by raising taxes. By contrast, just about everyone realizes that an all-​​powerful gov­ern­ment 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 obser­vant. 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 broad­band was rare and AJAX not yet invented, I can’t recall. Cer­tainly, it would have been an aston­ish­ing essay in 1995, when Graham was devel­op­ing one of the first webapps, Viaweb. There are some moments that feel espe­cially prophetic—“Clients shouldn’t store data; they should be like tele­phones. In fact they may become tele­phones, or vice versa.”—but ulti­mately the essay is for­get­table by virtue of being familiar and, in the year 2010, uncon­tro­ver­sial. The title is a ref­er­ence to Bill Gates’ book The Road Ahead; with Windows Azure, even Microsoft is going down the other road now.

[Update: In assess­ing the pre­science of “The Other Road Ahead,” I neglected to examine the foot­notes in the 2004 book version. One is bor­der­line 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 fore­sight 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 nec­es­sary, 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 rev­o­lu­tion­ary features when it debuted three years later, and Graham acknowl­edges 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.”]

Tags:   hackers & painters   philosophyComments Off

This is the second in a series of posts about Paul Graham’s book Hackers & Painters.

The second chapter of Hackers & Painters, the one that lends it title to the book, is easily con­densed into a common aphorism: “Pro­gram­ming 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 over­played. “In hacking, like painting, work comes in cycles. Some­times you get excited about a new project and you want to work sixteen hours a day on it. Other times nothing seems inter­est­ing.” Well, isn’t that true of all endeav­ors? From studying eco­nom­ics to Quiz Bowl to building CarlWIki, I remember my entire under­grad­u­ate expe­ri­ence as an alter­nat­ing series of bursts of interest. Even when I had a 9-​​to-​​5 job working at a college book­store, there were days when I was excited about effi­ciently pro­cess­ing textbook returns (seri­ously!), and other days that were like watching grass grow.

There are also parts that ring hollow, perhaps simply because Graham and I are dif­fer­ent kinds of hackers. He writes, “I like debug­ging: it’s the one time that hacking is as straight­for­ward as people think it is. You have a totally con­strained 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 dis­cov­er­ing unex­pected subtleties—what I’d thought was a simple design might turn out to be quite intri­cate and delicate—but not outright bugs.

The high­lights 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 com­pa­nies want to decrease the standard devi­a­tion of design outcomes because they want to avoid dis­as­ters. But when you damp oscil­la­tions, 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 dif­fer­ent kettle of fish. In “What You Can’t Say,” Graham starts by asking what heresies a time traveler from the future might be sur­prised by in our era. Then he broadens his scope: “I want to find general recipes for dis­cov­er­ing what you can’t say, in any era.” This is not, of course, his true aim. As the chapter goes on, it grad­u­ally shifts away from being a how-​​to guide on iden­ti­fy­ing heresies toward being a combat manual for waging war on polit­i­cal cor­rect­ness. 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 unthink­able thoughts,” and advises that they be cautious in what they say.

As Graham alle­gor­i­cally explains: “Suppose in the future there is a movement to ban the color yellow. Pro­pos­als to paint anything yellow are denounced as ‘yel­low­ist,’ as is anyone sus­pected of liking the color. People who like orange are tol­er­ated but viewed with sus­pi­cion. Suppose you realize there is nothing wrong with yellow. If you go around saying so, you’ll be denounced as a yel­low­ist too, and you’ll find yourself having a lot of argu­ments with anti-​​yellowists. If your aim in life is to reha­bil­i­tate the color yellow, that may be what you want. But if you’re mostly inter­ested in other ques­tions, being labeled as a yel­low­ist will just be a dis­trac­tion. 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 ‘polit­i­cal cor­rect­ness’ meant the begin­ning of the end of polit­i­cal cor­rect­ness, because it enabled one to attack the phe­nom­e­non as a whole without being accused of any of the specific heresies it sought to suppress.” And: “What counts as pornog­ra­phy and violence? And what, exactly, is ‘hate speech’? That sounds like a phrase out of 1984.” And: “So when you see state­ments being attacked as x-​​ist or y-​​ic (sub­sti­tute your current values of x and y), whether in 1630 or 2030, that’s a sure sign that some­thing is wrong. When you hear such labels being used, ask why.”

Here Graham is advo­cat­ing what count­less smart people do but don’t talk about: Being icon­o­clasts inter­nally without starting argu­ments 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.

Tags:   hackers & painters   philosophy2 Comments