January 19, 2008
Domain-Specific Languages: The Big, Dirty SecretThe world of Domain-Specific Languages has a big, dirty secret.
Imagine you are a Java programmer, and that Sun are making small changes to the Java language every single day. As your software evolves, so too does the language it's written in. How much effort would you waste keeping your code in step with the programming language?
Of course, Java doesn't change every day, thank goodness. And that's because it belongs in a problem domain that is relatively stable - computer programming.
Many problem domains are far less stable, and on the vast majority of projects our understanding of the domain evolves rapidly as we add new functionality and learn more about the problem.
Propononents of DSL-based development - like software factories - have got it arse-backwards. The point at which the domain model is stable enough to be reused is usually towards the end of the project.
There is really no diference between creating a reusable code library to model our domain logic and defining a DSL that contains the sames types, operations and business rules. In the 90's, organisations attempted what we might now call planned reuse, investing millions up-front in the development of reusable business and system logic components. Do you remember what happened to planned reuse? That's right: it didn't work.
And that was because the only way to know what logic is reusable is to build the applications and identify commonality (i.e., duplication) as we go. I would call that evidence-based reuse. Planned reuse is highly speculative compared to evidence-based reuse. There's no great mystery as to why it didn't achieve the high levels of reuse we'd hoped for. And, of course, there was also the very great risk associated with developing business logic without any end user feedback from a working application, which meant most of these great white elephants contained logic that was just plain wrong.
So now, in this age of iterative and evolutionary design, we flesh out our understanding of the domain one usage scenario at a time, getting meaningful feedback from domain experts as we go, and our reusable domain libraries evolve as we iterate towards a working solution.
We've learned our lesson.
Except, well, maybe some of us haven't. With Domain-Specific Languages and the concept of software factories, it looks like planned reuse is back on the table.
The practical problems are glaringly obvious: even fans of DSLs acknowledge the difficulty in allowing our DSLs to evolve. Various sophisticated and convoluted techniques are being proposed to ease some of the pain, but I've been here before and I know how this dance usually ends - with millions of pounds-worth of unreused code gathering dust on the shelves.
I don't doubt that DSLs will be successful in stable domains, like computer security or data manipulation. Indeed, they already are. But the people pushing the technology need to realise that they live in a bubble where problem domains tend to stay put from one day to the next.
For the rest of us, planned reuse is just too much of a gamble, and the tricky process of evolving our programming languages while we're using them is not going to go away. At the very least, DSL tool vendors need to create more seamless integration with day-to-day coding so that duplicate logic can be refactored into a DSL, for example, and refactorings to DSLs are automatically propagated to any code written using them. in other words, DSLs should be treated as simply "more code" (like our old reusable libraries).
By creating this artifical distinction between reusable code and DSLs, though, with each requiring its own set of tools and techniques to work with, we are severely hampering our ability to follow a feedback-driven, evidence-based approach to reuse.
And that may well mean that we are making development a whole lot harder for ourselves. Until these issues are practically addressed, I think I'm going to stick to good old-fashioned code libraries for most applications.
Posted 13 years, 6 months ago on January 19, 2008