分享到:文章主题: 什么是函数式编程,为啥不要面向对象
chinaover楼主
chinaover
身份
新人
文章
995
星座
未知
积分
742
等级
灌木(4)

发信人: chinaover (chinaover), 信区: Programming
标  题: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 13:22:09 2018), 站内
  
  
--
  
※ 来源:·水木社区 //m.www.hrnr.net·[FROM: 49.95.180.*]
  

返回顶部
blitz第1楼
blitz
身份
核心驻版
文章
3802
星座
双鱼座
积分
46744
等级
楠木(12)

360彩票双色球走势图表 www.hrnr.net 发信人: blitz (blitz), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 14:24:38 2018), 站内
  
functional是一个很大的筐(OO的筐也不?。?,名以上叫函数式风格的代码可以差别很大。
  
我觉得有如下几个特点的可以装进这个筐里面:
1. 函数可以作为变量传递和返回
2. 函数可以动态组装(例如根据传入的参数,构造新的函数,并返回)
3. 强调immutability,变量默认不可变(Rust),甚至强制不可变(Haskell)
4. 更强调数据的映射,函数式编程更像是在用逻辑IC搭电路,而不是过程,强调空间上的组合,而不是按照时间来组织步骤。
  
此外,还有一个我认为和函数式正交,但是紧密联系的概念就是类型系统
我不知道为什么,好像强调类型系统的语言大部分都同时强调函数式。类型系统也是一个很好用的东西。如果一种语言拥有丰富的类型系统特征,往往写起来比较轻松(哄编译器总比调试segfault容易)。
  
我主观上感觉, Functional更具有数学上的美感,具有内在的一致性。Functional和OO并不是同一个范畴的概念,一个语言可以既OO又Functional (e.g., scala),或者既不OO,也不Functional (汇编,C,C当然可以操作函数指针,但是我觉得这个和Functional差了很远)
  
【 在 chinaover 的大作中提到: 】
  
--
  
※ 来源:·水木社区 //www.hrnr.net·[FROM: 159.226.171.*]

返回顶部
a0123456789q第2楼
a0123456789q
身份
用户
文章
1484
星座
未知
积分
9682
等级
白杨(6)

发信人: a0123456789q (a0123456789q), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 14:37:34 2018), 站内
  
同意。
  
functional 和 object可以并行不悖。
  
另外补充一点:
  
oo其实比functional 高级。
  
oo可以包含funcional,并包含一些扩展。反之不然。
  
  
  
【 在 blitz (blitz) 的大作中提到: 】
: functional是一个很大的筐(OO的筐也不?。?,名以上叫函数式风格的代码可以差别很大。
: 我觉得有如下几个特点的可以装进这个筐里面:
: 1. 函数可以作为变量传递和返回
: ...................
  
--
  
※ 来源:·水木社区 //www.hrnr.net·[FROM: 183.95.135.*]

返回顶部
eGust第3楼
十年
身份
版主
文章
24792
星座
狮子座
积分
88743
等级
椽桷(13)

发信人: eGust (十年), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 16:14:58 2018), 站内
  
oo 高级……纯粹是工程师自发设计的野路子,之前是把数据组合到一起就有了 struct,再把函数指针组合到一起于是就有了 class。由于完全没有理论性的东西在里面,导致发明了无数混乱不堪的概念,实际当中更由于不同语言的不同设计导致用法也各不相同。这种自然生长的语言特性跟真实的项目工程非常像,每遇到一个坑,就搞出来一堆东西去把坑填上,于是填的过程中又挖了许多新坑出来。
  
到了 fp 事情就非常简单了,什么可不可重入、线程安全,传统语言里的问题全都变成了伪问题,唯一存在的问题就是怎么处理 side effect。所以到了这个世纪,不管是语言还是框架都在学 fp,这个10年的进步可比90年代的 oo 十年进步大太多了。
  
别误会,我的工作语言是 ruby,能正经用的语言里没有更 oo 的了。另外 ruby 虽然支持极其强大的 meta-programming,但却由于缺少函数类型而跟 fp 绝缘。
  
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 同意。
: functional 和 object可以并行不悖。
: 另外补充一点:
: ...................
  
--
  
※ 修改:·eGust 于 Dec  1 19:10:22 2018 修改本文·[FROM: 122.58.214.*]
※ 来源:·水木社区 www.hrnr.net·[FROM: 122.58.214.*]

返回顶部
a0123456789q第4楼
a0123456789q
身份
用户
文章
1484
星座
未知
积分
9682
等级
白杨(6)

发信人: a0123456789q (a0123456789q), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 17:16:01 2018), 站内
  
你也提到了side effect。这就是oo能搞而fp不能搞的啊。
fp的东西oo全能搞,无非就是个没有状态的object而已。
  
  
  
【 在 eGust (十年) 的大作中提到: 】
: oo 高级……纯粹是工程师自发设计的野路子,之前是把数据组合到一起就有了 struct,再把函数指针组合到一起于是就有了 class。由于完全没有理论性的东西在里面,导致发明了无数混乱不堪的概念,实际当中更由于不同语言的不同设计导致用法也各不相同。这种自然生长的语言特性跟真实的项目工程非常像,每遇到一个坑,就搞出来一堆东西去把坑填上,于是填的过程中又挖了许多新坑出来。
: 到了 fp 事情就非常简单了,什么可不可重入、线程安全,传统语言里的问题全都变成了伪问题,唯一存在的问题就是怎么处理 side effect。所以到了这个世纪,不管是语言还是框架都在学 fp,这个10年的进步可比90年代的 oo 十年进步大太多了。
: 别误会,我的工作语言是 ruby,能正经用的语言里没有更 oo 的了。另外 ruby 虽然支持极其强大的 meta-programming,但却由于缺少函数类型而跟 oo 绝缘。
  
