The Hidden Costs of Domain-Specific Languages
Written by Rui Curado on November 25th, 2009While I am a big fan of Domain-Specific Modeling, I am openly not in favor of Domain-Specific Languages. DSL supporters advocate many good things. Are they real? Is it the whole truth?
Let’s see some good (valid) points about DSL’s:
- It’s domain-specific (duh!)
- Encapsulates boring details
- Can increase abstraction to the next level
And other not so valid points:
- It’s a Shiny New [mainstream] Thing. Most developers love that
- It’s cool and I can do it too
The first are very enticing, valuable, and sought for, and most of DSL’s attraction I guess comes from these features. But, will it pay off?
I really don’t have much experience with DSLs, so I won’t use my own arguments. I’ll let the community speak for myself. Here is a tiny sample of DSL criticism:
http://c2.com/cgi/wiki?DomainSpecificLanguage
… the Tower Of Babel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.
…
writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won’t survive the departure of its designers.
http://www.theserverside.com/news/thread.tss?thread_id=42078
The other mistake some folks make is they think that with a DSL that “non-coders” can actually use the DSL.
But since a DSL is designed for automation of an underlying objet model, writing in a DSL is just like writing in any language — whether it’s DOS .BAT files or Java, and it takes a coding mindset and understanding of the underlying domain as represented by the computer in order to make effective use.
There was much more written on this thread. You can go to the original page to read more opinions.
As general use of DSLs become mainstream, so become the complaints about their shortcomings. If we take so much time to master a general purpose language, should we invest a comparable amount of time in limited-use languages? How can we get support for a DSL, apart from its own creators? Where’s community support? What happens after the departure of the language’s creator? What’s BNF? Do I need it?
DSL critics say really useful DSLs are hard and expensive to create. DSL supporters answer that DSLs are not designed, they evolve. Well, won’t any of those “evolutionary steps” risk breaking the entire development based on that DSL, much like a broken app build? Will the evolution in the language be severe enough to trash what has been done so far? Can you imagine yourself developing a complex C++ software system while C++ itself was still being designed and developed?
Still too many unanswered questions.
25
PM
Good point, Rui!
I have commented your note today…
26
AM
You are aware that C++ is still in design and development? And even worse every C++ environment/flavour is under even heavier development than “standard” C++? Generally all the points you state read somewhat like “aren’t antibiotics evil – because they all cause hyperresistant bacterias?” or “UML diagrams are obsolete!”. You generalize without any specific constraints – so not worth any discussion.
26
AM
C++ is a general-purpose language. It has to have a long update cycle. A long update cycle, larger than most projects, won’t do much harm. On the other hand, any DSL with an update cycle of C++’s would be considered dead.
UML is not obsolete. It is just not the best option for some tasks…
4
PM
I don’t think the DSL thing is so much a “way of life” type of problem, as in your all for it or all against it, or it shouldn’t be – It’s only worth using if it actually solves your problem.
I’ve found an interesting uses for it that has saved me alot of time. I found it usefull for describing my development domain (my apps are db driven, with tables of diferent comun types/usages, and made up of diferent comun types of columns and patterns). With it, I’ve been able to generate and maintain soooooooo much of the code that I need for the app, through all the layers It’s helped me develop my own framework, with all my comun patterns and generate something more of a domain-specific and customizable API than an actual language.
Naturally it’s not complete, but it doesn’t stop me from customizing it to solve the problems I need to solve for my clients. And I KNOW it’s not the silver bullet everyone wants. But it has helped get all the comun stuff automáticly and require only the interesting stuff to be added by hand. It has also helped some of my new colleagues get on board the team and speed up development. It ends up describing some of my own development patterns, and keeping things systematic.
Alot can be done with a DSL, just like any language or diagram. I believe it’s more about choosing whats best for a specific problem and going with it, then using one or the other for everything.