Rockford Lhotka

 Friday, January 23, 2009
« Windows Home Server rocks! | Main | Interesting Silverlight data binding &ld... »

For some years now there’s been this background hum about “domain specific languages” or DSLs. Whether portrayed as graphical cartoon-to-code, or specialized textual constructs, DSLs are programming languages designed to abstract the concepts around a specific problem domain.

A couple weeks ago I delivered the “Lap around Oslo” talk for the MDC in Minneapolis. That was fun, because I got to demonstrate MSchema (a DSL for creating SQL tables and inserting data), and show how it can be used as a building-block to create a programming language that looks like this:

“Moving Pictures” by “Rush” is awesome!

It is hard to believe that this sentence is constructed using a programming language, but that’s the power of a DSL. That’s just fun!

I also got to demonstrate MService, a DSL for creating WCF services implemented using Windows Workflow (WF). The entire thing is textual, even the workflow definition. There’s no XML, no C#-class-as-a-service, nothing awkward at all. The entire thing is constructed using terms you’d use when speaking aloud about building a service.

A couple years ago I had a discussion with some guys in Microsoft’s connected systems division. My contention in that conversation was that a language truly centered around services/SOA would have a first-class construct for a service. That C# or VB are poor languages for this, because we have to use a class and fake the service construct through inheritance or interfaces.

This MService DSL is exactly the kind of thing I was talking about, and in this regard DSLs are very cool!

So they are fun. They are cool. So why might DSLs be a bad idea?

If you’ve been in the industry long enough, you may have encountered companies who built their enterprise systems on in-house languages. Often a variation on Basic, C or some other common language. Some hot-shot developer decided none of the existing languages at the time could quite fit the bill. Or some adventurous business person didn’t want the vendor lock-in that came with using VendorX’s compiler. So these companies built their own languages (usually interpreted, sometimes compiled). And they built entire enterprise systems on this one-off language.

As a consultant through the 1990’s, I encountered a number of these companies. You might think this was rare, but it was not all that rare – surprising but true. They were all in a bad spot, having a lot of software built on a language and tools that were known by absolutely no one outside that company. To hire a programmer, they had to con someone into learning a set of totally dead-end skills. And if a programmer left, the company not only lost domain knowledge, but a very large percentage of the global population of programmers who knew their technology.

How does this relate to DSLs?

Imagine you work at a bio-medical manufacturing company. Suppose some hot-shot developer falls in love with Microsoft’s M language and creates this really awesome programming language for bio-medical manufacturing software development. A language that abstracts concepts, and allows developers to write a line of this DSL instead of a page of C#. Suppose the company loves this DSL, and it spreads through all the enterprise systems.

Then fast-forward maybe 5 years. Now this company has major enterprise systems written in a language known only by the people who work there. To hire a programmer, they need to con someone into learning a set of totally dead-end skills. And if a programmer leaves, the company has not only lost domain knowledge, but also one of the few people in the world who know this DSL.

To me, this is the dark side of the DSL movement.

It is one thing for a vendor like Microsoft to use M to create a limited set of globally standard DSLs for things like creating services, configuring servers or other broad tasks. It is a whole different issue for individual companies to invent their own one-off languages.

Sure, DSLs can provide amazing levels of abstraction, and thus productivity. But that doesn’t come for free. I suspect this will become a major issue over the next decade, as tools like Oslo and related DSL concepts work their way into the mainstream.