Friday, January 23, 2009
« Windows Home Server rocks! | Main | Interesting Silverlight data binding &ld... »
DSLs – fun, cool, but maybe a bad idea?

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.

Programming
Friday, January 23, 2009 5:30:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [9]  |  Related posts:
Why MVVM?
WinRT and .NET
HTML5 “standard”?
TFS extensibility
Minneapolis PDC, Code Mastery and more!
Talking Business and Objectification with Rocky Lhotka
Friday, January 23, 2009 6:31:52 PM (Central Standard Time, UTC-06:00)
But there is a huge difference between a DSL and a general purpose programming language. If you hire a new programmer you will have to teach them the domain of your application regardless of the fact that your app uses an API for a general purpose programming language or a custom DSL. In fact I would argue that learning a domain with a custom language would probably be more intuitive than learning an entire API for a general purpose programming language. I think that is exactly the power of a DSL. It cuts away the cross cutting concerns and allows you to focus on the domain, which will need to be translated to the new developer regardless.

And under the hood the DSL will be transformed into code more recognizable as a general purpose programming languge (or with it). In fact it might even be possible that the developer really doesn't even care what the DSL is, it might be that they simply maintain the transformation code while business analysts are the ones learning the actual DSL.

It just seems like there is a very large distinction between a DSL and a general purpose programming language.
Justin Chase
Saturday, January 24, 2009 1:54:57 AM (Central Standard Time, UTC-06:00)
It's an interesting point of view, and I'd definitely like to know what Martin Fowler thinks of this argument.

My thoughts are that DSLs allow for a higher level of abstraction just like OOP. The fact is a new developer will still need to learn the domain whether they do it by staring at C# code or at a custom human-readable DSL. The real challenge will be in writing the DSL so that it is fully extensible and adaptable to future business endeavors. I suspect (and I may be wrong) that developers won't be writing in DSLs anyway. They will be writing the DSLs themselves!
Jonathan Parker
Saturday, January 24, 2009 7:43:53 AM (Central Standard Time, UTC-06:00)
If a DSL increases the learning curve of a domain, what you have, really, is merely a shoddy DSL. That said, I am pretty sure that just as we have had shoddy OOP (as it became a resume builder), shoddy multi-threaded code (as it became a resume builder), shoddy XML sublanguages (as anyone tried to use XML... HA), you will have crap DSLs.

That said, DSLs can succeed where general purpose XML does not, in that it gives us a chance for easy human readable syntax, and if done right, reasonably writable syntax by developers. Using language that both understand.

I have no doubt that, in a 2014 job ad somewhere, you will see a requirement for "knowledge of foobar specific DSL required" - because some misguided company will decide that the specific DSL represents a different skillset. But that wont be that different than today, where such things are done now with industry specific XML dialects. In fact, the mark of a decent DSL will be the utter nonsense the idea of being "skilled" in it is. Being skilled in a DSL should be about understanding a domain, as Justin notes.
Aaron Erickson
Saturday, January 24, 2009 10:45:13 AM (Central Standard Time, UTC-06:00)
DSLs will be abused, just like every other feature or language function that programmers have ever received. Inevitably some developer will create what you are talking about, an entire mini-language that can be strewn across multiple systems and create a nightmare.

In my opinion though, this is not how DSLs will be effectively used. DSLs will be used to solve small, specific problems, not replace the languages that we are already using. The languages we are currently using are already large and flexible, which is why they aren't particularly well suited to any one specific task. If people start thinking that they can build DSLs which will allow them to replace their Java, C#, Ruby, etc... code, then I think we are going to be headed down the path that you are talking about.
Justin Etheredge
Saturday, January 24, 2009 11:20:20 AM (Central Standard Time, UTC-06:00)
You know, I am going through an example just like the one that Rockford has illustrated. Company X needs me to write a program that converts code from their "proprietary DSL" into XML. The original DSL was designed in the early 90's and its parser was written in C++.

