Intentional Software raises the curtain

I'm not sure. If you do this the right way, you could build a Smalltalk the way it should have been. And that's not really an over-engineered enterprisey thing by itself is it?

One of my friends was working at Intentional on this very system and after he raved about it for a while, I said "this sounds like an MVC implementation with an Abstract Syntax Tree being the model and the various"projections" (or whatever the terminology was - I forget - it has been a few years) being the View. Did I get the idea right?". He was a bit deflated but said "yeah that is what it is " and changed the topic.

Checked out IP in Wikipedia. Not only do I understand it, I'm fascinated by this approach, and have fiddled with similar ideas for years. Yay wikipedia!

Because when you write everything in "plain english", your text suffers from mainstream journalist information degradation syndrome.

Imagine you are contracted by a circus to write some custom software to manage their operation. The software has to do things like track the length of the bearded lady's beard, find the best deal on insurance for the sword swallower, calculate the trajectory of the human cannonball, and of course cross-reference everything to generate insightful reports.

You start by grilling the customer until you have a full understanding of how the whole operation works (aka the "domain") and exactly what the software needs to do (requirements).

You could then take the fast and dirty approach which would be to just hard-code the requirements, hand it to the customer and run. You would probably write a lot of code that you feel like you've written a million times before, but this case is just different enough that you can't reuse anything, so a lot of time and money is wasted writing redundant code. And hopefully, you'll be over the horizon by the time the bearded lady decides to grow a moustache and they want to track that too, because your app doesn't do that.

If you want to be all innovative and outside the box, you might make a DSL called ClownML to describe circus management workflows:

  attraction AmazingGeorge {
    type = HUMAN_CANNONBALL
    weight = 85kg
    distance = 100m
  }

  attraction LovelyLucy {
    type = BEARDED_LADY
    hair_types = [BEARD,MOUSTACHE]
    hormone_level = 7
  }

  preshow {
    check Cannon.pitch == AmazingGeorge.required_angle
    check LovelyLucy.beard_length >= 3 feet && LovelyLucy.moustache_bushiness >= 2 furlongs
  }

Now the customer, without the aid of a programmer, can use this simple, intuitive language to adapt your application to their changing needs. Of course, they won't actually touch this "code" with a ten foot pole, but at least you can use the language to make maintenance easier on yourself.

But wait, now they want to launch someone out of a catapult instead of a cannon and ClownML doesn't have a catapult type. They also want the person they launch to be Lovely Lucy and that's an even bigger problem because having the same person be two different attractions is not even expressible in ClownML. You go back to the drawing board and create ClownML 2.0 which has classes, inheritance, polymorphism, lambdas and syntactic macros. There is no conceivable requirement that could not be expressed in this language. Unfortunately, you've simply wasted a huge amount of time inventing a general purpose programming language which is twice as verbose and half as powerful as Ruby or Python and looks like Perl on acid.

The circus fires you (out of a cannon) and hires Charles Simonyi. They pay him $100M, he hands them a copy of Domain Workbench and blasts off to Neptune in a Russian rocket, never to be seen again.

The circus ringleader sits down with Domain Workbench and using [intuitive interface X], describes the general domain of circusology, much as he described it to you. Using this input, the software generates an abstract language which can describe circus management applications in a very concise way, much like you tried to do. The language is abstract in that it has no single concrete representation. Rather, it can be represented, and edited, as text, tables, diagrams, trees or graphical morphing hypercubes. The ringleader chooses his favorite representation, one which is intuitive and non-programmery, and uses it to implement his specific requirements. If he later finds that he can't describe something in circusology language, maybe because the very nature of his business has changed, he can go back to [intuitive interface X] and quickly alter the definition of circusology language just enough to accommodate that change, without breaking his existing code.

Exactly how the things in the previous paragraph work, Intentional Software has left as an exercise for the reader. If they are to be believed, they have it all figured out and have just been waiting for the right time to fill the rest of us in, for the last decade or so.

There is a presentation here -> http://www.infoq.com/presentations/intentional-software . I haven't watched it yet though :)