Poe on Programming

One of the strongest influences on my programming has always been an essay I read in my sophomore year of high school, around about the same time I began to feel the magic of programming. Mr. Carino was a young man just out of college, a Slayer fan and ardent Twain admirer, and a man who would disappear mysteriously a year later. That year, though, he gave the most electric class I've ever taken, and one of the works we read in American Literature was Edgar Allan Poe's The Philosophy of Composition.

Code As Poetry

In The Philosophy of Composition, Poe attempts to describe exactly how he composed The Raven, simply because he's never seen such an attempt before. While we might be wise to doubt his motives (as did TS Eliot), it nevertheless may be interpreted to provide solid principles for the construction of a program.

Before we do so, I must first convince you that code should be read as poetry instead of prose. Since this will always be a matter of opinion, and I know that many people will disagree, my argument will be short and simple.

When you read prose, you read it as if it is being narrated to you; whether by a narrator, a character in the story, or many characters, the distinguishing characteristic of prose is its similarity to speech. We find that it is allowed a much greater freedom of verbosity, so long as it accomplishes its goal of conveying a plot to its reader.

Poetry, on the other hand, is an abstract block of words in which every one must carry meaning if the poem is to be any good. We value the poem for the beauty not only of the story or image given, but of the way in which it is constructed as well. It tends to be much denser and more compact than prose. When you read it, you must proceed carefully and consider the meaning of each word, and each group of words, and pay attention for double meanings and allusions if you are to grasp it fully.

To help us decide how we read code, let's go to a particularly nice bit of it, and meditate on it for a moment. Did you read it as if it were speech, or poetry? Did it have a narrative "flow" for you, or was it something of an abstract block of "words"?

Of course, code is really neither prose nor poetry; it is a distinct art form of which Poe could not have been aware. I like to think that it may be read much more closely to poetry than to prose, and we will proceed from here as if this were true.

Unity of Impression

If any literary work is too long to be read at one sitting, we must be content to dispense with the immensely important effect derivable from unity of impression- for, if two sittings be required, the affairs of the world interfere, and everything like totality is at once destroyed. But since, ceteris paribus, no poet can afford to dispense with anything that may advance his design, it but remains to be seen whether there is, in extent, any advantage to counterbalance the loss of unity which attends it. Here I say no, at once. What we term a long poem is, in fact, merely a succession of brief ones- that is to say, of brief poetical effects. It is needless to demonstrate that a poem is such only inasmuch as it intensely excites, by elevating the soul; and all intense excitements are, through a psychal necessity, brief. For this reason, at least, one-half of the Paradise Lost is essentially prose- a succession of poetical excitements interspersed, inevitably, with corresponding depressions- the whole being deprived, through the extremeness of its length, of the vastly important artistic element, totality, or unity of effect.

In the first sentence of this paragraph, Poe provides an alternate metric to Yegge's metric of "code size" - that of "unity of impression". Beautiful code is that which is not composed of "a succession of brief.. poetical effects", but of just the poem. It is code without filler, bureaucracy, or artifice, regardless of how long it is.

As a practical matter, not all programs may be written in this manner. In an operating system kernel, a great deal of "corresponding depressions" — documentation, error handling, and interrupt handling — must be interspersed in between the "poetical effects", making it "essentially prose".

This does not change the fact that the Linux kernel or a BSD kernel is a thing of beauty, just as Paradise Lost is great despite "the extremeness of its length". Instead, it should give us motivation for our programs, to write them with as few depressions as possible so as not to drag down their unity of impression.

A great example of code as poetry is OpenBSD's tail¹, which I referenced in a previous post. After I sat down with it for an hour, it was extremely clear to me what it did. In the beginning, it set out the patterns of code which would continue throughout, enabling me to quickly find my way to the part that mattered, despite my relative unfamiliarity with C.

It is a great strength of the Unix philosophy that each bit of code may be kept as brief, self-contained, unified, and therefore beautiful. It is a pleasure to work with tools which have been pared down to their bare bits instead of expanded to encompass ever more functionality.

Design for a Purpose

My next thought concerned the choice of an impression, or effect, to be conveyed: and here I may as well observe that throughout the construction, I kept steadily in view the design of rendering the work universally appreciable. I should be carried too far out of my immediate topic were I to demonstrate a point upon which I have repeatedly insisted, and which, with the poetical, stands not in the slightest need of demonstration- the point, I mean, that Beauty is the sole legitimate province of the poem.

If beauty is the sole province of poetry, I propose that data transformation is the sole province of the computer program. (I am not the first to do, although I cannot recall where I read it first). Therefore, when designing a program, we should at all times keep in mind the transformation which we wish to achieve, and discard all those parts which do not assist in that goal.

While this seems at first straightforward, it is important to consider that programs are designed for humans and by humans. Unlike poetry, most code is not generated by its author for the appreciation of the masses. Instead, it is designed to fulfill a purpose, specifically to achieve a certain data transformation.

Just as very few great poems were authored by multiple people, very few great programs have been authored by multiple people. If we consider long programs to be composed of many poems separated by dull bits, their great parts are almost exclusively those parts over which their maintainers have slaved to bring to a state of terse beauty.

If you must have many people working on a program, it is of the utmost importance that they all know and share an understanding of what exactly it is that the program is intended to accomplish. Without this deep shared knowledge of intent, the program will lack a single impression, or effect, to be conveyed, and likely fail to impress.

All The Rest

The length, the province, and the tone, being thus determined, I betook myself to ordinary induction

Once you have determined the length, purpose, and tone of your program, the rest is, as they say, trivial. Poe dedicates the rest of his essay to applying the principles discussed in this essay, and showing how "The Raven" falls ever so simply out of them. If you write a program while at all times keeping in mind its unity of purpose and the impression you intend to convey, perhaps you will find some beauty in it.

I hope that you will read the essay in its entirety; I'm sure that I have failed to do it justice here. Although it is of questionable merit as a method of writing the next "The Raven", perhaps it will help you think about how to write your next program.

¹ pybloxsom is another, and reddit readers provide many more.