Lampson’s argument was that hardware would become so cheap that “almost everyone who uses a pencil will use a computer,” and that these users would be able to use “reliable software components” to put together complex programs. “As a result, millions of people will write non-trivial programs, and hundreds of thousands will try to sell them.”⁵

A poet, however, might wonder why Lampson would place poetry making on the same spectrum of complexity as aircraft design, how the two disciplines — besides being “creative”—are in any way similar. After all, if Lampson’s intent is to point toward the future reduction of technological overhead and the democratization of programming, there are plenty of other technical and scientific fields in which the employment of pencil and paper by individuals might produce substantial results. Architecture, perhaps, or carpentry, or mathematics. One thinks of Einstein in the patent office at Bern. But even the title of Lampson’s essay hints at a desire for kinship with writers, an identification that aligns what programmers and authors do and makes them — somehow, eventually — the same.

Both writers and programmers struggle with language. The code at the beginning of this chapter is in Microsoft’s C#, one of thousands of high-level programming languages invented over the last century. Each of these is a “formal language,” a language “with explicit and precise rules for its syntax and semantics,” as the Oxford Dictionary of Computing puts it. Formal languages “contrast with natural languages such as English whose rules, evolving as they do with use, fall short of being either a complete or a precise definition of the syntax, much less the semantics, of the language.”⁶ So these formal dialects may be less flexible and less forgiving of ambiguity than natural languages, but coders — like poets — manipulate linguistic structures and tropes, search for expressivity and clarity. While a piece of code may pass instructions to a computer, its real audience, its readers, are the programmers who will add features and remove bugs in the days and years after the code is first created. Donald Knuth is the author of the revered magnum opus on computer algorithms and data structures, The Art of Computer Programming. Volume 3 of the Art was published in 1973; the first part of Volume 4 appeared in 2011, the next part is “under preparation.” If ever there was a person who fluently spoke the native idiom of machines, it is Knuth, computing’s great living sage. More than anyone else, he understands the paradox that programmers write code for other humans, not for machines: “Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”⁷ In 1984, therefore, he famously formalized the notion of “literate programming”:

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.⁸

Good code, then, is marked by qualities that go beyond the purely practical; like equations in physics or mathematics, code can aspire to elegance. Knuth remarked about the code of a compiler that it was “plodding and excruciating to read, because it just didn’t possess any wit whatsoever. It got the job done, but its use of the computer was very disappointing.”⁹

To get the job done — a novice may imagine that this is what code is supposed to do. Code is, after all, a series of commands issued to a dumb hunk of metal and silicon and plastic animated by electricity. What more could you want it to do, to be? Knuth answers: code must be “absolutely beautiful.”¹⁰ He once said about a program called SOAP (Symbolic Optimal Assembly Program) that “reading it was just like hearing a symphony, because every instruction was sort of doing two things and everything came together gracefully.”¹¹

We are now unmistakably in the realm of human perception, taste, and pleasure, and therefore of aesthetics. Can code itself — as opposed to the programs that are constructed with code — be beautiful? Programmers certainly think so. Greg Wilson, the editor of Beautiful Code, an anthology of essays by programmers about “the most beautiful piece of code they knew,”¹² writes in his foreword to that book:

I got my first job as a programmer in the summer of 1982. Two weeks after I started, one of the system administrators loaned me Kernighan and Plauger’s The Elements of Programming Style … and Wirth’s Algorithms + Data Structures = Programs … [These books] were a revelation — for the first time, I saw that programs could be more than just instructions for computers. They could be as elegant as well-made kitchen cabinets, as graceful as a suspension bridge, or as eloquent as one of George Orwell’s essays.¹³

Knuth himself is careful to limit the scope of his aesthetic claims: “I do think issues of style do come through and make certain programs a genuine pleasure to read. Probably not, however, to the extent that they would give me any transcendental emotions.”¹⁴ But in the many discussions that programmers have about craftsmanship, elegance, and beauty, there is an unmistakable tendency to assert — as Wilson does — that code is as “eloquent” as literature.

“Hackers and Painters” provoked an equally famous takedown titled “Dabblers and Blowhards” by the painter and programmer Maciej Ceglowski:

It is true that both painters and programmers make things, just like a pastry chef makes a wedding cake, or a chicken makes an egg. But nothing about what they make, the purposes it serves, or how they go about doing it is in any way similar …

With the exception of art software projects (which I don’t believe Graham has in mind here) all computer programs are designed to accomplish some kind of task. Even the most elegant of computer programs, in order to be considered a program, has to compile and run. So just like mechanical engineers and architects, computer programmers create artefacts that have to stand up to an objective reality. No one cares how pretty the code is if the program won’t work. The only objective constraint a painter has is making sure the paint physically stays on the canvas (something that has proven surprisingly challenging). Everything beyond that is aesthetics — arranging coloured blobs in a way that best tickles the mind of the viewer.¹⁵

Paul Graham has been hugely successful as a programmer and venture capitalist, and his essays about technology and business are sometimes thought-provoking and insightful. But his writings about art are full of majestically fatuous statements delivered with oracular certainty: “One of the reasons Jane Austen’s novels are so good is that she read them out loud to her family. That’s why she never sinks into self-indulgently arty descriptions of landscapes, or pretentious philosophizing.”¹⁶ And, “The paintings made between 1430 and 1500 are still unsurpassed.”¹⁷ But for Graham’s primary readership of programmers, these pronouncements are the foundational caissons on which his grand art-hacking equivalence rests. Ceglowski the painter is skeptical:

You can safely replace “painters”… with “poets,” “composers,” “pastry chefs” or “auto mechanics” with no loss of meaning or insight … The reason Graham’s essay isn’t entitled “Hackers and Pastry Chefs” is not because there is something that unites painters and programmers into a secret brotherhood, but because Paul Graham likes to cultivate the arty aura that comes from working in the visual arts.¹⁸