A colleague of mine pointed me at the presentation slides of Microsoft Architecture Days held during my holiday. Of particular interest for me was the presentation on Domain Specific Languages (DSL). The slides are in English, but the presentation itself (available as a video clip) is in Finnish. Although I had heard of DSL before, this was my first real introduction to the theme - and a good one!
In case you don't know what DSM (Domain Specific Modeling) is, here's a very short recap: It's all about about crafting a modeling tool (usually a visual one) for your specific need. It's different from UML-based modeling tools in several aspects. First, DSLs discuss the problem, not the solution. Instead of modeling with code concepts such as "This is a class", you model with domain terminology along the lines of "This is a login dialog". You then need a custom implementation - a code generator turning your model into a target language such as C# - for your modeling objects.
Second, the DSL has the semantics and behavior of your domain; if you're building a banking application, you use the terminology from the banking world. No, not just that; you use terminology from your banking application. This is different from most CASE constructs where the modeling language attempted to be universal, naturally killing much of the customizability. In the DSL world, you control every aspect of it. There won't be a 3rd party vendor stating that your dialog components must look like this, and the generation process can produce any artifacts you desire, ranging from compilable source to resource XML files and whatever.
Third, successful DSL cases have a common characteristic: All code is generated from the DSM, and there is no need for roundtripping (reverse engineering your code-level changes back into the model). You don't customize the end-language result - just as you don't hex edit the exe files produced by your compiler. You customize the generator to produce the right results.
Thus, domain specificity allows both a higher level of abstraction and more customizability. The drawback is, of course, that you need to tailor a language and a code generator for your purpose, and this is often a non-trivial task. It's not a particularly new issue though; for example NetHack has had a map-generation language implemented with lex/yacc for a long time. Most of us wouldn't touch those monsters though, so it's all about tools. Luckily, there's going to be DSL support in Visual Studio Team System - one more reason to wait for Whidbey. There are plenty of modeling tools for other platforms, so it's not a .NET thing.
The need for higher abstraction - describing problems instead of struggling with code concepts - is everywhere. Right now, we're resolving much of the issues by trying to build sophisticated class frameworks to support the development needs. It's an important path to take, but it certainly falls short. One of the problems is that as long as we work on the code level, we cannot avoid some of the necessary evils: even the best classes need instantiation, using directives, method calls, event handlers and whatnot. Another one is that even with a great framework, a lot of code is still needed for a complex application. Unless extreme discipline for code management is used, an application with a lot of code is rarely very readable. Also, domain-level problems ("Calculate the shipping costs for X") tend to vanish in the depths of code (lines and lines filled with logic such as "ShippingCostManager.GetWeatherVariables(x, WeatherController.CurrentWeather)").
Be it web page design, Bugzilla development, business reporting applications or whatever, this need for higher level modelling exists for most situations. DSM won't solve all the problems, and crafting your own language won't probably be the right way for simple one-shot applications. But for complex product families and software with long lifecycles, DSM has been reported to give 3-10 times increase in productivity. It's certainly a promise worth more investigation - the companies behind that sort of assertions were Nokia and Lucent, among others (see the presentation slides for more details).
For the working environment, DSLs could change quite a few things. It takes the expert programmers and architects to build the language, but thereafter much of the development is doable even with lesser technical skills. Used correctly, this might work as a way to get the client's domain expertise to a much better use. Possibly, it might even allow software companies to empower the visionary people with lesser technical ability. It can dramatically reduce the effort needed to guide new employees into the development; a problem-oriented development approach hides much of the technical details inherent in all complex applications. It could help architects to enforce the patterns they now distribute as documents and presentations; with a DSL, you probably couldn't do the wrong things.
It would be irresponsible to conclude such a positive post without a pessimistic note. There is no silver bullet. But objectively taken, Nethack's map generation language certainly makes much of a difference in creating action-packed special levels for the game. There, the small DSL used is an enormous time saver. If the language generation tools advance well beyond the infamous lex/yacc pair, the initial cost of using DSL could drop drastically. The concept of high abstractions and custom languages make most architects wet their pants in excitement. The need for this technology is evident. As I already said, it's all about tools.
Additional info: DSMForum.org, Microsoft DSL Tools page.
Posted by Jouni Heikniemi at March 12, 2005 08:56 AM