Live data from Hacker News

Generating code from natural language is closer than you think

blog.stephenwolfram.com

71–80 of 83 posts

Re: Generating code from natural language is closer than you think

#71
post #8

This is in the class of "demoware", projects that are easy to program fancy demos for but are very difficult to bring to production status. (See also: "fully visual programming".) It's only really interesting if they escape from that. We'll have to wait and see.

There is a difference between visual programming and natural language. Natural languages already have tokens, syntax, and grammar whereas visual fields do not have them. All those elements must be imposed onto a visual language before it can be translated into the machine language (e.g. there is no obvious convention for visual commands or visual conditionals).

I don't think so, see Aardappel for an example

http://strlen.com/aardappel-language

(There are otheres there, Wouter did some extensive research)

Re: Generating code from natural language is closer than you think

#72
post #8

This is in the class of "demoware", projects that are easy to program fancy demos for but are very difficult to bring to production status. (See also: "fully visual programming".) It's only really interesting if they escape from that. We'll have to wait and see.

There is a difference between visual programming and natural language. Natural languages already have tokens, syntax, and grammar whereas visual fields do not have them. All those elements must be imposed onto a visual language before it can be translated into the machine language (e.g. there is no obvious convention for visual commands or visual conditionals).

Would programming in "Egyptish" be visual or natural?

Re: Generating code from natural language is closer than you think

#73
This will exactly end like Infocom adventures. They are mostly nice, but quite often you hunt for the exact phrase the parser understood (but to be fair, it happened more often in Magnetic Scrolls).

But would you call using a text adventure (put blue ball in red box) programming?

Re: Generating code from natural language is closer than you think

#74
I think that the title should be: Generating code that can be described in a short phrase is closer than you think.

We can create a database with the different phrases that people use to suggest a command, for example:

Calculate the limit, find the limit ... all of this is Limit, and so on.

To sell a product, this kind of ability is well received. Is like telling to your telephone: Please call this number for me, the number of my friend Alfred. And the computer lookup Alfred in its database and connect with that number, that is not deep IA but is a useful trick for selling products.

Re: Generating code from natural language is closer than you think

#75
Natural language can lead to contradictions and ambiguities. Just look at that star trek episode where they supposedly brought down androids built by a very advanced ancient race just by saying stupid and self contradictory things.

Which by the way was a stupid premise but hey :)

Re: Generating code from natural language is closer than you think

#76

Earlier quoted context omitted.

There is a difference between visual programming and natural language. Natural languages already have tokens, syntax, and grammar whereas visual fields do not have them. All those elements must be imposed onto a visual language before it can be translated into the machine language (e.g. there is no obvious convention for visual commands or visual conditionals).

I don't think so, see Aardappel for an example http://strlen.com/aardappel-language (There are otheres there, Wouter did some extensive research)

It is "qsort.m" which provides the context for understanding the icon below it. However, the icon isn't more representative of a quick sort than a bucket sort or a bubble sort. It's simply an arbitrary mapping of a textual token (qsort) to a graphic token (example of arbitrariness is that lighter colors on top maps to lowest values to the left).

The arbitrariness of the mapping between text tokens and graphic tokens quickly increases beyond convention the ability to establish a convention (example: "Number of cheeseburgers shipped from Peoria to Toledo last month."

Re: Generating code from natural language is closer than you think

#77

Earlier quoted context omitted.

Draw a circle. Color it red. Make it smaller. No, 5% bigger. Make the radius 5 units. Refining specifications like that seems like the holy grail of movements like aspect-oriented programming, NLP or no. Separating concerns is a really good thing.

circle = Circle(); // default origin, radius, color, etc. circle.set_visible(true) circle.color = RED circle.make_smaller() circle.set_radius(5) // or whatever. just saying we can do approximately this already today, in most any modern language, as long as you're willing to express it in the prog language rather than the natural language. And I'm not sure having it expressed in a natural language is better in any sig…

Yes. Now make this actually render a circle after each step. And provide pronouns (anaphora) like this, it and the radius (inferred noun in some syntax). My whole point was about a) smart objects that have prepopulated fields with default values, and b) anaphora. I don't have an opinion about the natural language at this point.

And get rid of the set_visible.

Re: Generating code from natural language is closer than you think

#78
post #47

"Make it possible for programmers to write in English and you will find the programmers cannot write in English." I teach computer science and have a particular fondness for introductory CS. The reason Stephen Wolfram is wrong, wrong, wrong about this is that people that have never been taught programming can't express themselves precisely enough in their native language, either; and even among those of us that have…

The problem with this analysis is that it discounts the possibility of interactivity. There are many who cannot think through the logical steps needed to complete a task, but can watch a system stepping through a task, stop it when it seems to go wrong, and provide an explanation as to what's wrong about it. There are a whole lot of problems for which this trial and error process would converge to a mostly working solution.

Hell, there are many programmers who code things this way - try it, change it, repeat. Natural language would just allow non-programmers who aren't familiar with the syntax to join in on this process. Continued practice would likely improve the reasoning abilities of the user and make the process faster.

Re: Generating code from natural language is closer than you think

#79

First off, did he really have to plug ANKS? Honestly it seems like every piece of writing I come across from him he has to mention it. Secondly, I think eventually programming will have to become more mainstream. And this will be done through some form of a natural language interface. Programming is best a tool to solve problems. It's way too limited now where only an elite group gets to control its use. Eventually p…

Most people are not able to use mathematics as a tool.

That's not true. Most people with jobs that aren't just manual labor use basic math to solve problems. As the problems get more complicated, the tools have to grow as well.

Furthermore, I'm not talking about your average office assistant. I'm talking about professionals in a science-related field. Being able to use programming as a tool is going to become invaluable.

Re: Generating code from natural language is closer than you think

#80
post #28
post #14

Earlier quoted context omitted.

> "Draw a red circle" is enough to get a red circle. Yes, but once you have to say "Draw a circle in this shade of red, give it a black border this thick, make it this big and put it at these coordinates" things are starting to get unwieldy. After a few different circles I'd probably start longing for draw_circle(fill_colour, radius, (x,y,z), border_colour, border_width). Edit: Added function arguments to make the co…

The problem with computer languages is that, if you want to do something new in a language you're just learning, you don't know if it's: draw_circle(...) circle_draw(...) circle.draw(...) Graphics::circle.draw(...) shape_draw('circle',...) or any of the million ways to ask the computer to draw a circle. and you don't know if you need to do: import graphics.package #include use graphics.io ... Just witness the myriad…

I think that it's disingenuous to point out the many ways to call a function across half a dozen languages while completely ignoring how many ways there can be to say something just in English.

Think of playing a text-based adventure game and how frustrating it can be trying to work out the exact phrase the designers had in mind. To make this work you'd essentially need a machine that could converse with you to build the program - the way that an engineer talks to a client to draw up a specification - which would be very cool.

I like your idea for an editor add-on. Snippets taken one step further.

Post reply on HN