--
  
※ 来源:·水木社区 //www.hrnr.net·[FROM: 183.95.135.*]

返回顶部
eGust第5楼
十年
身份
版主
文章
24792
星座
狮子座
积分
88743
等级
椽桷(13)

发信人: eGust (十年), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 18:28:52 2018), 站内
  
fp 也没不能搞啊,event-driven 就好了啊。只不过是 fp 本身不支持 side effect,所以没有一个正统的解决方案,目前还是百花齐放的状态。
  
比如 react 最流行的状态管理 redux,前几年还是 redux-thunk,属于工程上摸着石头过河的项目。这两年 redux-saga 流行起来了,其背后的理念是一篇1987年的论文。跟 fp 一样,结果都是学院派出身比野狐禅好用,只是我不确定过两年会不会有别的出现不敢把话说太满而已。
  
现在的 fp 也都不是只能递归不能循环的“正统”了,比如 js 搞出个最后只剩 jsc 支持的尾递归 specification(注意是正式标准,“正确”的 es6 尾递归是不能爆栈的)。所以更多说的也是一种风格而已:避免使用 mutable 变量,尽量写纯函数,枚举时生成新的 array/list、dict/object/hash 而不是直接修改,尽量写简单易懂的小函数再 compose/flow 成复杂的,提供 curry 版的库函数……fp 更多还是思维习惯上的转变,从操作变量到数据映射,从无数个入口点到单向数据传输。oo 你都不知道用了一个方法之后这个对象的成员变了没有,本质上跟 fp 就是矛盾的。
  
最后,没什么东西是汇编做不了的,这话听起来耳熟不?
  
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 你也提到了side effect。这就是oo能搞而fp不能搞的啊。
: fp的东西oo全能搞,无非就是个没有状态的object而已。
  
  
--
  
※ 来源:·水木社区 www.hrnr.net·[FROM: 122.58.214.*]

返回顶部
a0123456789q第6楼
a0123456789q
身份
用户
文章
1484
星座
未知
积分
9682
等级
白杨(6)

发信人: a0123456789q (a0123456789q), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 18:32:21 2018), 站内
  
object=function + data
  
【 在 eGust (十年) 的大作中提到: 】
: fp 也没不能搞啊,event-driven 就好了啊。只不过是 fp 本身不支持 side effect,所以没有一个正统的解决方案,目前还是百花齐放的状态。
: 比如 react 最流行的状态管理 redux,前几年还是 redux-thunk,属于工程上摸着石头过河的项目。这两年 redux-saga 流行起来了,其背后的理念是一篇1987年的论文。跟 fp 一样,结果都是学院派出身比野狐禅好用,只是我不确定过两年会不会有别的出现不敢把话说太满而已。
: 现在的 fp 也都不是只能递归不能循环的“正统”了,比如 js 搞出个最后只剩 jsc 支持的尾递归 specification(注意是正式标准,“正确”的 es6 尾递归是不能爆栈的)。所以更多说的也是一种风格而已:避免使用 mutable 变量,尽量写纯函数,枚举时生成新的 array/list、dict/object/hash 而不是直接修改,尽量写简单易懂的小函数再 compose/flow 成复杂的,提供 curry 版的库函数……fp 更多还是思维习惯上的转变,从操作变量到数据映射,从无数个入口点到单向数据传输。oo 你都不知道用了一个方法之后这个对象的成员变了没有,本质上跟 : ...................
  
--
  
※ 来源:·水木社区 //www.hrnr.net·[FROM: 183.95.135.*]

返回顶部
iRoNcOoL第7楼
人在胖 天在看
身份
用户
文章
4865
星座
双鱼座
积分
87823
等级
椽桷(13)

发信人: iRoNcOoL (人在胖 天在看), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 18:45:04 2018), 站内
  
然而你这个没有状态的 object 没有什么大用, 做不了什么事
  
看看 clojure 的 persistent data structure 实现的 immutable,  
不能修改一个数据结构, 如果修改, 其实是生成了新的数据. 有人
可能觉得这不过就是 COW, 然而并不是. 它内部实现为树, 只需要
新建少量数据, 原先的未被修改部分可以安全的被共享. 所以性能
也很好.
  
所以, 有 persistent data structure 的支持,很容易写没有副作
用的函数, 性能也不错
  
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: 你也提到了side effect。这就是oo能搞而fp不能搞的啊。
: fp的东西oo全能搞,无非就是个没有状态的object而已。
  
  
--
  
※ 来源:·水木社区 www.hrnr.net·[FROM: 111.220.83.*]

返回顶部
eGust第8楼
十年
身份
版主
文章
24792
星座
狮子座
积分
88743
等级
椽桷(13)

发信人: eGust (十年), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 18:55:39 2018), 站内
  
冯诺依曼体系 ram 放的不是 function 就是 data,你是想说啥?
  
【 在 a0123456789q (a0123456789q) 的大作中提到: 】
: object=function + data
  
  
--
  
※ 来源:·水木社区 www.hrnr.net·[FROM: 122.58.214.*]

返回顶部
a0123456789q第9楼
a0123456789q
身份
用户
文章
1484
星座
未知
积分
9682
等级
白杨(6)

发信人: a0123456789q (a0123456789q), 信区: Programming
标  题: Re: 什么是函数式编程,为啥不要面向对象
发信站: 水木社区 (Sat Dec  1 19:20:45 2018), 站内
  
obj > func
【 在 eGust (十年) 的大作中提到: 】
: 冯诺依曼体系 ram 放的不是 function 就是 data,你是想说啥?
  
--
  
※ 来源:·水木社区 //www.hrnr.net·[FROM: 183.95.135.*]

返回顶部