纯函数式编程的缺点
本文总结了函数式编程的几大缺点，其中主要焦点是可变性状态Mutation是否应该是默认，union-find算法的Dr. Harrop说：目前我们还没有发现一个有效率的纯函数的union-find集合。也就是说：对于有状态的操作命令式操作会比声明式操作更有效率。
纯函数编程的缺点有：
1.没有纯粹的函数式的非排序的字典或集合Set
自从上世纪90年代字典在软件中应用以来已经到达高峰，字典是一个每个程序员都能在标准库中常用的集合。
纯函数或持久数据结构，比如那些在Okasaki’s fabulous monograph被发现的事物都能成为伟大的工具，他们提供了在不用担心可变状态Mutation的情况下，能重用旧集合版本实现的持久化功能，在大多数情况下(特别是逻辑编程和编译程序)。它们会使得解决方案更简洁和清晰。 部分原因是它使得回溯变得平常，然而，持久成为性能方面的一个很大成本，也就是持久化性能很差: 纯函数字典通常比一个正常的哈希表慢10倍以上，也曾经发现慢过40倍。
此外，大多数函数式编程语言（OCaml，Haskell、Scala）都不能表达一个快速的通用可变的哈希表，因为他们缺乏杀手锏：具体化的泛型、值类型和快速GC写屏障（write barrier）。
当心，有人试图声称，Haskell的纯函数字典比Haskell的可变的哈希表更快。正确的结论是Haskell的可变哈希表相比其他语言的实现是缓慢的，所以，显得纯函数字典比较快。
2. 没有纯函数式弱哈希表
使用垃圾回收机制收集命令式语言，一个图的顶点与边之间的关系可以使用弱哈希表表达，垃圾回收机制会替你收集其子图。而因为在纯函数编程中，没有纯函数弱哈希表，所以，你必须自己编写垃圾回收机制。
请注意，大多数开发人员从来没有用过弱哈希表，因此让他们编写自己的垃圾回收机制是多大的一个问题。
3. 没有纯函数的并发集合
根据定义，不可变集合不能支持并发可变状态操作，因此，如果你想共享一个可变状态的集合，比如内存数据库等，在这点上，没有有效的纯函数式解决方案可替换。
4.大多数图算法看起来很差，当以FP风格编写时更慢。
纯函数式编程是解决某些问题的伟大工具，但是对于图算法这点，纯函数解决方案在速度和清晰都方面都很差。
比较Prim’s algorithm in 12 lines of Python和Prim’s algorithm in 20 lines of Haskell. 为什么Haskell使用Prim的算法? 可能因为Kruskal的算法是基于union-find集合建立，而目前还没有发现有效率的纯函数的union-find 集合.
5. 传统命令式数据结构和算法的惯性是巨大的
除了图算法，计算机科学65年发表的文献几乎完全集中在命令式的解决方案，因此命令式程序员会很容易站在巨人肩膀上，而纯函数程序员只能从零开始，记得几年前，Haskell还是博士论文题目。
几个haskell程序员编写了通用的并行快速排序Haskell程序，点击这里看看发生了什么
6. 所有函数式编程的实现，包括纯与不纯的，都会产生太多的分配设计。
1960左右，麦卡锡发明了Lisp。核心数据是结构链表。每一个列表节点是一个独立的堆分配的块。所有现代的函数性语言都是由此演变而来。在上世纪70年代Schema作为Lisp相同的数据表示策略。在上世纪80年代，SML增加了unboxing with tuple，堆分配作为一个单一的内存块。在上世纪90年代，OCaml稍微加了点unboxing的浮点数组。Haskell增加了一些unboxing数据的能力。
但到目前为止，没有任何函数编程语言默认使用unboxing tuple。即使F#，基于.NET提供任意的值类型，仍然使用.NET的boxed tuple。因此，所有的现代的函数性编程语言产生很高的分配率(allocation rate)基本上没有很好的理由。因此，他们对垃圾收集器产生的压力远远超过普通必要的压力水平。这是一个严重的问题，不只是因为它使串行代码变慢，而且因为垃圾收集器是一个共享的资源，因此，对GC施加了过多压力会阻碍并行程序的可扩展性。
命令式集合通常更快的，函数式语言想在性能上超过命令式集合的性能很难，前者变成后者的天花板。
7. 纯函数式编程在理论上并行概念很好，但是实践中性能不行，而性能是使用并行的唯一目的。
今天编写并行程序有两个目的：首先实现客观上更有效率的目的，其次使得本来很慢的方案变得不那么慢，大多数情况下，函数式编程中的并行属于后者。在高性能计算领域几乎没有人直接运行函数式代码，当大多数函数程序员使用并行编程并不是为了获得最快的性能，而是为了能在原有性能基础上有所提升。
像Haskell纯函数式语言被设计成空间和时间的概念，这能让你从更高层次和视角看待你的问题，但是也产生大量内存消耗和需要很长时间获得结果。
注意：人们只谈论可扩展性而否定绝对性能， 其实绝对性能和可扩展性都很重要。
8. 函数式编程很难解决实际问题( It took 50 years for normal people to dilute the smug weenies to the point where you can get a useful answer about functional programming on social media.)
我在函数式编程领域有20年，几十年来，函数式程序员和解决实际问题之间存在鸿沟，感谢这些问题因为Scala, Clojure 和 F# 等出现了改善，但是确实多年来存在蠢货主导了函数式编程领域的场景，使得人们使用它很难来解决实际问题，比如一些LISP社区一直在解释Lisp一些参数为什么是好的，但是经过很多年我才发现这些参数是错误的。
9. 大量有关函数式编程的误传。
如果你批评Haskell的哈希表性能，你会得到错误的指导，比如有人建议你关闭垃圾回收。
多年来，函数式编程社区炫耀它们简短的筛选法和快速排序算法的实现，其实他们并没有真正落地执行这些算法。
为什么Haskell在业界很少使用彻底揭露了Haskell的行业真相。