Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Book on Leveraging Domain-Specific Languages by Martin Fowler with Rebecca Parsons

Book on Leveraging Domain-Specific Languages by Martin Fowler with Rebecca Parsons

In their new book  Martin Fowler and Rebecca  J. Parsons address the topic of Domain-Specific Languages. DSLs promise many benefits for software engineering such as increasing the abstraction level, improving communication between different stakeholders, and improving productivity. According to the authors a Domain Specific Language (DSL) can be defined as follows:

"A computing programming language of limited expressiveness focused on a particular domain."

The example for a concrete DSL provided in the book is called Miss Grant’s Controller. It defines a language for opening secret compartments in buildings by performing actions like opening a drawer or closing a door. By using a DSL, engineers can easily reconfigure the system instead of identifying and changing multiple locations which is the case when the configuration is written in a general-purpose language.

The book introduces the category of external DSLs which are different from the main programming languages used, and internal DSLs that are hosted by the underlying programming language like Ruby on Rails. The third category, Language Workbenches, represent custom environments for editing and creating DSLs. No matter what category developers are using, it is essential to build any DSL on top of a sound semantic model as the authors keep emphasizing.

“Domain-Specific Languages” does not only address the concepts behind DSLs, but also tries to explain the subject in a pragmatic manner using examples in Java, C# and other languages.The book contains different patterns that reveal best practices in designing DSLs.

InfoQ could interview Martin (MF) and Rebecca (RJP) to get the motivation and rationale for writing a book on this emerging topic:

InfoQ: What is the main message you like your readers to grasp?

RJP:  There is a lack of understanding of DSLs, their uses, and the tools and techniques needed to implement them. This book attempts to allay the fears people have around creating languages, with the hope that we’ll start to see some interesting and effective new uses of DSLs.

MF: In my travels I saw quite a few DSLs built in projects, but I think they missed some good ideas because it was too hard to find information about the various techniques you can use to build a DSL. My hope for this book is that it collects together these techniques and thus makes it easier for people to explore DSLs. This way we'll have a better chance of seeing what their true potential is.

InfoQ: Where is the boundary between MDSD (Model-Driven Software Development) and DSLs?

MF: This is a difficult question to tackle. I've not kept a close eye on the MDSD community, but it seems to have some quite distinct strains within it. There are those who are focused on a well defined semantic model that's used to drive computation. For this group, there's a good synergy with DSLs because DSLs are a good way of expressing models that describe alternative computational models (which I refer to as Adaptive Models in the book).

But there's the other strain of MDSD, those who think diagrams should be worth a thousand lines of code. This is the CASE heritage which correlates with the OMG's MDA. Their embrace of DSLs seems to be a dying movement grasping at straws to retain some fragments of respectability.

InfoQ: What are the benefits of using DSLs and when would you prefer internal or rather leverage external DSLs?

MF: Whenever we talk about the pros and cons of DSL usage, I always stress that a DSL is nothing more than a thin veneer over a library or framework (which we refer to as a Semantic Model). The decision about whether to build a DSL is about whether the advantages of expressing the behavior in a DSL rather than the usual command-query API make it worthwhile.

RJP: Using a language supporting the proper abstractions for the problem at hand is crucial to effective software development. Tailoring a language to the business problem also provides a mechanism for the business to understand what’s being developed.DSLs provide the option to tailor the language itself to the problem at hand, facilitating communication between the business and the development team.

As for the internal versus external language decision, each has its advantages. From the language design perspective, an external DSL provides the greatest flexibility, since internal DSLs must respect the parsing and language semantics of the host language.

MF: This flexibility can be particularly useful when working with non-programmers.

RJP: But this design flexibility comes at the cost of additional build and development complexity.  External DSLs require the addition of tools to the development environment. Additionally, processing a DSL requires additional steps in the build to build the parser.

MF: Many developers aren't very familiar with the parsing techniques you need for external DSLs, or they were exposed to them in college in the context of general-purpose languages, which are much more complicated to work with.

RJP: Another consideration is an editor for scripts written in the DSL. An internal DSL allows the use of an IDE for the host language; such editors don’t exist for an external DSL, necessitating potentially the need to create one. Since DSL scripts are frequently short, this is less of an issue. However, certain applications, such as pension rules, are actually quite lengthy.

InfoQ: What should a programming language provide in terms of features and properties to allow easy integration of internal DSLs?

RJP: Clearly there has to be some way to augment the syntax of the language with some form of new semantics. This feature can take many forms. Lisp languages have a very flexible syntax and also utilize macro-processing facilities. Ruby has a missing method handler.

