The post starts with the following statement:
While I am a big fan of Domain-Specific Modeling, I am openly not in favor of Domain-Specific Languages.... which leaves me puzzled. I'm pretty sure that the DSM guys call their abstractions DSLs as well.
Anyway, the post itself is not particularly interesting, but at the end of it there are a couple of questions about DSLs. This sort of questions which I've heard often and which contain a lot of miss- and preconceptions. Thought it was a good opportunity to answer them.
So here are the questions and my answers:
If we take so much time to master a general purpose language, should we invest a comparable amount of time in limited-use languages (i.e. DSL)?No, you shouldn't and you won't. DSLs are much easier to learn, since they are limited and focused. The important thing is that you have to understand the domain. But that is necessary in any case, no matter if you translate everything to a general purpose language or write it down like it is meant to be (i.e. using a DSL). If you know the domain very well, but are not able to grasp the DSL, than the DSL might not be that good.
How can we get support for a DSL, apart from its own creators?How can you get support for an API, apart from its creator? Well, by looking at the code or any existing documentation, or by asking any other users. In many aspects DSLs are comparable to libraries or frameworks.
Where’s community support?It depends on whether it is a widely used DSL (i.e. there is a community) or one you use and have defined in your one-man project. For the DSLs used in Ruby on Rails there's much community support, for instance. Same for the DSLs we have in Xtext.
Where's the community support for your homegrown libraries?
What happens after the departure of the language’s creator?It is like with any other artifact in your software system: A DSL definition needs to be clean, understandable and maintainable. If you know that an important team member is leaving the project, make sure she's not taking any exclusive knowledge with her. That is she should coach other people before she lefts.
What’s BNF? Do I need it?see http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form :-)
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?Useful DSLs can be very simple and at the same time a very complex DSL can be absolutely useless. It's not the complexity of a DSL, which makes it useful, but whether how good it is to solve the problem at hand. KISS and YAGNI are important principles here as well.
When defining concepts and abstractions it is key to find a good compromise between simplicity (abstraction) and re-usability. The simpler a DSL and the higher its potential for reuse the better. You're hitting a sweet spot, then. You start leaving that sweet spot as soon as you add concepts to the DSL which are only used by a small subset of the users. Often it is better to have two simple DSLs in two projects, than putting everything into one big DSL.
Back to the question: I don't think that evolution and design is mutual exclusive. Don't everybody design software systems incrementally these days.
Changing a textual DSL is not a big problem in practice. At least not as long as you have a decent test suite (which you should have no matter if you use DSLs or not). However, managing compatibility and versioning can become quite complicated, but again it's the same as with APIs.
Will the evolution in the language be severe enough to trash what has been done so far?You can shoot your foot, if you want. But you don't need a DSL to do so.
Can you imagine yourself developing a complex C++ software system while C++ itself was still being designed and developed?
I can imagine, but I am not keen on doing that. That is why we have things like versioning and that is also why people think about compatibility when enhancing public programming interfaces. Such interfaces can be a method signature, but it can also be a syntax of a language. It doesn't matter. If it breaks it breaks. And the designer has to be explicit about the contract of that interface as well as its life cycle.
9 Kommentare:
Nice post. It's interesting that all these questions have their equivalent in terms of using a framework or API in a general purpose language, which is of course the alternative...
Hi Sven, thanks for reading my post.
Anyway, the post itself is not particularly interesting
Agreed. My post was actually a rather superficial analysis of what can go wrong with DSLs. I would have worked harder on this post if I ever imagined so many people would read it.
The post starts with the following statement:
While I am a big fan of Domain-Specific Modeling, I am openly not in favor of Domain-Specific Languages.
... which leaves me puzzled
The difference between Domain-Specific Models and Domain-Specific Languages should not leave you puzzled. They could be different views of the same domain, but they are not the same thing. For instance, ABSE models are domain-specific, but they do not form or have a DSL. They are just non-graphical models, with constraints, attributes and a transformation code in a general-purpose language.
I am sure that the "DSM guys" are Kelly/Tolvanen. MetaEdit+ builds models on constraints, much like AtomWeaver and ABSE, hence the "Modeling" word in "Domain-Specific".
No, you shouldn't and you won't. DSLs are much easier to learn, since they are limited and focused.
Right. But aren't they... hmmm... programming languages? If they are, then they have specific behavior, implicit intent, etc, like a regular language. It's exactly the same difficulty. Only the domain changes!
What’s BNF? Do I need it?
see http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form :-)
I know what BNF is. :-P
But won't learning BNF, EBNF, ANTLR or any other notation be an additional weight while creating a DSL? That was the question's intent.
Changing a textual DSL is not a big problem in practice. At least not as long as you have a decent test suite
Test suites catch unintentional changes. I was referring to "un-avoidable" changes or additions in the language syntax, for instance. You know that developers always think their changes are a "must-have"...
Can you imagine writing a complex C++ software system while the standard libraries are still being designed and developed?
A language and a library are not the same thing. You don't need the standard libraries to write a large C++ system. I develop in C++ since 1996 and never used the standard library. Anyway I was again referring to its syntax, not API availability or depth. Since you can have any syntax in a DSL, what stops you from "improving" it?
To finish, I just want to say that I am sure Xtext is a great tool and DSLs have their place.
But everything comes at a price and DSL surely have their own!
>>The post starts with the following statement:
>>
>>While I am a big fan of Domain-Specific Modeling, I am openly not in favor of Domain-Specific Languages.
>>
>>... which leaves me puzzled
>
>The difference between Domain-Specific Models and Domain-Specific Languages should not leave you puzzled. They could be different views of the same domain,
> but they are not the same thing. For instance, ABSE models are domain-specific, but they do not form or have a DSL. They are just non-graphical models, with constraints,
> attributes and a transformation code in a general-purpose language.
I don't know much about ABSE, but I think most people define a DSL as a programming language, which is targeting at a specific problem domain (i.e. is not general purpose).
The concrete syntax doesn't matter. If ABSE models are executable and follow a syntax definition (e.g. a schema), I'ld call them a programming language. Don't know enough about it in order to tell whether it's domain-specific or not...
> I am sure that the "DSM guys" are Kelly/Tolvanen. MetaEdit+ builds models on constraints, much like AtomWeaver and ABSE, hence the "Modeling" word in "Domain-Specific".
Yes, I had Steve Kelly and JP Tolvanen in mind. Modeling languages built with MetaEdit+ are definitely DSLs.
>> No, you shouldn't and you won't. DSLs are much easier to learn, since they are limited and focused.
> Right. But aren't they... hmmm... programming languages? If they are, then they have specific behavior, implicit intent, etc, like a regular language. It's exactly
> the same difficulty. Only the domain changes!
Yes, they are programming languages. But they are not general-purpose programming languages (GPL).
For a DSL the domain is specific, that is regular expressions are extremely good to match character streams, but a bad tools for other things.
While a GPL can be used for everything, but has not its particular strength in character stream matching.
>>What’s BNF? Do I need it?
>>see http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form :-)
> I know what BNF is. :-P
I knew you know :-)
> But won't learning BNF, EBNF, ANTLR or any other notation be an additional weight while creating a DSL? That was the question's intent.
Yes, if you use a tool you haven't used before, you'll have to learn it.
So you can decide, whether you want to use your swiss knife to core thousands of apples or learn how to handle an apple corer.
That really might of cause not pay off in some cases!
>> Changing a textual DSL is not a big problem in practice. At least not as long as you have a decent test suite
>Test suites catch unintentional changes. I was referring to "un-avoidable" changes or additions in the language syntax, for instance. You
>know that developers always think their changes are a "must-have"...
Whenever you change a software system, tests are your best friend. Good test suites catch every breaking change.
Of course there are situations where you need to add a breaking change to an API (DSLs, libraries, frameworks).
What can we do in those cases?
1) let the clients take care of migration
2) help them with documentation
3) help them with compiler checks
4) provide a deprecation lifecycle for the old API
5) provide automated migration (i.e. refactoring)
It depends on the kind of change and of the number of clients and on other political things, what you want to do.
Many people just choose, to keep and maintain the old API forever.
Anyway, any of these options can be done with a DSL. And they are not particularly harder to do than with a library or a framework.
>> Can you imagine writing a complex C++ software system while the standard libraries are still being designed and developed?
> A language and a library are not the same thing. You don't need the standard libraries to write a large C++ system. I develop in C++ since 1996 and never used the
> standard library. Anyway I was again referring to its syntax, not API availability or depth. Since you can have any syntax in a DSL, what stops you from "improving" it?
If you don't use an API, then you're of course not interested in its changes.
I tried to stress the analogy between DSLs and libraries once more. But I see I couldn't make it clear.
I'll try once more with a counter question:
> Since you can have any syntax in a DSL, what stops you from "improving" it?
Since you can have any number of methods in a Java interface, what stops you from adding additional?
>To finish, I just want to say that I am sure Xtext is a great tool and DSLs have their place.
I'm glad you're not taking my comments offensive.
>But everything comes at a price and DSL surely have their own!
Absolutely, it's just that I think the hidden costs you described are not specific to DSLs but are general challenges of re-use.
While I am agreeing with Sven's position, I am disagreeing with the notion that DSLs are programming languages in the comments above.
E.g., is perfectly possible to define a DSL that will be used for capturing requirements. And that is not a programming language.
Is reuseability not against the meaning of "domain specific"?
Don't get me wrong, i like DSL but i don't think its the ultimate weapon against everything. Its focused on one area of problems and so in my opinion its not build to be reusable (or its not domain specific ;) ).
Just a couple of points.
The first in response to the question about evolutionary changes possibly breaking everything that you've done previously.
This doesn't have to be the case at all. The reason being that the DSL is a formal language, and if things change enough, you can write another translator for the original DSL, to translate it to the new one ! So, you can update your code using the old DSL programatically - you don't have to just throw it away.
Secondly, in reply to the comment - "E.g., is perfectly possible to define a DSL that will be used for capturing requirements. And that is not a programming language."
...this is in fact kind of the ultimate that you might want to aim for ! The clients define their requirements using the DSL - and these are then automatically translated into a working system, for the platform required. Eg, you have a translator that converts the DSL into Java, say. If one day you decide you want to move to .Net, all you need to do is modify your translator to spit out C#.
When you say, using the DSL to specify requirements is not a programming language - I would rather say, the DSL may be more of a declarative programming language, where you specify what you want, not so much how to do it. It's still a programming language, in the sense that eventually, a computer will run what you have written. However, it's a higher level language than your typical imperative programming language.
In many cases, this declarative (functional !) style of DSL is what we might want to aim for, rather than an imperative style DSL.
- guraaku
DSLs make knowledge explicit. In many companies the technical knowledge is very implicit. Sometimes even only in the head of a few employees.
Sure it will cost a lot of effort for them to create a DSL, as will it take a lot of effort for any new colleagues to learn the language. But the sole fact that the whole DSL process was undertaken improved the status of the technical knowledge. I might add here that the process also might help to tidy up the workflow itself, just like in software verification, where the sole act of creating a formal model usually leads to a finding of half of the errors (this quantity is figure of speech :)).
Business people write papers about how to preserve knowledge in companies, seriously....
Hi ttwhy,
Why should dsl be un-reusable to honor its domain specificity?
I think it is one of the aims of a dsl to be re-usable or why would I spend time and effort in something I will use only one or two times?
While a dsl focuses on one area of problems, that does not mean we can not reuse it since this area of problems can be encountered again and again.
Also, if one dsl focuses on one part of the problem, and provides a way to efficiently write a part of the solution, multiple dsl combined together could bring the whole solution.
Regards
Post a Comment