The State of Natural Language Programming

gManZboy writes "Brad Meyers (and co) of the Human Computer Interaction Institute at Carnegie Mellon have written an interesting paper about the state of natural language programming. They point out that well understood HCI principles aren't finding their way into relatively new languages like Java and C#."

Comments

Programming in english sucks anyway

[Qzukk]

Inevitably you end up with an artificially rigid language structure that sounds like something that nobody would EVER say. Perfectly easy to read, after all, who wouldn't understand what "ADD VAR1 TO VAR2 GIVING VARX", but who the hell would use the word "giving" in such a way. It's a nightmare to learn or write, at least for English-speaking people who would have to constantly fight years of learning to speak real English to make up for the fake english in the language.

Re:Programming in english sucks anyway

[Anonymous Coward]

Witness--why everyone hates legalese in EULA's. Achieving unambiguous precision with English is HARD.

Re:Programming in english sucks anyway

[Pxtl]

imho, natural language programming languages are awful because they add a tiny bit of verbal legibility in exchange for a) losing nice obvious visual cues like { and } and b) missing something painfully obvious:

We learn math pretty friggin' soon after learning to spell. And at that point, you never write "one plus one equals two" ever again, if you ever did.

The fact is that comptur language has a closer relationship mentally to math than to english. So why not use mathematical language? Its even better, as its not tied to a single human language (who wants to translate "plus" into Swahili?)

IMHO, modern commercial languages do suck for not learning from their more academic peers (Java, I'm looking in your direction - inner classes rock, but they're no excuse for all the missing stuff).

But for "englishoid" languages, I learned VB first and then Java, and I have to say the first thing I loved about Java was the unambiguous { and } blocking.

I'm all for using natural english in the parts of programming where it belongs - like flow control, function calls, class definitions, etc. But having unambigous "this is a block" characters helps mental consistency, and using mathematical syntax helps people understand the more mathematical concepts (although the C = as assignment thing is an abomination - := pwns it).

I don't buy it.

[vontrotsky]

I disagree with the article's assumption that interesting programming errors are due to people being unable to express themselves "naturally" in code. Rather, I find that almost all errors worthy of debugging come not understanding the problem domain correctly.

jeff

Natural language programming.

[Adhemar]

The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.

- Edsger Wybe Dijkstra, "On the foolishness of natural language programming".
An interesting read.

Good point!

[goldspider]

One thing that programming languages force upon you (the programmer) is the ability to get what you want using the least possible resources.

Natural language, while easier for beginners, would make for horribly inefficient code and would be undesirable for any sizeable application.

Wow.

[cbiffle]

Well, I'm not sure if it's that nobody read the article, or if nobody actually understood it, but.

We've had a lot of posts about "OH NO! COBOL!" Yes, yes, I agree with you -- pretending to be English usually results in awkward and unnatural syntaxes. One of the advantages of a formal syntax like most programming languages is that it clicks the brain into a different mode. (How many of you can read sigs like 2b||~2b? I thought so.)

But that's not really the paper's main aim. It makes a couple of notes that all of us, particularly those of us in language design, could benefit from.

1. People tend to deal with collections in the aggregate far more often than they step through them an item at a time. The example given was "set the nectar of all the flowers to 0." Look past the syntax for a moment and look at how simple that is.

2. Debugging the traditional way sucks. Did anyone actually read that bit at the end about the 'Why?' questions, and look at the screenshots? Holy crap. That's really impressive.

Of course, I may be biased, because the points made in the article are basically the same that underlie a language I'm currently designing. :-) (And no, I'm not using Englishy COBOL syntax.)

Is this a good idea?

[hugesmile]

It seems that the effort here is to allow end users to state their "problem" in natural language, and then a program gets generated to solve their problem.

Right now that happens - only the program gets generated by programmers (sometimes outsourced to India!)

Unfortunately, what the user says they want, and what they really want are usually very different things. Natural Language Programming really doesn't solve that problem.

The critical piece is the Designer, who sits between the end user and the programmer, and asks the tough questions: "Do you really want that? Let me explain the implications of what you just asked for." "How critical is that piece of functionality that you just added on a whim, but it just added 3 years to the project plan?" "You're asking for the data to be selected this way, but really there's no use for that - have you considered selecting the data this other way?" etc.

Re:Is this a good idea?

[Taladar]

The difficult thing with programming isn't usually the syntax but the fact that most people can't cope with the computer doing exactly what they tell it to do.

Specialsied languages are not just for programming

[EmbeddedJanitor]

Natural languages are often not the best way to express problems/concepts concisely. The use of specialised languages is not something that is specific to programming. We (humans) have special languages for all branches of mathematics, chemistry (H2O...), physics (E=Mc2), music, drawing house plans.... These specialised languages came about because natural languages do not provide an effective means for communicating these ideas. For an example, consider some music written in a natural language: "Big drum beat followed by a bit of silence then a soft ....." Imagine trying to read and play that.

Programming is also something that is easier to express in a specialised language. Sure we can make some things more human readable but does that make it easier to understand? The hard part of programming isn't reading/writing the code so much as knowing what structures and concepts to use. Making programming more natural language like will not really make programming easier, you still need skill and practice. Using the music analogy again: I don't play music and can't read music score (the language of music). If Beethoven's fifth (if he ever had a fifth) was rewritten in a natural language it would not make it easier for me to play; I'd still need a whole lot of practice with a piano or whatever to play effectively. Relative to aquiring the piano skills, I expect learning to read sheet music would be relatively simple.

Where natural languaages might help is in system design and requirement capture. Still, however, I think that most often things go wrong because when people are expressing their thoughts in a natural language they use very woolly thinking and use vague terms.