Claudio Perrone spots the mistake that many beginners make in starting to use DSM: building a modeling language that is at essentially the same level of abstraction as code:

Last week Eamon O'Tuathail of Clipcode released a Domain Specific Language (DSL) for some of the Gang of Four design patterns using the Microsoft DSL Tools for Visual Studio 2005. It is indeed a very remarkable proof of concept and although the implementation is still pretty rough, it represents a valuable model for discussion and learning...

Besides some understandable limitations of both the language and the underlying platform (i.e. the DSL Tools) that will be undoubtedly addressed in future releases, my main interest (and point of concern) lies in the level of abstraction of the model...

As my exploration of the Domain-Specific Modeling (DSM) world progresses, I'm more and more obsessed by the idea that if we want to create the biggest ROI, it is essential to push our models towards a level of abstraction that is significantly higher than the level at which code statements and classes are written. In other words, a one-to-one mapping between a class created in a diagram and a class generated in code does not generally save enough time and I would dare to consider it an anti-pattern.

...if you think about it, a GoF pattern is still at a pretty low level of abstraction. In fact, it is the very essence of an OO pattern to address recurring cross-domain concerns. So a "real" DSL may still be built on top of it and possibly provide an even higher return of investment for your organization.

I can't help but be impressed by Claudio's level of understanding. Most good developers can learn quickly how to build a DSM for their domain, but to understand the wider implications of DSM in general and for others' domains requires a couple more grey cells. As more people move to using DSM there'll be a need for people like Claudio to add practical experience to theoretical understanding and use both to help others out.

The GoF design pattern language is a nice proof that it is possible to use the MS DSL tools to build new modeling languages, substantially faster than with Eclipse but substantially slower than with MetaEdit+. It took two days to build, including the presumably fairly simple code generators. Whilst MetaEdit+ would be much faster - no more than two hours - it's interesting to wonder whether having an easier environment would also make for better decisions in the modeling language design:

the toolbox is generally filled with lots of different elements even if the main concepts (in this case the GoF patterns) are more coarse grained.

Another area I'd be interested to know more about is the support in the Microsoft DSL tools for changing an existing modeling language. Let's take the easiest possible case: how easy is it to add, say, a new pattern to the GoF language? Do existing models update automatically to just work, allowing instances of that new pattern to be added? Is there any support for making sure that all users have the same version of the modeling language? Or for controlling the language centrally?

These are issues that we only really started to think about after the first version of MetaEdit back in 1991, and have revisited in various forms over the years. From experience I can say that coming up with good solutions that allow modeling language evolution and scale well is not something that can be achieved overnight. But it is eminently possible: our customers have modeling languages that have been used and constantly evolved over ten years with hundreds of users.