Redian新闻
>
我对为什么使用FP的理解 (补)
avatar
我对为什么使用FP的理解 (补)# Programming - 葵花宝典
i*r
1
dream职位,已经一个多月了,没有消息。特求在slb工作的朋友帮忙内推,非常感谢!
avatar
H*y
2
外出几天。因为一些原因,小猫自己留在家里不方便。小猫极不喜欢关笼子,所以尽量
不送去宠物医院寄存。
6个月大,爱打滚。
不挑食,不挑猫沙。
可以提供所需物品,也可付些钱。
谢谢 :-)
如果有兴趣,请联系 832 566 0185 李
avatar
c*o
3
zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
我想可能是我没讲清楚,现在解释一下。
对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
debug)都是派生的而已。
我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效
颦而已。
avatar
j*n
4
'scumbag'这家公司其实什么都好,就是有个毛病,喜欢在不入流的媒体上打绿卡广告
。交投名状前建议搞清楚是真招人还是假招人,不然人家还要想方设法disqualify你,
你简历如果实在太强,那没办法还要先cancel这个广告,换个地方再打一次,人家绿卡
申请人还要咒你一万遍啊一万遍。
avatar
p*2
5
Try monad是很不错的,我们大量使用。
avatar
d*n
6
与hslliburton 和 Baker Hughes 相比好在哪里?

【在 i****r 的大作中提到】
: dream职位,已经一个多月了,没有消息。特求在slb工作的朋友帮忙内推,非常感谢!
avatar
l*n
7
没错。

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
p*j
8
我怎么听说他家不办绿卡的呢?奇怪
avatar
b*e
9
嗯,就是说程序的semantics是composable的。这对test automation也有帮助。

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
s*e
10
办,不过H1b要用得快完了才给办

【在 p****j 的大作中提到】
: 我怎么听说他家不办绿卡的呢?奇怪
avatar
d*r
11
能达到这种效果确实很牛, FP菜鸟的疑问是:
会不会编写时候造成各种过度解耦和不自然的模式,
导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
w*w
12
SLB几万人,做啥的都有。除非找到很相关的人,不然没用。

【在 i****r 的大作中提到】
: dream职位,已经一个多月了,没有消息。特求在slb工作的朋友帮忙内推,非常感谢!
avatar
m*u
13
如果“好的fp追求短小精干的函数和它们的组合", 那完了。。。
现在的框架思想(大一统思想)满天飞,城头变幻大王旗,一天一个新框架的现实条件
下,“追求短小精干的函数和它们的组合”不符合码农的操性。
我们准备开倒车,回到API上,废掉框架,“追求短小精干的函数和它们的组合”,结
果遇到了很多码农的阻力(尽管他们天天被框架操的死去活来)。码农是记吃不记打的
(喜欢快糙猛的快感),“好的fp追求短小精干的函数和它们的组合",码农们表示走不
通啊。。。
avatar
k*5
14
不是大牛的答复:效率通常不是开发时考虑的优先级,不然大家都回到C/ASM了。

【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?

avatar
c*o
15
这个不是大牛的回复。
1. 是的“效率下降”是有的,但是并不都会下降,有时候会更好。一般来说,
immutability 会有浪费,lazy loading 会有节约。recursive和loop其实是一样的。
这也是为什么,在云计算里,在硬件越来越便宜的情况下,软件越来越复杂的现在,fp
会开始被使用。
2. 这个倒没啥,习惯了其实就是另一套,没啥难不难的,oo/imprative 的模型理解很
自然么?学语言的时候都过一遍了,你还记得当时的理解痛苦么?

【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?

avatar
c*o
16
“好的fp追求短小精干的函数和它们的组合"和框架完全不对立啊。不知道为啥要对立
起来。

【在 m**u 的大作中提到】
: 如果“好的fp追求短小精干的函数和它们的组合", 那完了。。。
: 现在的框架思想(大一统思想)满天飞,城头变幻大王旗,一天一个新框架的现实条件
: 下,“追求短小精干的函数和它们的组合”不符合码农的操性。
: 我们准备开倒车,回到API上,废掉框架,“追求短小精干的函数和它们的组合”,结
: 果遇到了很多码农的阻力(尽管他们天天被框架操的死去活来)。码农是记吃不记打的
: (喜欢快糙猛的快感),“好的fp追求短小精干的函数和它们的组合",码农们表示走不
: 通啊。。。

