In his recent posts he started to talk about MDSD and how it's related to DSLs. As I'm somewhat involved in the MDSD community, I wanted to clarify what MDSD means to me.
Basically, MDSD is about
1) defining domain-specific abstraction (no matter how) and
2) make them executable (no matter how).
Defining abstractions
Sometimes the general-purpose programming language (GPL), e.g. Java or Ruby, can be used to define such abstractions (we call these abstractions APIs or internal DSLs). If the GPL is not flexible enough or we need static typing or better tooling, etc. we design an external DSL.
Most people think that developing an external DSL is complicated, because if it's a textual DSL you need to develop a parser, if it's graphical you need an editor, etc.. Therefore people customize/extend existing languages like XML or UML a lot.
However, nowadays it's not complicated to define an external DSL anymore. Frameworks like Xtext and the Eclipse Modeling Project in general offer a variety of tools and libraries to make the design of external DSLs easy and more important flexible, in terms that the DSL can grow and evolve over time. DSLs are a lively part of your project and therefore need to evolve like the rest of your software.
Make DSLs executable
"A difference is that most MDSD people assume that you'll want to generate code from that model rather than executing the model directly."I don't assume code generation. Interpretation is of course a common option. Both approaches have their pros and cons. Generally speaking, one could say that code generation has strength when the DSL is of a structural nature (like a domain or component model), the target language is statically typed and you don't need to have dynamic execution of DSL expressions.
But it's also perfectly ok to generate code out of behavioural languages (such as statemachines) or interpret structural information like hibernate or spring do with their XML-based configuration DSLs.
Other misconceptions about MDSD
"In order to use model-oriented DSLs you need a different, RepositoryBasedCode, approach to tooling."There are a lot of modeling tools using this approach. However we (Eclipse Modeling) use plain text files to store our models, because we think it's important to have all relevant information to build the software system in the same version control system. Also we want to reuse common, proven tools such as Diff and Merge.
"DSLs seem to have a proportionately higher emphasis in the MDSD world than they do in the mainstream programming world."MDSD is not a holistic approach to develop software or a replacement to "mainstream programming", it's just the "how can I use external DSLs"-technique. And DSLs are just one useful thing among many others. MDSD emphasizes DSLs like AOP emphasizes Aspects.
"A particularly visible sub-community of MDSD is centered around ModelDrivenArchitecture (MDA). I'm not much of a fan of MDA in particular ..."MDA indeed is a heavyweight thing which is based on overly complex standards and faces problems which are not relevant in most situations (like being platform independent). Also the suggestion of using UML and it's profile mechanism to define DSLs and layering code generators (make them target platform independent) with multiple model transformations is questionable.
To me MDSD has not much in common with MDA.
"Model Driven Software Development (MDSD) ... considers itself as an alternative to the traditional style of programming"To me it's more like an extension. Again: MDSD is only about using DSLs, interpreters and code generators and integrate them in your project. To be a good software developer you need to have much more than this in your mental tool box.
"Most fans of MDSD base their enthusiasm on the basis that models are ipso facto a higher level abstraction than programming languages."I also have met people (mostly with a CASE or MDA background) who haven't yet understood that models are just information like code is information and DSLs are just about specifying information in an abstract, concise, intentional and non-redundant manner. Models are code!
Sometimes those people even talk about "hand-written code" like it was something dirty. They argue that with models and code generation everything gets automated and forget that especially modeling in a graphical tool takes more time than writing the same information into a text document. IMHO such statements are one of the reasons why people like Martin think of MDSD being a holistic, tool-centric, heavy-weight approach (this is what I read between the lines).
