January 2007

Anything You Can Do, I Can Do Meta

Continued from page 12

By Scott Rosenberg

Intentional Programming Explained
Simonyi and company are pioneering a push-button approach to programming.

[ Click here for a diagram of Simonyi's planned approach]

Shane Clifford, a developer at Intentional Software, tells this fable.

Once there was a village with four parks, maintained by four competitive neighborhood associations. The first association decided to spruce up its park with a new bench. It solicited proposals from three of the world's leading bench makers. None of the designs won a majority of the neighbors' votes, so the association chose the most popular design. The process was democratic--but in the end, most were unhappy with the new bench.

The second association decided it wanted its own bench, but one that everybody liked. It found a manufacturer that built customized benches from mix-and-match parts. But the wood seat the members liked didn't come in the right length, and the decorative back didn't work with the green legs they liked. So they compromised on parts that did work together. The neighbors were proud of the finished bench, but no one sat on it very often.

The members of the third association saw how much money the first two had spent and decided they could do better. The craftsmen in the group asked everybody for suggestions, and in the end they built a simple, elegant bench that everyone agreed was the nicest in the village. Unfortunately, it wobbled dangerously.

The fourth association wanted a bench, too, but it didn't want to repeat the other groups' mistakes. The neighbors turned to a little-known bench maker who advertised "a new bench-making experience." The bench maker arrived with a flatbed truck loaded with odd-looking machines. He began to ask questions like "What is this bench's most important feature? What's the next-most-important feature? What materials do you like? What's your favorite shape for the bench's feet?"

After each answer, the bench maker would turn a few knobs on his machines, and a new image of the bench-in-progress would appear on a large screen. Sometimes the image wasn't quite right, so the neighbors would backtrack and answer the questions differently. After 50 questions, the bench maker pushed a large button. The machines hummed for a while, then disgorged a beautiful bench matching the final image on the screen. Everyone was glad to have had a chance to contribute, and many people sat on the bench every day.

To get a bench that makes everyone happy, you must build an automatic bench-making machine; help clients define their precise hopes for their bench; translate those hopes into instructions the bench-making machine understands; and then press the "Make" button. Clients get close control over the outcome, and bench makers, freed from the repetitive and mechanical parts of bench making, get to spend more time using their skills to feed their clients' wishes into the machine.

Substitute software for benches, ­Clifford is saying, and you'll understand intentional programming--so named because programmers are focused on the way their customers intend a program to work, and not on the clutter of code required to implement those intentions.

Intentional programming is similar in concept to what-you-see-is-what-you-get word processing programs, which Charles ­Simonyi, Clifford's boss, pioneered. "Wysiwyg" text editors let computer users manipulate a document's appearance on screen without forcing them to master the underlying code. ­Similarly, intentional programming encourages computer users to express their needs in their own familiar language, then shows them comprehensible views or "projections" of the emerging design before the executable code is assembled. It's not the only programming philosophy that relies on such graphical representations; the Unified Modeling Language (UML), developed in the mid-1990s at Rational Software (now part of IBM), also uses graphical diagrams to represent a program's function, structure, and behavior. But UML diagrams can't be transformed into finished software, which is Simonyi's dream for intentional programming.

Just how does Intentional Software hope to realize that dream? Let's put ­Simonyi's plan into its own diagram ( click here ). The software-building process begins, naturally, with the customer: any organization with an information-intensive task that needs automating. Simonyi calls the people at these organizations "domain experts"; they, not the programmers, know what the program should do.

With the programmers' help, the domain experts list all the concepts and definitions the software will need to encompass. All these definitions go into a database that Simonyi calls the "domain schema."

Like the bench maker turning his knobs, the programmers then incorporate the definitions in the domain schema into "domain code"--a high-level representation of the software's functions, expressed in a "domain-specific language," or DSL, that can be tailored to suit the industry in question. But while DSLs can vary, each action the software must carry out is stored in a uniform format, an "intentional tree." Intentional trees have the advantage of being visually simple but logically comprehensive, which means they can be manipulated, revised, and "projected" or reënvisioned at will.

For example, the computation represented by the simple program statement

return a = b / (c +1) ;

is represented by the following intentional tree:

Return
(

Assign
(

a,
Div
(

b,
Plus
(

c,
1

)

)

)

)

Once encoded in tree form, the computation can be projected in many other ways that might be more familiar to domain experts, such as

b
return a = ------- ;
c+1

As their first concrete task, Simonyi and his colleagues at Intentional Software are working on building a special tool, the Domain ­Workbench, designed to manage these projections. Both the domain experts and the programmers use the Domain Workbench to edit and reëdit the projections until they look right. After that, the domain code is fed into a "generator"--the equivalent of the bench maker's truckload of machines--that churns out "target code" in a language such as C++ or Java that other computers are able to understand, compile, and run.

Once the target code is generated, it can't be turned back into domain code. In that respect, the generator is like an encryption program that irreversibly transforms plaintext into ciphertext.

However--and this is perhaps intentional programming's biggest advantage--it's easy to scrap old target code and generate improved code from scratch. Simply revise the domain code using the Domain Workbench's Wysiwyg editor and run it through the generator again. In most older approaches, even the slightest change in the original assumptions might require programmers to sift through millions of lines of code, updating every instance of a concept, definition, or computation by hand.

The generator remains the biggest black box in Intentional Software's process. In technical publications, all the company will say about this mysterious component is that the prototype is being written in Microsoft's C# programming language and that it accesses the domain schema and the domain code using an "application programming interface," a way for two programs to communicate, that's built into the Domain Workbench. Clearly, though, writing the generator itself, or tailoring it for a specific industry or DSL, will be a big part of the cost of any intentional-programming project.

"Wysiwyg empowered millions of more users to author great-looking documents," Simonyi writes on the company's blog. "It is time to do the same for software users."

By Wade Roush