avatar
c*o
17
说实话,就算不编FP, 理解这些也是很有意义的。
avatar
z*e
18
其实你应该说monad的
为啥避开了呢?
那个adt就是一个典型的monad
avatar
z*e
19
理解这个还是要从monad入手
monad其实就是一种aop
真正的aop要难过一般的monad
理解了aop,monad也不太难
avatar
z*e
20
你的目的换个说法
就是你写的func必需能够完全按照你的预想的去执行
否则就是错
所以如果有程序猿未考虑到的exception抛出
那就是程序猿的错,而非框架的问题
avatar
z*e
21
现在之所以用fp,主要是lambda
而用lambda的主要目的,就是为了充分发挥机能
而fp其他部分则会导致机能下降
那如何避开这些部分,是一般框架作者需要思考的问题
当然这不是使用者需要思考的问题

【在 k***5 的大作中提到】
: 不是大牛的答复:效率通常不是开发时考虑的优先级,不然大家都回到C/ASM了。
avatar
z*e
22
有选择性的吸收就没有问题了
比如为了async用lambda
java加入lambda不是没有道理的
所以还是要明白为什么要这么做
然后什么时候做,什么时候不做
而非教徒式的崇拜,啊,什么都应该fp

【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?

avatar
c*o
23
FP不是就只有monad的,很多时候用applicative functor, 甚至Traversable, 这个其
实都不重要,重要的是思想和目的。
”充分发挥机能“也不是fp的目的,其实虽然资源利用率高,但是我的经验是单位工作
,资源消耗的多了。
最大的目的是清晰,明了,可理解的的编程。显然很多时候大家都光看表面的东西了。
avatar
z*e
24
我知道呀
fp有很多东西,只是一个统称
所以把fp挂嘴边的,就跟把造轮子挂嘴边的一样
多半是个骗子,具体问题具体分析
那个问题其实想问的是monad
fp其他部分没有必要卷进来,比如lambda和immutable

【在 c******o 的大作中提到】
: FP不是就只有monad的,很多时候用applicative functor, 甚至Traversable, 这个其
: 实都不重要,重要的是思想和目的。
: ”充分发挥机能“也不是fp的目的,其实虽然资源利用率高,但是我的经验是单位工作
: ,资源消耗的多了。
: 最大的目的是清晰,明了,可理解的的编程。显然很多时候大家都光看表面的东西了。

avatar
z*e
25
顺便问你一个问题
monad是不是就是一个aspect which is monadic type
以及针对这部分的操作,也就是bind
所以monad不仅仅是一个数据结构,同时也是一个computation unit?

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
z*e
26
就是monad其实就是一个很小的自成体系的一个module
只不过这个module非常小,甚至小于函数的scope
所以换个名字,叫monad,一般module包含有多个函数以及object
avatar
c*o
27
Warning: boring stuff next.太长了,不知道有人看没有。
monad不是一个数据结构,它是一个“类型“的一个“类型”的一个“类型”。(
higher order type)
举例
type:
String
first order type:
List[X], can be List[String], List[Int], List[Double]
higher order type :
Monad, Can be List[X], Try[X], Option[X]
严格来说,Monad是一个高阶的类型,一个“类型“的一个“类型”的一个“类型”
他的定义就是一个类型F,如果能在之上定义
def unit[A](a: => A): F[A]
def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
这个类型就是一个monad.
比如List
def unit[A](a: => A): List[A]
给一个x,我能用unit做一个一个元素的List: (x)
scala> List("a")
res0: List[String] = List(a)
这儿的List constructor 就是unit
def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
scala> val la = List("test1ntest2n", "test3ntest4n")
la: List[String] =
List("test1
test2
", "test3
test4
")
scala> def f: String => List[String] = (x: String) => x.split("n").toList
f: String => List[String]
scala> la.flatMap(f)
res1: List[String] = List(test1, test2, test3, test4)
monad的定义就是有些类型有共同点:
都可以在这些类型之上定义
def unit[A](a: => A): F[A]
def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
他们就是monad
应为抽象了共同点,所以才强大。
正式的定义还要加上条件约束:
// Monad Law
// left identity: f(a) == flatmap(unit(a), f)
// right identity: a == flatMap(a, x => unit(x))
// associativity: flatMap(a, x => flatMap(f(x), g)) == flatMap(flatMap(a, f)
, g)
所以数据结构/computation unit很难归纳它。
List是monad其实是说List是monadic type

