Code Poems

Immersed, by necessity, in technical matters lately, I began to wonder what my vocation, software, and my avocation, poetry, have in common. (Meanwhile my readers, if any remain, began to wonder if I was ever going to post again.) The literary lawyers go on about the intimacy between poetry and the law and compile an immense anthology devoted to attorney-poets. Who better to speak for the programmers than I? And I do have some company in these two interests: Richard Gabriel, the well-known Stanford computer scientist, is a poet, and among the poet-bloggers Mike Snider and Ron Silliman, two poets as different as you’re likely to find, both write software for a living. Less illustrious, perhaps, than Wallace Stevens and James Russell Lowell and Archibald MacLeish, but computer science is an infant profession while the lawyers have been with us forever.

What the programmer shares with the poet is parsimony, and here we leave law far behind. Programmers, like poets, often labor under near-impossible conditions for practice, and for fun; Donald Knuth, responsible for TeX, the world’s best typesetting program, says that his favorite program is “a compiler I once wrote for a primitive minicomputer that had only 4096 words of memory, 16 bits per word. It makes a person feel like a real virtuoso to achieve something under such severe restrictions.” A popular game in computer science is to try to write the shortest possible program, in a given language, whose source code is identical with its output. Is this any different from writing poems in elaborately complex forms, like sestinas or villanelles, or playing bouts-rimé? In a sense, it’s the constraints that make the poetry.

Successive versions of the same program shrink, even as they improve. In Version 1.0 the developers usually lack, like Pascal in his letters, the time to make it shorter. In 2.0 excess code is pruned, methods and interfaces are merged that at first appeared to have nothing in common, more is done with less. Successive drafts of the same poem shrink the same way, for the same reason. The Waste Land was supposed to have been cut by Ezra Pound from five times its present length. (Pound claimed that he “just cut out all the adjectives.”) Whether it wound up any good is a topic for another day; that it wound up better than it started no one can reasonably doubt.

Good programming requires taste. Certain constructs — long switch or if/else blocks, methods with a dozen arguments or more, gotos, labels, multiple return statements, just about anything that looks ugly on the page — these must make you queasy, your fingers must rebel against typing them. Some programmatic and poetic strategies look eerily alike. The classic way to avoid switch and if/else statements in code is polymorphism, which closely resembles ambiguity in poetry.

Donald Knuth maintains a complete list of errata for all his books, and pays $2.56 ($.02⁸) for every new error you find. In most human endeavor the perfect is the enemy of the good, and many people who have never written a program or a poem might regard Knuth’s quest for perfection as insane. Randall Jarrell once defined a novel as “a long stretch of prose with something wrong with it,” which is amusing but overbroad. A poem is a stretch of verse with something wrong with it; a program is a stretch of code with something wrong with it. A novel is a stretch of prose with something hopelessly wrong with it. For poets and for programmers, perfection seems always a few revisions away. This may be an illusion, but it’s an illusion that the novelist, the civil engineer, certainly the lawyer, cannot share.

In truth, however, yesterday’s code had more in common with poetry than today’s. The great lyric code poems, the brilliantly compressed algorithms, have mostly been written, and live on in the native libraries that all modern programmers use but few read. They are anthologized in Knuth’s three-volume opus, The Art of Programming, one volume each for fundamental algorithms, semi-numerical algorithms, and sorting and searching. Where yesterday’s tiny assembly programs were lyric, today’s n-tier behemoths are epic, and epic programs, like epic poems, never fail to have something hopelessly wrong with them. Nonetheless, in programming we have entered the age of the epic, and there’s no going back. Once, in a bout of insanity, I interviewed for a programming job at a big bank, and encountered a C programmer who liked to work close to the metal. He asked me to write a program that would take a string of characters and reverse it. I asked if I could use Java and he said sure. My program was a one-liner:

The point being that Java has a built-in method to reverse a string, called, remarkably, reverse(). Now I knew exactly what he wanted. He wanted me to use one of the classic algorithms, which have been around since at least the 1960s and are described in Jon Bentley’s excellent book on programming in the small, Programming Pearls, among other places. He wanted a nostalgia tour. But these algorithms are great poems that have already been written. Any decent function library, like Java’s, includes them, and it makes no sense to reinvent them, priding yourself on your cleverness. I didn’t get the job.

(Update: Rick Coencas comments. mallarme comments. Ron Silliman points out in the comments that he’s not a software developer after all; I apologize for the error.)