Fundamentally open approach to Domain Specific Tooling


My last post on our deployment tools and Rob’s comments on them suddenly seemed to me to be a case in miniature of our whole approach to domain specific tooling and why I’m passionate about it.
 
We take our domain-specific deployment language and convert it to WiX to get the installation job done. (WiX is itself a DSL one level lower down the abstraction stack than our language – it is converted to MSI files by the WiX toolset).
 
Two points about this are critical:
  • The templates used to do the model transformation are just text files that you can modify or add to.
  • The generated WiX files are just text files that you can modify or add to. (Of course modifying generated code is its own slippery slope)
 
As Rob points out, “if a particular developer has additional setup needs then she can take the generated .wxs file and customize/extend it.”
 
This approach does mean that the MSI author is somewhat exposed to the nuts and bolts of the WiX implementation of their DSL.  It’s not simply a black box tool – if the sight of an XML file makes you queasy then you’ll have some acclimatizing to do.  This was what I meant by the word “open” in my title – apologies to those who have politically charged views over the use of that word 😉
 
We don’t believe that at a given point in time ANY tool addresses 100% of the needs of 100% of its customers but we don’t want our customers to be blocked from having their needs met by the scope of the feature set that we happen to have implemented at that particular time.
 
In an old discussion on a feature we don’t support currently Steven Kelly expressed the view that we seem to be targeting developers with our tools, whereas his esteemed tool aims more (or at least as much) to target domain experts by always doing 100% code generation thereby relieving them of the need to write any code.  A question Steven: What happens when the feature an authoring user wants isn’t supported by the current version of your tooling?
 
I really believe in our approach of having both generated code and, more importantly, the mechanism by which it is generated fully malleable to developers.
 
If the success of your product or application relies on being able to implement a specific feature in your DSL designer, we shouldn’t be the ones to get in your way – or at least not more than we can possibly help.
Comments (2)

  1. Steven Kelly says:

    Good question, Gareth! We want MetaEdit+ to work as a DSM tool for non-programmers too, as you say. Anything important in a modeling language, like concepts, rules, and symbols, must thus be easy to make without programming. This of course requires us to put more power into the tool "out of the box", but that’s fine: it makes life easier for our programmer users too.

    When users want to go beyond what’s already in the tool, they can use the API. That’s WebServices based, so they can access it with whatever programming language they prefer. (Interestingly enough, no customers have used it yet, so I guess we’re doing at least a fair job at giving them the power they need without them having to program.) For integration up or downstream we have XML import and export of models.

    On the generator side, the generators are written by the metamodeler in our own generator language. That gives the full control over generation that you mention – and you’re right that it’s vital. Fixed generators played a main reason for the downfall of CASE tools 20 years ago, and generation of only skeleton code by UML tools has been a mockery of what raising the level of abstraction, automation and productivity of development should be. Having our own language to write generators in means they can be written much faster than using a standard language like C# or VB, as I mentioned earlier (http://www.metacase.com/blogs/stevek/blogView?showComments=true&entry=3294407238).

    Since your question was so good, and this window’s so small :-), there’s more in my blog: http://www.metacase.com/blogs/stevek/blogView?entry=3311420578