Slashdot Mirror
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#."
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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
On that site, there's http://www.alice.org/whatIsAlice.htm which says
So, this is just like Visual Basic. I know that can't be true, or else Microsoft would be marketing VB as NLP. So what am I missing?
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Cobol, anyone?
...
Multiply x by y to get something or the other
An interesting read.
One of the big problems this approach will have to overcome (in my opinion) is that people generally tend to order their thoughts in a manner specific to their native language. A development environment that seems intuitive and easy to use to a native English speaker might be backwards or obtuse to a person who natively speaks another language. To clarify; I'm not speaking strictly of grammatical structure of language, but of a seemingly inherent difference in the way people learn things based on what language is used in the teaching. For this reason it has always seemed better to me for programmers to learn a new, common language (that of the higher-level compiler they are interested in) so that when they work with others, everyone is on the same page (similar to scientists and doctors using Latin nomenclature).
I'd imagine that a "natural language" system could be developed with different approaches based on the native tongue of the programmer, but I would think this would damage the benefits of commonality that other languages now enjoy.
That's about as far as I got. I guess he didn't really express his ideas in the same way that I wanted to think about them.
Which nicely illustrates the point that there's always a "semantic gap" associated with natural languages, which builds up because people have different ways of thinking. The semantic gap is even wider when one of the entities being communicated to happens to be a machine. There's a reason why traditional programming languages are precise and exact...it's so that the gap is reduced - the machine will do exactly what you tell it to do...even then we have a disconnect between what the programmer's thinking, and the code that he's writing.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Natural language isn't precise enough for serious programming. I personally wouldn't enjoy typing so much for no added benefit. It seems like this sort of thing only has value amongst people who are learning to programming. Why would a mainstream language like Java or C# cater to this bunch?
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.
"Ask not what your country can do for you." --John F. Kennedy
IMO it's nothing more than a better way to introduce *newbies* into programming.
Would would any programming want to code in english? To me this:
myvar++
makes more sense than:
increase the variable myvar by one please
Do we really want people who can't understand something as simple as "myvar++" to be programming in the first place? Seems to me we NEED a barrier to entry. There're enough lousy programmers out there already.
Well, I'm not sure if it's that nobody read the article, or if nobody actually understood it, but.
:-) (And no, I'm not using Englishy COBOL syntax.)
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.
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.
There are two main features of applescript. 1) The english like syntax 2) the ability to control other applications Of the two the second is by far the most important. But to gether they create a new programming experience. Because most of the complexity is sequestered in the applications you are comtrolling the applescript code tends to be very short. On average I would say my applescripts are about 30 lines with only 5 - 10 lines of working code the rest is error catching and handleing. Because of the syntax it is very easy to read the code moths or years later. Also the having short code helps. BUT the most important thisis tha becasue the code is sort YOU CAN START AGAIN. How much code is kludged because no one wants to rip out and recode 1000 or more lines of code? There is a real benefit in short code that you can read
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.
Engineering is the art of compromise.
Where's my compilable flowchart? They're more universally understandable across human languages/cultures, including geek/wonk/artist/customer/PHB, than text. They can be intermediate-compiled to text procedures for lexical parsing techniques. And they're much easier to design, program, debug, maintain and document, especially for parallel/distributed/networked applications. They're natural language without speech. Where's my gcc flowchart preprocessor?
--
make install -not war