Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generating code from natural language is closer than you think

blog.stephenwolfram.com

Post reply on HN
Print view View original

31–40 of 83 posts

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

#31

Post by brudgers »

sendos wrote: post #28
Kev wrote: 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…

Exactly. Natural language will build more of the mechanism for you.

* "I set the brake up by connecting up rod and lever."--Yes, given the whole of the rest of the mechanism. Only in conjunction with that is it a brake-lever, and separated from its support it is not even a lever; it may be anything, or nothing."* -- Wittgenstein

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

#32

Post by jarpadat »

necubi wrote: post #15
brudgers wrote: post #11

Earlier quoted context omitted.

"Draw a red circle" is enough to get a red circle. Basic, C++, or Javascript just aren't that closely coupled with the way we think. The advantage of natural language over a high level programming language would appear to be analogous to that which a high level programming language has over assembly. I think you may be conflating programming with software development. People still develop software in assembly languag…

Where is the red circle drawn? How large is it? What shade of red? How are those arbitrary values chosen, and how do I choose others? The inherent problem with NLP is that human languages are imprecise and ambiguous. For an example of the problems with NLP, try using Wolfram Alpha. While it returns useful results for many queries, as soon as you start off the beaten path it can become an exercise in frustration as yo…

> Where is the red circle drawn? How large is it? What shade of red? How are those arbitrary values chosen, and how do I choose others?

http://www.wolframalpha.com/input/?i=draw+a+red+circle

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

#33

Post by jerf »

brudgers wrote: post #12
jerf wrote: 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).

Well, sure there's a difference between visual programming and natural language. There's a difference between both of those and augmented reality, which also has remained firmly demoware. And those three are different from the Minority Report-style interface that's been talked about a lot lately courtesy of the Kinect.

Note in particular the differing levels of what you might call "eventual feasibility" for each of those things... but none of that changes the fact that they are all demoware, and another demo isn't really all that intrinsically interesting until they push it somewhere actually useful, and thereby, new. Demoware isn't necessarily a permanent status, but another demo is not sufficient to escape.

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

#34

Post by silentbicycle »

alanh wrote: post #20
stellar678 wrote: post #5

I would be fascinated to see several hundred years down the road how natural languages and computer languages have comingled and evolved into something new. I'd be inclined to believe that bringing natural language to computers won't just be a one-way street. You already see this in places like hacker news here where people often use constructs like "s/thing/other thing/" because it's more concise and useful than wri…

I upvoted you. But I am not sure that "/thing/other thing/" is more concise or useful than all alternatives. "thing" → "other thing" is the same length, and while not natural language, it isn’t a computer language. I think using the sed-like (right?) language is more useful as a signaller. Check it out, yo, I grep shit all the time .

The whole s/X/Y/ thing is very Unix, and is a (sub)cultural signifier as much as anything. I'm not sure if it's originally from ed, sed, or what, but most people (self included) probably picked it up from vi (nvi/vim/etc.) or perl.

X->Y makes just as much sense, but the s (for "substitute") makes it mnemonic - I read it as "sub X for Y".

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

#35

Post by silentbicycle »

jarpadat wrote: post #32
necubi wrote: post #15

Earlier quoted context omitted.

Where is the red circle drawn? How large is it? What shade of red? How are those arbitrary values chosen, and how do I choose others? The inherent problem with NLP is that human languages are imprecise and ambiguous. For an example of the problems with NLP, try using Wolfram Alpha. While it returns useful results for many queries, as soon as you start off the beaten path it can become an exercise in frustration as yo…

> Where is the red circle drawn? How large is it? What shade of red? How are those arbitrary values chosen, and how do I choose others? http://www.wolframalpha.com/input/?i=draw+a+red+circle

And yet, "draw a red enso"* just gives me a circle.

* http://images.google.com/images?q=enso

(The results for "bring me some delicious pho" are similarly unsatisfactory - it just tells me that delicious means "greatly pleasing or entertaining". Not news to me, pal!)

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

#36

Post by silentbicycle »

ElbertF wrote: post #26
brudgers wrote: post #11

