Martin Fowler unveils details of his upcoming DSL book

Posted by Sadek Drobi on Nov 21, 2007 10:24 PM

Community

Architecture

Topics

Domain Specific Languages,

Design

Tags

Book,

Language Oriented Programming,

Design Patterns

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.

1. Back to top

   QCon SF

   Nov 22, 2007 6:41 AM by Geoffrey Wiseman

   These were most recently presented at the QCon SF 'Domain-Specific Languages' tutorial, AFAIK.

   Reply

2. Back to top

   Re: QCon SF

   Nov 22, 2007 6:48 AM by Sadek Drobi

   Unfortunaitly, Although I wanted so much to attends this tutorial but I couldn't :( That was because I had a flight connection problem at chacago + security checks in airports! Waiting for someone to cover ideas from there in his blog...

   Reply

3. Back to top

   Re: QCon SF

   Nov 27, 2007 10:19 PM by Scott Pfister

   I had the fortunate opportunity to hear the tutorial by Neal Ford in Chicago at NFJS, and it was among the best I heard that weekend. As I don't have a blog, I suppose I can just do a quick brain dump here... The key points I took away were a) what makes something a DSL, and b) how to utilize the concept directly in Java interfaces or Ruby without having to actually invent a new language and tools to go with it. The power of a DSL dawned on me when he used waffle house hash brown language as an example: scattered, smothered, covered, chunked, topped, diced, peppered, & capped. The people who were familiar with that "Domain" immediately knew what it was before he revealed it -- because it's so specific and focused. And the volume of detail conveyed in so few terms makes the general strength of DSLs quite clear. Regarding how it can be utilized in Java interfaces, the train boxcar example made the case fairly succinctly. Compare traditional usage to what he calls 'Car fluent':

   Car car = new CarImpl();
   MarketingDescription desc = new MarketingDescriptionImpl();
   desc.setType("Box");
   desc.setAttribute("length", 50);
   ...
   car.setDescription(desc);
   

   Car car = 
   Car.describedAs().
       box().
       length(50).
       includes(Equipment.LADDER).
       has(Lining.CORK);
   

   The simple trick is to have "setters" that return 'this' (or whatever is relevant). It's no panacea -- there are obvious drawbacks and tradeoffs being made such as more frequent interface changes and what he called 'the finishing problem' (having incompletely initialized objects after the return of the constructor but before the necessary setters have been called). But for the right context and audience it can be a very powerful concept. Lots more in the talk including examples in Groovy, Ruby, some new DSL terms to be coined in Fowler's book ('method chaining', 'expression builder', others). If you're interested, he has posted the handouts to this talk on his site. I, for one, am looking forward to Fowler's DSL book and expect to see more and more usage patterns of DSLs in the coming years.

   Reply

• Older >