“Computer, how many new email messages do I have?”

“About 300.”

“How many interesting ones?”

“When is an email message ‘interesting’?”

“Let’s call an email interesting if it came from work or from someone I wrote to in the past week.”

“You have 52 interesting messages.”

“Please list my email with the interesting ones first.”

Will we ever converse with our computers like this? What I find compelling about this dialog is that beyond the difficult activities of natural language processing and understanding, it requires the computer to learn something new (in this case, a temporary definition of “interesting” messages). So not only is the user talking with the computer, but is programming it. This is the dream of natural language programming.

In 1978, Edsger Dijkstra, a giant in Computer Science, lambasted efforts to develop programming languages based upon English and other natural languages in his lecture “On the Foolishness of Natural Language Programming.” In it, Dijkstra rails against efforts at the time (like NLC) that directly translated programming language statements into English sentences and paragraphs. He views the research into natural language programming as attempts to remove “the obligation to use a formal symbolism”.  He then argues that formal symbolism is vital for concise communication, and that replacing programming languages with English will simply facilitate “making statements the nonsense of which is not obvious.”

He’s right. The reason why we have different notations for different concepts is because we can be more concise, precise, and comprehensible in them. The statement “t = t + 1” is more concise than the phrase “increment the variable ‘t’ ”, (which in C or Java could also mean “t++” or “++t”, and have different side effects). Matrix calculations in NLC (expressed in English) are harder to understand than in  Matlab or standard mathematical notation. Visual interfaces are excellent for dialog layout, especially when compared to rows of object initialization statements with specific pixel values or font sizes. Entity/Relationship diagrams facilitate understanding database structure. I cannot imagine playing PacMan over the phone with someone trying to describe what is happening in English prose. Calculus, set notation, predicate logic, mathematical graphs, and many other formal symbolic systems enable us to understand and discuss highly complex concepts. As Dijkstra states, “thanks to [formal symbols], school children can learn to do what in earlier days only genius could achieve.”

But what about mundane day-to-day concepts?  Why must we say “John = new Person();” when we really want to say “John is a person.”? Why must we click though a calendar program instead of being able to say “Set up an executive meeting next Tuesday morning at the earliest time people are available.”?  Why do we have to rewrite systems to horizontally scale instead of being able to tell our server, “Replicate and synchronize this web site onto this second machine.” Yes, these statements have huge amounts of ambiguity, and the development effort to create environments that can infer, simulate, or ask about the unknown information is currently infeasible. But that’s the point: natural language is ambiguous because we know so much about each other’s motives and goals.

We don’t want to use natural language programming to calculate integrals or invert matrices. I hope that no one wants to write FFT algorithms in English sentences.  We want to use natural language programming to describe and interact with day to day concepts including email, meetings, appointments, deadlines, and people. Because there are many times in which we don’t care about the precise details and simply want to get things done, in these domains natural language programming is enabling, ideal, and wise.