The English-Likeness Monster Stalks a New Generation of Programmers - raganwald's posterous

Every generation of programmers seems doomed to reinvent the failures of the previous generation, albeit in cooler and hipper ways. Consider the "English-Likeness Monster," a/k/a writing programs in English.

After all, if you use English to tell the computer to move a block from one pile to another, how hard can it be to have the computer understand how to move money from one account to another or copy a record from disk to magnetic tape?

And yet, it turns out that for all but trivial domains, English is too imprecise. It becomes a read-only language. Meaning, that once you figure out how to get the computer to do the right thing, the command is easy to read. But figuring out which English command achieves the desired result is a nightmare.

So to write English-ish AppleScript, you had to have a model in your head of what was underneath the parser, and then you had to play a little game of getting the parser to do the right thing. It's far simpler to learn a precise, unambiguous language and manipulate the parser directly.

In other words, a programming language.

And note well: Not all programming languages are either "obviously easy to read' and "precise and unambiguous." Many try to be easy to write and end up being a little like the English-likeness monster in that you have to play with them a bit to get the desired result. Semicolons are optional unless the next line begins with any of five special characters. Parentheses are optional. You can write if x then y or y if x. 

And of course, the lessons continues to be re-learnt whenever someone discovers the joy of a "Domain-Specific Language." DSLs are usually read-only. The fantasy of a business executive writing requirements directly in a testing DSL or model writing DSL always seems to require unicorn blood to lubricate the apparatus. This would be a reasonable requirement (A test might be written once but read many times), except that if it is hard to write, it might be buggy in subtle ways. Code has to be easy to write if you really want to trust it.

In the end, compromise is the worst of both worlds. Programming languages need to be strict and unambiguous. They need to be easy to understand. And by understand, we are not talking about the ridiculous notion of veryLongVariableNames or function keywords instead of arrows, we are talking about being easy to reason about.

And you simply can't reason about English.