November 2003

Everyone's a Programmer

Continued from page 2

By Claire Tristram

Programming In Pictures

When you ask Simonyi to explain just how the dronelike parts of programming might be automated, eliminating bugs caused by human error, he will tell you a story about jet engines.

"Think about the turbine blades," he says. "They have to be perfect. If you were to use the most meticulous craftsman to make them, you still wouldn't get anywhere near the degree of accuracy you need. You need to create a machine to make the blades. Are humans involved in the process? Of course. You need them to build the machine, and to maintain it and adjust it. Can machines fail? You bet! But they fail in a disastrous way, and you can see it right away and can fix it. It's the same thing with code! You don't want humans to touch it. It will have bugs in it! Can humans do something? Yes. They can build the machine."

What, exactly, would a machine for writing software look like? It would itself be software. But its function would not be to solve the end problem-to perform some new home or office task. Rather, it would be a software "generator," causing a particular piece of software to be written. Telling the generator what program to write would be accomplished through an easy-to-understand interface, sometimes referred to as a "modeling language."

The most widely adopted modeling language today is the Unified Modeling Language, which evolved from work Booch and fellow programmers James Rumbaugh and Ivar Jacobsen did at Rational Software-and which is now being developed by the open-source software community under the stewardship of IBM and the other members of an industry consortium called the Object Management Group. The Unified Modeling Language is a system for creating diagrams. It's intended to let managers of large software projects visualize their designs and make sure they meet the clients' requirements before programmers sit down to write code in programming languages such as Java or C++.

Simonyi's vision, and the reason he started his company, is to take the idea of models and go one step further: to link the model and the programming so tightly that they eventually become the same. Programmers and users will be able to switch between many contrasting views of the model they are creating, and revise programs at will simply by tweaking the models (see "Just-in-Time Programming," below). It's something like an architect being able to draw a blueprint that has the magical property of building the structure it depicts-and even, should the blueprint be amended, rebuilding the structure anew.

Just-in-Time Programming: In this hypothetical intentional software program from a "just in time" auto parts ordering system, option packages run across the top, parts numbers along the left. Any changes a factory manager adds-say, information for a new model year (pop-up box)-would be automatically reflected in the software code.

"It goes all the way back to the notion of what you see is what you get,'" says Gregor Kiczales, who left his part-time position at the Palo Alto Research Center last year to cofound Intentional Software with Simonyi but has since returned to his longtime position at the University of British Columbia in Vancouver, where he is a professor of computer science. Kiczales champions a programming technique known as aspect-oriented programming, which allows programmers to edit all instances of related commands quickly, even within a very complicated program-just as a word-processing program can locate and replace every instance of a misspelled word. It's a technique that will support the underlying architecture of intentional programming. "The idea of intentional programming is, what if we did that not just with word processing, but with programs?" says Kiczales, who remains a consultant at Intentional Software.

Simonyi describes the new model for generating programs as looking very much like a PowerPoint palette, which anyone can use to create presentation slides by pasting text, charts, or images into different sections of an intuitive virtual workspace. But Intentional Software also believes that different types of problems may call for different interfaces, to meet the needs of different clients. Scientists working with computer simulations, for example, might want to use a generator programmed to mechanically translate mathematical descriptions into the corresponding code.

The kind of software Simonyi envisions will not only relieve tomorrow's programmers from the need to behave like machines; it will also enable experts in a given field-insurance, accounting, health care-to make their own changes to their software, easily and without the constant aid of a programmer. Suppose you are a corporate accountant using custom financial software, and a new tax law is passed, Simonyi posits. "You can edit the description of what you want to do on your own, and now you run the generator again. You don't involve programmers again. The generator runs at computer speed, about a billion times faster than human, and a billion times more precise, and you get your change."