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

41–50 of 83 posts

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

#41

Post by aaronblohowiak »

silentbicycle wrote: post #34
alanh wrote: post #20

Earlier quoted context omitted.

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

ed gave rise to sed and vi. ed -> em -> ex (VIsual mode). vim is Vi iMproved.

x->y suggests lambda to many people in our community.

Edit: I meant to provide some additional information to other readers, not to disagree in any way.

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

#42

Post by silentbicycle »

aaronblohowiak wrote: post #41
silentbicycle wrote: post #34

Earlier quoted context omitted.

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

ed gave rise to sed and vi. ed -> em -> ex (VIsual mode). vim is Vi iMproved. x->y suggests lambda to many people in our community. Edit: I meant to provide some additional information to other readers, not to disagree in any way.

Well, right, but how many people here have actually used ed standalone? (lone hand) It's overwhelmingly likely that most people picked it up from vi(m).

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

#43

Post by aaronblohowiak »

derefr wrote: post #40
silentbicycle wrote: post #38

Earlier quoted context omitted.

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…

Do rules need to be global in scope?

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

#44

Post by silentbicycle »

aaronblohowiak wrote: post #43
derefr wrote: post #40

Earlier quoted context omitted.

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…

Do rules need to be global in scope?

Not necessarily. Some Prolog implementations have module/packaging systems, some don't. Prolog is a weird language - many details feel very antiquated* , yet on the whole it's way ahead of its time (esp. constraint programming). I think it would fare much better as an embedded library (like e.g. Lua or SQLite), rather than a freestanding language. Working on it, though I will likely finish other projects first.

* Case in point: Loading a file is "consult"; I assume this is historically because Prolog was originally a language for doing NLP in French. (See e.g. HoPL-2.)

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

#45

Post by imd »

akkartik wrote: post #29
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…

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.

This gradual construction and refinement of exactly what you want reminds me of a certain TNG episode where they do just this: http://memory-alpha.org/wiki/Schisms_%28episode%29

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

#46

Post by zellyn »

Sure, by the time you enter all the specifics of the Circle, you've got something more unwieldy than a succinct programmatic description.

But for most people unfamiliar with Mathematica syntax, typing, "draw a red circle" and having the computer choose sensible (or any) defaults yields a template of the exact code one would have needed to type. Which saves Googling or reading the manual for circles, and teaches the syntax in a very natural way.

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

#47

Post by blahedo »

"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 been programming for decades, when we express ourselves in natural language we can be very precise but it takes a lot more work and becomes a lot more unwieldy than just writing out our instructions in [pseudo]code.

CS educators have been wishing for a long time that "intro to CS" didn't equate to "intro to programming". And it doesn't have to, not quite, but the reason it always seems to revert there is that the prerequisite for every other thing in CS is, not programming itself, but a certain precision of thought that is easiest to teach just by teaching students to program. In a programming language. Because if you try to make them write out instructions in a natural language, and you notice that they aren't being precise and therefore deliberately misinterpret that instruction, they just think you're being a dick about it. They sometimes even think this if you honestly misinterpret them. (This is true even in a non-CS context.)

Saying that we will soon be "generating code from natural language" is, at best, misleading. It implies that people who couldn't learn a programming language will be able to program, which is quite untrue---I promise that with the possible rare exception of a few pathological edge cases, when people can't learn to program, the language is the least of their problems. And for those of us that can and do learn programming languages, all but the simplest sorts of programs will probably be easier to write in a programming language (which was designed for that sort of thing) than in a natural language (which was not).

(And holding up Mathematica as an exemplar is particularly egregious; it is so loaded with syntax that "just works" that you need to either have a deep familiarity with traditional mathematical notation or else a degree-level CS background in programming language theory if you want to have a good shot at learning the language in anything more than a pattern-matching fill-in-the-blank way.)

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

#48

Post by demallien »

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.

Yup. This isn't going anywhere. We already use natural language fir programming - it's called writing a specification, which you then send to a special compiler called a programmer.

Now how many of us have seen a specification that was unambiguous, complete, and efficient? Have a look at the trouble that progammers have implemented browsers capable of passing Acid 3. And that's for a special case where the spc writers are programmer themselves, and have even provided a set of programmatic test cases to test validity.

Or alternatively, how many times have you tied to help a friend do a complex computing task (automated backups, transferring an iPod from one computer to another, whatever) and you start asking questions to find out exactly what they want, which tradeoffs they want to make etc, and they just get frustrated with you?

Those are three major flaws with natural language programming

- not even humans can correctly compile natural language specs

- it is incredibly difficult to write a natural language spec that is correct, unambiguous and efficient

- people already dislike dealing with the complexity of computer programming, even when they have a programmmer holding their hand, asking all of the right questions.

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

#50

Post by julian37 »

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…

This is addressed in the article, and arguably the article's main point. Quoth:

"I have to say that something I thought would be a big issue is the vagueness of natural language. That one particular natural language input might equally well refer to many different precise programs.

"And I had imagined it would be a routine thing to have to generate test examples for the user in order to be able to choose between different possible programs.

"But in reality this seems to be quite rare: there is usually an “obvious” interpretation, that in typical Wolfram|Alpha style, one can put first—with the less obvious interpretations a click away."

Post reply on HN