Revisiting “DSLs are a bad idea”…

My post a few months ago entitled “DSLs: Definitely a bad idea!” certainly seemed to touch a nerve for some people. What was intended to be a sort of lighthearted throwaway entry engendered a lot stronger reactions than I’d expected. So I thought it might be worthwhile to back up for a second and revisit the issue, address some (though not all) of the comments, and talk about how they connect to how I see M.

To start with, yes, of course, I was engaging in a bit of hyperbole by saying that DSLs are a “bad idea.” DSLs are just a tool, and tools are neither bad nor good in and of themselves-it’s all in how you use them. I don’t believe that DSLs are so dangerous that only highly qualified and well studied people should be allowed to attempt them. But I do believe that they have enough of a capacity to cause mischief that they should not be entered into lightly unless you are just fooling around. I mean, if you’re just creating a DSL for your own amusement, then who cares? Have a ball! In fact, I think it’s a great way to learn about programming languages and how they are put together. But if you’re in an environment where you’re going to depend on that DSL for something, or if other people are going to have to depend on it, then you should really take a step back and think carefully before heading down that path. Because DSLs have a nasty habit of taking on lives of their own if you’re not really careful about it.

The question then arises: “Paul, you work on the DSL component of M. Why are you telling us we should think twice before creating a DSL? Aren’t you speaking against your own interest?” I don’t see it that way, for this reason: what I’m mainly talking about here is that one should pause before one creates an entirely new DSL. Maybe this was imprecision in my previous piece that I should have corrected, but I think one can have much less concern when one is working in a domain where there is already a language of some sort defined.

This, to my mind, is where M’s DSL capabilities really shine. If you’ve got a domain that has no domain-specific language associated with it, think carefully before you embark on creating one. But if you’re working in some domain that already has some domain-specific language associated with it, the damage is already done, so to speak, so you might as well jump in and try to make things better! In particular, if you’ve got a domain that has a language associated with it that is more machine-friendly than human-friendly (*cough* angle brackets *cough*), then I think that M’s DSL capabilities are going to be hugely useful for you.

So overall, I’m just cautioning against the hammeritis that often infects the programming community (you know, “when all you have is a hammer, .”). DSLs are a wonderful tool, and I’m hoping to soon start talking about how you put them together. Just, you know, hammer responsibly.

4 thoughts on “Revisiting “DSLs are a bad idea”…”

  1. Pingback: Anonymous
  2. Paul,

    This M thing has got me kinda psyched – I can never tell whether you’ll looking forward to the next esoteric tool or the future of Domain-Driven-Design – the centerpiece of which is a ubiquitous language that is a technical dialect of the problem domain – the goal imho of every domain layer – M could really facility maintaining that language in a high-fidelity, low-noise, syntax.

    I agree with you that tools are neither good nor bad but are always subject to abuse but I really hope you all make it really easy to fall into the pit of success with this tool 🙂

  3. DSL, languages, class libraries, application programs, and technology needs some aging before becomming really useful. The main point is that useful is over the long term (5+ years) which precludes a .NET developer, for example, from including version 1.0 or, CTP or beta version of a tool/library/language for any production system until that tool has been available as a released (i.e., not CTP, not permanent beta status) product for 1+ years. This helps to avoid technologies that are unlikely to be used and/or updated. This also makes it easier to find developers with the right experience and update the software you’ve developed.

    This is exactly what is done for long term purchases and should be followed when writing production software. Throw away software excluded.

    Hardly anyone buys the cheapest car from the cheapest manufacturer beacuse it’s known that the cheapest car is the least reliable and more costly over the long run.

  4. Ok, i posted this comment to a wrong post, sorry:


    I was a big fan of DSL-s about 3-5 years ago. Today i see a big, teoretical disadvantage of DSLs: It hides multiple (too much) aspects of the problem, and shows explicitly only one. (The one which I choose, usually i choose the problem domain aspect)

    But there are a lot of aspects of a problem, such as error handling, authorization context, transactional context, identity/equality context, redundancy context, performance aspect, parallel executability, extensibility, modularity, manageability, traceability aspects, and so on.

    If i provide a DSL for the problem domain, i have to deal with these aspects on DSL implementation side. But there are no practices, patterns to do this. In fact the result will be a DSL with a complex backend where the architecture will be ruined by the actual DSL infrastructure. I think there are a huge amount of problems where this doesnt worth the effort.

    Usually the problem domain is not so important to make additional effort to express it in a cleaner way.

Leave a Reply