functional programming why? (转载)# Java - 爪哇娇娃
c*o
1 楼
【 以下文字转载自 Programming 讨论区 】
发信人: coltzhao (coltzhao), 信区: Programming
标 题: functional programming why?
发信站: BBS 未名空间站 (Fri Nov 1 14:53:02 2013, 美东)
编了一段FP的code了，来说说我的理解。
FP其实不是编程方式的不同，是实现你想法到working code的方法不同。
大家说起FP，一般都先想到function first.没错，但是FP还有很多很重要但是不为人
了解的侧重点。
1. immutability (不变性），这个很多人说不实用，没错，在某些意义上是不适用。
但是对于非IO瓶颈的项目，你总能把你最看重的那部分分离出来做纯FP,immutable.其
他的继续imperative.其实实际编程时考究的主要是建模／抽象／算法，把它变成
parallellable,其他都容易，FP就是让它容易的工具。让你能多想建模／抽象／算法。
2. lazy evaluation,这个其实也是各种FP强调的一点。也很好，和 immutability 在
一起，能大大简化模型／算法，
2.1 不会有多余的不需要的计算,只有用到的时候才算，而且immutability可以缓存。
2.2 因为只有用到的时候才算，你可以构造无限大小的数据结构。
2.3 很新奇的就是，你还可以用lazy evaluation来构造control structure/flow因
为在构造的时候你并不执行。
这个之所以是FP feature，因为只有在no side effect的pure环境下才最好，不然后有
各种问题 （nondeterministic execution order/space leak)。
3. composability, 其实这才是FP的精髓， 软件工程么，就是用小软件搭大软件。能
把大的问题转成多个小的问题。
OO是把大问题转成多种object互动的关系，FP是把大问题转换成一个抽象的algebra
： 一个／多个type，和在这些类型上定义的函数。
你可以看到，上面两个方法并不矛盾 （把object换成type,互动换成函数）。
OO之所以有那么多design pattern，就是为了支持object 互动
FP之所以有那么多抽象结构（functor/applicative/monad/moinoid etc.)就是为了
能够支持函数之间的转换和合并
多个小对象组成大系统，多个小函数组成大系统
在不同的领域， FP/OO各有所长，很多OO pattern在FP 里根本没必要，反之也是
FP对并发，以及复杂抽象性问题上有优势。但是很多时候不适用与side effect有关的
东西。
学会两个其实是很好的一种职业发展
发信人: coltzhao (coltzhao), 信区: Programming
标 题: functional programming why?
发信站: BBS 未名空间站 (Fri Nov 1 14:53:02 2013, 美东)
编了一段FP的code了，来说说我的理解。
FP其实不是编程方式的不同，是实现你想法到working code的方法不同。
大家说起FP，一般都先想到function first.没错，但是FP还有很多很重要但是不为人
了解的侧重点。
1. immutability (不变性），这个很多人说不实用，没错，在某些意义上是不适用。
但是对于非IO瓶颈的项目，你总能把你最看重的那部分分离出来做纯FP,immutable.其
他的继续imperative.其实实际编程时考究的主要是建模／抽象／算法，把它变成
parallellable,其他都容易，FP就是让它容易的工具。让你能多想建模／抽象／算法。
2. lazy evaluation,这个其实也是各种FP强调的一点。也很好，和 immutability 在
一起，能大大简化模型／算法，
2.1 不会有多余的不需要的计算,只有用到的时候才算，而且immutability可以缓存。
2.2 因为只有用到的时候才算，你可以构造无限大小的数据结构。
2.3 很新奇的就是，你还可以用lazy evaluation来构造control structure/flow因
为在构造的时候你并不执行。
这个之所以是FP feature，因为只有在no side effect的pure环境下才最好，不然后有
各种问题 （nondeterministic execution order/space leak)。
3. composability, 其实这才是FP的精髓， 软件工程么，就是用小软件搭大软件。能
把大的问题转成多个小的问题。
OO是把大问题转成多种object互动的关系，FP是把大问题转换成一个抽象的algebra
： 一个／多个type，和在这些类型上定义的函数。
你可以看到，上面两个方法并不矛盾 （把object换成type,互动换成函数）。
OO之所以有那么多design pattern，就是为了支持object 互动
FP之所以有那么多抽象结构（functor/applicative/monad/moinoid etc.)就是为了
能够支持函数之间的转换和合并
多个小对象组成大系统，多个小函数组成大系统
在不同的领域， FP/OO各有所长，很多OO pattern在FP 里根本没必要，反之也是
FP对并发，以及复杂抽象性问题上有优势。但是很多时候不适用与side effect有关的
东西。
学会两个其实是很好的一种职业发展
