什么是函数式编程思维
函数式编程
FP(Functional Programming) ,就像《骇客帝国》尼欧吃的红色小药丸,你一旦吃了就永远回不去了。
函数作为一等公民和
closure capture
好处大家都知道, 传统语言都在想方设法集成这些特性. map, filter, reduce 等等东西写代码处理集合真是非常舒爽, 一眼就能看懂干什么, 又不用担心循环中的边界条件
.函数式语言中的另一个利器是
pattern match
, 很多费脑子的复杂操作一下就搞定了... 为什么Thinking in Java
这么大这么厚一本书, 学完了你基本干不了啥事情? 因为在Java
的思维世界里, 你要和概念的海洋作斗争, 而命名恰恰就是编程的两大难题之一. 如果有pattern match
, 哪用想这么多没意义的中间变量名?什么是
immutability
? 其实细分起来有语法上的immutable
(例如 Java 里的final
关键字), 和运行时对象的immutable
(一个变量名可以修改指向不同对象, 但对象的内容不可变). 两者的联系是: 如果语法上规定所有变量都是 "final
" 的, 那么运行时对象就相当于都immutable
了. 但如果语法上部分变量是final
, 部分不是, 那么就不能得出运行时对象全都immutable
的结论.
而在运行时对象都是 immutable
的情形下, 很多优势才会显现出来.
"immutability 会拖慢程序"
略扯淡, 应用了 immutability
的 VM 实现可以去掉很多情况的 lock
, 并发处理速度会更快.
就算不是并发处理的情况, 如果所有对象都 immutable
, 手动的保护性拷贝都可以去掉, 处理复杂业务会更简单快速.
其实编译器可以把很多 immutable
的操作改写成 mutable
的操作, RAM
能不能擦写没什么影响的. LLVM
中间语言就是个变量名 immutable
的语言, 但是编译出来的代码效率很高 --- 编译器就是这么贱, 你明明为了提高性能重复利用同一个变量, 但是它却偏偏要先把你写的单个变量改成多个变量单次赋值再去做优化...
对象实例 immutable
了 GC 能更简化. 因为只有新对象指向老对象, 老对象不能指向新对象, 对实现分代 GC
的人来说真是一个天堂! Haskell 和 Erlang 的分代 GC 实现都不复杂而且效率很高 (但 Clojure 因为是 JVM 上的二奶语言享受不到这个优惠, Scala 不是所有对象都 immutable
, 只能起用接口限制程序员的效果了...)
在 immutable
的环境里还有什么好处? 就是没有环引用! 不用做环检测不用加弱引用, 那引用计数还不爽翻了? 是的... 有人用引用计数实现 Erlang
的, 写得非常爽... 所有变量 immutable
, 就用引用计数做内存管理, 当引用数为 1
的时候还能做destructive update, 节省一次内存分配释放, 也不损害 immutable
的语义。
immutable
的环境还能轻易实现 debug step back. 至今大部分语言和环境的 debugger 都没有后退功能, 而后退功能的实现难点主要是要保存对象变化的历史记录, mutable 的对象系统就得复制或者深复制对象才能恢复历史. 而 immutable 的环境里, 只要保留之前的对象的引用, 就能直接恢复.
immutability
至今表现还不太好的地方是哈希表
, 例如 Haskell
的哈希表实现就一片混乱... 如果要实现一个高效的 immutable
并且保持插入顺序的哈希表... 你会比较蛋疼. 现在做得比较好的是 HAMT
或者 RRB tree
, 但也没有 mutable
的哈希表快.
函数式语言
的执行效率不高,这个如果从单个线程的观点来说是对的。但是同时函数式编程没有副作用,因此很容易并行化,在多核的CPU上优势就比较明显了。
immutable 会造成代码比较难写吗?
事实上就是思维方式要改变, 用更高阶的操作就好了, 然后你会发现经常变得更好写了. 而且 state monad + do notation
可以让你退回去用 mutable
的思维方式想问题, 而且, 这个 state
是严格控制在 local
的不会搅乱你其他部分的程序.
如果所有对象都 immutable
, 那程序根本就没有传值和传引用的区别了, 学习起来更简单, 语义更一致 (但一心要当大杂烩的 Scala 反而变得很复杂...)
其他
组件和对象会不会比 immutable 更适合 GUI 编程? 现状是 functional language 在 GUI 库上面还不够成熟, 但应用
functional
概念架构的GUI
反而速度更快更稳定, 在 web 前端框架上面已经逐渐体现了, 例如 swannodette/om · GitHub 和 Raynos/mercury · GitHub. 用 Om 实现一个历史后退的功能真的清爽容易到了极点.函数式语言中常用的 list 也受限于当前的 CPU 架构体系, locality 没有 array 好, 不过很多 list 中使用的
idiom
也可以直接应用到 array 上, 问题不大。某些
面向对象
的方法论使用大量的隐喻
, 使得不懂的人都可以以为自己懂了, 也许才是其最重要的优势吧.