MF: Closures (aka anonymous functions or lambdas) strike me as particularly important since they allow you to control the evaluation order of nested expressions, as well as naturally express a hierarchic structure.

RJP: The cleaner the syntax of the language is the cleaner the resulting DSL is. Syntax elements such as “{}” in Java clutter DSLs implemented internally in Java, for example.

InfoQ: I guess DSLs can address the problem domain but also the solution domain. Are they also appropriate for dealing with crosscutting concerns? Is AspectJ also a kind of DSL?

MF: I think AOP is an unconnected concept, other than in the generic sense that describing aspects with a DSL may be more readable than a framework's command-query interface.

InfoQ: Who (from your point of view) has the responsibility to participate in establishing a DSL within a project context – architects, developers, requirements engineers? How would the process of establishing a DSL systematically look like?

RJP: This depends a great deal on the target user set of the DSL. Some DSLs are business facing while others are more technically focused. For business focused DSLs, the business analyst would drive the language design, working in conjunction with the technical team.

MF:  I don't think we have enough experience yet at DSLs being developed in a more widespread way.

InfoQ: Probably most DSLs will not be created in a big bang approach, but evolve over time? If yes: What are the implications of DSL evolution on software engineers in terms of their responsibilities and activities? How can we (quality- test) DSLs?

RJP: Considering testing, there are a variety of moving parts to test with a DSL, depending on how its implemented. First, the “grammar” needs to be tested to make sure it actually recognizes the desired legal sentences. There is little need to test that the parser works correctly, but it does make sense to test that the “semantics” for a given parsed sentence correspond to expectations. If you use the Semantic Model approach the book advocates, this semantics testing simply ensures that the model is populated in the right way, as traditional unit testing of the code for the framework tests the actual behaviors.

Evolving the language works in much the same way as evolving code, with the exception of once the DSL is in production use, migration of existing scripts might have to be addressed.

MF: DSL scripts are very much like the consumers of any other published interface, so the same issues crop up in migrating them as we have with any other API. I certainly expect that an evolutionary design is the best way to work with DSLs.

On the whole, however, I don't see a big shift in project roles here. DSLs are more of a tool to help a deeper and more precise conversation between different roles.

InfoQ: How can you adapt DSLs to cope with variability in a domain, for instance when developing a product line?

MF: Like so many things, I don't think there's much of a difference between these and any other kind of code. DSLs dive into peoples' minds here because DSLs are a natural way to express variations, in comparison to a command-query API.

InfoQ: As DSLs seem to address a subdomain of a system such as configuration, how would a project team balance the tradeoff between ending up in a lot of small DSLs as compared to creating a large and complex DSL that covers multiple areas?

RJP: DSLs are to aid understanding.  While a proliferation of lots and lots of DSLs might inhibit understanding, if those DSLs accurately represent the problem domain, the various DSLs should be no harder to keep track of then the various problem domains. Simplicity of the language is the goal. Better to deal with multiple small languages than one large hairy one.

MF: Our exhortation is very much to have multiple small DSLs. You don't want to extend regular expressions to style HTML, nor CSS to match text patterns. For us, the thing that makes DSLs different is their limited expressiveness.

InfoQ: In your book you’ve included a chapter on Language Workbenches where you mentioned that most of the IDEs are still immature. What could a Language Workbench look like that you would use instead of ANTLR or compiler-generators? What’s your take on tools such as MPS (Meta Programming System)?

MF: We've been monitoring the Language Workbench space. A couple of colleagues have been working with Intentional over the last few years. Tools like this have great promise, but they are both a shift for developers and in their early days. The advantage of simpler tools is that they are resting on much more established technologies. But this is a situation that could change quite rapidly as Language Workbenches mature.

InfoQ: What are the reasons that some organizations and projects do not leverage DSLs? Complexity, lack of understanding the problem and solution domain?

RJP: In addition to the issues of new tools and processes, using DSLs requires a different way of thinking about the problem. There’s still a lot to be discovered about what constitutes a good language design for DSLs. Here’s also the “we’ve heard this for so long” about business readable/writeable programs which likely produces some skepticism.

InfoQ: On the front cover of the book there is this nice, little bridge. Why did you choose this picture for your DSL book?

MF: When I started my signature series, I decided that the cover theme would be bridges since my wife was a bridge engineer. This particular bridge is of great historic importance, as it is the world's first bridge made of iron. It's also not that far from where I grew up, so I had long ago pencilled it in for my next book.

Rate this Article