DSLs and You

Domain Specific Languages are a thing. They let you express what you want in terms relevant to the problem at hand, and can hide a lot of complexity. Consider the lowly SQL select statement. You get to specify a few parameters and the system does yeoman’s work to actually figure out how to optimally read the data. CSS is also a DSL. Our team wrote and used Turtl to process JSON files and it makes templating and data extraction a lot easier. Those are all text based DSLs, and we’re all very familiar with them, but not all DSLs are text based.

Most form builders and interface layout tools are visual DSLs. Yes, there is a config file behind the UI that you can muck with, but the intent is to use the visual interface. There are even visual DSLs for personal robots. The world’s largest tire manufacturer (LEGO) also produces a visual DSL for it’s Mindstorm robots. It’s based on LabView, which is another visual DSL that’s widely used for industrial purposes.

But that doesn’t mean that DSLs are the solution to all your problems. For one thing, they’re specific, which means if your problem isn’t covered by the designed use cases you’ll have a very hard time doing what you want, if it’s even possible. It’s also another level of indirection which makes it harder for the end user to know exactly what’s going to happen. And like other languages, how you handle the edge cases is important. And you need to be consistent across versions. You never really know how your customers are going to use it, but you need to support/maintain those use cases going forward.

So, a DSL may be the solution to your problem, but make sure you include all the future costs in your evaluation