Domain Specific Languages

For just about as long as there have been programming languages, there have been domain-specific programming languages. It’s a way to get to a meta level of programming where you’re dealing with higher level constructs. I’m going to sligtly broaden this concept for the discussion with embedded programming languages — often something like JavaScript is grafted onto an existing application.

The issue, nearly invariably, is that while the languages work in the happy case, there is precious little tooling support for debugging.

The way these tend to grow is in phases. At first there's a solution that’s coded in a general-purpose language. The exact language doesn’t matter in this case.

These grow for a while, then someong decides to be “smart.” It sure sounds smart at least. You have the perfect spec of whatever it is that you find to have objectionable complexity. You can make an abstraction for it, then delegate the business logic to non-technical folks.

That’s the plan at least.

But it has two major problems:

• Programming requires a certain mindset — one that can easily deal with the abstractions that are thrown at you all the time. Just because you can explain a Gherkin file to an analyst, doesn’t mean that that analyst will ever make a new one. I’ve never seen it happen in real life at least.

• The language that you’re writing, be it one of your own creation or an embedded language, will have no practical way to debug it. Just because it makes sense to the person who came up with the project, doesn’t mean that anyone else will full grok it.

The simplicity, if you can even call it that, that you start with rarely stays that way. New requirements get added that eventually conflict with the architecture of the system. Once this happens you not only have the issues I talked about above, but you get that added bonus that the system slowly grows to be a speghetti of hacks.

Be careful before you invent a new language.