Model-driven Software Development vs. Haskell

Question

Just reading the (german) Wiki-Article about Model-Driven SW-Development (MDSD). Summing up the Wiki-Definition:

• MDSD is about the DRY-Principle (Dont repeat youself)
• MDSD is about the Design of DSLs (Domain Specific Languages) and Generators
• More concise description of problems (through the higher level of abstraction of the respective DSLs) is possible through MDSD.

Since I know and use higher-order functional programming I wonder, and my actual question is: Is MDSD nothing but a desparate attempt to inject (a part of) the powerful features higher-order functional programming offers into programming languages / paradigms which inherently lack those features?

(Or did I misunderstand and could MDSD even be used to substantially support higher-order functional programming?)

Answer 1

I prefer to look at it the other way around. OOP, MDSD, TDD, domain-driven design, and the many other paradigms out there are just that...paradigms. They're ways of looking at the task of software development that people have developed to address things that they perceived lacking in whatever came before them. It turns out that functional programming does the same thing--it gives the programmer powers of abstraction that aren't elegant in languages that don't have first-class functions. So I wouldn't say MDSD is a desperate attempt to give non-functional languages functional features as much as I'd say it's people coming at the same problem from a different perspective.

Some of the answers to this recent SO question have a different way of saying it. ShreevatsaR says, "Almost anything you can do with macros you can do with a higher-order function". Matthias Benkard says, "The lack of macros is mitigated somewhat by more elaborate...concepts like monads and arrows." Other comments also echo the same theme. You mention that one of the tenets of MDSD is generators. Macros are compile-time generators. So I would translate their statements as an argument that MDSD is inherently easy in functional languages.

Answer 2

There is a major difference between making a DSL (Domain Specific Language) (FP) and creating a whole bunch of Domain Objects (OOP) (with business logic inside the objects).

FP can suffer the same problem (and advantages) that procedural languages do: Separation of Behavior and Data. OOP languages discourage this. This separation is known as the Anemic Domain Model.

This "separation" can make changing your data very difficult (and maybe even worse with a DSL) See my post: Handling incremental Data Modeling Changes in Functional Programming

However on the flip side changing behavior and have things stateless across the board are pain in the butt with OOP Domain Driven design. However with things like AOP ITD's, and Meta-programming this becomes less of a problem.

Scala and Ruby are nice example of a mixture of both techniques.