Now that "domain-specific" has become something of a buzzword, people are eager to claim that what they do is domain-specific. For some, just naming a variable or XML tag "person" instead of "x" seems to be enough. For a great take on this from April 1st, see Anders' blog: "A framework for cross platform DSL development".

There's a serious side to it as well: if your DSL or DSM solution locks you in to a certain programming language, IDE, or operating system, that's plain wrong. A Domain-Specific Modeling language should fit tightly with a certain problem domain, but your tools for it should allow you to change the solution domain later, just by building a new generator that operates on the same models. If the tools are tightly coupled to a certain language, IDE, or OS -- or even worse and sadly all too common, to a particular version of a given IDE or OS -- that's hardly giving you the freedom of choice that DSM is meant to bring.

Yes, there is a cost to supporting multiple platforms, and I sometimes have to defend why MetaEdit+ platform support covers all the common cases, but in the long run it pays off. If you focus on just one platform, it's all too easy for the tool to become highly coupled to implementation details in the current OS or IDE version. Not only does that make the tool vendor's life harder when a new version comes out, but for tools that require metamodelers to program, the metamodelers too will find themselves stuck. Their modelers will want the latest version of the IDE for coding in, but the modeling tool will require them to stick with the old version -- or continually pay the cost of this tight coupling at every version upgrade.