设计/构建大型功能程序的好方法是什么,特别是在Haskell中？
我已经阅读了很多教程(自己写一个方案是我最喜欢的,真实世界Haskell紧随其后) - 但大多数程序都相对较小,而且是单一目的.另外,我不认为它们中的一些特别优雅(例如,WYAS中的大量查找表).
我现在想要编写更大的程序,包含更多移动部件 - 从各种不同来源获取数据,清理数据,以各种方式处理数据,在用户界面中显示,持久化,通过网络进行通信等.一个最好的结构,这样的代码是易读,可维护,适应不断变化的要求？
有大量文献针对大型面向对象的命令式程序解决这些问题.像MVC,设计模式等的想法是实现广泛目标的理想规定,例如在OO风格中分离关注点和可重用性.此外,较新的命令式语言适合于"随着您的成长而设计"的重构风格,在我的新手看来,Haskell似乎不太适合.
Haskell有相同的文献吗？如何在功能性编程(单子,箭头,应用等)中使用异域控制结构的动物园最好地用于此目的？你能推荐什么最佳实践？
谢谢!
编辑(这是Don Stewart回答的后续行动):
@dons提到:"Monads在类型中捕获关键的建筑设计."
我想我的问题是:如何在纯函数式语言中考虑关键的架构设计？
考虑几个数据流的示例和几个处理步骤.我可以将数据流的模块化解析器编写为一组数据结构,我可以将每个处理步骤实现为纯函数.一个数据所需的处理步骤将取决于其值和其他数据.一些步骤之后应该是GUI更新或数据库查询等副作用.
什么是以正确方式绑定数据和解析步骤的"正确"方法？人们可以编写一个大功能,为各种数据类型做正确的事情.或者可以使用monad来跟踪到目前为止已处理的内容,并让每个处理步骤从monad状态获得接下来需要的任何内容.或者可以写很多单独的程序并发送消息(我不太喜欢这个选项).
他链接的幻灯片有一个我们需要的东西子弹:"将设计映射到类型/函数/类/ monad上的成语".什么是成语？:)
我一次又一次地听到,我正在努力理解并验证FP和OO是正交的想法.
首先,2个概念的正交意味着什么？
FP尽可能地鼓励不变性和纯度,而OO似乎是为状态和变异而构建的 - 一个有点组织的命令式编程版本？我意识到对象可以是不可变的,但OO似乎意味着状态/改变我.
它们看起来像是对立的.这对他们的正交性有何影响？
像Scala这样的语言可以很容易地执行OO和FP,这是否会影响这两种方法的正交性？
oop paradigms programming-languages functional-programming scala