问函数式编程的陷阱/缺点

EN

我很难想到函数式编程的许多缺点。话又说回来，我是函数式编程国际会议的前主席，所以你可以放心地认为我有偏见。

我认为主要的缺点与孤立和进入壁垒有关。学习编写好的函数式程序意味着要学会以不同的方式思考，而要做好这件事需要投入大量的时间和精力。没有老师是很难学习的。这些属性会导致一些缺点：

• 新来的人写的函数式程序可能会不必要地慢--比方说，比C新手写的C程序更有可能。另一方面，新来的人写的C++程序也可能不必要地慢。(所有这些闪亮的功能...)

一般来说，专家编写快速的函数式程序没有困难；事实上，现在在8核和16核处理器上性能最好的一些并行程序都是用Haskell.

• It's编写的，与开始使用Python或Visual Basic的人相比，开始使用函数式编程的人更有可能在实现承诺的生产率提高之前放弃。只是在书籍和开发工具方面没有那么多的支持。

• 可以交谈的人更少了。Stackoverflow就是一个很好的例子；相对较少的Haskell程序员定期访问该站点(尽管部分原因是Haskell程序员有自己的活跃论坛，这些论坛比Stackoverflow更古老、更成熟)。

你不能很容易地与你的邻居交谈，这也是事实，因为函数式编程概念比Smalltalk、Ruby和C++等语言背后的面向对象概念更难教授和学习。而且，面向对象的社区已经花了几年的时间为他们所做的事情开发了很好的解释，而函数式编程社区似乎认为他们的东西显然很棒，不需要任何特殊的隐喻或词汇来解释。(他们错了。我仍然在等待第一本伟大的书“功能设计模式”( functional Design Pattern)。

• 惰性函数式编程(适用于Haskell或Clean，但不适用于ML、Scheme或Clojure)的一个众所周知的缺点是，很难预测评估 lazy 函数式程序的时间和空间成本-even专家无法做到这一点。这个问题是范式的基础，并且不会消失。有很多优秀的工具可以用来发现事后的时间和空间行为，但要有效地使用它们，你必须已经是专家了。

函数式编程的一大缺点是，从理论上讲，它与硬件和大多数命令式语言都不匹配。(这是其明显优势之一的另一面，能够表达您想要做的事情，而不是您希望计算机如何做。)

例如，函数式编程大量使用递归。这在纯lambda演算中很好，因为数学的“堆栈”是无限的。当然，在真实的硬件上，堆栈是非常有限的。在大型数据集上天真地递归可能会使您的程序变得繁荣。大多数函数式语言都会优化尾递归以避免这种情况发生，但是让算法尾递归可能会迫使你做一些相当不美观的代码体操(例如，尾递归映射函数创建一个向后列表或必须构建一个差异列表，所以它必须做额外的工作才能以正确的顺序返回到正常的映射列表，而不是非尾递归版本)。

(感谢Jared Updike的差异列表建议。)

如果你的语言没有提供良好的机制来通过你的程序检测状态/异常行为(例如，一元绑定的语法糖)，那么任何涉及状态/异常的任务都会成为一件苦差事。(即使有了这些糖，有些人可能会发现更难处理FP中的状态/异常。)

函数式习惯用法通常会造成大量的控制反转或懒惰，这通常会对调试(使用调试器)产生负面影响。(由于不可变性/引用透明性，FP不太容易出错，这在一定程度上抵消了这一点，这意味着您将不需要经常调试。)