【在 z****e 的大作中提到】
: 顺便问你一个问题
: monad是不是就是一个aspect which is monadic type
: 以及针对这部分的操作,也就是bind
: 所以monad不仅仅是一个数据结构,同时也是一个computation unit?

avatar
z*e
28
定义第二个条件是为了啥?
为了flatMap操作方便?

【在 c******o 的大作中提到】
: Warning: boring stuff next.太长了,不知道有人看没有。
: monad不是一个数据结构,它是一个“类型“的一个“类型”的一个“类型”。(
: higher order type)
: 举例
: type:
: String
: first order type:
: List[X], can be List[String], List[Int], List[Double]
: higher order type :
: Monad, Can be List[X], Try[X], Option[X]

avatar
z*e
29
总结一下
首先monad能够通过一个type转换成另外一种monadic type(return?)
所谓monadic type就是能够通过flatmap进行依次转换的东西(bind?)
所以包含有生成list方法的List class是一个monad
同样,包含有生成map方法的HashMap也是一个monad
嗯,Set好像也可以

【在 c******o 的大作中提到】
: Warning: boring stuff next.太长了,不知道有人看没有。
: monad不是一个数据结构,它是一个“类型“的一个“类型”的一个“类型”。(
: higher order type)
: 举例
: type:
: String
: first order type:
: List[X], can be List[String], List[Int], List[Double]
: higher order type :
: Monad, Can be List[X], Try[X], Option[X]

avatar
z*e
31
感觉只要是集合体,都可以flatmap操作
除非flatmap有自己一套恶心的定义
应该没有,所以其实monad就是一个通过某个参数生成一个集合
只要能做到这一步,那么这个集合就是一个monad
所以其实不仅仅是list/map/set,其他general的结构也都可以做成monad
但是一般还是list/map/set
这样理解对不对?
avatar
c*o
33
不是,
Map是一个monad,因为
它也能实现unit/flatMap
但是那里面的
def unit[A](a: => A): F[A]
def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
F就是Map
上一页刚才的实现
F是List
所以才说monad是type of type of type
type (Monad) of type (List, Map) of type (List[String], List[Int], Map[
String], Map[Int])

【在 z****e 的大作中提到】
: 总结一下
: 首先monad能够通过一个type转换成另外一种monadic type(return?)
: 所谓monadic type就是能够通过flatmap进行依次转换的东西(bind?)
: 所以包含有生成list方法的List class是一个monad
: 同样,包含有生成map方法的HashMap也是一个monad
: 嗯,Set好像也可以

avatar
c*o
34
可以不是集合体,比如Try, Future, IO, State
甚至有复杂的continuation (基本上functional goto :) )
不是集合的monad基本都是为了打包side effect

【在 z****e 的大作中提到】
: 感觉只要是集合体,都可以flatmap操作
: 除非flatmap有自己一套恶心的定义
: 应该没有,所以其实monad就是一个通过某个参数生成一个集合
: 只要能做到这一步,那么这个集合就是一个monad
: 所以其实不仅仅是list/map/set,其他general的结构也都可以做成monad
: 但是一般还是list/map/set
: 这样理解对不对?

avatar
l*n
35
monad是为了non-deterministic而生的。

【在 z****e 的大作中提到】
: 定义第二个条件是为了啥?
: 为了flatMap操作方便?

avatar
z*e
36
如果是collection的monad的话,那就是deterministic了

【在 l**********n 的大作中提到】
: monad是为了non-deterministic而生的。
avatar
c*o
37
BTW,有一个很有用的知识
只要能实现flatMap, unit, 就可以用它们实现map
def map[A,B](fa: F[A])(f: A => B): F[B]
map就好理解的多,基本上是提取内容作操作再塞回去。
scala> val lb = List(1,2,3,4)
lb: List[Int] = List(1, 2, 3, 4)
scala> lb.map(x => x+1)
res4: List[Int] = List(2, 3, 4, 5)
和monad一样,能实现map的就叫functor
每一个monad 一定是一个 functor, 因为map能用flatMap/unit抽象的实现。
avatar
z*e
38

这个不是是set不是monad还是可以不说集合体?

【在 c******o 的大作中提到】
: 不是,
: Map是一个monad,因为
: 它也能实现unit/flatMap
: 但是那里面的
: def unit[A](a: => A): F[A]
: def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
: F就是Map
: 上一页刚才的实现
: F是List
: 所以才说monad是type of type of type

