When it comes to implementing industrial-grade Domain Specific Languages (DSLs), rushing to deliver something as early as possible can prove dramatically counter-productive.
This is true for all software projects, not just DSL projects, but it is as if the DSL community needs this reminder more than any other.
If your project matters, if it delivers anything of true value, if it is at all successful, it will last for years. It will be augmented and improved to support evolving needs, and in comparison with this ongoing effort, the ability to demonstrate a prototype in days or even hours makes very little difference.
In fact, focusing on these early developments can jeopardize the project altogether, putting its long-term viability at risk.
Do you think I’m exaggerating in a desperate attempt at making a weak case? Read on, because this is not just about the cruel effects of time. It is about the plethora of exciting technologies that are available to develop textual and graphical DSLs in a matter of hours.
At conferences, promoters of such technologies give flamboyant demos, going from a DSL concept to a working implementation in a single workshop, with everybody in the audience completely blown away by the genius and elegance of it all.
And blown away they should be.
These efforts are impressive. That is, for an academic audience that has an attention span that only goes as far as the few months it takes to write and publish a paper. Unfortunately, few appreciate the importance of the longer time spans that we work with in an industrial setting and how vital it is to withstand the test of time.
The tools that are used in many of these demos induce a dependency that has a very high probability of proving toxic if the DSL lives on for a few years – by which time our friends from academia will have most certainly lost interest.
They are based on a scaffolding of technologies, most of which are the result of research projects for which long-term support and maintenance is uncertain at best.
In other words, these tools, these frameworks are great, but your dependence on them has a very good chance of killing your DSL project. And ironically enough, the probability of this toxic dependency going awry grows the more successful your DSL is, the longer it is used, and the more it is promoted by an enthusiast user base.
The solution to this problem is remarkably simple:
Don’t use these fancy tools to do anything more than prototyping.
Use them to demonstrate things early and fast if you must, but rollback and go for more conservative, less productive but more future-proof methods of implementation.
That even includes simple things like parser generators.
Don’t get me wrong, Yacc, ANTLR, and the like are great (and you would not expect a compiler geek like me to say otherwise), but their added value is limited, especially when dealing with a language you design yourself, where making it easy to parse is one of the most reasonable design goals you can pursue. Their added value is limited and using a parser generator poses yet another liability for your project.
And just for the record, if you can’t write a parser for a simple language without the assistance of a parser generator, you might consider pursuing a career in a field that does not involve languages in the first place.
This also means that even if you support a graphical notation, you may be better-off supporting an underlying textual format as to allow your DSL programs, models, scripts, or whatever terminology you use in your specific context, to be persisted independently of the GUI used to create and maintain them.
This allows you to revamp and redevelop its graphical representation when, not if technology has moved on and your DSL environment has become obsolete.
To prevent your DSL from collapsing under its own weight after a couple of years in production, you must treat it very much like a standard, normal, software project. You must care for the damaging effects of time on software architectures.
And of all the things that can make your industrial grade DSL brittle, a dependence on a scaffolding of technologies with an uncertain future should be at the top of the list of your worries.
