Language Workbenches

Is This the Era of the DSL?

by Michael Swaine

Under names like Language-Oriented Programming, Language Workbenches, and Intentional Programming, a new paradigm of software development is gaining in importance.

Even if you do most of your coding in Ruby, I’ll bet you don’t call yourself a Ruby programmer. Ditto for Java, C# or C++ or Objective-C, assembler or Erlang or Clojure. You’re way too savvy to characterize yourself in terms of one programming language. Your current language of choice doesn’t define you personally or professionally.

But it does make some sense to identify eras of programming in terms of a dominant language. There was a time when you couldn’t pass yourself off as a professional software developer unless you were proficient in C; while back in the dawn of time when I enrolled in my first programming class, it was taken for granted that programming meant Fortran. I’m not suggesting there aren’t scores of other languages in use in any era, and plenty of people who program exclusively in these non-dominant languages. But it still means something to characterize the period, say, from 1973 (Unix kernel rewritten in C; now there’s a killer “app”) to the rise of object-oriented languages in the mid-80s as the C Era.

So if every era can be characterized by a dominant programming language, what era would you say that we are in today? It’s a tough question, isn’t it, because there seems to be more freedom to choose your language to fit the task today than at any other time in the history of programming. In fact it’s been said that we’re in a “post-modern era of language diversity.” Sounds good to me.

But I’d like to push it a step further and suggest that the blade of the plow of progress today is not even in the field of general-purpose programming languages at all. I’d argue that this is the era of the DSL.

Domain-speci?c languages (DSLs) are, as the name suggests, specific to a particular problem domain. A DSL’s syntax reflects the natural language of experts in the domain. As Venkat Subramaniam says in Programming Groovy, “You don’t use them for general-purpose programming like you use Java, Groovy, or C++, because DSLs have a very limited scope and capability.” A DSL can be internal, meaning that it is mapped onto the syntax of a general-purpose language, or external, in which case it stands alone. Creating an external DSL takes more work, but provides more control. And as Terence Parr demonstrates in Language Implementation Patterns and The Definitive ANTLR Reference: Building Domain-Specific Languages, it’s not that hard to create external DSLs.

But you knew all that. You would have to know about DSLs, because they’re ubiquitous. Ant and make are examples of external DSLs, gant and rake are internal DSLs. As Paolo Perrotta points out in Metaprogramming Ruby, the Unix shell is really a DSL for gluing command-line utilities together. Rails is a DSL.

But why claim that this is the Era of the DSL? After all, domain-specific languages are nothing new. The whole tradition of Little Languages in Unix is just another take on the idea of DSLs. NASA was using DSLs as far back as the early days of the Apollo program in the 60s.

What’s new today is a shift in the center of gravity of software development toward DSL-based programming. It started to be noticed four or five years ago and there have been indications just this year that it is ready to come into its own.

Five years ago, Sergey Dmitriev of JetBrains articulated a model of DSL-centric programming called Language-Oriented Programming (LOP). Rather than:

Analyze the problem and model a solution

Choose a general-purpose language

Code the solution in the GPL

the LOP model calls for you to:

Analyze the problem and model a solution

Choose a domain-specific language or write one

Code the solution in a syntax closer to the domain using the DSL

JetBrains has been following up on this model and developing tools to make it practical, while other companies have been exploring similar models, including Charles Simonyi’s Intentional Software. An umbrella term for these approaches, used by Martin Fowler, is Language Workbenches.

Four years ago, Fowler spelled out the shortcomings of DSLs and identified what was needed to overcome the drawbacks to DSL programming. He described an approach to programming that puts DSLs in the center of the process and provides the kinds of tools you expect to have in a real development environment. He pointed out examples where people were exploring this approach, including the JetBrains and Intensive folks. And he captured all these approaches under the umbrella term Language Workbenches, a term that suggests that the tools needed for DSL-centric programming are all hanging on the wall above the workbench.

Intentional Software, is working on a system that completely implements all of Fowler’s requirements for a Language Workbench. Simonyi says that it’s crucial to separate the problem from the program, and his company plans to empower a domain expert to encode the problem using a DSL.

Now things are heating up. Fowler is giving lectures and writing a book on Language Workbenches. In May at the DSL Developer’s Conference, Intentional Software took the wraps off its secretive DSL-centric Intentional Domain Workbench. And in July JetBrains announced the 1.0 release of its Meta Programming System, or MPS, for DSL-centric programming. Attendees at the Intentional demo were effusive, comparing it to the legendary 1968 “Mother of all Demos” at which Doug Engelbart previewed pretty much everything. Whether you call it Language-Oriented Programming or Language Workbenches or something else, DSL-centric programming seems to be experiencing some heat right now.

Four years ago Martin Fowler wrote, “[W]e probably have little idea what DSLs will look like once we’ve had experience with language workbenches.... If language workbenches live up to their hopes, in ten years time we’ll look back and laugh at what we now think DSLs should look like.” OK, we’re almost halfway to ten years. Are we starting to crack a smile?