发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

纯函数式编程的缺点

         
2016-06-08 10:43
赞助商链接

本文总结了函数式编程的几大缺点,其中主要焦点是可变性状态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 PythonPrim’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的行业真相。

原文:
The Flying Frog Blog: Disadvantages of purely func

函数式编程      Haskell     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com