Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

The State of Natural Language Programming 387

Posted by michael from the =-NE-== dept.
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#."
This discussion has been archived. No new comments can be posted.

The State of Natural Language Programming More

The State of Natural Language Programming

Comments Filter:

  • Proposal (Score:5, Funny)

    by Anonymous Coward on Tuesday November 16, 2004 @01:35PM (#10833060)
    If
    Natural Language is not making its way into Programming
    Then
    Programming should make its way into Natural Language
    Else
    Continue

    • on a bumper sticker (Score:5, Funny)

      by devphil ( 51341 ) on Tuesday November 16, 2004 @01:50PM (#10833296) Homepage


      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.

      • honk if you.love ruby

        ;)

    • Is this a good idea? (Score:5, Insightful)

      by hugesmile ( 587771 ) on Tuesday November 16, 2004 @02:01PM (#10833428)
      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? (Score:5, Insightful)

        by Taladar ( 717494 ) on Tuesday November 16, 2004 @02:22PM (#10833686)
        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 (Score:5, Insightful)

        by EmbeddedJanitor ( 597831 ) on Tuesday November 16, 2004 @03:35PM (#10834751)
        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.

        • In a way, the languages of mathematics and music are natural languages. Someone didn't sit down one day and enumerate all of the rules for mathematical expressions, it evolved to suit the needs of mathematicians and has retained the flexibility that results from such evolution, much like "social" languages.

          It's hard for programming languages to "evolve" in the same sense since they aren't "for humans, by humans", but we do try new language designs and find that some work better than others.

          Some of the mor

      • 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

  • Doesn't seem to say much. (Score:3, Funny)

    by BigZaphod ( 12942 ) on Tuesday November 16, 2004 @01:36PM (#10833082) Homepage
    The article seems like some kind of summary. Unless I missed something important, like, a second page or something. But basically, it seems to suggest that, even after all these years, we still aren't any closer to having a natural way to program. Huh.
    • Ha! There is a page 2. Heck, even a page 3.

      *sigh*

      Well I feel dumb. This is why I need a sign above my computer that says, "Absolutely no Internet posting before caffeine intake."
      • Actually, I still agree with your point having read all three pages. Not enough specific examples of problems in languages and what the better way would have been.
    • That was assessment also.

      However i did visit alice.org. I clicked on gallery and found no way to navigate back!

      Seems kinda of odd that a site dedicated to "natural programming" concepts would not take the time to employ "natural navigation". Hmmmmm.

  • Programming in english sucks anyway (Score:5, Insightful)

    by Qzukk ( 229616 ) on Tuesday November 16, 2004 @01:37PM (#10833090) Journal
    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 (Score:4, Insightful)

      by Anonymous Coward on Tuesday November 16, 2004 @01:40PM (#10833145)
      Witness--why everyone hates legalese in EULA's. Achieving unambiguous precision with English is HARD.
    • You mean like Cobol?
    • It might be a little rigid, but not necessarily that bad. HyperTalk goes:
      put the sum of var1 and var2 into varX

      or:
      set varX to the sum of var1 and var2

      or:
      add var1 and var2
      put the result into varX
      • I'd love to see a Hypertalk-like language come back from the deadly. Applescript is *close*, but not quite there, and Hypertalk seems to be a very obvious no-brainer choice for visual programming.

        Is it slow? Yeah, it's slow... no doubt. What you'd do is put the power in the methods of the objects, and just let Hypertalk tie the objects together. (For instance, Hypertalk might be too slow to negotiate a fast FTP download, but it's certainly fast enough to contain a statement like "if startDownload is tr
    • Looks good to me. Maybe I've been using COBOL too long.
    • Once they can make a translator that works, I'm thinking that they could make an NL compiler fairly easily. It would probably require proper grammar, but I think that you could easily rearrange words, split infinitives, etc. It seems to me that the Japanese language would be the easiest to process for tokens: it seems to be a pretty rigidly-structured language.

      I don't know that an NL compiler would be necessarily useful, though. Programming languages are meant to bridge the gap between the human and t

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

      You're right. I prefer "yielding" myself, or perhaps "motivating" on a light day.

      Then again, on the principle of never using a word where a polysyllabic construct will do, we could employ "entering the result into".

      Then again again, if I may misquote Disraeli, perhaps I'm just inebriated with the exuberance of my own verbosity now.

      Hmm. Friday mu

    • Re:Programming in english sucks anyway (Score:5, Insightful)

      by Pxtl ( 151020 ) on Tuesday November 16, 2004 @02:22PM (#10833688) Homepage
      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).
      • And at that point, you never write "one plus one equals two" ever again, if you ever did.

        This is true for primatives.

        But for even slightly more complex tasks ("Find all the people who live in New York, and add their votes."), natural language is about as good. As the tasks get more complex, natural language ("Look for your friend in this picture, then see who's standing next to him.") quickly describes things that are formal language headaches.

      • Re:Programming in english sucks anyway (Score:5, Informative)

        by wmshub ( 25291 ) on Tuesday November 16, 2004 @03:54PM (#10835060) Homepage Journal
        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.

    • Oh, you mean COBOL! (Score:3, Informative)

      by jd ( 1658 )
      I certainly believe that people drift towards computer languages that closest match the method of their thought processes, but I do not agree that you should (or even could) write a programming language that mirrors natural languages or pure thought.

      Down that path lies madness. Or Adam and the Ants.

      Fourth Generation languages expressed things in terms of the requirements, rather than the actual mechanisms involved. Such languages have been around for a while, but have largely failed in the "real world".

    • Re:Programming in english sucks anyway (Score:4, Insightful)

      by truthsearch ( 249536 ) on Tuesday November 16, 2004 @02:52PM (#10834140) Homepage Journal
      "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.

  • Is it any wonder? (Score:5, Funny)

    by Tackhead ( 54550 ) on Tuesday November 16, 2004 @01:37PM (#10833093)
    > 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.
    }

    • It's a crying shame that this post is already moderated to +5 Funny; it richly deserves an Insightful or three.
      • Sadly true. Will somebody actually RTFA and realize that 99% of the other posts are offtopic? The article isn't describing a new way to program the computer using natural language; we already have COBOL for that, and we all know how that approach works.

        The article is talking about new programming paradigms, which deprecate the old Von Neumann architecture programming model and allow for a more flexible mindset while programming. Last generation scripting languages (Python, Ruby...) would be a step in that
    • Hmm, once upon a time there was a system ->

      Donald A. Waterman, Allen Newell: PAS-II: An Interactive Task-Free Version of an Automatic Protocol Analysis System. IEEE Trans. Computers 25(4): 402-413 (1976)

       which, considering the state-of-the-art then (it was PDP 10 [wikipedia.org]) times was performing not too bad (as I thought then).

      Starting from there, I think it would be feasible today to come up with s. th. conforming to "HCI-ideas" more than particularly java which could tackle the DWIM-problem a little bett

  • Not gonna work (Score:5, Funny)

    by JohnGrahamCumming ( 684871 ) * <`slashdot' `at' `jgc.org'> on Tuesday November 16, 2004 @01:37PM (#10833105) Homepage Journal
    Given the state of natural language on /. this isn't going to work :-)

    John.
  • Is Macromedia's ColdFusion syntax. As it continues to become less tied to HTML it will be interesting to see where this goes.

    But natural language requires more typing than say C syntax.

    A EQUALS B
    A = B

    But does the thought process get speeded up. If so one needs to know how the gains and loss affect overall development.

    • Good point! (Score:5, Insightful)

      by goldspider ( 445116 ) on Tuesday November 16, 2004 @01:45PM (#10833219) Homepage
      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.
      • I don't think it would be that bad. It'd be akin to using a higher-level language like Python, where you don't care how something is sorted when you call list.sorted(), just that it's sorted. Some people think that Python is horribly inefficient, but it turns out that even 100x slower than C isn't too bad for many applications.
        • Umm, that sort example works in any language- thats why we created interfaces and APIs. In C you write a function called sort, and call it. THe end result is a sorted array you use as needed. Same in C++, Java, assembly, machine code, etc. Its not anything magic about Python.

          As for 100x slower than C not being bad- I take it you're willing to pay for all my future hardware upgrades? If not, then its bad.

    • For economy you cannot beat:

      (eq? a b)
      • Yep. Lisp - because assembler was too easy to understand.

        I'll admit that the consistency of syntax is wonderful, but that's no excuse for
        a) not having any built-in facility for BEDMAS-calculation. Some sort of standard macro for that is sorely lacking, and if its there, then the tutorial writers have to stop ignoring it - its absense is one of the language's biggest failings.
        b) totally obtuse keywords. Yes, you learn what car and cdr mean pretty fast, but they're only the beggining of Lisp's obfuscated
    • But does the thought process get speeded up.

      You mean like: Hey, that's a nice piece of code, maybe it'll help me out here <clickety>. Or something moore complex like envisioning the interworkings of a whole system in your head and trying to turn that into something useful based on recalled behaviour of snippets of symbols...

      I just don't think natural language meshes well with solution space. At best it might be useful for high-level specification.
    • [nitpick]
      You ought to say "put the value of b into a"
      [/nitpick]

  • I don't buy it. (Score:5, Insightful)

    by vontrotsky ( 667853 ) on Tuesday November 16, 2004 @01:40PM (#10833136)
    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

    • Re:I don't buy it. (Score:5, Interesting)

      by Bastian ( 66383 ) on Tuesday November 16, 2004 @01:56PM (#10833374)
      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.
      • The problem is: Define "bug" and "bug impact level". How do you do that fairly and objectively? Just getting a set of very basic terminology figured out is going to be a drawn out flame-war. (Or is going to marginalize you into a specific niche which moots the whole point from the get-go.)

        Basically it comes down to two things: time and money. Developers aren't going to spend the time to study their own bugs and development models, except when and where it helps them write better software faster. Stan
        • The project should be shielded from flame wars and unwilling developers because the people it falls to to conduct this study are folks like the faculty at the HCI research group at CMU who are trying to study how we should be programming.

          Besides, we shouldn't be working from case studies in corporations, because that would make it darn hard to do any sort of experimental controls. On the other hand, it would be easy at CMU because they have a big stinkin' pile of undergrads that they can force or pay to s

  • Hmmmm (Score:3, Insightful)

    by Profane MuthaFucka ( 574406 ) <busheatskok@gmail.com> on Tuesday November 16, 2004 @01:40PM (#10833151) Homepage Journal
    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 [alice.org] 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?
    • What your missing is an understanding of what VB, Delphi and their ilk offer, and what NLP is. I don't mean for that to sound offensive in any way, please forgive me if it does.

      VB makes creating GUI-based applications quicker (and easier, many say) by allowing you to create the user interface in a visual fashion and then attach code to the visual elements. You still have to get down there and type code though to make the application do anything aside from some "canned" interface functions.

      Alice, OTOH, i

  • Oh NO! Not Again! (Score:3, Insightful)

    by kaalamaadan ( 639250 ) on Tuesday November 16, 2004 @01:40PM (#10833152) Journal
    Cobol, anyone?

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

    • Re:Oh NO! Not Again! (Score:2, Insightful)

      by Tablizer ( 95088 )
      Cobol, anyone?

      (Or SQL for that matter. We managed to finally obsolete COBOL more or less, but SQL is still with us.)

      Anyhow, the idea behind the COBOL Natural Language push was to rid the need for programmers or at least greatly reduce their training. However, it was found that somebody with some training could translate business logic into something that the computer could understand better than amatures. In other words, with some training productivity was so much higher than some manager trying to be

  • "Computer?"

    "Working"

    "Program the holodeck to look like the inside of a seedy 1920's era Jazz Club. We need to write another time machine episode."


  • Natural language programming. (Score:5, Insightful)

    by Adhemar ( 679794 ) on Tuesday November 16, 2004 @01:41PM (#10833157)
    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" [utexas.edu].
    An interesting read.

  • Write a Natural Language Compiler (Score:5, Interesting)

    by TheUnFounded ( 731123 ) on Tuesday November 16, 2004 @01:42PM (#10833164)
    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. :)

  • People think in their languages. (Score:4, Insightful)

    by Mr.Spaz ( 468833 ) on Tuesday November 16, 2004 @01:42PM (#10833175)
    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.
    • "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"

      Yeah, like maybe the programming language itself? Maybe it's just me but I think in whatever programming language I'm using. It's so much harder to try to convert data structures and algorithms to a natural language, or vice versa. The best we can hope for (in my opinion) is people usin

  • I didn't RTFA... (Score:4, Insightful)

    by GillBates0 ( 664202 ) on Tuesday November 16, 2004 @01:43PM (#10833181) Homepage Journal
    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.

    • I think they are really looking for a modification of Perl... where the goal is to think like Larry Wall. If they could think better than Larry, they would have their own language. (I think it is no mistake that Larry Wall is a linguist.)

  • Natural Language isn't for Serious Programming (Score:4, Insightful)

    by I_Love_Pocky! ( 751171 ) on Tuesday November 16, 2004 @01:44PM (#10833203)
    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?

  • Ah, I see the problem... (Score:3)

    by Nijika ( 525558 ) on Tuesday November 16, 2004 @01:44PM (#10833209) Homepage Journal
    "The goal is to make it possible for people to express their ideas in the same way they think about them." There's your problem right there :) I think they're probably not being adopted because in the world of programming convention is the key to interoperability. Human thought and language aren't so strictly tied to convention.
  • It seems to me that the steps in the Natural Programming approach are not at all novel and certainly not as useful as they appear. The authors seemed to have forgotten the train wreck that was AppleScript. The authors state that syntax in program languages are too complex. I would argue that the syntax of a programming language needs to be more complex then the syntax of a natural language. The sad fact is that English (and other natural languages) were not designed with enough precision for things like

    • Re:Remember Apple Script (Score:2, Insightful)

      by Anonymous Coward
      > The authors state that syntax in program languages are too complex. I would argue that the syntax of a programming language needs to be more complex then the syntax of a natural language.

      I think you really mean the opposite of what you said. The syntax of natural language is bogglingly complex. You can express the syntax of even perl with a few kilobytes of EBNF. Noam Chomsky tried to come with formal syntax rules for spoken languages and utterly failed (though his work is what led to BNF and compa
    • 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.
    • Dude, I have news for you, AppleScript is still a bit of a train wreck [apple.com].

      Not that it's not powerful and fairly easy to use ( you can do a *lot* of fairly amazing stuff with AppleScript that can't really be done otherwise ), but it is _not_ as straightforward as it should be... doing something relatively simple, like string manipulation, just isn't easy. How do you take a path name and add a few characters to it? It's kinda hard to figure out.

      Of course, you could blame some of AppleScripts' difficulty-of-use o

  • What is the PURPOSE of natural language? (Score:3, Insightful)

    by Anonymous Coward on Tuesday November 16, 2004 @01:48PM (#10833264)
    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.

  • The problem is (Score:2, Insightful)

    by Anonymous Coward
    It isn't that there aren't any languages that follow these principles coming out; lots of them are. It's just that the only languages that have become popular ignore these principles.

    The fact is that people don't care what's academically sound, or what people have "proven" is the best way to do things. In fact, the things people do care about are directly contradictory with what's academically "best". It isn't some kind of head-slapping coincidence that the new popular languages ignore "natural programming

  • NLP (Score:2)

    by caluml ( 551744 )
    Nothing to do with making people do what you want [google.com] then?
  • OK I'm not up on natural language parsing, so what does:
    =-NE-==
    Mean?

  • Wow. (Score:5, Insightful)

    by cbiffle ( 211614 ) on Tuesday November 16, 2004 @01:52PM (#10833316)
    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.)
  • Usually new concepts spawn new programming languages. Then after the concept has been proven, the features are hacked into other existing languages. Like Objects and SmallTalk. And the like. There are plenty of expiramental languages out there. If it really is a good idea, create a new language around it. If its such a fundemental change, then it couldn't be dropped in to a production quality language. No one would have the skills to use it, and everyone would switch to a competing language product, especia
  • In my experience the problem has always been that no one can really agree on limits to what a natural language should be able to do. Take the example in the subject, from the document -- "set the nectar of all flowers to 0". Fine, it's "more natural" than something like
    for (int i =0; i < flowers.length; i++) { flowers[i].setNectar(0); } or something like that.

    But wouldn't the most natural way be to say something like "no flowers have nectar"? This gets into a completely different level of parsin

  • Deterministic vs. nondeterministic (Score:3, Insightful)

    by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Tuesday November 16, 2004 @01:55PM (#10833350) Homepage Journal
    The current crop of computers is based on series of logical operations, and there is little in common between discrete logic and the Real World. Most programming languages bear a strong resemblance to mathematical notation, and that's not just coincidental.

    The real problem is a lack of strong domain models for most real world situations. That is, if you're starting a project to emulate something happening outside of a computer, then there's a very large likelihood that you're going to have to build your own object model to describe the situation to the desired level of accuracy. Once you have that model, it's easy enough to say "do this until that happens", but there's a world of difference between that point and staring at a blank screen at the beginning of a project.

    There's been some progress (depending on who you ask) to make this easier for those who aren't full-time programmers, such as UML and related design tools, but even these are mainly limited to building a high-level template of the final result so that a human can manually implement all of the details.

    This may or may not be avoidable. Vernon Vinge (author and CompSci professor) refers to the "Age of Failed Dreams" where humans eventually concede that some things just aren't possible. Expecting a current deterministic Turing device to be programmable at the level where people interact with each other may very likely be one of those areas.

  • ...a torrent of all the presentations is here [rubyforge.org].

    Anyway, he had some interesting things to say about micropayments; a summary of his talk is at the bottom of the page in Jim Weirich's blog here [onestepback.org].

  • English and Computer Language dont Mix Well. (Score:4, Interesting)

    by jellomizer ( 103300 ) * on Tuesday November 16, 2004 @02:03PM (#10833451)
    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.

  • What is natural language? (Score:3, Insightful)

    by drgonzo59 ( 747139 ) on Tuesday November 16, 2004 @02:04PM (#10833468)
    It is a matter of habit and training. I am used to think in terms of objects so any object oriented language is "natural language" for me. When I solve a problem I think of objects, methods, properties and how they work together. I don't have to translate from some abstract "natural" concepts to OO concepts. I am sure someone who is using lisp will see lists and functions in the same problem that I see objects and methods.
    I understand that the goal is to have the user just tell the computer what to do in English. The problem is that English is not precise and is too ambiguous. I don't know if I would want to fly on an airpline if I knew the computer on board was programmed in English.
  • Argh! The slashdot title completely mischaracterizes the article. The authors never use the term "natural language" at all! They call what they're talking about "natural programming", and if you read the article I hope you'll agree that it is something we should all be longing for: the ability to express ourselves in code that is close to the problem domain.

    IMO, the best direction for natural programming is embedded domain-specific languages [yale.edu]. The best direction for natural debugging is a harder prob

    • Yes, the slashdot title completely mischaracterizes the article.

    • Finally, someone gets the point. :-)

      Programming languages that allow writing high level code using concepts close to the application domain are simply more powerful than those that force the programmer to convert between the application domain and the computational facilities of the language all the time. Some languages support writing higher level code this way much better than others, and this is where a lot of the research behind the next generation of languages should be going.

  • standard flaw in research like this (Score:3, Insightful)

    by egomaniac ( 105476 ) on Tuesday November 16, 2004 @02:07PM (#10833506) Homepage
    Why does all research like this seem to revolve around "toy" problems? They study non-programmers or, when they include real programmers, focus only on small tasks that can be completed in an hour or so.

    Great, I accept that a new language can make toy problems easier.

    However, I think the situation is very different when you have a real programmer working on a real program. Writing a real application, like a word processor or a web browser, is difficult no matter what language you do it in -- and I would argue that the difficulty doesn't vary much between languages. In fact, I would further argue that many of these research languages, while making toy problems easier, would actually make "real" programming substiantally harder, because the semantics of the language are not as formalized and thus more difficult to remember and deal with.

    I'm certainly not opposed to advances in language theory and design -- our modern-day large applications would be essentially impossible to write if all we had to work with was machine language. But to be a major advance, a new language should focus on making real problems easier for real programmers, not making toy problems easier for non-programmers.
    • Hate replying to myself, but I should clarify: when I said that the difficulty of writing a program doesn't vary much with language, I meant among similar-level languages. The difficulty of writing a word processor in, say, C++ vs. Java isn't as different as you would expect.

      Obviously, machine code (or BrainFuck) is enough of a difference to have a real impact on difficulty, and I accept that a super-duper-high-level language could make the process substantially easier, if a suitable one existed (but it d
  • Programmers sit serenely, silently coding for hours at a stretch.

    Then they execute the code for the first time, see the results, and scream out SHEEEIIIIT, GODDAMN IT!!!

    Hence, to an outside observer, the natural language of programmers is indistinguishable from a case of Tourette's Syndrome.

  • but _WHICH_ natural language? (Score:3, Insightful)

    by museumpeace ( 735109 ) on Tuesday November 16, 2004 @03:10PM (#10834409) Journal
    a language that leaves all the verbs for the end of the sentence? A language that likes the modifiers to follow rather than precede their nouns?...my point is , you have one translation problem in going from high level language to machine language and another going from "natural" language to high level language. But a third problem is finding a culture-neutral natural language OR solving the natural language translation problem...and you have seen how atrocious babelfish results can be...we just aren't there yet folks! The ambiguity that must be dodged in going from normal human speech to a computer program hides in different places depending on the language, especially on which words have multiple meanings. And inflection? What are you going to do? program with emoticons?
    I know that natural language is creeping into UI's in specialized search engines. If you know where to look, you will find natural language search features on Fidelity.com and perhaps other financial websites. These are much more carefullly bounded problems than the broad challenge of allowing a user to express a solution or algorithm for an arbitrary problem a computer could be programmed to do in, say C, but using ordinary speech. The article sited is interesting and it might make life better for us programmers but I am not getting my hopes up that more than incremental change to computer languages is around the corner.

  • Flowcharts (Score:4, Insightful)

    by Doc Ruby ( 173196 ) on Tuesday November 16, 2004 @04:02PM (#10835184) Homepage Journal
    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?

  • Natural language does not... (Score:3, Insightful)

    by Jagasian ( 129329 ) on Tuesday November 16, 2004 @04:05PM (#10835225)
    ... make a good programming programming language. Mathematics has "been there and done that" with natural language versus a formal language. Why reinvent the mistakes of the past?

  • Natural language compilers?are they kidding??? (Score:3, Insightful)

    by master_p ( 608214 ) on Tuesday November 16, 2004 @04:15PM (#10835369)
    It is very difficult to write a context-free programming language, let alone a natural one! when we speak, everything is meant relative to the current context. There is no way that a mathematical abstraction can be made out of that, unless really powerful computers can try every production possible in the same time (thinking about quantum computers).

    We humans don't even talk logically at times (logically in the mathematical sense). We say one thing, we mean another one. One of the most difficult things for new students is to get used to the strictly mathematical nature of computer languages. Computer thinking requires every bit to have its special meaning in the universe. Most people choke on that. The most capable programmers are those that can hold a mental model of the application, its various parts and as a whole. These types of people can translate requirements to code very efficiently, because they can reason about a program's state better since they remember the whole program and they can immediately recognize the consequences of any programming decision.

    And when one becomes familiar enough with the way the computer works, then the verbosity really gets in the way.

    What we need is a development environment that can reason about the state of the program. That's the root of all problems. Embedding state information in a program is something I haven't seen in any language. Most languages, if not all, work in the assumption that anything can happen anytime, and they don't have state constraints, thus allowing the programmer to make mistakes that could be cought in compile time.

Slashdot Top Deals

If all else fails, immortality can always be assured by spectacular error. -- John Kenneth Galbraith

Close