To sum up, I don’t know what Microsoft is selling over there but it isn’t what the larger community has come to know as “Domain Specific Languages”. Perhaps a better term would be “Domain Specific Designer”.

Using “Designer” tends to put the focus on the tool; I think the equivalent term for the actually language should be “Domain-Specific Modeling Language”. I’ve also heard people talk about “textual DSLs” (which is fine) vs. “graphical DSLs”, but I’m not a fan of the latter term. In all the real industrial cases I can think of, the graphical format of the DSL does not show all the information contained in the model. To see the fine details of an object, you have to double-click its property dialog open or look at its property sheet. That’s an important advance over textual DSLs, which show all the detail. With a DSM Language the language designer chooses what is important enough to show all the time, and what can be hidden as details. He can also allow the modeler to make that decision for some elements (like most UML tools allow the modeler to show or hide the Attributes and Operations compartments of a UML Class symbol).

There was some discussion earlier about the difference between wizards, earlier code generators and DSM with full code generation. The main difference is whether you have to maintain what is generated, at the level of the generated code. Wizards and old-style code generators generally meant you had to do that: they produced lots of code quickly, but it was unfamiliar to you and you needed to maintain and probably extend it. With DSM, the code generated is the same as the code you wrote by hand before, and you don’t need to read or edit it. (See this blog entry for more detail.)

And of course so as not to be accused of bias towards Microsoft, I ought to point out that they’re not the only people doing this :-). The DSM Forum is the industry organization for all companies involved, and the web pages are a good starting point for information and links to further reading, real world cases and related events. In addition to Microsoft’s pre-release DSL tools there are also others that have a longer history in this area, including ourselves at MetaCase with MetaEdit+, which has been used commercially for over ten years so is a tad more mature (if you’ll excuse the lack of modesty), and the Vanderbilt University GME research tool, which has also been around for years and is great for those who want to work on coding the next generation of such meta-tools.

If you want to play around with this to learn more, I think you’ll easily get furthest in a short time if you start with the MetaEdit+ 31-day evaluation version: in an hour you can build your own first modeling language. If you prefer MS tools, you can try it out for 90 minutes on-line here - installing it can be something of a long process, so that’s a good alternative.

“Using the Microsoft DSL tools you can create your own designer, integrated into Visual Studio, for a visual domain-specific language. The tools help you define the domain-specific language and generate the code of a graphical designer for you. The resulting designer uses the same underlying modeling technology that is used by the Class Designer and Distributed System Designers in Visual Studio 2005.”

In the end, I believe it complies with what a Domain Specific Language is, in its purest form, it’s just that Microsoft has a different way on “how” it achieves the end goal.

Personally, I have been a fan of visualization tools, particularly from an architectural design perspective, because it raises the level of abstraction, much like how architectural blueprints are common practice in the “traditional” building design/construction world, using visualization tools like AutoCAD. This is something we are still struggling with in the software development world – we don’t have a “standard” architectural blueprint that every programmer understands, from a semantic meaning perspective, and can build software that meets the specifications of the blueprint.

This is what I mean by software industrialization – I certainly don’t mean making it a mechanized process, it will never become that way, but at the same time, every physical buildings architecture has been derived from an “architectural blueprint “where everyone involved in the construction process knows how to read it and more importantly, knows what it means. From where I sit, we (still) don’t have anything like that is the software development world. To me DSL’s are one step closer to this inevitable realization.

I am an old Smalltalk guy and I can tell you, this ain’t LISP - again, a DSL is NOT a programming language and that’s the whole point I am trying to make – obviously poorly.

I think the point was made aptly, there’s just some disagreement about your definition. For instance, Fowler describes DSLs as follows:

The basic idea of a domain specific language (DSL) is a computer language that’s targeted to a particular kind of problem, rather than a general purpose language that’s aimed at any kind of software problem. Domain specific languages have been talked about, and used for almost as long as computing has been done.

He then points to Eric Raymond’s Minilanguages and Paul Graham’s Programming Bottom Up, both of which describe using highly extensible languages (like Lisp) to craft new language features that serve a specific problem domain.

For more background, see Domain-Specific Languages: An annotated Bibliography, which cites some 78 historical DSL texts. The definition of “DSL” put forth in that paper is as follows:

A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.

To sum up, I don’t know what Microsoft is selling over there but it isn’t what the larger community has come to know as “Domain Specific Languages”. Perhaps a better term would be “Domain Specific Designer”.

Remember UML and class diagram’s where you could “draw” a class diagram hierarchy and Rational’s tool will build the code framework (ok stubs) for you? Well, a DSL is a much more refined and higher level abstraction that allows you to “design” a specific language to solve a problem domain issue of interest - without hand crafting code. That’s the point of a DSL. Who care’s “how” it is done. All I can tell you is that it would take me 10X longer to handcraft the code, compared to what I “designed” in the DSL to generate the code (more or less what I would have hand crafted in C# anyway) for me. In other words, a DSL is simply a productivity tool that allows me to describe or define or model the solution, using meta data. That’s it. Simply another tool in the toolbox. Nothing more, nothing less.

In my mind, the entire point of a DSL is to be so abstract and high-level that you can write the code by hand but without writing any plumbing and infrastructure.

The canonical example of a language whose mentality is that you should do any task by creating a DSL of this type for the problem at hand and then using that DSL to solve it is Lisp, as Alex Schroeder points out. The main tool towards that end are macros—which are far more powerful in Lisp than in any of the mainstream languages.

(FWIW, such macros are coming to Perl6.)

My job is to solve business problems using IT where the requirements are generally very poor and there is little money or time to solve the business problem at hand. Just part of the reality in my little business world I live in from a Systems Integrator perspective. So to combat that, I try and find anything (beg, borrow or steal) that assists me in meeting unrealistic requirements and schedules. This means a lot of incremental and iterative development to close the aforementioned gaps.

I look at DSL’s as just another tool in the toolbox to help me solve the business problem at hand. As Alex has pointed out, my job is to design a solution to solve a business problem without having to write the same (or similar) plumbing or infrastructure code every time So spending more time in the problem domain helps me do this. Using DSL’s along with writing code, using 3rd party components and any other piece of design and/or code that I can reuse helps me solve the business problem.

Don’t get me wrong. I live to code. But business constraints of the real world force me to do (some) unnatural acts. The application integration DSL I put together, albeit small, greatly assists me in meeting those business constraints, hence the reason why I use it – in addition to traditional coding (interface development), etc. But when I can make a domain model/designer change in my DSL and have a solution delivered to my paying clients in fraction of the time it takes to traditionally code everything by hand, my clients really appreciate that and keep me employed. I am just being pragmatic about the whole thing.

I also believe that, as in everything software, everyone has a different meaning and motivation to use the languages and tools we use. Hopefully, with this little explanation some of that has come to light.

A colleague of mine suggested reading Thinking Forth as a way of learning about DSL’s.

My (few) links about DSL’s are here.