Thinking about model driven software development

I hate buzzwords, and MDSD is one of them. No so much because as an bad idea, but because its so often misunderstood. When someone talks about model-driven development, he usually means two things:

• drawing some pictures (or diagrams, if a tools is used)
• he can solve all development problems with these pictures, and there is no need for further abstractions

I came to think the see these pictures as a special kind of domain specific languages. Its graphical, and will therefore require special tool support (as long as don’t want to create code, you can draw them on a flip chart but generating code is what MDSD is all about). This also means that its always difficult to create these diagrams from another tool (meaning that you have a higher language).

The last thing is the main point - DSL are created to solve some problems easier than in a general programming language. The DSL abstracts some things away, and make other things easier on its way. But this doesn’t mean that it is the end of the road - for some even more specific problems it can be a good idea to create an even higher abstracted DSL, which generates code in the former DSL. If doing so is easy, this encourages the creation by the developers. This can be seen in the Ruby & Rails community - as Jamis Buck stated: /most well-written Ruby programs are already a DSL/. For me thats one reason development in Ruby is so fast, and so much fun.

Of course, Ruby did not invent this. Lisp with its /defmacro/ did this some decades earlier, and took it to a much more extreme level: since data is code, and code is data, every DSL specified in Lisp is also Lisp code - which means that you need no special facilities for code generation, and you get all the power of Lisp on all levels of abstractions you want to create. To change Jamis’ quote: in Lisp its not possible to write a program which is not a domain specific language.

For my journey with Common Lisp, this means that I now need to write Lisp programs :)