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#."

33 of 387 comments (clear)

  1. Proposal by Anonymous Coward · · Score: 5, Funny

    If
    Natural Language is not making its way into Programming
    Then
    Programming should make its way into Natural Language
    Else
    Continue

  2. Programming in english sucks anyway by Qzukk · · Score: 4, Insightful

    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.
    1. Re:Programming in english sucks anyway by Anonymous Coward · · Score: 4, Insightful

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

    2. Re:Programming in english sucks anyway by Pxtl · · Score: 4, Insightful

      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).

    3. Re:Programming in english sucks anyway by truthsearch · · Score: 3, Insightful

      "Real" natural language processing means the computer can interpret what you're trying to say no matter how you say it. As long as grammer is correct, there can be a variety of ways of saying things. NLP tries to be smart at figuring out sentances it's never seen before by learning from past conversations. Of course with the complexity of natural language this is difficult and doesn't always work, but we've learned enough about how to do it that we should already have ways for computers to "understand" more natural instructions.

    4. Re:Programming in english sucks anyway by wmshub · · Score: 5, Informative

      Did you two (the parent & grandparent of this) really read the article? It's not about programming in English, it's not about syntax, it's about structure.

      For example, they pointed out that people think about tasks in an event-driven way, their example is "when pac-man is out of lives, the game is over". But they must program by finding where in the program the number of lives goes down, and inserting the code there. An event driven language would simplify.

      Their other example was that most languages make people think in loops, when they really want to operate on a group. Saying "for (i = 0; i len; ++i) { x[i] += 10; }" it a really clumsy way to express what people thought, which was "add 10 to everything in x".

      Anyway, I agree that parts of the article don't sound too helpful, but they aren't talking about writing in English; they're talking about changing the structure of languages to more closely match what people think.

  3. Is it any wonder? by Tackhead · · Score: 5, Funny
    > They point out that well understood HCI principles aren't finding their way into relatively new languages like Java and C#."

    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.

    ...most ideas just don't work that way.

    #include // Do What I Mean

    thingy main (thingy list) { Sort thingy
    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. // wave hands
    But he didnt like it.
    Fuck this, I'll pay some guy in India to do it.
    }

  4. Not gonna work by JohnGrahamCumming · · Score: 5, Funny

    Given the state of natural language on /. this isn't going to work :-)

    John.

  5. I don't buy it. by vontrotsky · · Score: 5, Insightful

    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

    1. Re:I don't buy it. by Bastian · · Score: 4, Interesting

      One thing that I have noticed about any debate about what programming facilities will most help programmers to write more bug-free code or spend less time debugging is that the debate is based entirely around anecdote.

      I would love to see some numbers on the frequency and nature of bugs in software, and I want to see these numbers broken up by language as well as by appliction domain. I suspect that a comprehensive collection of such statistics doesn't exist, since I haven't seen any empirical data enter into the various debates to which they would apply.

      Until someone spends some more time researching this information, I doubt that the development of programmign technology will advance in a fashion any more directed or smooth than science and technology did back in the fourteenth century.

  6. Hmmmm by Profane+MuthaFucka · · Score: 3, Insightful
    The article wasn't really that clear on exactly what NLP is, but they pointed at something called Alice.

    On that site, there's http://www.alice.org/whatIsAlice.htm which says
    Rather than having to correctly type commands according to obscure rules of syntax, students drag-and-drop words in a direct manipulation interface. This user interface ensures that programs are always well-formed. In addition, Alice reifies object-based programming by providing animated, on-screen 3D virtual objects.

    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!
  7. Oh NO! Not Again! by kaalamaadan · · Score: 3, Insightful

    Cobol, anyone?

    Multiply x by y to get something or the other ...

  8. Natural language programming. by Adhemar · · Score: 5, Insightful
    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.
  9. Write a Natural Language Compiler by TheUnFounded · · Score: 5, Interesting

    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. :)

  10. People think in their languages. by Mr.Spaz · · Score: 3, Insightful

    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.

  11. I didn't RTFA... by GillBates0 · · Score: 3, Insightful
    The goal is to make it possible for people to express their ideas in the same way they think about them.

    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
  12. Natural Language isn't for Serious Programming by I_Love_Pocky! · · Score: 3, Insightful

    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?

  13. Good point! by goldspider · · Score: 4, Insightful

    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
  14. What is the PURPOSE of natural language? by Anonymous Coward · · Score: 3, Insightful

    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.

  15. on a bumper sticker by devphil · · Score: 5, Funny


    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)
  16. Wow. by cbiffle · · Score: 4, Insightful

    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.)

  17. Is this a good idea? by hugesmile · · Score: 4, Insightful
    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.

    1. Re:Is this a good idea? by Taladar · · Score: 5, Insightful

      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.

    2. Re:Is this a good idea? by Erik+Hollensbe · · Score: 3, Insightful

      AppleScript is a pretty decent example of how this works well - it's close enough, in fact a little to far for my taste... often finding the "right words" becomes a chore.

      example:

      set bDmg to true
      display dialog "Compress DMG?" buttons {"Yes", "No"} default button 2

      if the button returned of the result is "Yes" then
      set sDmgFormat to " -format UDZO "
      else
      set sDmgFormat to " -format UDRW "
      end if

      From a script I use to build .dmg files.

  18. English and Computer Language dont Mix Well. by jellomizer · · Score: 3, Interesting

    It Would be nice to send out the specs for the program and run it threw the parser and get the program you want but the truth is that normal Human Language wasn't designed for problemsolving espectilly in some of the details that programming requires. Things like nested Lists. (1,2,3,(2,4,3,2),5,2,(2,3,5,6)) Which are easy to learn to program and install are much harder with natural language.

    Make a List with the values 1, 2, 3, then this is a list of 2,4,3,2, now we are back in the first list with some more values of 5 then 2, now we get an other list inside this list as 2,3,5,6 Now we finish both list.

    As you see in english this is clumzy I am sure someone with a better master of english may be able to make it a little more percise but still just giving up and using the () makes it a lot easier to see and understand then using a bunch of words.

    Most human languages were made Thousands of years ago. And came from languages 10s of thousands of years old if not Millions of years old. They were not designed for micro processing of infromation. They were required for more common sience reasioning. Which we as humans often fail a lot at and imagin how poor a computer would be a common sience.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  19. Re:Remember Apple Script by philge · · Score: 3, Informative

    Applescript is alive and well an dearns me a decent living. One of the main benefits of applescripts syntax is that is it alot easier to read then it is to write because of its english like language. So when you come to look at it six month later its is a lot easier to figure out what it does.

  20. Some 17 years ago ... by KlaymenDK · · Score: 4, Informative
    ... Dan Winkler created HyperCard together with Bill Atkinson.
    Granted, it was by no means a fast runner, but you could write more or less plain English to it:
    go to the last card of stack "Home"
    go to black with visual effect fade to black
    go to the previous card with visual effect venetian blinds
    get the third word of line 2 of field "Slashdot"
    put it into the messagebox
    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
  21. Re:AppleScript, anyone? by philge · · Score: 3, Insightful

    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

  22. Re:Applescript by MoneyT · · Score: 4, Interesting
    Probably because it's too obvious. I ran into that problem a few months ago. Version 6 of matlab for OS X had a unique problem in that one needed to start X11 and then start Matlab before it could be run, there wasn't a single command to do both. Of course, this lead to confusion on the part of our users, and so the simple and obvious solution would be to write an apple script to do it. That was the easy part:
    tell Finder to open application X11
    tell Finder to open application MatLab
    The problem was, in the way that Matlab was setup, the helper app used to launch MatLab in the X11 environment never truely opens (it bounces in the dock for a while and then goes away having begun the true MatLab startup. The end result of this was that since Apple Script was not being notified that the application had finished opening, it was recieving an error that startup had failed and kept retrying the start. This resulted in an infinate loop of MatLab window creation.

    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:
    ignoring all errors
    tell Finder to open application MatLab
    That's it.
    --
    T Money
    World Domination with a plastic spoon since 1984
  23. Specialsied languages are not just for programming by EmbeddedJanitor · · Score: 5, Insightful
    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.

    --
    Engineering is the art of compromise.
  24. Perl version by Black+Perl · · Score: 3, Funny
    $_ =
    q[ for ( @_ ) { push @_, sort grep /\w+/, @_ } print unpack 'A*', pack 'B*', join '',
    reverse map
    { length ( $_ ) >> 1 }
    split /\S+/
    ];eval
    --
    bp
  25. Re:Is this a good idea? i.e. apples vs grapes by faragon · · Score: 3, Interesting

    To compare the natural language (Noam Chomsky tells that it is universal for every human language) with any programming language it is quite non-sense: programming languages tends to unambiguation, to be context free and deterministic. It's quite similar to compare an image versus a verbal description of it: the image it is finite and unambiguous, while the verbal description only can be arbitrary.

    I understand that the point of this thread is to find a way to remove or to light some "translation" between the "human idea" and the "human computerized/programmed solution". For me, as the years go by, C/C++ is another language built-in myself. I can convert problems into solvable ones via computing, quite on the fly (still planning and designing the solution, but the implementation itself comes in a natural way, like the water that falls down a river).

  26. Flowcharts by Doc+Ruby · · Score: 3, Insightful

    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