Join 3,496 readers in helping fund MetaFilter (Hide)


Warning: James Joyce may cause system crash
March 25, 2005 12:35 PM   Subscribe

A tool that turns English into computer code? Maybe someday. Metafor is a code visualizer from researchers at MIT which produces non-executable (but meaningfully-structured) code out of natural language. Here is a quicktime demonstration of what it looks like in action. Here's the paper as a PDF.
posted by Hildago (26 comments total)

 
By way of Roland Piquepaille's Technology Trends.
posted by Hildago at 12:36 PM on March 25, 2005


Less should be done to lower the bar into what is already an industry saturated with incompetent get-rich-quick artists, not more.

Think about it. You want less qualified people writing software? That'll save time. Sure.
posted by jon_kill at 12:54 PM on March 25, 2005


Why do we need to bother developing a programming language based on natural language or even English language when we've got MS's and PhD's in CompSci in India willing to write in C++ and Java for $7.50/hr? /facetious

Also, what jon_kill said.
posted by psmealey at 12:57 PM on March 25, 2005


"There is a bartender whose name is bartender; the bartender knows how to make a drink called a bartender. If a customer named bartender orders a bartender from the bartender, the drink will cost zero dollars."

Ah... ambiguity...
posted by odinsdream at 1:07 PM on March 25, 2005


jon_kill - I think you're not seeing its end use... A language like this ultimately won't be for programmers; it'll be so users can ask computers to do things for them (sort of like how computers are "programmed" in Star Trek vocally).
posted by glider at 1:35 PM on March 25, 2005


Computer languages tend to get easier, a natural language interface doesn't cross a slippery slope where all of a sudden you can hire otherwise incompetent programmers. A shitty Python programmer would be just as craptacular at C and vice versa. The value in hiring a programmer is in their problem solving abilities in my opinion. A good programmer can take a relatively vague description of how something should work and come up with code that performs that task while optimizing resource requirements based on the codes intended use. That's what I'm willing to pay for. In general I couldn't care less about what languages somebody knows, good programming practice transcends language.
posted by substrate at 1:42 PM on March 25, 2005


Knowing programming languages is a valuable skill because the devices don't understand human communication. No inherent reason why specialised programming languages should be the preferred paradigm for instructing machines.
posted by Gyan at 2:10 PM on March 25, 2005


this ability has been around for years, its called python :).
posted by Mach5 at 2:12 PM on March 25, 2005


Programming is a silly thing to have people doing. Computers just need to learn on their own, damn it.

Show the computer that you have A and you want X, you have B and you want Y, you have C and you want Z. That's when the computer should slap its forehead and say "Now I get it!" and write its own code to solve that problem in general. So you feed it a cookie.

(Actually, three or more programs should solve the problem and the one with the best answer should get the cookie.)
posted by pracowity at 2:12 PM on March 25, 2005


...code that performs that task while optimizing resource requirements based on the codes intended use.

As resources approach zero cost, zero power, infinite speed, and infinite density, what problem do you solve by optimizing their use?
posted by ZenMasterThis at 2:17 PM on March 25, 2005


Learning a programming language is not the hard part of writing good code. The real task is clearly defining the exact behavior you want the program to perform under all circumstances. If you can lay that out unambigiously in English, you've done most of your work already anyway.
posted by tdismukes at 2:24 PM on March 25, 2005


