Home » forums » LtU Forum

Automatic Programming

Wouldn't the ultimate programming language be English? No, of course not, you say, it's too imprecise and ambiguous. (It's not even statically typed :^). From a programmer's standpoint, true -- but the programmer gets specs from somebody somewhere and is concerned with turning them into machine code.

So I'm not talking about cocktail-party English. I mean technical, jargon-laden English complete with embedded equations and diagrams such as the specs for a development project are written in anyway. And included is the assumption that it's not just one way, but there is a dialogue between the customer and the developer(s).

A bit of history: up until the early 80s, there was a strong subfield of AI called automatic programming. The idea was exactly the above: hand the system the same specs you'd give a human developer, and it did the rest.

Over the course of the 80s, AI collapsed. There was a boom in expert systems, there were Lisp machines, there was the Connection Machine. None lived up to its promise, and there was the concomitant bust. Automatic programming as a separate subfield of AI disappeared completely.

Even so, a lot of the stuff in languages now came out of 70s AI. Object-oriented languages look an awful lot like the "frame-based" AI languages at the semantic level. Any language with type inference is using a theorem prover to construct programs, just like the AP systems did.

One of my mentors at Rutgers did his PhD on the last AP project (Psi at Stanford). He claims that the ultimate downfall of AP was that you couldn't build the natural-language front end without cracking the general AI problem. (And no one has...)

So here's my question for the Ultimate Lambdas: skip the natural language. Design a formal input language for the front end. But still pose it at the semantic level of the specs. An expert system looks a lot like the kind of thing that goes on in an optimizing compiler. We have quite a lot of experience with automatic design and design assistants. Today's workstation has more horsepower than a Connection Machine. Why aren't we doing automatic programming?

Josh

By J Storrs Hall at 2007-03-09 13:17 | LtU Forum | previous forum topic | next forum topic | other blogs | 116804 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The Law of Automation

When asked to automate something, I frequently invoke a law that I word something like this:

You can't successfully automate something that you don't already thoroughly and reliably know how to do manually.

Consider it invoked here.

By Marc Hamann at Fri, 2007-03-09 13:47 | login or register to post comments

While I don't believe that

While I don't believe that the proposal here is realistic, a more formal system for specifications could be useful regardless. Specifications are rarely complete up front; rather, they are typically evolved. Wouldn't it be nice to have a parser for your specs that can tell you whenever there is an incomplete portion somewhere? It could even suggest possible solutions. Whether it be the first time you write the specs or simply an evolution of them, they could be formally checked automatically. I may even be possible to check the final program for conformance to the specs. Knowledge for existing programming languages can be used to design the spec language, and eventually the gained knowledge from the spec language could used in actual programming languages.

But how would a specification language work, anyway? There are some simple specification languages out there (UML, for example), but these are too separated from the problem domain in favor of closely mapping to language constructs. A formal spec language of the sort considered here would need to be easy to translate directly from natural language while still holding important formal properties. There might be a very fine line between this language and a true programming language anyway.

By Jake M at Fri, 2007-03-09 16:02 | login or register to post comments

Formal Spec Langauges

There ar elots of formal specification languages out there that are designed to deal with this sort of problem. The range from being very close to the programming language, such as JML, designed specifically to integrate with Java, to languages like Z which are far more abstract. Both of those can be parsed to find incomplete portions, and inconsistencies. And yes, you can even check the final program against the specs. Neither are that close to plain English (JML is probably the closer of the two in practice), but are better, and less ambiguous, than UML. Z, in particular, is closer to plain mathematics (and other spec languages, such as CASL, hew even closer to pure math, particulalry algebra), which is still pretty good - as the original poster admits, any "plain English" spec is going to have to be bolstered with math to be exacting enough anyway, so why not just go with straight math?

By Leland McInnes at Fri, 2007-03-09 19:23 | login or register to post comments

Look

Look Here

http://www.ics.mq.edu.au/~rolfs/controlled-natural-languages/

and here

http://attempto.ifi.unizh.ch/site/description/index.html

Might be natural front ends for Alloy or something like it.

I have a friend who tech writes to a standard something like this and says that it doesn't take a writer too long to learn to conform to the rules.

ww

By Webley Webster at Fri, 2007-03-09 18:08 | login or register to post comments

Intentional Programming

Isn't this what "intentional programming" is all about? (see http://www.intentsoft.com/technology/IS_OOPSLA_2006_paper.pdf)

By Jeff Foster at Fri, 2007-03-09 21:08 | login or register to post comments

Two things:

This is why I love ltu; perspective on interesting subjects.

"You can't successfully automate something that you don't already thoroughly and reliably know how to do manually."

There are many, many, huge legacy systems that occupy vertical markets that are extremely profitable for the companies that maintain them. I work on one of these. The thing that keeps these products profitable is the difficulty (impossibility) of duplicating functionality that spans three industries and has accreted over 30+ years. The obstacles to entering such markets are profound. It seems to me that in a domain where the problem is known, but competitiveness is limited by developer productivety (ie I know the space, but I can't write 30 million lines of code) something like an expert system, automatic programming, domain specific language, model driven architecture, etc... makes entering these types of markets possible (well, conceivable at least), and thoroughly upsetting some apple carts along the way.

Number two; it also seems to me that as language theorists, the academic tendancy is to build frameworks, like JML, when a very narrow domain would require a very narrow and specific solustion; ie the 'expert' in expert system.

Anyway, the thought process of 'how can a few developers re-implement a 40 year old, 40 MLoc system?' is the idea that got me into languages in the first place. I don't need a language to specify any system with near english language, I just need a language to specify a specific system such that 1 stmt == 1000 stmts of traditional code.

By MTaylor at Sat, 2007-03-10 00:50 | login or register to post comments

Mloc Mania

You're absolutely not alone in this. For instance these guys (warning: pop-up; wtf?) are into liberating cobol programs.

By Koray Can at Sat, 2007-03-10 02:24 | login or register to post comments

Pop-up

Yes, bizarre to see a pop-up on an academic site. It's caused by a hit-counter gone bad. I emailed the maintainer.

By Jeff Nowakowski at Sat, 2007-03-10 20:31 | login or register to post comments

Autocoding

There are some such tools for micro-controller programming in the automotive field. They allow the developer to draw diagrams representing the data flow using filters, state machines, etc.
They call this "auto-code".

When you're ready, you just press the "generate code" button. The
resulting C code doesn't require any manual changes.

The diagrams are also used/regarded as documentation (at least for
people who can read it).

Some keywords for a search: Matlab/Simulink, ASCET.

By ecl at Tue, 2007-03-13 14:08 | login or register to post comments