It turn out the best "path of least resistance" we found was to re-write the parser into Rhino DSL/Boo. It was easy to do, and had the added bonus of upgrading their legacy parser into the CLR. Once the new parser was finished, it was an afterthought to add functionality to convert the parsed code into an XML format.

My point is, instead of throwing away the DSL with the bathwater, we implemented it in a fashion that makes it more extensible and downgrade-compatible for earlier versions. Legacy old DSLs are not the "dark side" in itself, it is finding a good systems for managing and defining those DSLs that is the problem.

Some killer DSL tools compatible with .NET/CLR:

Jetbrains Meta Programming system (MPS)
Boo (see the book building DSLs with Boo for examples)
pete w
Sunday, January 25, 2009 1:04:52 PM (Central Standard Time, UTC-06:00)
I've worked for companies that went the "DSL route" years ago and now they were stuck with their own proprietary outdated technology. The decision might had been good at the time and they might had gotten a lot of benefits out of it, but it's important to consider the disadvantages as well. The issue that you point out is very real and it must be weighted carefully.

A couple of years ago Gaving King had an interesting (and controversial?) post called "In defence of the RDBMS" in which he claims:

"If you think that relational technology is for persisting the state of your application, you’ve missed the point. The value of the relational model is that it’s democratic. Anyone’s favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That’s why we are stuck with them." http://blog.hibernate.org/Bloggers/Everyone/Year/2007/Month/05/Day/23#in-defence

I think the same can be said about general purpose programming languages. Their value is that anyone can understand them and run with them.


Hector Correa
Sunday, January 25, 2009 3:12:09 PM (Central Standard Time, UTC-06:00)
You're right, like any technology, DSLs will get abused. Remember when MTS came out - any new app had to have all the business logic sat in it. All that did was make it virtually impossible to debug and created a special type of DLL Hell. I saw several projects perfectly capable of being delivered, fail in large part because of the insistence that MTS be used. The latest big thing is Sharepoint - at least until the meltdown a number of corporates were mandating everything had to be written in this. Ignoring the fact that development is so painfully slow, and the platform itself so poorly documented, you end up delivering in a month what an ASP.NET developer could build in a fractionof the time. And then finding that nothing works when moved into production!

Many years back I wrote a lot of software interfacing to industrial machinery. The many different options for data transfer were really tough to capture via a GUI so we ended up writing C 'interface' DLLs for each different type we came across. I experimented with writing our own simple basic scripting language that a service technician could use to 'tweak' the final connections on site, without needing to know programming. I can see companies writing their own DSLs for this type of application, and indeed I can see an application right now, for adding user-configurable integration facilities to an existing application, again without forcing the user to know how to program.




Richard
Tuesday, January 27, 2009 2:27:31 PM (Central Standard Time, UTC-06:00)
I was never fan of DSL, neither now. However, the problems you state are relevant to any development. For example, Few years ago some company decided to develop their internal library of business objects, that looked like, well, like Csla, for example :) They built huge system upon this library. Is there something wrong with that? I think not. Then the developed some library for building their user interface, let's say in WinForms. Something similar to 3rd party libraries, like DevExpress. Some application shell. Is there something wrong with that?

Wouldn't you go the same way? That's not a rhetorical question, I am really interested in how you would you go.

Now, any developer from this company has to know this libraries. Until next generation of the libraries for modern technologies (WPF, Silverlight) are ready it's all the same as with DSL.
Maxim Alexeyev
Thursday, February 05, 2009 11:11:24 AM (Central Standard Time, UTC-06:00)
I do agree with Maxim.
I am generally not a fan of heavyweight inhouse-brew frameworks.
I think much too many people in the programming industry think that creating a private framework is a necessity or even offers a competitive advantage.
I think those days are mostly over. Today technology is mostly commodity for almost any types of problems we have (a least in enterprise IT). Investing heavily in a private framework almost always results in reinventing the wheel.

I had the same thoughts as Rocky when I was listening to Episode 95 of Software Engineering Radio. An I thought I had lost my faith in technology ... but It seems that Rocky has also lost his faith ;-)
Jonas
Comments are closed.