Metafor: Translating Natural Language to Code

vivin writes "Computer programming is second nature to most of the Slashdot crowd. However, this is not true for the vast majority of people. Formal programming languages are not as expressive or flexible as natural languages. This becomes more evident when we try to translate user requirements into actual code. Researchers at MIT have come up with a program that bridges this gap. It's not so much a tool that turns English into code, as it is a program that translates requirements (in English) to code. When Metafor analyzes English, nouns phrases become objects, verbs become functions, and adjectives become object attributes (or properties). In addition to helping programmers visualize their program better, I think it also promotes writing concise (and therefore) requirements and descriptions. Metafor doesn't handle run-on sentences (or bad English) that well." Update For for the dupe. Not going well. Appreciate all the hate mail. Really encourages improvement.

Comments

This story is a dupe, but

[GreyWolf3000]

I think the idea has been around a long time. The whole object oriented paradigm (in addition to providing useful functionality like dynamic function binding) is designed to shape code around human thought.

One of the things that really bothers me about Linux is the pervasiveness of languages like C that make no attempt to model higher thought and instead force the developer to constantly re-learn old unusable APIs and shove ancient hacks that are unreadable just to get drivers working. Objects in code need their a[tt]ributes to mirror real-word equivalents, otherwise reading the code is impossible because no one else can make sense of all the confusing acronyms and variable names.

I actually think that .NET is the right step for us. Mono is really the first sensible language (Java doesn't count; it's not free) that has any mindshare for Linux, and let's face it the Linux world needs it. Until writing software for Linux can just be a simple translation of designs in our heads to GUI design and implementation, Linux will lag behind the rest of the world because of how long it takes to write software for it.

Rules

[igny]

How hard is it to change rules of treating the sentences? Can Metaphor learn Chinese, for example?

Re:Very Cute

[Anonymous Coward]

Actually, I could see this being very helpful for guys like me that used to be pretty capable before OOP. I think I can wrap my head around the ideas, but it just seems so damn clunky and frustrating to use. I realize its actually not for people smarter than I, but this could actually make things easier for guys like me.

Should people like me be writing software then? Well, not commercial grade stuff, but who's to tell me I can't knock together stuff for my own use using something like this?

I just hope it works as advertised.

Doomed to fail?

[PissingInTheWind]

From Dijkstra's timeless "How do we tell truths that might hurt?":

Projects promoting programming in "natural language" are intrinsically doomed to fail.

He said that 30 years ago. People still don't listen.

Re:Doomed to fail?

[MenTaLguY]

Did you really struggle against old habits? Many programmers I know, who were brought up on BASIC, turned out to be the strongest zealots for other types of programming and weren't held back by some extra knowledge about gotos at all.

Yes, I did. The knowledge wasn't a problem, but the habits that came from using them extensively were obstacles to constructing useful abstractions. Note that I grew up with old-school BASIC. Mandatory line numbers, and GOSUB was the highest level of abstraction you could reach. None of this QBasic stuff.

It took me a long time before I could stop thinking about loops in terms of gotos, and be able to recognize things like e.g. the potential for parallelism/vectorization.

A formal CS education would have helped me (I got a degree in graphic design instead), but I think I would have been much better off learning about control constructs at first in their own right, and only later learning about how they could be implemented with goto, once I had learned to reason about them abstractly.

Coming at gotos from that direction, I might have been frustrated with their limitations, but I don't think I would have found them particularly hard to understand.

Regarding the paper, I'm not all that impressed. I agree with some things -- Dijkstra gets quoted a lot without real understanding, and everyone could stand exposure to systems programming, because they're going to run up against it at some point in their career whether they like it or not.

However, in my current programming job, I'm part of a team that ends up cleaning up other's failed projects a lot. Very often the deepest problems are due to inappropriate use of global or shared state (the next deepest tend to be due to poor error handling, and the use of long imperative-style blocks where code was cut-and-pasted instead of being refactored into common functions/objects -- the availability of gotos seem to exacerbate this last problem).

Frankly, I don't think the current crop of programmers is averse _enough_ to using global variables. The opposite extreme (overly avoiding global state) can be just as bad, but the resulting code is still significantly easier to reason about and clean up with a good refactoring tool.

