I see that Steven is having another go at Microsoft’s DSL Tools.
Not for the first time, my impression is that he makes it look worse than it actually is. To quote:
“As long as Microsoft thing of building modeling languages as a programming project, it’s going to be impossible for them to make the changes they need to, without breaking existing modeling languages built with their tools. If they have the possibility to make major improvements to DSL Tools, my suggestion would be to go right ahead: the important market is those who have not yet been reached. Those brave enough to use CTPs, betas and version 1.0 knew what they were letting themselves in for.
This is of course a problem with tools that require programming to build modeling languages, or a separate compilation step between the definition of the metamodel and using it to model with. In MetaEdit+, the metamodel is specified directly in the tool, with no programming, and models are made based directly on it, with no intermediate compilation. In other words, the metamodel is expressed as pure data, which makes both metamodel updates and tool updates easy and painless for the users.”
In DSL Tools, a large proportion of the code for a designer is generated from a dsl definition. If we make changes to the code generators, then to migrate to a new version is a matter of regenerating the code. If we make changes to the designer definition, then, in the case where those changes are not pure extensions to the designer definition language, we can provide a tool to migrate existing definitions across to the new format. If the designer author has written custom code to finish off their designer, then we could break that custom code if we make sigificant changes to the APIs it is written against, although there are various techniques that can be used to mitigate some of the pain (for example, deprecating APIs over versions). Now, as we add more features to DSL Tools, we will do our best to reduce the amount of custom code that designer authors will feel the need to write, but I think we’ll always want to provide that outlet, as authors will always want to push the boundaries of the designers they wish to create beyond what we have thought about in advance when designing the dsl definition format.
Now, I wonder what happens in the MetaEdit+ case. If the format in which the metamodel (dsl definition) is expressed changes (which it might if they want to add new features), then there has to be code somewhere which migrates metamodels expressed using previous versions to the new version. And I don’t see how this is any different to us providing a tool (which may be integrated with the DSL designer itself) that migrates a dsl definition expressed in previous versions of the dsl definition language into newer versions. The difference in the two situations is that with DSL Tools, the extra custom code needs to be converted, but I wonder how much effort that really is, given appropriate guidance and the fact that significant changes to the APIs are not exactly frequent occurrences.