ZenMasterThis: Well, your name gives me a good start.. some programmers, myself included, take pride in figuring out resource-conservative ways to do things, even if the resources are "infinite" (which they aren't...and never will be), because there's a kind of, well, zen to writing programs well. Programs can be -badly- written.

There was a site posted here awhile ago to a blog that had daily bad programming examples. One of them worked out to something like this:

while true, generate random numbers. If generated number falls between 1 and 10, jump out of while loop and print number.

This is obviously insane, even if processing power were "infinite" and you got your answer pretty quickly. The right thing to do is, of course, to only generate random numbers between 1 and 10.

Maybe that's a bad example, but I hope I'm getting the point across all the same... programming can be Good, and it can be Horrible. Even if we have infinite memory and processing power at our disposal (which, again, we never will), there's still a very, very good reason that we should stay as far away from Horrible as possible.
posted by odinsdream at 2:33 PM on March 25, 2005


Part of the purpose of the program as an instructional tool is to get novice programmers to understand that the grammar and syntax of a programming language carries information in the same way that a natural language sentence does. I'm a novice programmer with a BA in English Lit., so maybe I'm just the perfect audience for this type of thing.
posted by Hildago at 2:46 PM on March 25, 2005


jon_kill writes "You want less qualified people writing software?"

Java! (to forestall flames, orthogonality is Sun Certified.)
posted by orthogonality at 3:04 PM on March 25, 2005


ZenMasterThis, resources don't really approach zero because the things we ask the computer to do increase just as rapidly. Your Windows XP installation consumes many orders of magnitude more resources than DOS 3.00 did. Doom 3 consumes many orders of magnitude resources than Commander Keen did. Nobody would've imagined that your home computer would be able to manipulate video from a camcorder 10 or 15 years ago. In another 10 or 15 years we'll be doing things on our computers that most of us don't expect and the skill required to write the software to do it in the available resources will still be something people get paid well for.

I saw something interesting today. I helped design what was for a short time the fastest supercomputer on the planet. It's been surpassed twice in the past year but what was most amazing to me was that since the first supercomputer,Cray 1 performance had increased 500,000 times.
posted by substrate at 3:18 PM on March 25, 2005


ZenMasterThis, resources don't really approach zero because the things we ask the computer to do increase just as rapidly. Your Windows XP installation consumes many orders of magnitude more resources than DOS 3.00 did. Doom 3 consumes many orders of magnitude resources than Commander Keen did. Nobody would've imagined that your home computer would be able to manipulate video from a camcorder 10 or 15 years ago. In another 10 or 15 years we'll be doing things on our computers that most of us don't expect and the skill required to write the software to do it in the available resources will still be something people get paid well for.

I saw something interesting today. I helped design what was for a short time the fastest supercomputer on the planet. It's been surpassed twice in the past year but what was most amazing to me was that since the first supercomputer,Cray 1, performance had increased 500,000 times.
posted by substrate at 3:18 PM on March 25, 2005


I've been working on something tangentially related to this for the past while (the natural language part, not the code generation part). IMHO there are weaknesses in the approach that they use — can you imagine trying to do a large application like that? — but it would be interesting to use it for instructional purposes. They also hand-wave at a lot of the interesting parsing issues by using templates and the like. However, if you get to the point where a substantial portion of the language is being understood by the program, you may as well interpret and run the program on the spot — why bother converting into code when you have everything you need already parsed?
posted by brool at 3:45 PM on March 25, 2005


>You want less qualified people writing software?

Who says this is for programmers?

This should be for end-users.

"Resize everything in my images folder newer than last week into thumbnails and generate a web page for them. Upload that webpage to my webspace."

Or natural language commands for Office suites instead of learning a scripting language.

No one is going to be develping apps with stuff like this. The c-style school of coding is going to be here for a long time.
posted by skallas at 3:53 PM on March 25, 2005


The real task is clearly defining the exact behavior you want the program to perform under all circumstances. If you can lay that out unambigiously in English, you've done most of your work already anyway.

Agreed. And if you can lay out all of the functionality in English, I'd like to work with you, because no one I've worked with has been able to do that. :)

Show the computer that you have A and you want X, you have B and you want Y, you have C and you want Z. That's when the computer should slap its forehead and say "Now I get it!" and write its own code to solve that problem in general. So you feed it a cookie.

(Actually, three or more programs should solve the problem and the one with the best answer should get the cookie.)


They've tried (and are continuing to try) that. Its called Genetic Programming or Evolutionary Programming. So far its had limited success, in that it cannot create a complicated program (like a web browser for example) but it has created patentable new solutions to problems.

