Beware of DSLs
At ooPSLA 2007 in Montreal there had been a very entertaining (and educating) panel on object-oriented programming languages and Simula 67 as their common ancestor. And the panelists were pretty excellent: Anders Hejlsberg (C#), James Gosling (Java), Guy Steele (Lisp/Scheme/Fortress), Bertrand Meyer (Eiffel), Ole Lerman Madsen (Beta). Now you might ask how this is related to software architecture.
First of all, programming languages have some influence on the way we think about architecture. Don't believe those experts that want to make you believe architecture design is completely unrelated to paradigms and languages. For example, one of the goals of Simula 67 was to provide a means for modeling systems which often got lost in state-of-the-art languages.
And secondly, we are currently facing a lot of discussions about DSLs (Domain specific languages). The panelists expressed their concern that now people are starting to develop DSLs who have no experience in language design. It is not trivial to design a language that is complete and consistent as well as usable. Believe me, I worked on such topics during my time at university.
The conclusions the panelists drew was that they prefer to add more modeling capabilities to programming languages over DSLs. Ruby is one of the examples in this area, but ,of course, it is only the beginning. Upcoming languages such as Scala, offer a lot of cool features for this purpose.
I discussed that issue with Markus (Völter), one of the gurus in Model-Driven Software Development and he shared this conclusion.
My conclusion and observation: Bad DSL design can cause more harm than value. Only language experts should become DSL designers. Designing DSLs on top of programming languages might be an appropriate approach. I already discussed Integrated DSLs in a previous posting.
posted by Michael at
1:05 PM
3 Comments:
Well, just to be clear:
I did agree that it is very useful to make sure general purpose languages can be extended with domain specific constructs. However, I still want static typing, code completion and the like. Also, incrementally extending existing languages only works for use cases where the user is primarily a developer.
There is also this whole other space where formalization and a domain-specific syntax (i.e. DSLs) can be used to empower domain experts to capture their know-how formally, using it as an input to code generation, for example. Since the user audience here aren't developers, there's no point in extending 3GLs, you need a "domain workbench" with a set of integrated custom languages. The important thing here is this: if you're the person who designs those languages, be sure you have a solid understanding of Programming Language Concpets so you don't (re-)invent wheels that don't work!
By
Markus Voelter, at 1:54 PM
... and something else:
you say:
"Bad DSL design can cause more harm than value."
here you can replace DSL with anything. Bad anything can cause more harm than value, right?
"Only language experts should become DSL designers. "
well, and only OO experts should design frameworks.
So, what's the point :-) ?
Markus
By
Markus Voelter, at 6:21 PM
The point is that languages are typically used for many applications. If you got a badly designed language, thid will inevitable cause a lot of trouble. So is this the case for frameworks, SOA,middleware ... But it doesnot make a statement invalid that it holds generally for various topics. Especially when people often tell me that they will start building their own DSLs which they consider an easy job. Its important to emphasize this point in the context of DSLs.
By
Michael, at 6:32 PM
Post a Comment
<< Home