On Code and Poetry. A conversation.
by Angus Croll
READER: Why are you writing about computer code in a literary magazine?
ME: I want to explore the similarities between code and poetry.
READER: Seriously? Computer code has nothing in common with poetry. Poetry is grace, code is function. Poetry connotes, code commands.
ME: But both try to represent complex ideas in concrete form. Poets build intimate impressions out of inadequate words. Coders instruct alien objects using a vocabulary rooted in the middle ages. Both perform their own kind of sorcery with a language designed for more humdrum tasks.
READER: Oh please! Poets are aesthetes, fashioning sentient imagery through language and form. Programmers are emotionally challenged philistines tapping out lists of commands for dumb machines.
ME: And yet both spend their days shuffling words and symbols, struggling to make a reality out of abstractions. Both are human. Both aspire to elegance of a sort.
READER: Computer Code? Elegant? How can zeroes and ones be elegant?
ME: Programmers rarely work in zeroes and ones. Their code is written for human consumption just as much as for machines. Humans must understand code because it’s their job to debug and maintain it—moreover, expressive (even beautiful) code is the means by which new idioms proliferate and the language evolves.
READER: Okay, but the code must work. Doesn’t that leave very little wiggle room for expression?
ME: Poems must work too. Poems whose language strays from the imagery by which they were conceived will be miserable failures. Luckily language offers flexibility to poets and coders alike. I write JavaScript, and JavaScript can be written in many ways. Human programmers argue passionately (and at length) about the elegance and expressivity of idioms and clause structures which to the computer are all the same. JavaScript authors develop their own voice and often have a distinct style.
READER: Show me what you mean.
ME: A simple example. Officially JavaScript expects a semicolon at the end of each statement (just as most Western European languages officially expect a full stop at the end of each sentence). But in reality it’s optional. So:
And so on. There are dozens more variants, I’ve barely scratched the surface. I didn’t even mention comma-first zealotry, or the dangling comma fanatics. Programmers argue about this stuff as though it matters. They attach significance to stylistic minutiae…
READER: …and you’re going to tell me poets do that too. But that doesn’t mean code is poetry—not even close.
ME: So now imagine I want to write a function to put Dante’s name into a sentence: “My favorite poet is Dante degli Alighieri”.
I could do so imperatively—from beginning to end, with a linear narrative:
This works just fine, but you’d need a wooden heart not to recoil at such a clunky rendition. It’s supposed to be an announcement but reads like a peregrination. We could re-write it as a single expression:
Alternatively we could use JavaScript’s new arrow syntax and spread operator:
The differences between these approaches are essentially stylistic. The computer just compiles and shrugs — from its perspective it’s all pretty much the same and the result is always identical.
As my friend Jacob Thornton (cofounder of @bumpers) puts it “It’s precisely this potential for expression which makes [JavaScript] not only bearable, but actually exciting… Like an artist painting a bowl of fruit, if I had to express each work the same way — with the only variety being in the fruits themselves — I’d surely have gone mad by now”.
READER: Interesting. How does this apply to poetry?
ME: Ask any ten poets to portray the same thing and you’ll probably get ten very different poems. Admittedly that’s difficult to prove because you’ll rarely come across two poems describing an identical phenomenon (Ozymandias perhaps?), and in any case all poets write from a unique perspective. However, one way is to consider different translations of the same poem.
The Bible has been translated into English perhaps more than any other text, so let’s consider the first couplet of one of its most well-known poems—A Time For Everything (Ecclesiastes 3) which was re-used as the lyric for the song Turn! Turn! Turn!
Here’s the famous King James version (1611):
To every thing there is a season, and a time to every purpose under the heaven:
A time to be born, and a time to die; a time to plant, and a time to pluck up that which is planted;
Now check out the Douay–Rheims version from 1582:
All things have their season, and in their times all things pass under heaven.
A time to be born and a time to die. A time to plant, and a time to pluck up that which is planted.
Fast-forward to the 1972 Living English translation:
There is a season of everything, and a time of every concern under the heavens
A time of being born and a time of dying, a time of planting and a time of grubbing out what was planted.
Three poems that say exactly the same thing, but choose to say it in different ways (and notice, by the way, with quite different punctuation). Notice the parallel with the code variations I illustrated earlier?
READER: Yes I do. So you’ve illustrated how both code and poetry use a diversity of approaches to represent the same thing. But—come on—code has no pitch or melody. No meter, stress or foot. No connotation, no metaphor, no life, no grace, no pain!
ME: Sure, code has very few of those qualities (a lot of poetry has very few of those qualities too by the way). If we’re only concerned with outcomes, then of course code is not poetry. But if there is a common thread it’s in the creative process, the obsession with form and syntax, the purging of deadweight so that every remaining word or symbol has purpose and the overall effect is as readable (and, yes, elegant) as it is meaningful.
READER: I see. Are you done now?
ME: Almost. Check out how Sylvia Plath solves the “sayIt” problem in JavaScript.
READER: *Sigh*
___________________________________________________________________
With thanks to Sara Simon, Joel Turnbull and Johnny Megahan for previewing this essay and suggesting improvements.
Lascia un commento