In the Labs: Automatic Code Generators

March 20, 2006 (Computerworld) Twenty years ago, software engineer Fred Brooks famously observed that there was no silver bullet that could slay "the monster of missed schedules, blown budgets and flawed products." Today, the creation of software might seem as expensive, trouble-prone and difficult as ever.

And yet progress is being made. While there is still no silver bullet in sight, an array of new techniques promises to further boost programmer productivity, at least in some application domains.

The techniques span a broad spectrum of methods and results, but all are aimed at generating software automatically. Typically, they generate code from high- level, machine-readable designs or from domain-specific languages—assisted by advanced compilers—that sometimes can be used by nonprogrammers.

Gordon Novak, a computer science professor at the University of Texas at Austin

Gordon Novak, a computer science professor at the University of Texas at Austin and a member of the school's Laboratory for Artificial Intelligence, is working on "automatic programming"—using libraries of generic versions of programs, such as algorithms—to sort or find items in a list. But unlike traditional subroutines, which have simple but rigid interfaces and are invoked by other lines of program code, his technique works at a higher level and is therefore more flexible and easier to use.

Novak's users construct "views" that describe application data and principles and then connect the views by arrows in diagrams that show the relationships among the data. The diagrams are, in essence, very high-level flowcharts of the desired program. They get compiled in a way that customizes the stored generic algorithms for the user's specific problem, and the result is ordinary source code such as C, C++ or Java.

Novak says he was able to generate 250 lines of source code for an indexing program in 90 seconds with his system. That's equivalent to a week of productivity for an average programmer using a traditional language, he says. "You are describing your program at a higher level," he says. "And what my program is saying is, 'I can tailor the algorithm for your application for free.'"

Novak says he intends to expand the system to allow construction of larger programs and eventually to turn it into a commercial product. "I hope to move programming up a level, from the writing of code to programming in terms of abstractions, such as physical models, financial models and so on," he says.

Douglas Smith, principal scientist at Kestrel Institute

Douglas Smith, principal scientist at Kestrel Institute, a nonprofit computer science research firm in Palo Alto, Calif., is developing tools to "automate knowledge and get it into the computer." Kestrel's development system works with two kinds of knowledge: the skills and techniques that programmers have—about data structures and algorithms, for example—and the application knowledge that an end user has.

Specware Features

A programmer starts with Kestrel's Specware, which is a general-purpose, fifth-generation language that specifies a program's functions without regard to the ultimate programming language, system architecture, algorithms, data structures and so on. Specware draws on a library of components, but the components aren't code. They are at a higher level and include design knowledge and principles about algorithms, data structures and so on. Smith calls them "abstract templates."

In addition, Specware can produce proofs that the working code is "correct"—that is, that it conforms to the requirements put in by the user (which, of course, may contain errors). "Some customers want that for very-high-assurance applications, with no security flaws," Smith says. Kestrel does work for NASA and U.S. military and security agencies.

Specware is essentially a productivity tool for programmers, producing several times as many lines of code as is actually written by the programmer. But Kestrel has something at an even higher level—a language called Planware that's specifically for creating scheduling applications. Smith says users at the U.S. Air Force, who know about airplanes, runways and air bases but not software, used it to create an aircraft scheduling system.

"It's a language for writing down problem requirements, a high-level statement of what a solution should be, without saying how to solve the problem," Smith says. "We think it's the ultimate frontier in software engineering. It's what systems analysts do."

In the future, Kestrel will enhance its techniques by incorporating some of the concepts of aspect-oriented programming that deal with issues that cut across programs, such as activity logging and authentication. When users make a policy change related to such cross-cutting issues, it can entail expensive code changes at many places in a system. "I want to allow programmers to write policies at a very high level and then have them automatically enforced," Smith says.

"How to put cross-cutting issues into designs is one of the most important things going on in software engineering right now."