函数式编程functional programming的特点

                   
banq
09-12-09 12 2777 4

以Erlang为代表的面向功能语言functional programming(FP)越来越热门,虽然本身有比较难学等缺点,
Where functional programming fits in一文总结总结了FP适合哪些场合?

Java平台的Scala,.NET的F#都是FP语言,而Ruby因为包含一些FP特点受到欢迎。
FP特点:
1.FP代码没有边界影响“side effects.”(目的明确,是一就是一,不会因为捣蛋鬼调用导致其他功能实现)
2.没有literal值, 简单的功能只是返回相同值。
3.许多FP语言有“lazy evaluation,”(类似懒加载机制),功能并不真正运行,直到他们被调用,比如你定义x = y +5,只有当x被使用时,才真正计算y+5,这个带来更好的性能boon和curse (有时不确定值),(注:这个和我们之前讨论的异步Domain Events好像类似,模型的值只有即时使用才访问数据库获得,我们也是为了获得更好地性能,见Domain Events异步应用)

FP语言的这些特性代表了思想的根本转变,但是使用FP语言,必须考虑是不是存在过度工程或overthinking的问题,因为这代码的其他维护者需要学习一个新的语言。

作者认为FP语言使用在算法应用领域比较好,在Xbox Live排名系统中,用F#替代C#重写,只用了10% 的代码量,节约了近90%的代码。

如果你使用现代主流的胶水库library glue code之类应用,如果你的代码是由一个个类组成的结构,而算法只是被融合在这些类之中,就没有必要使用FP语言。

[该贴被admin于2009-12-09 14:24修改过]

4
weidagang2046
2009-12-09 13:12

functional programming -> 函数式编程,其根源是数学中的lambda演算
side effect -> 副作用,OO中接近的概念是不改变对象状态的方法调用
lazy evaluation -> f(x + y),如果f内部根本未用到这个参数,x+y不会被计算,您举的例子也是对的
[该贴被weidagang2046于2009-12-09 13:14修改过]

banq
2009-12-09 14:02

2009年12月09日 13:12 "weidagang2046"的内容
functional programming -> 函数式编程,其根源是数学中的lambda演算
side effect -> 副作用,OO中接近的概念是不改变对象状态的方法调用


多谢,看来应该翻译成面向函数式编程,side effect翻译成副作用更贴切。

weidagang2046
2009-12-09 15:04

推荐一篇FP的文章,里面对FP的优势做了很好的介绍。在OO语言中也可以借鉴一些FP的风格改进设计。http://www.cnblogs.com/erain/archive/2008/12/14/1354810.html

banq
2009-12-09 15:55

2009年12月09日 15:04 "weidagang2046"的内容
推荐一篇FP的文章,里面对FP的优势做了很好的介绍。在OO语言中也可以借鉴一些FP的风格改进设计。http://www.cnblogs.com/erain/archive/2008/12/14/1354810.html


彻底受教了,不过对这篇文章有不敢苟同之处:
之前一段试图将数学哲学化很让我反感,这是典型的泛数学主义思想,数学之外还有一个艺术,不是所有事物都可以量化数学化,如果可以,如今就不存在那么多未知领域和疑惑,也不能认为混沌结构思维毫无用处,中国人靠中医活下来了,活得不差。这是灌水,不多说。

用currying说明设计模式就不需要使用,这也只是一厢情愿(GoF设计模式三作者15年后再谈模式),算法数学占据主要地位大概只有特定算法科学领域,现实的胶水模块领域,还必须注重架构和模式,在DDD中有一段对算法观点:

1.算法或计算非常复杂,导致设计受到了冲击,模型中的概念变成了用“怎么做”来解释,而不是用“是什么”表达。(主次颠倒)

2. 算法本身存在内聚性(因为它能用公式表达,公式就是算法具有内内聚性的特征),使用策略模式等框架把这些内聚计算分离出来,用一个明确接口来说明这个框架的功能,将怎么做复杂细节交给框架(主要管算法的API)去完成。

3.我们计算方法不可能把所有功能都包含进来,我们需要的也不是一种万能计算机制。(批评那种算法万能观点,没有一个算法能够把万事万物功能算进来,如果是,就成了周易算命了)。

在DDD中将副作用也就是边界影响归纳为柔性设计,所谓柔性实际就是艺术性的事情,这是架构的目标,DDD认为柔性设计为:
1.明显意图的接口:面向接口编程,做什么目的在接口中清晰表达,而无需翻看具体代码。

2.边界影响: 消除边界影响,不要搞一机多能。

3.粒度适当界定 粒度不能太大,造成重复和冗余,很多概念混在一起;当然粒度也不能太细,以至于太碎,不能完整表达一个领域概念。高聚合、低关联。

4.消灭依赖 每复杂的依赖关系无疑提高了系统的复杂性,每个依赖都是值得怀疑的。

5.操作封闭 服务行为操作的是同一个类型,不要一次性处理多个模型。

6.声明性设计,尽量使用成熟框架,保证质量。 如DSL

可是这些这篇文章中用轻飘飘一句:“因为 lambda 演算不是被设计为在物理局限下工作的。因此,象面向对象的编程一样,函数式编程是一系列理念,而不是严格的教条,”这其实就是柔性艺术性的特征,由于作者背景知识原因没有认识到罢了。

所以,函数式编程和OO不矛盾,而且是在OO世界中属于一个“怎么做”的问题,而OO方法论如DDD是解决把“是什么”和“怎么做”如何分开。

说得详细一点:“是什么”就是需求是什么,先要把需求说清楚,功能要求说清楚;“怎么做”是如何实现问题,通过软件技术架构或算法等等科学来实现。

btw:由于我们都是在学“怎么做”中长大的,忘记“是什么”这个主要目标,就容易造成井底观蛙,舍本求末,南辕北辙,这实际是为什么当前科学总是不能转化为生产力的原因之一。

以上只是个人想法。
[该贴被banq于2009-12-09 16:29修改过]

3Go 1 2 3 下一页