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#."
If
Natural Language is not making its way into Programming
Then
Programming should make its way into Natural Language
Else
Continue
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.
Well, duh! That's because if, according to the article...
> The goal is to make it possible for people to express their ideas in the same way they think about them.
#include // Do What I Mean
thingy main (thingy list) { Sort thingy // wave hands
No, like this
With the guy's name on the right
No, I guess the middle initial deserves its own column. No, I didn't think of that.
But don't print the middle initial.
No, not like that.
Eew, that font sucks.
Yeah, like that.
No, like it was before.
Yeah, no--wait. I gotta talk to my boss.
He said to do it like this.
But he didnt like it.
Fuck this, I'll pay some guy in India to do it.
}
Given the state of natural language on /. this isn't going to work :-)
John.
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
An interesting read.
Write a Natural Language Compiler and you'll find that programmers can't write in a Natural Language. Can you imagine what would happen when you have to understand, not the flow of the code, not the overall process of the application(s), but HOW the writer was THINKING when they wrote the code? I've worked on a couple interesting projects where the programmers originally were involved in the physical business process, and eventually ended up coding (don't ask). When I had to edit their code, there was NO way of understanding it unless you actually talked to them and realized how they were thinking about the problem. It's not that the code was so poor, but they wrote code based on how they'd seen the business operate, and that just didn't translate nicely into straightforward code.
:)
Personally, I don't see how creating a language that encourages this behaviour can be a good thing. Isn't this the point of learned programmers? The ability to translate real world situations into easy to understand processes? Then again, I'm no language development guru.
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
YOU FORTH LOVE IF HONK THEN
And here's some filler text to compensate for /.'s sucktacular lameness filter. Blah blah blah. "It won't be any more frightening than the time I climbed up an elevator shaft with my teeth," said Sunny.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
Granted, it was by no means a fast runner, but you could write more or less plain English to it:Who could possible be confied by this code?
Notice the brilliant little keyword called "it", that you could use with "put" and "get". Neat, simple, easy!
eulogy
"Good news, everyone!"
The solution of course was to tell Apple Script that regardless of what hapens, just issue the open application command and stop caring. I spent a good hour or so digging through documentation until I finaly found how to do this, and the answer is so blaringly obvious that it makes one feel stupid when they realize they should have known it all along:That's it.
T Money
World Domination with a plastic spoon since 1984
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.