Martin Fowler unveiled some details about his upcoming book on DSLs and posted on his Work In Progress gateway the first draft of its introductory part. Most probably, the book will have a “duplex” structure with a section of narratives and a reference section in which a certain number of DSL related topics are likely to be presented in form of patterns.
The draft introduction offers some elements of context about DSL. Building on his previous articles and further developing ideas he presented at Jaoo 2006 and, more recently, at a TSS’ Barcelona event, Fowler gives an example of a Domain Specific Language case and provides some new insights on DSLs, their implementation and use.
Defining what a DSL is, Fowler argues that characteristics that are usually used, i.e. domain focus, limited expresiveness and “language nature”, are rather blurry. Hence, the only way to determine the boundary of DSL is to consider “a particular usage of a language” and “the intent of either the designers or users of this language”:
If the designers of XSLT designed it to be about XML transformations then I'd argue it's a DSL. If a [user] uses a DSL for its purpose then it stays a DSL, but if someone uses a DSL in a general purpose manner, then it's no longer a DSL (in this usage).
In Fowler’s view, DSLs are first of all a tool that helps to abstrac some part of a system. Hence it is useful “when you realize you need a component, or when you already have a component and you want to simplify how you are manipulating it.” The use of DSLs offers indeed a certain number of benefits. Not only do they improve code readability and enable a better communication with domain experts, but they are also instrumental for changing execution context, e.g. shifting logic from compile time to runtime, and using an alternative declarative computational model when imperative programming is not the best choice.
In the example Fowler uses, the DSL is implemented on the top of predetermined API for a framework. He stresses however that it is also possible to start from the DSL design. In this case, one would first define “a set of example controller behaviors” written in some DSL form. To proceed with implementation it is necessary to build both the framework with API and the concrete syntax of the DSL. Three approaches are possible:
Some might like to do little bits at a time across all these elements: building a little bit of component function, the DSL to drive it, and hooking that thread all up with tests. Others might prefer to build and test the framework first and then layer the DSL over it. Yet others might like to get the DSL in place and then build the library and fit them together.
Fowler also provides some insights into possible DSL outputs. The most obviouse one is a running program that can be produced either through interpretation – immediat execution of the program – or through code generation. To avoid an additional compilation layer in this latter case, one can use dynamic languages like Javascript. When it comes to interpretation two approaches are possible: “one-step interpretation where each statement in the DSL is parsed and interpreted immediately” or a “two-Step Interpretation parses the entire input DSL, translates it into an abstract representation and then executes the abstract representation”. Fowler higlights the fact that internal DSL are often interpreted whereas “tutorials on external DLSs […] tend to assume you use code generation” even though his choice would be to use interpretation as well.
DSLs however can also be used for producing a visualization representation which is a read-only projection representing the domain. This can allow additional options that would be “too hard in an editable form” like creating a diagram. This visualization is actually easy to add once “the hard work of creating a component framework” is done.
Last but not least, Fowler outlines a certain number of problems related to DSL use. Along with common critics – cost of building, risk of language cacophony, difficult design – Fowler mentions the issue of migration. He believes that it is rather similar to the migration of an API. What makes the difference however is the lack of tooling, e.g. for refactoring, especially for external DSLs. Here, some techniques may help, for instance, Migration Execution which he defines as a technique that makes it “relatively easy to get the abstract representation to generate source code for itself, incorporating any changes you might wish to make”.
Another issue raised by Fowler is the constant need to beware not letting things get too complex and evolve into generality. He advocated for introducing “other languages for particular and difficult cases” and layering them over the base DSL. Fowler believes however that problems related to the use of DSL are often overstated, “usually because people aren't familiar enough with how to build DSLs and how they fit the broader software development picture.”
To get deeper insights into these issues and many more, you can follow Fowler’s Work in Progress on the book.