Modelling in the run time

Don Box says "In my mind, the only way this stuff will get traction is if we change the runtimes to work in terms of higher-order expressions.  Otherwise we're stuck in the 1980's CASE world where box-and-arrows and code were like matter and anti-matter, despite the best attempts at roundtripping UML and code."

I think he means we need to be able to reason and debug at the level of the models. In which case I wholeheartedly agree.  But until everything is done using modelling, we need a well-designed transition from the modelling to the code.  I think of this as the "customization cliff" - once you step outside of what is covered by your DSL, you plunge down a cliff onto the rocks of the low-level platform.  Instead, you need to be able to step down easily onto the next level of detail.  "Easy things should be easy, and slightly harder things should be only slightly harder".

Comments (3)

  1. Anton Lauridsen says:

    Depends on what level you are moddeling. Personally I think that a lot more effort should go into working on a pattern level.

    Patterns could easily be adapted to a generic tool for predicting and studying an application prior to the actual implementation.

  2. I would have to agree with Don on this one. What Steve describes is fine for the expert user that wants to customize the framework, and is using the language as a easy way to describe the bulk of what is repetitive work for the expert. But, for this strategy to work the user much deeply understand the framework down to the level of the executable language that is semantically closed (the programming language in this case.

    Right now the debugger, and run-times think in the semantics of C# and VB for the .Net world. Anyone trying to use a DSL built on top of that needs to know how that level works to do any customization of the DSL behavior. This has been happening with the WPF and WCF communities. They each offer a framework and a DSL of sorts to make things easier (XAML for WPF and config files for WCF). But, as soon as anything goes wrong you need to understand the C# run-time underneath that. Currently the mapping from XAML to C# is not really clear because the framework does so much for you, but has so little instrumentation at the XAML level of semantics. Until the user can do all their work (create, debug, reason) at the higher level it is just a convenience on top of a framework. This is not a bad thing, but it is not the same as C# over C or C over assembly.

  3. Tad Anderson says:

    I am afraid the crash to the cliff is going to start once you step into your DSL, depending on who put it together. I think every yahoo in the world who likes to re-invent the wheel will be putting out their own designers. Full Read…

    GAT/GAX is a different story… The Guidance Automation Toolkit (GAT) has potential to be a very useful tool, especially if the organization is willing to make the upfront investment in an Architectural Driven Development process or a Product Line Engineering (PLE) process.

    Restrictive Development using the GAT tools could be the rope that lowers you down the cliff.

    Full Read …

Skip to main content