I like the following quote from Jay Field's screencast The 5 Ws of DSLs:
The DSL movement is in a stage that is similar to the stage of OO before Design Patterns were documented.
The concepts for DSLs are slowly being fleshed out. As experience is gained, best practices will evolve. But we are at the beginning of this process!
Along those lines:
Overuse of DSLs is one of the antipatterns in Groovy development.
Do not create a DSL if a native solution would be as elegant.
Some DSLs will live and some DSLs will die...
- Rocky Lothka, .NET Rocks Episode 417
I think theres quite a lot of good information on DSLs. Unfortunately most of it is being ignored by the Groovy/Ruby devs focusing on internal DSLs. There's a whole body of knowledge related to DSLs - evolution, versioning, tool support, automated model evolution based on meta-model transformations. I'd check out resources on Domain Specific Modeling or Model Driven Development - there's lots of great stuff!
ReplyDeleteSubscribing to comments!
ReplyDeleteThis comment has been removed by the author.
ReplyDelete@Peter
ReplyDeleteFunny, I have made the opposite experience.
In my experience especially the modeling guys (MDA, MDD, MDSD ...) have usually a very narrowed understanding of what a DSL is.
I met quite some people that believe that a DSL is just a new fancy term for UML profiles.
They never heard about textual or even internal DSLs...
On the other hand, the Ruby/Groovy guys I have seen have usually a much broader and deeper understanding of the topic as a whole. Just watch Jay Field's presentation as an example.
They are just focussing on the specialization of internal DSLs.
The internal DSL approach is much more pragmatic and lightweight in the sense, that it brings less accidental complexity.
The heavy tooling and additional infrastructure that is needed by the MDA/MDSD approach brings a lot more accidental complexity. There is a lot of information available in this area, but I think it mostly deals with the accidental complexity and not with the incidental complexity of DSL creation and the concepts behind it.
In general, I think the upcoming DSL-Book by Martin Fowler is going to be THE reference on this topic. The book is going to show the different areas and notion of DSLs and is going to relate them.
The book will probably shape how we will think about the topic in the future.
But this is still work in progress...
Hi Jonas,
ReplyDeleteI think (like all too many people) you've had the unfortunate experience of talking to someone from the MDA camp who thinks UML + stereotypes = perfect DSL tooling and have rightly noted that is bunk.
However, have you checked out projectional editors like JetBrains MPS? What about the Eclipse based tooling like openArchitectureWare which just got folded into Galileo? What about the work that Steve Kelly and JP Tolvanen have been doing for years over at MetaEdit+ on their metacase tool?
Internal DSLs are a step up from APIs, but they have substantial limitations as the number of models grows. Firstly, there is no direct tooling support. How do I get code completion, syntax highlighting and static type checking on my model statements (and this is from a guy who mainly codes in dynamically typed languages - but I believe static type checking and code completion is particularly important with DSLs as they are often used occasionally, making help with using them more important).
And what about the real problems like model interoperability and DSL evolution. Lets say I change the metamodel for one of the models in my internal DSL. How do I validate whether model statements in other internal DSLs are still making valid cross DSL references? (Because one of the things we've learned in the DSM community is that lots of little DSLs are better than one monolithic one).
And finally, here is the killer. Lets say your metamodel changes (the grammatical structure of your internal DSL). You have 100,000 statements in that DSL across 200 projects. Try writing a script that'll automatically apply the grammatical transformation to all of the statements in your DSL which is syntactically embedded in a 3gl - it's a close to impossible task in the general case. Give me an external DSL where the concrete syntax is XML or even a database schema, and I can describe the grammatical transformations and apply them automatically to both the metamodel and all models using XSLT (or another language capable of model to model transforms like ATLAS or Xpand) or database transformations and suddenly all of my statements are up to date. This is a HUGE issue when you start to use DSLs really broadly. I wrote a paper on the DSL evoluion at the DSM forum at ooPSLA and did a practitioner report at ooPSLA on a software product line using a lot of these techniques. I'm far from the most knowledgeable proponent of DSM, but I honestly feel guys like Markus Voelter, Steve Kelly, JP Tolvanen and Jos Warmer (most of whom were on a panel I ran the other week at a Code Generation conference in Cambridge, England) have a lot to say about these concepts. I'd also recommend checking out the whole KISS approach being pushed by guys like Jorn Bettin out of switzerland. There's also Eelco Vissers work on everything from scannerless parsing to his "webdsl" project which is really interesting conceptually.
There's a lot more out there than the basics that Neil Ford and the Ruby/Groovy guys are talking about and I think there are great use cases for both internal and external DSLs, but in my experience most of the DSM guys are well aware of and use internal DSLs where they are a good fit, but many afficionados of internal DSLs don't yet have as broad a perspective on the big issues that arise as DSL usage grows - metamodel evolution, model interoperability, tooling support, multiple projections, etc. Nobody has all the answers, but I think the DSM community has some interesting questions :-)
@Jonas, And just to follow up, while I think there is still accidental complexity in the DSM tooling space (and can we just ignore the guys who believe "UML is the answer - now what is the question" - we don't even invite them to the conferences any more :-) ) but I think there is also essential complexity that becomes obvious as the number of statements/models in your DSLs grows to the point where dsl evolution, intermodel operability and support for projectional editing become valuable.
ReplyDeleteGreat discussion, BTW :-)
@Peter
ReplyDeleteThanks for your interesting comments!
I just realized that I we sat next each other at gr8conf in Copenhagen ... is this possible?
Well most of my experiences with Modeling were actually with oAW :-) But mostly with visual modeling together with a UML-Tool :-(
I just found it very clumsy and fragile to set up the whole oAW-Infrastructure, and it often prevented a natural evolution of the systems later on.
I have seen a demo of Intentional Software, and I think it can be very promising, but only for a very special kind of projects ...
Too funny - I think we *did* sit next to each other at gr8 in Copenhagen. Small world :-)
ReplyDeleteYou lost me at UML modeling! I have seen many people take that approach and few have much fun with it. For visual modeling, MetaEdit+ is pretty cool if it meets your use case. For textual I like the oAW xtext tooling.
I also like just using XML concrete syntax with XSD as metamodel as it's very easy to get started with but still gives you the benefits of external DSL in terms of the capacity for DSL evolution. I do agree that internal DSLs are a step up from an API, however, and they are a great fit where the number of statements isn't huge (not tens or hundreds of thousands of statements in the DSLs) and/or where the likelihood of having to apply gramatical transformations to those statements is fairly small.