|
Weighing-in on the DSL versus standardized language debate
May 10, 2007
URL:http://www.drdobbs.com/architecture-and-design/domain-specific-languages-versus-generic/199500627
DDJ: We are joined today by Steven Kelly, CTO of MetaCase, cofounder of the domain-specific modeling forum, and longtime contributor to Dr. Dobb's Journal. Steven, when do you think the benefits of domain-specific languages outweigh the advantages of using universally understood notations?
SK:First off, I don't think there's really such a thing as a universally understood notation. The "U" in UML stands for "Unified," not "Universal," and UML diagrams are certainly not understood by many customers. While most IT developers will recognize the core diagram types, they don't necessarily have the exact same understanding of them. And of course, there are plenty of procedural Perl or embedded C programmers for whom an object-oriented modeling language has never been relevant enough to learn.
Still, UML is great as a way for OO programmers to talk about code. It can be used whatever the problem domain: Whether you're building space shuttles, database applications, or games. The interesting thing is that discussions don't often make use of that lingua franca property -- the game developers talk to other game developers, and to customers for the games. For that purpose, they already have a shared language, which is the vocabulary and terms of the problem domain.
A domain-specific language crystallizes that shared vocabulary, along with the rules of what information must be recorded about each element, and how the elements can be connected. This gives developers and customers a precise, high-level, shared language for discussing, thinking about, and designing applications. The tight fit with the problem domain, high level of abstraction, precision, and ability to use with customers are clear areas where DSLs excel over generic languages like UML.
An experienced developer in that domain can build a working application directly from these high-level specifications. More importantly, it's normally possible for an expert developer to specify how an application should be built from such specifications in general. In other words, the expert developer can specify what each element and structure in the modeling language maps to in the programming language and frameworks in use. Rather than write an in-house style guide in Word, the expert can specify these mappings as a code generator. Now, any model built with the modeling language can be turned into code automatically. Unlike previous code generators, provided by external tool vendors with no idea of your problem domain or code, this one is written by your own expert developer to produce the kind of code he would write by hand.
DDJ: And this naturally has an impact on productivity?
SK: Industrial cases of domain-specific modeling languages and generators consistently show productivity increasing by a factor of between 5 and 10. The question then is: "How much effort is it to build your own modeling language and generator, and how many times will you use it?" If you are working in the same problem domain on a regular basis, the payback is all but certain: Researchers and practitioners like Lucent's David Weiss generally find the break-even point is at around three applications or features in the same domain. Note the mention of "features" there. Even if you are only building one product, that product may contain many parts that can all be expressed with the same modeling language.
DDJ: Are the two approaches in competition or can they coexist?
SK: Domain-Specific Languages have been around a lot longer than UML -- just look at things like LabView and SQL. People have been creating their own in-house textual DSLs since the dawn of the computer industry, and I can't see that stopping. In any given domain, a good Domain-Specific Language will always beat a generic language: horses for courses.
Creating in-house graphical modeling languages is something rather newer. There is a lot more work involved in supporting graphical modeling compared to textual editing. Building your own graphical modeling tool has only been realistically possible since the 1990s, when the first metaCASE tools were released. Tools like our own MetaEdit+, and the recently released Microsoft DSL Tools and Eclipse EMF/GMF, automate all or most of the graphical modeling support.
Even with the best domain-specific modeling language and tool, however, there will always be things that lie outside its domain. For those areas, we will still need traditional programming and generic modeling languages. Similarly, for areas where a particular application is a one-off from the point of view of a given company -- unless there is an off-the-shelf tool that supports it, most likely, it will be built with traditional techniques.
DDJ: Where do you see the "conflict" heading in the future?
SK:The situation is rather like the move from assembly language to third generation languages: Nowadays, most people never have to touch an assembler and can do all their work at a higher level of abstraction. To make that possible, there must still be people building the lower levels, and certain parts of a project may need to drop down to a lower level for a critical optimization or hardware interface.
The key factor pushing people towards domain-specific solutions is the increase in productivity, with quality and communication with customers also important concerns. As most of the productivity increase comes from the code generation, and a generic or "universal" modeling language cannot offer that, we will see an increasing move to domain-specific solutions. Hopefully, most of the move will be made by lead developers seeing this is the right way to go, rather than managers pouncing on the latest buzzword. And conversely, let's hope that those developers who decide to wait have equally good reasons, not just "bah, humbug!"
An interesting question is how much we will see modeling languages for broad domains such as "any web application," and how much for in-house domains. The greatest productivity increases come from the latter, because the language can be made to precisely fit the needs of just one company. More importantly, the company is in control of the language and generators, so they can evolve as the problem domain evolves. In today's fast-changing world, that may prove to be the decisive factor.
Editor's Note: For more information on domain-specific
languages, refer to the
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.