avatar
c*o
39
monad可以不是集合体

【在 z****e 的大作中提到】
:
: 这个不是是set不是monad还是可以不说集合体?

avatar
c*o
40
介于monad functor之间的是applicative,是stream processing 的重要角色。
BTW,这些都能用java实现,只是不能抽象的实现。
能实现list/stream/map monad,但是不能实现抽象的monad

【在 c******o 的大作中提到】
: BTW,有一个很有用的知识
: 只要能实现flatMap, unit, 就可以用它们实现map
: def map[A,B](fa: F[A])(f: A => B): F[B]
: map就好理解的多,基本上是提取内容作操作再塞回去。
: scala> val lb = List(1,2,3,4)
: lb: List[Int] = List(1, 2, 3, 4)
: scala> lb.map(x => x+1)
: res4: List[Int] = List(2, 3, 4, 5)
: 和monad一样,能实现map的就叫functor
: 每一个monad 一定是一个 functor, 因为map能用flatMap/unit抽象的实现。

avatar
z*e
41
soga,明白了
多谢

【在 c******o 的大作中提到】
: monad可以不是集合体
avatar
l*n
42
monad定义了两个函数:return , bind

【在 z****e 的大作中提到】
: soga,明白了
: 多谢

avatar
c*o
43
在scala,和我的例子里是unit/flatMap
不同名字而已。

【在 l**********n 的大作中提到】
: monad定义了两个函数:return , bind
avatar
z*e
44
我前面说了呀
灌水要看context

【在 l**********n 的大作中提到】
: monad定义了两个函数:return , bind
avatar
z*e
45
flatMap
concaMap
filter
reduce
还包括map,不是collection那个map
这些在rxjava里面都有了
感觉就是scala前面做,java跟着后面抄
java8弄了lambda(without currying)
vert.x弄了async(without immutable&mul-process)
rxjava弄了monad(collection part, without side effect)
这种选择性吸收深得我心啊,取其精华,弃其糟粕
下一个弄啥?streaming吗?
avatar
z*e
46
+观感正面,-观感负面
lambda +,写程序更简洁些
currying -,混乱,map到底是func还是obj?
1st-class func -,混乱,理由同上,同时需要跟immutable配合
immutable -,同上
monad +,collection部分不错,但是如果是包装其他的则观感负面
functor +,不错,理由同上
dynamic type +,有限滴使用,搬运数据时候用,否则混乱
async +,可以提升性能
single thread -,这哥们是来搞笑的
scala以上全部都可以做,也都可以不做
clojure到dynamic type以上都必需做到,谁让它纯呢?
java基本上就只允许做观感正面部分,除了dynamic type
which可以交给groovy完成,负面部分不是特别麻烦就是会被禁
java8加了lambda
vert.x有async
rxjava有functor和monad
avatar
z*e
47
灌水收获也是如此
主要还是看scala那几个在说啥
其他clj和js的都在扯蛋
avatar
p*2
48

大牛,这个我早说过吧?当时你还不承认。

【在 z****e 的大作中提到】
: 理解这个还是要从monad入手
: monad其实就是一种aop
: 真正的aop要难过一般的monad
: 理解了aop,monad也不太难

avatar
p*2
49

这个我早就想过了。对于需要性能的地方可以imperative。但是90%以上估计不需要。

【在 z****e 的大作中提到】
: 现在之所以用fp,主要是lambda
: 而用lambda的主要目的,就是为了充分发挥机能
: 而fp其他部分则会导致机能下降
: 那如何避开这些部分,是一般框架作者需要思考的问题
: 当然这不是使用者需要思考的问题

avatar
z*e
50
昨晚给你的那个链接里面就说了一个例子
恰好那个例子就是游戏
vert.x用来对付游戏没有问题,会很容易
恰好我就在用vert.x来对付类似的场景
但是node会很苦逼,多线程这些手段还是有用的
至于这占多少百分比,那就不知道了
而且vert简单的场景也很容易,没觉得比node复杂
所以这个余地我还是留着了

【在 p*****2 的大作中提到】
:
: 这个我早就想过了。对于需要性能的地方可以imperative。但是90%以上估计不需要。

avatar
p*2
51

我以为你在讨论fp。

