Overview

Over the last years I’ve built a dozen or so large scale Domain Specific Languages (DSL) and almost without exceptions, they’ve been hard sells. Usually, each of these received initial resistance in the organizations they’ve been introduced. This despite their convincing potential and their eventual success.

Here are some examples of these successes:

• Project for Company X. Created a set of DSL’s for various aspects of their development. Two main effects:
• Average time to develop an application went from 4 man-years to 3 man-weeks (factor of 70 improvement)
• Project for State Agency Y. Create a DSL to handle a complex connection between implementation layers
• Average time to develop a connection went from ~one week to 10 minutes (factor of 240 improvement)
• Project for Company Z. Created a DSL to generate variations of application that track various initiatives (metrics not in yet, but we expect a similar improvement in development effort as in the other projects on this page)

In this blog post I’ll focus on the kind of resistance one may expect and why.

Building our own language, You’re kidding right?

The most common objection is to the presumed effort required to create a DSL. Few have experience writing a language and those that do typically wrote languages some time ago.

Fact is, if we suggested that one build a language to solve their problem a decade ago, it would have been a very ambitious project. We would have looked at a massive project taking months if not years to complete.

With today’s tools though, writing a DSL is what I usually categorize as a “weekend project”. Although there have been languages that have taken me months to complete, the typical effort is in days (or worst case weeks).

The latest tools in the open source and also in the commercial world are very different from the ones available say a decade ago. Here is a typical estimate for a language…

• Design of the language (the abstract syntax) – Typically 1-3 days
• Implementation of the concrete syntax – Typically 1 day
• Including editors with syntax highlighting, auto completion, …
• Transformers – 1 day to weeks…
• This is often the tedious part where you generate code or other artifacts from the abstract syntax

OK… the times above are not true for everyone. It requires that you have intimate knowledge of the language generation tools, but achievable I believe for any reasonably skilled engineer.

My way around the concern of effort is BUILD THE TOOL FIRST, THEN SUGGEST IT.  Because the effort is rather moderate, I can usually build a first cut of a tool over a long weekend or while flying around (no kidding, I do my best work on airplanes :)). The realization that a language can be created over such a short time and already be useful typically removes the concern of complexity.

The approach you suggest sounds a lot like a 4gl. We tried that before and it was a disaster

A 4GL and a DSL are different things. A 4GL was a general purpose language at some high level of abstraction (I have nothing against that by the way). A DSL is a special purpose language preferably at the HIGHEST level of abstraction possible. Believe me, they are different.

Again the remedy is education, but the association between experiences on 4GL’s and expectations of a DSL is real and something you must prepare for.

That is going to be a disaster for recruiting… Who would want to work on that?

Ouch… so true… and so hard to argue against… I’ve tried a myriad of ways to work around this. Let me give you a few examples.

The Parallel Approach

The parallel approach means that we create a DSL that generate code, but also allow for the developers to do the same by hand.

This has the following effect:

• We are still using the general purpose language… It is just that you can use this tool to makes you more productive.
• Eventually, the DSL becomes the dominant or the only approach

The Hook Approach

Leave something to be done in the general purpose language. Don’t hide it all. This usually make a lot of sense anyway. There is often some part of the the problem that may be best solved by a general purpose language. Typically, this is some procedural part of the problem. As long as SOME PART is written in the ‘recruiting language’ the solution may be a lot more palpable.

I’m hoping that some of these objections will disappear with time, but right now they are real and I have to admit that I’ve modified DSL’s ensure that programmers get to program in the general purpose language, EVEN THOUGH I KNOW HOW TO GENERATE THAT CODE TOO and it would have been more productive.

We make money by the hour… Why?

I’m sure some of you think I’m kidding, but believe me! This is a common response from some development domains  (typically government or contractors for government projects). This is the one argument that will usually make me give up head for the door. Personally, I don’t understand how organizations can live by those goals and openly talk about them.

Government! Change your metrics!!!

Summary

When you suggest the use of DSL'’s in software organizations, expect resistance. Very often this resistance is based on unjustifiable concerns and often the way around it is build it first… This eliminates the fear of the complexity of building a language, it also gives the stakeholders a chance to see what it would look like.

My favorite tool to show off the ideas are slightly different based on what kind of concrete syntax I want. If I want a graphical syntax, I prefer to use the Microsoft DSL tool (although, the graphical modeling framework of Eclipse (GMF) also works well). If I’m creating a textual syntax, my favorite tool right now is XText (Eclipse based tool).