Why language isn't computer code: Language and computers

Abstract

"Detail-oriented" may be a stable and global personality trait: people with it will not only write prose and code painstakingly, but will not bounce cheques, leave home without their keys or sign the restaurant bill before inspecting it. [...]they are often verbose.

The differences between formal and natural languages are as big as the similarities

ON JULY 20th, Kyle Wiens, who runs two technology companies, wrote a blog post for Harvard Business Review titled "I Won't Hire People Who Use Poor Grammar. Here's Why." The nub:

If you think an apostrophe was one of the 12 disciples of Jesus, you will never work for me. If you think a semicolon is a regular colon with an identity crisis, I will not hire you. If you scatter commas into a sentence with all the discrimination of a shotgun, you might make it to the foyer before we politely escort you from the building.

The jokes don't quite work. (If you think "Apostrophe" belongs among James, Peter and John, your problems are bigger than grammar. The substitution of "apostrophe" for "apostle" is so silly I misunderstood the joke the first time round.) But the sentiment is sensible enough:

Good grammar is credibility, especially on the internet. In blog posts, on Facebook statuses, in e-mails, and on company websites, your words are all you have. They are a projection of you in your physical absence. And, for better or worse, people judge you if you can't tell the difference between their, there, and they're.

You won't be hired at The Economist, either, if you can't tell a semicolon from a colon or a colon from a colonoscope. Mr Wiens goes on to say that "In the same vein, programmers who pay attention to how they construct written language also tend to pay a lot more attention to how they code." This is plausible. "Detail-oriented" may be a stable and global personality trait: people with it will not only write prose and code painstakingly, but will not bounce cheques, leave home without their keys or sign the restaurant bill before inspecting it. Such people are valuable in many jobs.

There are also direct analogies between natural language and computer code. Well-written code is light on the computer's memory, and runs smoothly; well-written prose is easy on the reader's working memory, and reads easily. Badly written code will cause errors in execution; badly written prose can cause errors in interpretation. Some people will never learn to write. Some will never learn to code.

But Mr Wiens goes too far on one point. (And not when he says he has a "zero tolerance approach", which most professional editors would change to "zero-tolerance approach".) He says "at its core, code is prose." No, it isn't.

He appeals to authority: "according to Stanford programming legend Donald Knuth [programmers] are 'essayists who work with traditional aesthetic and literary forms.'" I'm not qualified to judge Mr Knuth's status as a legendary programmer, but I am qualified to say that he was either being poetic here, or talking out of his colon. Show me a block of code in picaresque, tragedy or folktale.

Or let me appeal to authority myself:

Although formal and natural languages have many features in commontokens, structure, syntax, and semanticsthere are many differences:

ambiguity: Natural languages are full of ambiguity, which people deal with by using contextual clues and other information. Formal languages are designed to be nearly or completely unambiguous, which means that any statement has exactly one meaning, regardless of context.

redundancy: In order to make up for ambiguity and reduce misunderstandings, natural languages employ lots of redundancy. As a result, they are often verbose. Formal languages are less redundant and more concise.

literalness: Natural languages are full of idiom and metaphor. If I say, "The other shoe fell," there is probably no shoe and nothing falling. Formal languages mean exactly what they say.

A hippy linguist railing against sticklers and their "proper grammar"? No, this is from Allen Downey, Jeffrey Elkner and Chris Meyers' book "How To Think Like A Computer Scientist: Learning with Python".

The disanalogies between computer code and language are as important as the analogies. A single missing character or bit of puntuation will cause a computer program to run improperly, while the "c" omitted from "punctuation" back there probably only caused you to slow down for a fraction of a second, if you noticed it at all. The literalness of computers is the source of human nightmares; if they ever decide that the world will be better off without humans, computers will wipe us out without shedding a tear. The difference between human communication and computer code is also behind much real-world confusion and irritation. Decades of brilliant research and billions of dollars spent has given us computers that can handle human language only as well as the flawed Siri, when the average five-year-old, with no formal training at all, can understand language Siri couldn't dream of parsing.

The understanding of "language as code" (or "code as prose") is behind some of the more wrong-headed forms of language sticklerism. Using "its" for "it's" is a mistake that annoys sensible readers. But it doesn't cause their brains to crash in the same way that using "whiel" for "while" will cause a program to malfunction. Believing that such errors are equivalent and that writing "crashes" on a single glitch, though, leads to an obsessive focus on rules over style and content. This probably leads further to worrying overly about non-rules ("that"/"which" or split infinitives, say). If language-as-code is taken too literally, the idea of optional rules, levels of formality, dialects, idiolects, variation, natural change over time and sheer fun will not compute. All the rules must be obeyed all the time. Of course different programmers have different styles (and there are a few "optional rules" in computer languages), but style is not syntax: programmers are not free to play with the rules as Joyce or Faulkner did.

There are kinds of writinglegal writing and technical documentation, saywhere the importance of eliminating all ambiguity makes prose almost like computer code. Mr Wiens may be right to hire only people who write like programmers. But most of us know computer wizards who can't write competently (they're too busy coding), and good writers who couldn't program "Hello, world!" (they're too busy writing on the tools the coders built for them). Fundamentally, good writers are empathetic, human and stylish. Good coders are literal, formal and algorithmic. To take the coding-as-prose analogy too far is to misunderstand the essence of both.