【在 z****e 的大作中提到】
: 昨晚给你的那个链接里面就说了一个例子
: 恰好那个例子就是游戏
: vert.x用来对付游戏没有问题,会很容易
: 恰好我就在用vert.x来对付类似的场景
: 但是node会很苦逼,多线程这些手段还是有用的
: 至于这占多少百分比,那就不知道了
: 而且vert简单的场景也很容易,没觉得比node复杂
: 所以这个余地我还是留着了

avatar
z*e
52
只取lambda不取fp的其他部分
就不会造成机能下降撒
比如immutable就可以不用
单纯的lambda是可以提升执行效率的
可读性也就是flatten通过rxjava来解决

【在 p*****2 的大作中提到】
:
: 我以为你在讨论fp。

avatar
d*u
53
终于看到一个学过FP的了

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
h*i
54
说得不错。用了FP做大项目之后,发现主要的好处就是这个,一切都是分离的,很容易
修改,一般就动一两个地方。很适合做商业逻辑,所以我觉得FP在做应用上有前途。做
轮子真没有太多优势。
其他的区别真的不太大。

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

avatar
p*2
55

项目大了就需要上OO了。FP也不例外。

【在 h*i 的大作中提到】
: 说得不错。用了FP做大项目之后,发现主要的好处就是这个,一切都是分离的,很容易
: 修改,一般就动一两个地方。很适合做商业逻辑,所以我觉得FP在做应用上有前途。做
: 轮子真没有太多优势。
: 其他的区别真的不太大。

avatar
h*i
56
OO和FP不矛盾。
Clojure里面,大型项目目前流行用record, protocol, component DI这一套来管理共
享的状态和资源,其实就是OOP,不过是FP的OOP。
但Clojure绝大部分的代码还是在immutable data上面折腾,充分利用FP的优势。
imperative OOP的毛病是本质上各种东西都是closely coupled, 因为你把一个object
的reference给别人之后,别人想干啥就干啥,所以你不能放心的给别人,要搞各种
pattern,弄得很复杂。这就没有FP那种“动这里绝对伤不到那里”的让人放心的保证
,这是最大的不同。所以我反复强调,用Clojure最大的不同就是immutable data, 是
一种不同的思维方式,因为很多IP程序员觉得最基本的东东都不能用了,得想别的办法
。不过其实过了这个坎,就会觉得其实别的办法也很简单(也许更简单?),以前不知
道而已。就为了能简简单单地放心,这个坎还是值得翻过去的。

【在 p*****2 的大作中提到】
:
: 项目大了就需要上OO了。FP也不例外。

avatar
l*s
57
immutable就是拿性能换开发效率,写c++接受不了可以理解,写java的接受不了只能是
精分了。

object

【在 h*i 的大作中提到】
: OO和FP不矛盾。
: Clojure里面,大型项目目前流行用record, protocol, component DI这一套来管理共
: 享的状态和资源,其实就是OOP,不过是FP的OOP。
: 但Clojure绝大部分的代码还是在immutable data上面折腾,充分利用FP的优势。
: imperative OOP的毛病是本质上各种东西都是closely coupled, 因为你把一个object
: 的reference给别人之后,别人想干啥就干啥,所以你不能放心的给别人,要搞各种
: pattern,弄得很复杂。这就没有FP那种“动这里绝对伤不到那里”的让人放心的保证
: ,这是最大的不同。所以我反复强调,用Clojure最大的不同就是immutable data, 是
: 一种不同的思维方式,因为很多IP程序员觉得最基本的东东都不能用了,得想别的办法
: 。不过其实过了这个坎,就会觉得其实别的办法也很简单(也许更简单?),以前不知

avatar
h*i
58
就是说嘛,我也觉得这样的人要么是精分,要么是只要“get used to it",不求真正
理解的人。
呵呵。

【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率,写c++接受不了可以理解,写java的接受不了只能是
: 精分了。
:
: object

avatar
z*e
59
真想换开发效率那就换ide
oop本身开发效率也不低
fp的一些名词导致的混乱会让维护变得恶心起来

【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率,写c++接受不了可以理解,写java的接受不了只能是
: 精分了。
:
: object

avatar
z*e
60
胡扯蛋
当你用了pure fp做多线程的时候
你几乎是不得不用immutable,否则就需要lock了
lock没有多少人真搞的,绝大多数人都会选择框架
无论是oop还是fp,而fp的框架必需用immutable,你根本就没有选择的权力
否则状态马上就escape鸟,这个跟oop完全不一样
oop才是真正的允许你选择要不要用immutable
因为oop可以保证object本身被线程单独执行,而非func
scope变大了,人的自由度自然就上升了