some programmers, myself included, take pride in figuring out resource-conservative ways to do things, even if the resources are "infinite" (which they aren't...and never will be), because there's a kind of, well, zen to writing programs well. Programs can be -badly- written.

While I agree that writing programs to use resources well is important, by far the majority of the problems caused by bad code that I see are caused by poor encapsulation. The use of global variables or the like that causes a tight coupling such that you can't make a change to one part of the app without affecting something entirely unrelated is much more prevalent and hard to fix than poor resource usage.

Never prematurely optimize. I still find myself doing that alot, but I try not to - I try to just optimize after I've profiled the code and found the hot spots.


IMO, Natural language -> code will not happen until we get general AI. On preview, what Skallas said "No one is going to be developing apps with stuff like this."
posted by Bort at 4:02 PM on March 25, 2005


Personally, I don't think it actually gets you much. The hard part of coding isn't finding the words, it's coming up with the conceptual flow of things... Like, for a scripting language, you could generally get by with like 10 commands... if, set, ==, for, while, etc.. If you can put together an english language program, you've already done the hard part
posted by salminen at 6:07 PM on March 25, 2005


I didn't read the article, only the paper, but it really looks like the most amazing part of this is not necessarily that it creates Python code, it's that it understands English so well that it can create code out of it.

This is excellent for its potential, not this specific application. Thanks, Hildago.
posted by blacklite at 7:48 PM on March 25, 2005


This is another example of people who feel that we would all be better off if we organize our thoughts according to a prespecified structure.
Know anyone like that? I'll bet you don't like them very much.
posted by Seano at 10:20 PM on March 25, 2005


I don't understand computer code as well as I understand linguistics, but I understand both of them just enough to find a certain humor in the fact that the structuralist foundation for Noam Chompsy's (an MIT man himself) model of generative grammar was without a doubt informed, if not inspired, by research done in computer science. This gives us one way of understanding language that was born out of the metaphor of programmability and computation and it is now itself being appropriated by the very influence which gave it its discrete logic in the first place. Using code to parse language to create code does not take into account that the "code" for language is only a representation for language, which is continually evolving, and devolving. I admire MIT for giving us a model for language use based on the COMPUTER metaphor, but it is just a model and will never explain the full efficacy of language, its mutability, or its relationship to consciousness.
posted by mrmojoflying at 10:34 AM on March 26, 2005



Less should be done to lower the bar


Pun intended?
posted by thanatogenous at 12:07 PM on March 26, 2005


The majority of software cost over the lifetime of a project is spent on maintenance and enhancement. Therefore the primary role for programming languages is to communicate a solution from one human to the next. Programming languages are HUMAN languages, which computers are (barely) smart enough to "understand".

Harware doubles in performance every 18 months or so. Programmer productivity has a doubling time much longer than that. Because humans are (still) bound by their peculiar wetware, any improvement in programmer productivity has to come from adding intelligence to the computer side of the equation. The greatest benefit from achieving a natural language level of programming abstraction is that it rasies the level of programmer productivity about as high as it can go while still relying on the biological substrate for solving the essential complexity of problems. Advancement beyond that will require that more of the burden of creative analysis and problem solving be borne by the computers themselves.
posted by gregor-e at 10:24 PM on March 26, 2005


Improvements in programmer productivity remain measurable only in the imaginations of HR managers. The fundamental quantity (how long it takes Engineering to produce what the customer wants) has remained roughly constant (ten times as long as the customer was initially told by Marketing) for as long as I've been watching the industry.

Yes, it does take less time to write Notepad these days; the trouble is, everybody expects Word now.

As programming environments get better and better at letting designers work with abstractions, the projects they make possible get harder and harder to debug. Nothing calls anything directly any more - that's unfashionable; if calling a function doesn't rely on a chain of at least three hidden anonymous pointers and a poorly documented dispatch engine of some kind (preferably involving converting all parameters to XML and back on the way), modern coders feel they're doing something wrong. And there are now so many different ways to use global variables while pretending not to, it makes my poor old head spin.

Elegance in coding is a lost art. Writing code for old, cramped machines was like expressing yourself in haiku; it took a hell of a lot of thinking to get it succinct. Nobody has to do 'succinct' these days, because there's simply so much storage to play with; hammering out endless reams of any old crap is clearly SO much more productive!

Reading source code in this day and age often gives me the distinct impression that the natural-language equivalent would look like what you'd get by giving William Burroughs a pair of scissors and a Gideons' Bible. But that's OK, because it's all re-usable (groan).

Trying to maintain bad code written in a programming language with restricted syntax and restricted semantics is bad enough. Trying to maintain bad code written in any reasonable approximation of natural language is gonna be a friggin' nightmare.

None of which stops stuff like Metafor being really kind of cool.
posted by flabdablet at 7:03 AM on March 27, 2005


« Older Chicken Payback...  |  Meet the NSP... Newer »


This thread has been archived and is closed to new comments