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?)

Disannul

Yes ;-) (For your first question) – Dirt

I asked something similar myself: #2808129 and this one which closed (still pissed about that) #3135325 – Lightface

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.

Misleading

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.

Lightface

When using DSLs, one way to make changes to the data easier is to keep knowledge of the data limited to a small set of primitive operations, and implement the rest of the operations in terms of these primitives. You can then enforce this by hiding the real data behind an opaque type (by not exporting the data constructors in the case of Haskell). – Epiphysis

@hammer while I agree with you the real problem I have with creating a DSL is to create the DSL (at least in Haskell) I find myself not focusing on the domain but rather complicated pedantic Haskell Monads, Combinators, Arrows and what not. (again just my opinion). – Lightface

@Adam Gent: That's a consequence of your limited familiarity with Haskell, not something intrinsic. People new to OOP would complain about not being able to focus on their problem because of complicated class definitions and inheritance and what not. – Retort

@Adam Gent: I can agree that it might be hard in some cases to show how your DSL is a Monad for example, but once you do you get a lot of stuff for free. Also, you can in most cases build your monad out of existing transformers. As @camcann says, once you're familiar with it, it's as natural as inheritance is to someone familiar with OOP. – Epiphysis

@camccan I'm not saying the complexity is not worth it and I am familiar with the concepts. The problem is most people are not. Domain is about communication. I have to yet to see a rapidly changing web application (or any app) written in traditional FP like Ocaml or Haskell. These languages are good for hard static problems. Thats why I think Dylan won the 2005 ICFP icfpc.eecs.northwestern.edu . One of the challenges of that contestt is that they changed the problem half way through. Haskell lost (it usually wins). – Lightface

@Adam Gent My company has a very rapidly changing web server written in haskell. Just because it's not open source software doesn't mean it doesn't exist. corp.galois.com/blog/2011/4/22/… contains pretty much all the public info about it. – Leakage

@Leakage I would love to see the source code of something like that so that I could learn from it. It seems like most of the open source static analysis FP is a parser/compiler. – Lightface