【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率,写c++接受不了可以理解,写java的接受不了只能是
: 精分了。
:
: object

avatar
p*2
61
immutable不是万能的。

object

【在 h*i 的大作中提到】
: OO和FP不矛盾。
: Clojure里面,大型项目目前流行用record, protocol, component DI这一套来管理共
: 享的状态和资源,其实就是OOP,不过是FP的OOP。
: 但Clojure绝大部分的代码还是在immutable data上面折腾,充分利用FP的优势。
: imperative OOP的毛病是本质上各种东西都是closely coupled, 因为你把一个object
: 的reference给别人之后,别人想干啥就干啥,所以你不能放心的给别人,要搞各种
: pattern,弄得很复杂。这就没有FP那种“动这里绝对伤不到那里”的让人放心的保证
: ,这是最大的不同。所以我反复强调,用Clojure最大的不同就是immutable data, 是
: 一种不同的思维方式,因为很多IP程序员觉得最基本的东东都不能用了,得想别的办法
: 。不过其实过了这个坎,就会觉得其实别的办法也很简单(也许更简单?),以前不知

avatar
d*r
62
大牛是做科学计算的类项目的吧, 你觉得多用immutable一般资源耗费如何, 比如一般
内存耗费Clojure比Java多多少?

object

【在 h*i 的大作中提到】
: OO和FP不矛盾。
: Clojure里面,大型项目目前流行用record, protocol, component DI这一套来管理共
: 享的状态和资源,其实就是OOP,不过是FP的OOP。
: 但Clojure绝大部分的代码还是在immutable data上面折腾,充分利用FP的优势。
: imperative OOP的毛病是本质上各种东西都是closely coupled, 因为你把一个object
: 的reference给别人之后,别人想干啥就干啥,所以你不能放心的给别人,要搞各种
: pattern,弄得很复杂。这就没有FP那种“动这里绝对伤不到那里”的让人放心的保证
: ,这是最大的不同。所以我反复强调,用Clojure最大的不同就是immutable data, 是
: 一种不同的思维方式,因为很多IP程序员觉得最基本的东东都不能用了,得想别的办法
: 。不过其实过了这个坎,就会觉得其实别的办法也很简单(也许更简单?),以前不知

avatar
p*2
63

既然都用了FP了,内存一般不是考虑的问题。当然也不是100%,所以有时候还是需要
imperative。

【在 d*******r 的大作中提到】
: 大牛是做科学计算的类项目的吧, 你觉得多用immutable一般资源耗费如何, 比如一般
: 内存耗费Clojure比Java多多少?
:
: object

avatar
h*i
64
我们不做科学计算,只做一般所谓的大数据的计算。主要的计算都是在线下进行的,分
布式,所以没觉得内存是问题。上线产品里面进行的计算都是非常简单的访问数据库和
对少量数据的计算,内存不是问题。用户多了的话也是同样的上更多的机器,所以
Clojure的资源消耗还没觉得是什么问题。
我没做过与Java的内存消耗比较。不过GC会回收不用的object(immutable data不是说
就不被回收了,呵呵),所以我觉得只要不是那种每一步都需要整个原始数据的算法,
应该不会太差。
同样的算法,这儿有比较不同语言的:
http://benchmarksgame.alioth.debian.org/u64q/clojure.html

【在 d*******r 的大作中提到】
: 大牛是做科学计算的类项目的吧, 你觉得多用immutable一般资源耗费如何, 比如一般
: 内存耗费Clojure比Java多多少?
:
: object

avatar
j*x
65
这个都是程序员说了算哦
写没有side effect的小函数几乎是所有语言都认同的best practice
。。。

【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处,看起来一点的不好。
: 我想可能是我没讲清楚,现在解释一下。
: 对于使用FP的人,如果真正很好的理解/执行了fp的方法,编了程序。那么在这个程序
: 里,我(或者其他人)可以随意抽出一段(以函数为最小单位),以百分百的信心说我
: 知道这个编的对不对,好不好。 我可以百分百的信心进行修改,然后说我绝对没有任
: 何可能破坏程序的其他部分。(所以好的fp追求短小精干的函数和它们的组合)
: 这是FP编程最根本,最基本,最重要的目的。其他的好处(对并行好,对分布好,好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的,像qxc抱怨的一样,那很可惜,你的FP可能只是东施效

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。