Earlier quoted context omitted.

"Draw a red circle" is enough to get a red circle. Basic, C++, or Javascript just aren't that closely coupled with the way we think. The advantage of natural language over a high level programming language would appear to be analogous to that which a high level programming language has over assembly. I think you may be conflating programming with software development. People still develop software in assembly languag…

This reminds of me of QBASIC (oh the nostalgia): CLS SCREEN 12 CIRCLE (200, 300), 50, 4

Me too. I wonder what people who learned Lisp, Prolog, or APL when they were five would be capable of now!

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

#37

Post by skybrian »

It's over-hyped as usual, but this looks like it could evolve into a handy way of generating snippets of working code that you can then modify. Think of it as an alternative to doing a Google search for a useful example to start from, or a better kind of Rails scaffolding.

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

#38

Post by silentbicycle »

derefr wrote: post #16
justin_vanw wrote: post #10

Well, I since it isn't possible (natural language isn't precise enough to even communicate efficiently with other humans that share the same hardware as you, much less an unthinking autamoton such as a computer), that would put the time frame at around never. If it ever actually happens, that would by definition of 'never' be sooner than I think, so all he has to do is actually accomplish it instead of talking shit h…

Programming languages are specificational : you say everything up-front, then the computer interprets all your statements at once and executes them. Natural language, however, is conversational . You say A, the person you're talking to interprets that as Z and asks for clarification, you explain the difference between A and Z, now the other person thinks M and asks more clarifying questions, etc. Computers are fully…

In more conventional programming terms, some languages have REPLs* for a conversation, and support declarative programming ("Here's what I want, figure it out"), but most are procedural ("Do this, than this, than this, then give me the result").

* Read/eval(uate)/print loops

Prolog (also Erlang and some others) is mixed; you reload a file of rules read as a whole, but can easily prompt the system for easy testing, and reloading is very fast. It's very convenient with a Prolog shell terminal and a vi window, two buffers in Emacs, etc.

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

#39

Post by ckcheng »

Not the same thing, but similar?, from 1983:

"A natural language query system for a prolog database" (Hadley) http://ir.lib.sfu.ca/handle/1892/7254

Not general code generation I suppose, but there's been quite some work on natural language to database queries systems in AI research elsewhere.

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

#40

Post by derefr »

silentbicycle wrote: post #38
derefr wrote: post #16

Earlier quoted context omitted.

Programming languages are specificational : you say everything up-front, then the computer interprets all your statements at once and executes them. Natural language, however, is conversational . You say A, the person you're talking to interprets that as Z and asks for clarification, you explain the difference between A and Z, now the other person thinks M and asks more clarifying questions, etc. Computers are fully…

In more conventional programming terms, some languages have REPLs* for a conversation, and support declarative programming ("Here's what I want, figure it out"), but most are procedural ("Do this, than this, than this, then give me the result"). * Read/eval(uate)/print loops Prolog (also Erlang and some others) is mixed; you reload a file of rules read as a whole , but can easily prompt the system for easy testing, a…

Prolog has a REPL, but only new facts can be declared through it efficiently, not new rules. If you (re-)declare a rule (through `assert`), the entire constraint database is actually re-evaluated behind the scenes. The big problem in conversational declarative programming is how to start with general-purpose rules, and work downward with more and more special-case exceptions, without each new assertion taking longer to integrate into the database than the last.

Inform is an exapmple of a natural-language-ish, rule-based system (for programming text adventures), that could efficiently re-declare rules in a REPL (if not for its basis in virtual machine image formats that expect to be compiled from complete specifications.) Inform guarantees efficiency by using a hub-and-spoke system of rules: rather than every rule having the possibility to interact with every other rule, rules can only interact with rules in their own "rulebook" (module), the core rulebooks (standard library), and the "meta" rulebook (monkeypatches to re-specify libraries.) Thus, integrating a new definition only takes O(k + n + e) time—where k, n, and e should all be small—rather than O(n^2). This works well for Inform, but I'm not sure whether it would be as effective in a general-purpose programming environment.

Post reply on HN