“Providing them with a ready-made language template would:
- Get them started on the wrong path: They would not think carefully about their problem domain and attempt to create a language that would fit it. Instead, they would take the ready-template and try to fit it to their problem domain via all kinds of complex adaptations (similar to the UML profiles approach): Let’s do it quick and ugly.
- Because of this, limit the possibilities and flexibility to generate the code they need, leading to a need to reverse engineer and round-trip: A road to nowhere…”
I pretty much agree with him. We ship just a very few templates in the DSL Tools and we’ve sometimes wondered about expending some effort to expand the set. On the whole we’ve decided against it unless we had a significant new feature to demonstrate.
I completely agree with Martijn on code generation templates – we only ship the most trivial templates as we can’t predict what code or documentation would be interesting for our users to generate unless we water it down to the point where it wouldn’t be useful to anyone in generating production-quality code. For example, are you generating classes that run inside COM+ component services, or are part of a WCF service hosted in IIS – who knows?
We pretty much take the view that templates are a learning tool for the facilities of the tools. it’s just that they’re just a learning tool that is a little more accessible than regular samples as they are a bit more in your face. Now the Visual Studio SDK has a first-rate sample browser, this is perhaps less of an issue than when we were first planning the facilities of DSL Tools.
However, one aspect of templates that we do think is perhaps a little more valuable as a genuine starting point is notational stuff. We’ve heard time and again from customers that although they want to build domain-specific models they’d like to start from somewhat familiar notations mapped on to those domains.
I suspect this doesn’t necessarily generate optimal languages, but it has some advantages. Firstly, it provides a degree of familiarity/acceptance to some previous modeling users. Also, given that the visual design of visual languages isn’t a skill everyone has, it does give those of us with a less artistic bent something to begin with and perhaps avoids too many purple and lime green modeling languages.
Anyway, what do you think? Have you based your DSL on one of our three main templates? Did they influence your domain model design or your notation design or both? Do you think they saved you much time, helped or hindered?
BTW – congrats to ALL the MetaEdit folks on shipping V4.5 of their tool. Those gradient fills sure are yummy 😉