c******o
发帖数: 1277 | 1 zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
我想可能是我没讲清楚，现在解释一下。
对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
debug)都是派生的而已。
我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
颦而已。 |
p*****2
发帖数: 21240 | |
l**********n
发帖数: 8443 | 3 没错。
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
b***e
发帖数: 1419 | 4 嗯，就是说程序的semantics是composable的。这对test automation也有帮助。
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
d*******r
发帖数: 3299 | 5 能达到这种效果确实很牛, FP菜鸟的疑问是:
会不会编写时候造成各种过度解耦和不自然的模式,
导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
m**u
发帖数: 541 | 6 如果“好的fp追求短小精干的函数和它们的组合"， 那完了。。。
现在的框架思想（大一统思想）满天飞，城头变幻大王旗，一天一个新框架的现实条件
下，“追求短小精干的函数和它们的组合”不符合码农的操性。
我们准备开倒车，回到API上，废掉框架，“追求短小精干的函数和它们的组合”，结
果遇到了很多码农的阻力（尽管他们天天被框架操的死去活来）。码农是记吃不记打的
(喜欢快糙猛的快感），“好的fp追求短小精干的函数和它们的组合"，码农们表示走不
通啊。。。 |
k***5
发帖数: 583 | 7 不是大牛的答复：效率通常不是开发时考虑的优先级，不然大家都回到C/ASM了。
【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?
|
c******o
发帖数: 1277 | 8 这个不是大牛的回复。
1. 是的“效率下降”是有的，但是并不都会下降，有时候会更好。一般来说，
immutability 会有浪费，lazy loading 会有节约。recursive和loop其实是一样的。
这也是为什么，在云计算里，在硬件越来越便宜的情况下，软件越来越复杂的现在，fp
会开始被使用。
2. 这个倒没啥，习惯了其实就是另一套，没啥难不难的，oo/imprative 的模型理解很
自然么？学语言的时候都过一遍了，你还记得当时的理解痛苦么？
【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?
|
c******o
发帖数: 1277 | 9 “好的fp追求短小精干的函数和它们的组合"和框架完全不对立啊。不知道为啥要对立
起来。
【在 m**u 的大作中提到】
: 如果“好的fp追求短小精干的函数和它们的组合"， 那完了。。。
: 现在的框架思想（大一统思想）满天飞，城头变幻大王旗，一天一个新框架的现实条件
: 下，“追求短小精干的函数和它们的组合”不符合码农的操性。
: 我们准备开倒车，回到API上，废掉框架，“追求短小精干的函数和它们的组合”，结
: 果遇到了很多码农的阻力（尽管他们天天被框架操的死去活来）。码农是记吃不记打的
: (喜欢快糙猛的快感），“好的fp追求短小精干的函数和它们的组合"，码农们表示走不
: 通啊。。。
|
c******o
发帖数: 1277 | 10 说实话，就算不编FP, 理解这些也是很有意义的。 |
|
|
z****e
发帖数: 54598 | 11 其实你应该说monad的
为啥避开了呢？
那个adt就是一个典型的monad |
z****e
发帖数: 54598 | 12 理解这个还是要从monad入手
monad其实就是一种aop
真正的aop要难过一般的monad
理解了aop，monad也不太难 |
z****e
发帖数: 54598 | 13 你的目的换个说法
就是你写的func必需能够完全按照你的预想的去执行
否则就是错
所以如果有程序猿未考虑到的exception抛出
那就是程序猿的错，而非框架的问题 |
z****e
发帖数: 54598 | 14 现在之所以用fp，主要是lambda
而用lambda的主要目的，就是为了充分发挥机能
而fp其他部分则会导致机能下降
那如何避开这些部分，是一般框架作者需要思考的问题
当然这不是使用者需要思考的问题
【在 k***5 的大作中提到】
: 不是大牛的答复：效率通常不是开发时考虑的优先级，不然大家都回到C/ASM了。
|
z****e
发帖数: 54598 | 15 有选择性的吸收就没有问题了
比如为了async用lambda
java加入lambda不是没有道理的
所以还是要明白为什么要这么做
然后什么时候做，什么时候不做
而非教徒式的崇拜，啊，什么都应该fp
【在 d*******r 的大作中提到】
: 能达到这种效果确实很牛, FP菜鸟的疑问是:
: 会不会编写时候造成各种过度解耦和不自然的模式,
: 导致: 1.效率下降(CPU, memory消耗太多); 2.模型理解很不自然.
: 请 FP 大牛说说, 上面2个是不是 FP 很难解决的问题?
|
c******o
发帖数: 1277 | 16 FP不是就只有monad的，很多时候用applicative functor, 甚至Traversable, 这个其
实都不重要，重要的是思想和目的。
”充分发挥机能“也不是fp的目的，其实虽然资源利用率高，但是我的经验是单位工作
，资源消耗的多了。
最大的目的是清晰，明了，可理解的的编程。显然很多时候大家都光看表面的东西了。 |
z****e
发帖数: 54598 | 17 我知道呀
fp有很多东西，只是一个统称
所以把fp挂嘴边的，就跟把造轮子挂嘴边的一样
多半是个骗子，具体问题具体分析
那个问题其实想问的是monad
fp其他部分没有必要卷进来，比如lambda和immutable
【在 c******o 的大作中提到】
: FP不是就只有monad的，很多时候用applicative functor, 甚至Traversable, 这个其
: 实都不重要，重要的是思想和目的。
: ”充分发挥机能“也不是fp的目的，其实虽然资源利用率高，但是我的经验是单位工作
: ，资源消耗的多了。
: 最大的目的是清晰，明了，可理解的的编程。显然很多时候大家都光看表面的东西了。
|
z****e
发帖数: 54598 | 18 顺便问你一个问题
monad是不是就是一个aspect which is monadic type
以及针对这部分的操作，也就是bind
所以monad不仅仅是一个数据结构，同时也是一个computation unit？
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
z****e
发帖数: 54598 | 19 就是monad其实就是一个很小的自成体系的一个module
只不过这个module非常小，甚至小于函数的scope
所以换个名字，叫monad，一般module包含有多个函数以及object |
c******o
发帖数: 1277 | 20 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？
|
|
|
z****e
发帖数: 54598 | 21 定义第二个条件是为了啥？
为了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]
|
z****e
发帖数: 54598 | 22 总结一下
首先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]
|
c******o
发帖数: 1277 | |
z****e
发帖数: 54598 | 24 感觉只要是集合体，都可以flatmap操作
除非flatmap有自己一套恶心的定义
应该没有，所以其实monad就是一个通过某个参数生成一个集合
只要能做到这一步，那么这个集合就是一个monad
所以其实不仅仅是list/map/set，其他general的结构也都可以做成monad
但是一般还是list/map/set
这样理解对不对？ |
z****e
发帖数: 54598 | |
c******o
发帖数: 1277 | 26 不是，
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好像也可以
|
c******o
发帖数: 1277 | 27 可以不是集合体，比如Try, Future, IO, State
甚至有复杂的continuation (基本上functional goto :) )
不是集合的monad基本都是为了打包side effect
【在 z****e 的大作中提到】
: 感觉只要是集合体，都可以flatmap操作
: 除非flatmap有自己一套恶心的定义
: 应该没有，所以其实monad就是一个通过某个参数生成一个集合
: 只要能做到这一步，那么这个集合就是一个monad
: 所以其实不仅仅是list/map/set，其他general的结构也都可以做成monad
: 但是一般还是list/map/set
: 这样理解对不对？
|
l**********n
发帖数: 8443 | 28 monad是为了non-deterministic而生的。
【在 z****e 的大作中提到】
: 定义第二个条件是为了啥？
: 为了flatMap操作方便？
|
z****e
发帖数: 54598 | 29 如果是collection的monad的话，那就是deterministic了
【在 l**********n 的大作中提到】
: monad是为了non-deterministic而生的。
|
c******o
发帖数: 1277 | 30 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抽象的实现。 |
|
|
z****e
发帖数: 54598 | 31
这个不是是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
|
c******o
发帖数: 1277 | 32 monad可以不是集合体
【在 z****e 的大作中提到】
:
: 这个不是是set不是monad还是可以不说集合体？
|
c******o
发帖数: 1277 | 33 介于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抽象的实现。
|
z****e
发帖数: 54598 | 34 soga，明白了
多谢
【在 c******o 的大作中提到】
: monad可以不是集合体
|
l**********n
发帖数: 8443 | 35 monad定义了两个函数:return , bind
【在 z****e 的大作中提到】
: soga，明白了
: 多谢
|
c******o
发帖数: 1277 | 36 在scala,和我的例子里是unit/flatMap
不同名字而已。
【在 l**********n 的大作中提到】
: monad定义了两个函数:return , bind
|
z****e
发帖数: 54598 | 37 我前面说了呀
灌水要看context
【在 l**********n 的大作中提到】
: monad定义了两个函数:return , bind
|
z****e
发帖数: 54598 | 38 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吗？ |
z****e
发帖数: 54598 | 39 +观感正面，-观感负面
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 |
z****e
发帖数: 54598 | 40 灌水收获也是如此
主要还是看scala那几个在说啥
其他clj和js的都在扯蛋 |
|
|
p*****2
发帖数: 21240 | 41
大牛，这个我早说过吧？当时你还不承认。
【在 z****e 的大作中提到】
: 理解这个还是要从monad入手
: monad其实就是一种aop
: 真正的aop要难过一般的monad
: 理解了aop，monad也不太难
|
p*****2
发帖数: 21240 | 42
这个我早就想过了。对于需要性能的地方可以imperative。但是90%以上估计不需要。
【在 z****e 的大作中提到】
: 现在之所以用fp，主要是lambda
: 而用lambda的主要目的，就是为了充分发挥机能
: 而fp其他部分则会导致机能下降
: 那如何避开这些部分，是一般框架作者需要思考的问题
: 当然这不是使用者需要思考的问题
|
z****e
发帖数: 54598 | 43 昨晚给你的那个链接里面就说了一个例子
恰好那个例子就是游戏
vert.x用来对付游戏没有问题，会很容易
恰好我就在用vert.x来对付类似的场景
但是node会很苦逼，多线程这些手段还是有用的
至于这占多少百分比，那就不知道了
而且vert简单的场景也很容易，没觉得比node复杂
所以这个余地我还是留着了
【在 p*****2 的大作中提到】
:
: 这个我早就想过了。对于需要性能的地方可以imperative。但是90%以上估计不需要。
|
p*****2
发帖数: 21240 | 44
我以为你在讨论fp。
【在 z****e 的大作中提到】
: 昨晚给你的那个链接里面就说了一个例子
: 恰好那个例子就是游戏
: vert.x用来对付游戏没有问题，会很容易
: 恰好我就在用vert.x来对付类似的场景
: 但是node会很苦逼，多线程这些手段还是有用的
: 至于这占多少百分比，那就不知道了
: 而且vert简单的场景也很容易，没觉得比node复杂
: 所以这个余地我还是留着了
|
z****e
发帖数: 54598 | 45 只取lambda不取fp的其他部分
就不会造成机能下降撒
比如immutable就可以不用
单纯的lambda是可以提升执行效率的
可读性也就是flatten通过rxjava来解决
【在 p*****2 的大作中提到】
:
: 我以为你在讨论fp。
|
d********u
发帖数: 5383 | 46 终于看到一个学过FP的了
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
h*i
发帖数: 3446 | 47 说得不错。用了FP做大项目之后，发现主要的好处就是这个，一切都是分离的，很容易
修改，一般就动一两个地方。很适合做商业逻辑，所以我觉得FP在做应用上有前途。做
轮子真没有太多优势。
其他的区别真的不太大。
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
p*****2
发帖数: 21240 | 48
项目大了就需要上OO了。FP也不例外。
【在 h*i 的大作中提到】
: 说得不错。用了FP做大项目之后，发现主要的好处就是这个，一切都是分离的，很容易
: 修改，一般就动一两个地方。很适合做商业逻辑，所以我觉得FP在做应用上有前途。做
: 轮子真没有太多优势。
: 其他的区别真的不太大。
|
h*i
发帖数: 3446 | 49 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也不例外。
|
l*********s
发帖数: 5409 | 50 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程序员觉得最基本的东东都不能用了，得想别的办法
: 。不过其实过了这个坎，就会觉得其实别的办法也很简单（也许更简单？），以前不知
|
|
|
h*i
发帖数: 3446 | 51 就是说嘛，我也觉得这样的人要么是精分，要么是只要“get used to it"，不求真正
理解的人。
呵呵。
【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率，写c++接受不了可以理解，写java的接受不了只能是
: 精分了。
:
: object
|
z****e
发帖数: 54598 | 52 真想换开发效率那就换ide
oop本身开发效率也不低
fp的一些名词导致的混乱会让维护变得恶心起来
【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率，写c++接受不了可以理解，写java的接受不了只能是
: 精分了。
:
: object
|
z****e
发帖数: 54598 | 53 胡扯蛋
当你用了pure fp做多线程的时候
你几乎是不得不用immutable，否则就需要lock了
lock没有多少人真搞的，绝大多数人都会选择框架
无论是oop还是fp，而fp的框架必需用immutable，你根本就没有选择的权力
否则状态马上就escape鸟，这个跟oop完全不一样
oop才是真正的允许你选择要不要用immutable
因为oop可以保证object本身被线程单独执行，而非func
scope变大了，人的自由度自然就上升了
【在 l*********s 的大作中提到】
: immutable就是拿性能换开发效率，写c++接受不了可以理解，写java的接受不了只能是
: 精分了。
:
: object
|
p*****2
发帖数: 21240 | 54 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程序员觉得最基本的东东都不能用了，得想别的办法
: 。不过其实过了这个坎，就会觉得其实别的办法也很简单（也许更简单？），以前不知
|
d*******r
发帖数: 3299 | 55 大牛是做科学计算的类项目的吧, 你觉得多用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程序员觉得最基本的东东都不能用了，得想别的办法
: 。不过其实过了这个坎，就会觉得其实别的办法也很简单（也许更简单？），以前不知
|
p*****2
发帖数: 21240 | 56
既然都用了FP了，内存一般不是考虑的问题。当然也不是100%，所以有时候还是需要
imperative。
【在 d*******r 的大作中提到】
: 大牛是做科学计算的类项目的吧, 你觉得多用immutable一般资源耗费如何, 比如一般
: 内存耗费Clojure比Java多多少?
:
: object
|
h*i
发帖数: 3446 | 57 我们不做科学计算，只做一般所谓的大数据的计算。主要的计算都是在线下进行的，分
布式，所以没觉得内存是问题。上线产品里面进行的计算都是非常简单的访问数据库和
对少量数据的计算，内存不是问题。用户多了的话也是同样的上更多的机器，所以
Clojure的资源消耗还没觉得是什么问题。
我没做过与Java的内存消耗比较。不过GC会回收不用的object(immutable data不是说
就不被回收了，呵呵)，所以我觉得只要不是那种每一步都需要整个原始数据的算法，
应该不会太差。
同样的算法，这儿有比较不同语言的：
http://benchmarksgame.alioth.debian.org/u64q/clojure.html
【在 d*******r 的大作中提到】
: 大牛是做科学计算的类项目的吧, 你觉得多用immutable一般资源耗费如何, 比如一般
: 内存耗费Clojure比Java多多少?
:
: object
|
j********x
发帖数: 2330 | 58 这个都是程序员说了算哦
写没有side effect的小函数几乎是所有语言都认同的best practice
。。。
【在 c******o 的大作中提到】
: zhaoce问我上次那个Try monad有啥好处，看起来一点的不好。
: 我想可能是我没讲清楚，现在解释一下。
: 对于使用FP的人，如果真正很好的理解／执行了fp的方法，编了程序。那么在这个程序
: 里，我（或者其他人）可以随意抽出一段（以函数为最小单位），以百分百的信心说我
: 知道这个编的对不对，好不好。 我可以百分百的信心进行修改，然后说我绝对没有任
: 何可能破坏程序的其他部分。（所以好的fp追求短小精干的函数和它们的组合）
: 这是FP编程最根本，最基本，最重要的目的。其他的好处（对并行好，对分布好，好
: debug)都是派生的而已。
: 我们讨论的FP的乱七八糟的东西只是达到这个目的的手段而已。
: 如果你的FP不能达到这个目的，像qxc抱怨的一样，那很可惜，你的FP可能只是东施效
|
