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.