Some global state is unavoidable (if nothing else the outside world is a global resource); the Platonic ideal (for non-systems-programming) is to have well-defined areas of code which are in contact with the "outside" world, where your IO, your external event sources, and your singletons go. Everything else need not have any global knowledge (e.g. the singleton you get via dependency injection just implements an interface you use; you needn't know it's a singleton).

I suppose Haskell's use of monads comes closest to this ideal, though I think they still haven't figured out all of the practical aspects yet.

Re:Other uses?

[AKAImBatman]

Just a thought, but wouldn't it be easier to produce a specialized programming language for this? The instructions could then be pivoted into either a readable recipe, or commands for a robotic machine. Something like this:

Ingredients
{
2 egg;
1 tsp vanilla;
4 cups flour;
}

Equipment
{
mixing bowl;
oven;
12x6 inch pan;
}

Directions
{
preheat oven 450 degrees farenheit;

break 2 egg into mixing bowl;
pour 1 tsp vanilla into mixing bowl;
pour 4 cups flour into mixing bowl;

mix mixing bowl;
pour mixing bowl into 12x6 inch pan;
place 12x6 inch pan into oven;

bake 15 minutes;
}

I call BS

[DarthStrydre]

Writing HTML is not programming. Drawing a stick figure with a smiley face is not art.

You are trying to imply that an artist should be able to write the next vector raytracing engine for HalfLife 3 with no knowledge of calculus. I claim BS. This is like giving the typical slashdotter with no art experience a contract to make a painting styled after a Rembrandt. "Its real simple! you just dip the paint brush in the paint, and drag across the paper"

In game development, there is a need for REAL programmers, REAL artists, and REAL musicians. Some people can pull off being two of these well enough, or even all three, but generally this is not the case.

Computer science is a science, mainly by the definition of "Methodological activity, discipline, or study".

Games are a work of art as much as a program. If you swap the personnel of the art department with the gaming engine department, the game will look like Duke Nukem Forever, and, uh... never mind.

Personally, the best programmers I know have graduated with degrees in electrical or computer engineering, not ComSci. ComSci folks seem to be too focused in the software realm. Yeah, this seems stereotypical, but based on observation. YMMV.

- Strydre

Re:Very Cute

[bratboy]

I think that most "real" programmers will have approximately the same reaction to this, which will be somewhere between a shrug and a snicker. To be an effective programmer you need to be able to accept certain formalisms, and for people who "get it" (i.e., are vulnerable to the snow crash virus) high level programming languages are quite readable. (have you ever tried explaining to a neophyte why you would use do-while vs. while{} vs. for(;;)? or variables?)

In working with designers (especially inexperienced ones) on video game projects, one of the things I noticed is that they have no conception of what is possible and what isn't. They will agonize for a week on how to simplify something that isn't actually difficult, and then assume that you can easily throw in something that's impossible. Part of becoming an experienced designer is learning the difference between the two.

Junior programmers have a different problem - they don't know how to structure their programs. Building experience is primarily learning patterns you can use to solve problems (a good, experienced programmer will look at "Design Patterns" and be able to tick off a large percentage that s/he uses, but never formalized, and maybe disagree with one or two). Switching to natural language for code specification isn't going to help.

The one area in which this might be useful is in scripting languages - using the video game example: when you want your designers to be able to put together behaviors for agents without having to learn some arbitrary language that you've thrown together. You're still probably going to have to have a programmer give the scripts the once over to make sure that they're not doing something silly, but it might be a more approachable interface for the designers.

It would actually be much more useful to have an IDE which allowed you to add graphics or voice as comments (how many times have I wanted to add a small sketch as a comment to some graphics code?).

daniel

Cooking for Engineers

[Dlugar]

I prefer the format used by Cooking for Engineers.

Time flies like an arrow

[Viking Coder]

When a Harvard natural language parser was given the phrase "Time flies like an arrow," in the 1960s it identified the following five parse trees in reponse.

