It was nice to see Microsofts' Gareth J agree with me when it comes to providing DSL tool users with ready language templates, i.e. generally a bad idea. It just leaves me to wonder about Microsofts' DSL tool strategy to provide users with complete ready languages (not leaving it just to templates but go the whole nine yards in providing organization A a method that organization B says is probably best for them, without knowing a whole lot about how exactly software is developed in organization B). At least, this is what the media tells me to be the strategy Redmond will follow and of course the media does not always get it right, but this most often happens when editors think they understand a new technology (...but then they don't...and still write a story on it), my guess is that they often get it right on strategy. Especially when interviewing and quoting team members and project leaders.
I wrote my earlier post on language templates with in mind the idea we at MetaCase have that it is probably best to allow the organization that uses the DSL to define that DSL... themselves and make defining tool support for the DSL (in the end that is what we need) convenient.
There are several reasons for this conclusion:
I wrote my earlier post on language templates with in mind the idea we at MetaCase have that it is probably best to allow the organization that uses the DSL to define that DSL... themselves and make defining tool support for the DSL (in the end that is what we need) convenient.
There are several reasons for this conclusion:
- MetaCase employees only know a lot about Domain-Specific Modeling tools, we do not pretend to know how software is or should be developed in different vertical problem domains
- Providing a ready-language to many (say more than 2) ALWAYS leans toward the one-size-fits-all problem that we see with UML: users want to change it to become more domain-specific, which if you would, often suffers from its original version legacy: The template problem.
- Allowing users to define their own, makes them think more and in different ways about their problem domain, which has the effect that they will start to understand their problem domain better, which is undeniably a big advantage, which can lead to more concrete advantages
No comments:
Post a Comment