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

Dupe

[tcopeland]

Of this, I think...

The associated paper is very weak

[Animats]

There's a paper linked from the article, but it's so short and weak that it's hard to tell if anything useful has been accomplished. In particular, it's not clear it if scales beyond the 25-line program shown. There are vague claims that it uses some database of "common sense" to help build the programs, but the paper shows no evidence of this.

This has been tried before, not successfully.

Re:Very Cute

[AKAImBatman]

My guess is that if you're having trouble wrapping your head around OOP, then you're going to have trouble wrapping your head around the ins and outs of a natural language interface.

For what it's worth, OOP is quite easy. The first thing you need to think is data encapsulation. Data encapsulation is simply the practice of bundling related data together. i.e. Color, make, year, and model are all attributes of a car. So you'd tend to put them together. You know, like structs. For example, a game sprite might have x, y, width, height, and direction variables.

class Sprite
{
int x;
int y;
int width;
int height;
int direction;
}

Of course, we want to know what the direction stands for, so we add static constants:

class Sprite
{
const RIGHT = 0;
const LEFT = 1;
const UP = 2;
const DOWN = 3;

int x;
int y;
int width;
int height;
int direction = RIGHT;
}

Now for the truly OOP part. We need a way of making the data operate on itself. For an example, I'll choose changing direction.

class Sprite
{
const RIGHT = 0;
const LEFT = 1;
const UP = 2;
const DOWN = 3;

int x;
int y;
int width;
int height;
int direction = RIGHT;

void changeDirection(int dir)
{
direction = dir;
}
}

Doesn't seem like much, but what if we want to ignore improper directions?

class Sprite
{
const RIGHT = 0;
const LEFT = 1;
const UP = 2;
const DOWN = 3;

int x;
int y;
int width;
int height;
int direction = RIGHT;

void changeDirection(int dir)
{
if(dir < 0 || dir > 3) return;

direction = dir;
}
}

In a real OOP program, we'd probably throw an exception, but you get the idea I hope. Now that we have our Sprite class, it can be treated as a complete data type of its own:

Sprite sprite = new Sprite();

sprite.changeDirection(Sprite.DOWN);

There you have it. A five minute introduction to OOP. Hopefully this will help unblock whatever mental issue is in your way. (Or badly written books as the case may be.) :-)

(Stupid lameness filter. Recognize code will you? No, that would be too difficult wouldn't it? Stupid lameness filter. Did I mention how stupid the lameness filter is? Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you? Stupid lameness filter. Recognize code will you?)

Use cases are deceptive

[crovira]

Its possible to construct perfectly correct use cases for an elevator which strands everybody on the roof.

Its also possible to construct use cases which don't make any sense (by not requiring the holes in the floors.)

Re:Use enums instead

[Tim C]

Java has enums as of 1.5 (or 5.0 if you're Sun's marketing dept). For previous releases, something like this should work:

public class Direction
{
public static final LEFT = new Direction(1);
public static final RIGHT = new Direction(2);
public static final UP = new Direction(3);
public static final DOWN = new Direction(4);

private int dir;

private Direction(int dir)
{
this.dir = dir;
}
}

Then the changeDirection method is

public void changeDirection(Direction dir)
{
this.direction = dir;
}

Re:Use enums instead

[Coulson]

The pattern for enums in Java prior to 1.5 uses a singleton class to achieve the same effect.

class EDirection
{
public static final RIGHT = new EDirection();
public static final LEFT = new EDirection();
public static final UP = new EDirection();
public static final DOWN = new EDirection();

private EDirection() {} // private constructor
}

The private constructor ensures that only these 4 instances of this class will ever be instantiated.

Re:Very Cute

[jericho4.0]

C++, the language many people firt work with in OOP, is not the easiest way to go about it. If you already know C, look at Objective-C. It is C + a very small set of OOP extensions.

If you don't know C, look at Python.

The OOP paradigm is much easier to get in the right language.

Re:Dupe checking is a not a technical problem.

[festers]

Sorry to reply again, I remembered something right after I hit the submit button. In August of 2001 I emailed Rob Malda and asked him if he still cared about Slashdot. There was an article that sparked a lot of criticism, and CmdrTaco's response was "Eh, we'll get over it." Here are some of those links:

http://slashdot.org/comments.pl?sid=21076&cid=2233 142

http://slashdot.org/comments.pl?sid=21076&cid=2233 751

It's kind of depressing to see that these issues keep getting rehashed year after year.

Bú shr -- Chinese ain't all that hard

[zooblethorpe]

Chinese is the hardest language in the world to learn.

By what metric? I've had a number of people tell me the same thing about English. As a native speaker of English, I've found Arabic much more daunting simply for the number of sounds that don't even approach anything in English, let alone the very complex grammar. Chinese by comparison was quite simple, with a grammar much closer to what I'd grown up with, and sounds I could at least approximate enough to be understood.

The problem with anyone saying "Language X is difficult" is that it has everything to do with where you're coming from. If you speak Samoan, then Mâori and possibly even Tagalog won't be too much of a stretch, as the languages are related. Coming from English and learning Mâori is a completely different ballgame.

By way of example, let's look at some simple sentences. "I am going to the store" in English works out to wö qù shângdiàn, literally "I go store" in Chinese. But try the same thing in Japanese, and it could come out umpteen different ways depending on who you're talking to. If you're amongst friends, you could say mise ni iku, lit. "store to go", with the subject of "I" only implied (implied subjects can make interpreting Japanese into English a real bitch, especially if you just missed the beginning of the conversation :). If you're talking to your boss, you might say watashi wa o-mise ni ikimasu, lit. "I (topic) (honorific)-store to go."

I'll be the first to admit this is a lame-ass example, but nonetheless, I hope it at least illuminates my main point -- what's difficult to learn depends on what you already know. :D

Cheers,