1) Time proceeds as quickly as an arrow proceeds.
2) Measure the speed of flies in the same way that you measure the speed of an arrow.
3) Measure the speed of flies in the same way that an arrow measures the speed of flies.
4) Measure the speed of flies that resemble an arrow.
5) Flies of a particular kind, i.e. time-flies, are fond of an arrow.

I would guess the source code for those five different interpretations would be, well, different. (The fifth one is my favorite.)

Dijkstra said it best...

[period3]

...in his paper on the "Foolishness of Natural Language":

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.

Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve.

When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

Re:About your update, Taco

[Tim C]

Seems to me that a slashdot employee has one or more of four duties:

1) pick stories to post
2) sell advertising
3) maintain the servers
4) design and implement additions, bug fixes, etc

Now, I'm not a subscriber, but I don't see much in the way of 4), even for features that the readership is crying out for, or that make financial sense for slashdot (such as moving to CSS for layout). I thought that /. got most of its advertising through the OSDN network, so I'd imagine that 2) is more or less minimal (and with /.'s fame, shouldn't be too hard anyway). That leaves 3) and 1). I have no idea about the time requirements of 3), but I can imagine that it might keep a couple of people busy full time.

That seems to me to leave an awful lot of time left over for 1), picking stories to post. And yet, it seems like every day or two there is a dupe, every week or so there is a downright inaccurate (or even lying) summary or headline posted, and every month or so something that's accurately summarised, but the source is just plain made up or wrong.

I know that the FAQ states that the editors don't check the stories for factual correctness, but Taco (et al) I ask you this: what do you do all day?

It's all a matter of perspective...

[benhocking]

Hey, anyone is free to use it - all I'm saying is that it's going to create more bloated shit than anything else, and then who do you think is going to have to fix it (also explaining why it costs so much more, when it "can't be that hard, 'cause we were able to do stuff using Metafor")

Sounds like someone has a case of the Mondays. ;) Seriously, you appear to be speaking from your experience as someone who has to support idiots (AKA the general population). OTOH, I'm speaking from my experience in the sciences where the amount of time spent writing code is frequently larger than the amount of time spent running the code. In many instances (not all) bloat is less of a problem than time wasted tracking down the reasons behind a segfault. That's one reason why many scientists "code" in Mathematica and/or MATLAB. Again, I'm not saying that this particular solution is any good, just arguing for the value in making programming easier at the expense of making the programs less efficient in space/time.

People are going to use it for stuff it's NOT suitable for - that's human nature. Give someone a hammer, everything becomes a nail.

Give a mother a band-aid, and everything's a boo-boo. I still remember that time when I had my legs and arms separated from my body - blood was spurting everywhere! - and my mother was trying to fix it with a band-aid (well, four band-aids). Luckily, I finally convinced her that this was a job for a surgeon.

Re:It's actually sorta important!

[A beautiful mind]

Dear CmdrTaco!

Please state your requirements about a dupe checker, between realistic boundaries.
Things like - integration into the accepting stories interface seamlessly, spamassassin style dupe detector with a point based system, or even coding bayesian algorithms - are possible.

I'm willing to (help to) code it. With two conditions. You'll apply it and use it. If this happens i'm predicting a serious decline in dupe stories and posts.

If you fail to do this or you're not interested in this offer, then STOP being pissed, put up with the hate mail, the accusations about ad revenues, and use the bloody search function.

Just to make sure this offer reaches you i'm going to mail it to you, and continue to do so - in regular periods - until i get some kind of reply, either a yay or a nay.

Yours, a beautiful mind

Re:Dupe checking is a not a technical problem.

[festers]

CmdrTaco doesn't read his own site. What does this tell you about how he feels about it?

Yes, that's been pretty obvious for the last couple years.

I don't read Kuro5hin much anymore for the same reason. Complaining about dupes will just drive him further away, even though he still has to work on it by contract.

You say that like it would be a bad thing. Maybe it's time he lost the presence, admit that's he's been burned out for years, and handed over the "reigns" to someone who cares enough about Slashdot to make the changes that are sorely needed. No one expects him to work at /. forever. If you can't find any pride in a job well done, maybe it's time to find another job...