模型驱动软件开发与 Haskell
只需阅读有关模型驱动软件开发 (MDSD) 的（德语）Wiki 文章。总结 Wiki 定义：
- MDSD 是关于 DRY 原则（不要重复）
- MDSD 是关于 DSL（领域特定语言）和生成器的设计
- 更简洁的问题描述（通过各个 DSL 的更高层次的抽象）可以通过 MDSD 实现。
因为我知道并使用高阶函数式编程，所以我想知道，我的实际问题是： MDSD 只不过是一种绝望的尝试，将高阶函数式编程提供的强大功能（一部分）注入到本质上缺乏这些功能的编程语言/范例中？
（或者我是否误解了 MDSD 是否可以用于实质上支持高阶函数式编程？）
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?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我更喜欢反过来看。 OOP、MDSD、TDD、领域驱动设计以及许多其他范式只是......范式。它们是人们看待软件开发任务的方法，人们开发这些任务是为了解决他们认为之前的任何东西所缺乏的东西。事实证明，函数式编程做了同样的事情——它为程序员提供了抽象能力，而这在没有一流函数的语言中并不优雅。因此，我不会说 MDSD 是一次绝望的尝试，旨在为非函数式语言提供函数式特性，我会说它是人们从不同的角度来解决同一问题。
这个最近的SO问题的一些答案有不同的说法。 ShreevatsaR 说：“几乎所有可以用宏做的事情都可以用高阶函数来做”。 Matthias Benkard 说：“宏的缺乏在一定程度上可以通过更复杂的……诸如单子和箭头之类的概念来缓解。”其他评论也呼应了同一主题。您提到 MDSD 的原则之一是生成器。宏是编译时生成器。因此，我将他们的陈述翻译为 MDSD 在函数式语言中本质上很容易的论点。
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.
制作DSL（领域特定语言）（FP）和创建一大堆领域对象（OOP）（对象内部包含业务逻辑）之间存在重大区别。
FP 可能会遇到与过程语言相同的问题（和优点）：行为和数据的分离。 OOP 语言不鼓励这样做。这种分离称为贫血域模型。
这种“分离”可能会使更改数据变得非常困难（如果使用 DSL，情况可能会更糟）请参阅我的帖子：处理函数式编程中的增量数据建模更改
然而，另一方面，更改行为和全面实现无状态事物对于 OOP 域驱动设计来说却是令人头疼的事情。然而，对于AOP ITD和元编程之类的东西来说，这不再是一个问题。
Scala 和 Ruby 是两种技术混合的很好的例子。
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.