Intentional programming and Dreaming in Code

Intentional programming and Dreaming in Code

Summary: Worth reading: I have been following Charles Simonyi's adventures in programming for many years. Charles is considered the father of Microsoft Word and the architect of Microsoft Office.


Worth reading: I have been following Charles Simonyi's adventures in programming for many years. Charles is considered the father of Microsoft Word and the architect of Microsoft Office. He left Microsoft in 2002, after more than 20 years on the Redmond campus, to form Intentional Software, with the intention of taking the drudgery out of software programming. In the MIT Technology Review, Scott Rosenberg has written an extensive profile of Charles, who is scheduled to take a 10-day trip to the International Space Station in April, and of the intentional programming concept.

Scott has also been busy lately preparing for a launch. Although he isn't heading for outer space, his book, "Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software," will be released on Tuesday. He uses the Open Source Applications Foundation's Chandler and Cosmo projects as a backdrop for exploring the lore and enigmas of software development and the human-computer interface. In the book, which is a thoroughly engrossing and instructive exploration into the heart and culture of software development, Scott writes:

"It's tempting to view the multitude of monster projects gone bad as anomalies, excrescences of corporate and government bureaucracies run amok. But you will find similar tales of woe emerging from software projects big and small, public and private, old and new. Though the details differ, the pattern is depressingly repetitive. Moving targets. Fluctuating goals. Unrealistic schedules. Missed deadlines. Ballooning costs. Despair. Chaos."

Software development is a fundamentally human endeavor, a Sisyphean task in which the hill seems to get steeper. After spending years conceiving and writing "Dreaming in Code," Scott distilled his experience into what he self-referentially calls Rosenberg's Law:

"Software is easy to make except when you want to make something new. And then, of course, there is the corollary. The only software that's worth making is software that does something new."

Intentional programming is something new aimed at taking complexity and errors out of the software development process. As part of Scott's intentional programming article in the Technology Review, Wade Roush provides an explanation of intentional programming, which so far has been more theory than practical reality. Here is the gist of it:

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:










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

return a = ------- ;
Does intentional programming make more sense to you now? 

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


1 comment
Log in or register to join the discussion
  • "Does intentional programming make more sense to you now?"

    The simple answer - no it doesn't.

    The fundamental basis of all programming has been known for years and programmers and designers regularly ignore it. I'll repeat for anyone who wants to know.

    1. The design of solution should reflect the structure of the problem being solved.

    2. Given the choice between algorithms pick the simplest (there may not always be a choice).

    3. In the following order of precedence
    a) Code should be correct (highest priority)
    b) Code should be clear, understandable and readable
    c) Code should be efficent (lowest priority)

    From what you've shown of the book it looks like he is trying to come up with an "automated" programming paradigm of the [i]"follow this and you can't go wrong"[/i] methodology. So far none have ever succeeded.

    [b]The solution to all programming problems[/b]

    What programmers REALLY need is good, solidly tested code libraries [i]at a high level![/i]. I'm not talking [b]strcpy[/b] or Java classes. What we need is an "uber-language" which works at a really high level. It should contain code and data structures where appropriate and should form the basis of the model in the MVC paradigm (and possibly be able to generate part of the view for the MVC)

    Take addresses - how many times do you see code to store, handle and manipulate addresses? Why isn't this sorted out by now? Why isn't there a "standard" address object that you can simply plug in?

    Invoices - They're common enough and they all have the same format. Yet everywhere you go there is another bug-ridden implementation of invoice processing.

    Calendars, Dates, To-do lists, appointment lists - LISTS!!!! They're all lists.

    Think what an ISO recognised date, invoice, address, etc format would do for data interchange! If they contained the basic screen layouts code would behave predictably enough for users as well. SQL is standard enough and works well so all their data manipulation should be in SQL. Adaptation to other storage technologies would be possible but the reality is that SQL meets the needs for the vast majority of database storage and retrieval.

    It would be so useful - that's why it will never happen.