hide all comments

DSM

Is your language domain-specific?

October 03, 2005 12:02:55 +0300 (EEST)

The DSL track at JAOO received a relatively large amount of interest: the hall held 100 people and was completely full, with people standing in hallways. The DSL track started with a short introduction by Martin Fowler. He discussed the difference between internal vs. external domain-specific languages and highlighted the tool support; something he calls Language Workbenches. MetaEdit+ is clearly such a Language Workbench the official product name is Method Workbench because in model-based software development we need more than just languages (at least generators…). My favorite was the presentation by Markus Völter, perhaps partly because the experiences he explained are similar to ours: making generation complete, never touching generated code, raising abstraction away from code, and incrementally creating the language and generators.

During the conference I noticed that “domain-specific” became a bit like a mantra: participants started to see domain-specific languages everywhere, even when just adding their own code template or similar to a general purpose language (like embedded SQL). Martin Fowler showed also some of these “internal” DSL languages. After he explained such a sample language, its domain-specific structure and proposed abstractions became easy to understand. But were all these language examples truly domain-specific languages? This question was asked by many in the conference? Perhaps the best way to find out if the abstractions put into the language are domain-specific for others too is via a simple test: Give it to other developers and after some time has gone (e.g. project or product is done) check the specifications (model/code) made with the language? Are the abstractions you or someone else invented earlier still recognizable? Are they used and followed or have they been mixed, misused or ignored? I would argue that the internal DSLs are not so good a way to deliver domain-specific abstractions and constructs because they have little power to ensure they are used, and used correctly. If you have found good abstractions they might be clear for you, but after you have put them into a domain-specific modeling language, you can be sure that others can use them too and in a correct manner. It would be sad if you find useful abstractions (architectural rules, component framework, programming model) but those are not used by others. Domain-Specific Modeling languages are a great way to help others leverage the knowledge of experienced developers.

Comments

re: DSL making models work

[MItch Barnett] October 16, 2005 02:03:23 +0300 (EEST)

Hi Juha-Pekka, Nice post. With respect to DSLs, you might find this interesting: BRIDGEWERX - A Software Factory for generating Application Integrations Cheers, Mitch