You: You’re writing about computer code and poetry? At the same time?

Me: I want to explore their similarities.

You: Seriously? Computer code has nothing in common with poetry. Poetry is grace, and 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.

You: But poets are aesthetes, fashioning sentient imagery through language and form. Programmers are philistines tapping out lists of commands for machines.

Me: And yet both spend their days shuffling words and symbols, struggling to make reality out of abstractions. Both are human. Both aspire to elegance of a sort.

You: Computer code is 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 how new idioms proliferate and the language evolves.

You: 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.

You: Show me what you mean.

Me: Well, 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 it’s actually optional. So:

const firstName = 'Dante';
const nobiliaryParticle = 'degli';
const lastName = 'Alighieri';

could also be written as:

const firstName = 'Dante'
const nobiliaryParticle = 'degli'
const lastName = 'Alighieri'

or even:

const
firstName = 'Dante',
nobiliaryParticle = 'degli',
lastName = 'Alighieri'

or for that matter:

const firstName = 'Dante', nobiliaryParticle = 'degli', lastName = 'Alighieri'

or yet:

const [firstName, nobiliaryParticle, lastName] = 'Dante degli Alighieri'.split(' ');

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 these things as though they matter. They attach significance to stylistic minutiae—

You: And you’re going to tell me poets do that too. But that doesn’t mean code is poetry.

Me: 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:

function announceFavoritePoet(name) {
const announcement = "My favorite poet is";
if (name.firstName) {
announcement += name.firstName;
}
if (name.middleName) {
announcement += name.middleName;
}
if (name.nobiliaryParticle) {
announcement += name.nobiliaryParticle;
}
if (name.lastName) {
announcement += name.lastName;
}
return announcement;
}

This works just fine, but it’s a clunky rendition. It’s supposed to be an announcement but reads like a peregrination. We could rewrite it as a single expression:

function announceFavoritePoet(name) {
return (
'My favorite poet is ' +
(name.firstName ? name.firstName + ' ' : '') +
(name.middleName ? name.middleName + ' ' : '') +
(name.nobiliaryParticle ? name.nobiliaryParticle + ' ' : '') +
(name.lastName ? name.lastName + ' ' : '')
)
}

Less pedantic but perhaps even harder on the eyes.

There’s a more elegant way:

function announceFavoritePoet(name) {
return [
'My favorite poet is',
name.firstName,
name.middleName,
name.nobiliaryParticle,
name.lastName,
]
.filter(Boolean)
.join(' ');
}

Alternatively, we could use JavaScript’s new arrow syntax and spread operator:

name => [
'My favorite poet is',
...Object.values(name)
].join(' ')

or a string template:

name => `My favorite poet is ${Object.values(name).split(' ')}.`

or express it functionally:

name => Object.values(name).reduce(
(msg, part) => `${msg} ${part}`,
'My favorite poet is'
);

The differences between these approaches are essentially stylistic. The computer just compiles and shrugs; from its perspective, they’re all pretty much the same, and the result is always identical.

As my friend Jacob Thornton (co-founder 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.”

You: Interesting. How does this apply to poetry?

Me: Ask any 10 poets to portray the same thing and you’ll probably get 10 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. But 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 reused 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?

You: 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 every remaining word or symbol has purpose and the overall effect is as readable (and, yes, elegant) as it is meaningful.

You: I see. Are you done now?

Me: Almost. Check out how Sylvia Plath solves the “sayIt” problem in JavaScript.

words='', wordless=' '
// I am calm. I am calm.
// It is the calm before something awful.
speak = word => word?
smothered_mouthfuls(word): end()
let smothered_mouthfuls = word => (
// Dutifully swallowing words
word = words ? wordless + word : word,
words = words + word,
speak
)
let end = yet => {
// Grudgingly, my ungainly tongue
// Pokes and stirs, to render
// Empty substance-less nothings
return null, void words? yet: words
}
speak('I')('am')('your')('opus')()

You: *Sigh*


This originally appeared in the Italian magazine Utsanga.