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

• Anonymous
  December 15, 2005
  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.
  
• Anonymous
  December 24, 2005
  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.
• Anonymous
  December 29, 2005
  The comment has been removed