What Programming Can Learn From Literature

Ever since I first mentioned I was writing a book that imagined the great authors writing software, I've encountered a steady stream of skeptics who react to the premise with eye-rolls or incredulity.
10/22/2014 09:30 am ET Updated Dec 22, 2014

Ever since I first mentioned I was writing a book that imagined the great authors writing software, I've encountered a steady stream of skeptics who react to the premise with eye-rolls or incredulity. Whether it's "Programming has nothing to do with literature! Get your filthy JavaScript away from my beloved authors!" or the converse, "Get your snooty literature away from my beloved JavaScript!," the perceived schism between technology and the humanities looms large.

Yet this so-called schism is a relatively modern phenomenon. Right now there's an overwhelming demand for software professionals, and this has spawned a sort of tech exceptionalism that dismisses the liberal arts as a sideshow for mushy technophobes and academics. That feels narrow minded. Those with a background in the humanities are more likely to have an inductive, open-ended approach to reasoning and are more likely to probe beyond the standard methodologies and question accepted practices. The chronology of great writers reads like a laundry list of language innovators: Homer, Chaucer, Shakespeare, Milton, Woolf, Joyce, Kerouac.

It's easy dismiss coding as a rote exercise -- a matter of following rules. But natural language is subject to rules of its own: grammar, syntax, spelling. The best writers test these rules, bend them, or break them outright, and in doing so they keep the language alive. Programmers break rules too. When a good programmer breaks a rule, it's not for effect -- they're trying to overcome an arbitrary convention that's hampering their ability to express themselves. Software's indebted to these programmers who are curious enough to experiment with language, because that's how new patterns and techniques are conceived. So I wanted to apply the quirks and transgressions of the great authors to JavaScript, to see where that pushed the language.

But isn't code simply a list of instructions for a computer? Sure, a program must make sense to a computer, but it's equally important that it be understood by humans (not least the human who wrote it). In fact the durability of a program pretty much depends on the ability of the author to express its logic in human terms. Programs are written and maintained by humans, and if they can't readily understand the purpose of a program, they won't try to improve it and they can't fix it when it (inevitably) goes wrong.

Since the 1960s, we've been hearing that soon computers will start writing their own programs. But it takes ingenuity, nuance, and emotional intelligence to craft quality code. Any computer with those qualities would probably be pretty good at writing novels too.

As a long-term coder and literature devotee, I'm the first to admit that writing literature and writing code are two very different processes -- yet I've become increasingly aware of the things they have in common. In both literature and code, words take their meanings from their context. Both literature and code use words (or symbols) to represent complex ideas in concrete form. Then they assign that idea to an object: a word, an expression, a function or method in code, perhaps a character or a place in literature. (Functional programming uses higher order functions to represent ideas of ideas, a concept familiar to readers of Woolf or Borges). Both literature and code are expected to more-or-less conform to rules of logic (even an experimental work of surrealism defines its own logic of a sort). In fact, literature's logic can be at least as complex as a program's--take Dostoevsky's Stavrogin, who "if he believes, doesn't believe that he believes, and if he doesn't believe, doesn't believe that he doesn't believe."

I chose to have these authors write JavaScript because it's the coding language that most resembles natural language. It's at its most expressive when combining simple idioms in original ways; its syntax, which is limited yet flexible, promotes innovation without compromising readability. Just as natural language has no dominant paradigm, JavaScript developers can select from a grab bag of approaches -- procedural, functional and object-oriented -- and blend them as appropriate. Most ideas can be expressed in multiple ways, and many JavaScript programmers can be identified by their distinctive coding style.

Because JavaScript has relatively few constraints, it leaves more creative wiggle room. Several eminent JavaScripters have exploited this wiggle room to experiment with new voices. Jacob Thornton (who wrote Bootstrap, the web's most popular development framework) speaks eloquently on the attraction of JavaScript to those of us who value creativity over predictability: "It's precisely this potential for expression which makes it 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."

To be clear, I'm not advocating that developers should go into work tomorrow and re-write their core utility as a Milton sonnet. Software teams need to collectively figure out the style that works for them. Most of the ambitious stuff is best reserved for personal projects and . . . well, maybe an odd book. That said, many of JavaScript's syntax choices have little or no effect on the generated bytecode. A prose analogy would be the difference between a semicolon and an em dash. It's a stylistic choice that doesn't alter the meaning in any significant way.

In my book, I try to show the breadth of styles and sensibilities that can be expressed in code. Hemingway's code is intentionally unsophisticated. He wants you to feel the awe of the Fibonacci sequence without him talking all over it. Shakespeare's solution is a "calckulation in two acts employing the humorous logick of java-scripte" (with comments in iambic pentameter). Austen appears to seek the approval of the grammar pedants while winking furiously at those who can see beyond the artifice, Borges generates prime numbers by imagining long-limbed monsters climbing a staircase, Nabokov exploits the rotational delta between Terra and Antiterra to predict the next happy number, Tupac raps out his solution, and Kerouac... oh but now I see your eyes rolling...

Angus Croll is the author of What If Hemingway Wrote Javascript?.