c******o
发帖数: 1277 | 1 编了一段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有关的
东西。
学会两个其实是很好的一种职业发展 |
m******t
发帖数: 635 | 2 OOP和FP很难共存吧，根本是两种不同的哲学，两个都强的人估计很容易精神分裂，所
以我一致很看衰Scala。
。
【在 c******o 的大作中提到】
: 编了一段FP的code了，来说说我的理解。
: FP其实不是编程方式的不同，是实现你想法到working code的方法不同。
: 大家说起FP，一般都先想到function first.没错，但是FP还有很多很重要但是不为人
: 了解的侧重点。
: 1. immutability (不变性），这个很多人说不实用，没错，在某些意义上是不适用。
: 但是对于非IO瓶颈的项目，你总能把你最看重的那部分分离出来做纯FP,immutable.其
: 他的继续imperative.其实实际编程时考究的主要是建模／抽象／算法，把它变成
: parallellable,其他都容易，FP就是让它容易的工具。让你能多想建模／抽象／算法。
: 2. lazy evaluation,这个其实也是各种FP强调的一点。也很好，和 immutability 在
: 一起，能大大简化模型／算法，
|
c******o
发帖数: 1277 | 3 共存很容易，就是两个都用好很难。
比说，OO要object封装，FP pattern matching要inspect内部结构。
但是你可以用object封装 或者 pattern matching。不一定同时同一个object两个都有。
在什么时候用那就不容易了。
【在 m******t 的大作中提到】
: OOP和FP很难共存吧，根本是两种不同的哲学，两个都强的人估计很容易精神分裂，所
: 以我一致很看衰Scala。
:
: 。
|
m******t
发帖数: 635 | 4 几年前折腾F#的时候碰过这种情况，几乎一模一样的卖点：什么先用OOP做原型，然后
一点点地替代成FP，或者使用FP写库，用OOP写逻辑blahblah。每时每刻脑子里都在斗
争，是否要mutable。
有。
【在 c******o 的大作中提到】
: 共存很容易，就是两个都用好很难。
: 比说，OO要object封装，FP pattern matching要inspect内部结构。
: 但是你可以用object封装 或者 pattern matching。不一定同时同一个object两个都有。
: 在什么时候用那就不容易了。
|
c******o
发帖数: 1277 | 5 反正两个都行，先写一个，然后再改。
这个需要做大量test的BDD/TDD，我们就这么干，好处是，到后面，效率和成果真的很
好，大家也都很有劲干。
实际中总是有一个侧重，基本上我们是能用FP的,能immutable就用，不然才imperative
【在 m******t 的大作中提到】
: 几年前折腾F#的时候碰过这种情况，几乎一模一样的卖点：什么先用OOP做原型，然后
: 一点点地替代成FP，或者使用FP写库，用OOP写逻辑blahblah。每时每刻脑子里都在斗
: 争，是否要mutable。
:
: 有。
|
m******t
发帖数: 635 | 6 这样的问题是两种并存对维护者的要求很高，如果要编写和维护用Scala写的库的话，
普通人基本上搞不定的。当然编写和维护库都不是一般的要求，但是F#和Scala这样的
混合型语言会出奇的高。
【在 c******o 的大作中提到】
: 反正两个都行，先写一个，然后再改。
: 这个需要做大量test的BDD/TDD，我们就这么干，好处是，到后面，效率和成果真的很
: 好，大家也都很有劲干。
: 实际中总是有一个侧重，基本上我们是能用FP的,能immutable就用，不然才imperative
|
c******o
发帖数: 1277 | 7 async/concurrency is always hard, at least FP/OO hybrid make it easier.
【在 m******t 的大作中提到】
: 这样的问题是两种并存对维护者的要求很高，如果要编写和维护用Scala写的库的话，
: 普通人基本上搞不定的。当然编写和维护库都不是一般的要求，但是F#和Scala这样的
: 混合型语言会出奇的高。
|
p*****2
发帖数: 21240 | 8
async/concurrency跟FP/OO有什么直接的关系吗？
【在 c******o 的大作中提到】
: async/concurrency is always hard, at least FP/OO hybrid make it easier.
|
z****e
发帖数: 54598 | 9 你最大的问题就是，你一直在说某个东西好，好在哪里
而别人总是在跟你说，这个东西坏在哪里，而你总是听不进去
现实生活中，各种paradigm都有好处，这也是最初这些东西的本意
但是各种paradigm都有坏处，那怎么取舍就显得很重要
就好比你一个价值$100的项目，如果你用oop来实现，基本上可以完成
如果你加入了其它paradigm，那可能会带来$110的收益
which也是你一直强调的部分
但是同时别人告诉你的是，会有另外一种可能
导致这$100的收益打折扣，变成0收益甚至是负收益的时候
知道了这个，你还会毫不犹豫地投入使用吗？
如果以上两种可能都存在，我们就做一个简单的估算，它们可能发生的概率相等吧
那么算一下expect value，你就能判断出来是否需要投入了
实际上别人在跟你说的时候，举出的例子往往都是项目彻底失败的例子
项目如果失败了，那一点优势相比之下就显得过于无足轻重了
而软件工程强调的一直都是，这个星球上，接近一半的项目是失败的
而在70年代，这个比例高达四分之三，现在经过多年摸索，有了大幅进步
但是不管怎样，失败的比例还是很高，至于为什么
这就是软件工程天天研究的问题，实际上也是所有工程学倒腾的问题
软件工程里面很讲究人的问题，普遍看法是
没有绝对完美的人，人都有问题，指望一个完美的人来干活是不切实际的
如果人的问题不可避免，那唯一能做的就是方法论了，否则就不需要软件工程这个学科
而别人跟你说的，其实就是你这个方法本身的问题
不要回避这些问题，悬崖不会因为你的闭眼而消失
其实你们用scala也没有什么很fancy的理由
就是之前用ruby，鉴于jvm的强大性能，想利用上jvm，又不想让之前的努力白费
所以两者权衡了一下，就选择了语法相近的scala
。
【在 c******o 的大作中提到】
: async/concurrency is always hard, at least FP/OO hybrid make it easier.
|
z****e
发帖数: 54598 | 10 其实jvm上最hot最facny的paradigm一直都是meta programming
元数据编程，每一次jdk的版本号更新，这一块都是引起广泛讨论的地方
也是高手跟初级码农的分界线所在
这个对于其它语言，其实也差不多 |
|
|
z****e
发帖数: 54598 | 11 所谓做软件工程就犹如带兵打仗或者做教练指挥球队踢球
就好比一个教练上来对你说，我只有指挥皇马或者曼联才能赢球
我只有指挥顶级强队才能赢球，你觉得这会是一个好教练么？
至少我不这么认为，我认为一个好教练，他能让三流队踢赢一线队
而不是反过来，那么当一个三流队里面没有c罗也没有梅西的时候
该怎么办？嗯 |
c******o
发帖数: 1277 | 12 说得不好，oo不知道，fp肯定有帮助，主要是immutability 和 更好的抽象包装。
【在 p*****2 的大作中提到】
:
: async/concurrency跟FP/OO有什么直接的关系吗？
|
G***l
发帖数: 355 | 13 FP跟OO共存没有问题，一些简单的FP style完全可以在oo方法的内部存在，反之不是很
方便，因为object天然比较heavy，没有function简单灵活。
抛开最底层的代码共存。模块共存还是很容易的。我的个人经验是，一定要定义好功能
模块，就算纯OO也要这么做不是嘛。然后一部分模块适合fp的用fp，别的还是用oo。我
的business logic和算法很多就是纯FP的方式写的。另外有一部分有FP里面会调用OO的
模块或者class，但是把state限制的function内部。其他分就是传统的OO了，但是会在
method level有一些fp的方式或者调用fp的模块。其实写代码，最重要可维护性，可读
性，可测试，不易出错。自从我用C#和F#混合编程之后，核心代码(business logic,
算法)的维护性和可读性都提高了很多。
。
【在 c******o 的大作中提到】
: 说得不好，oo不知道，fp肯定有帮助，主要是immutability 和 更好的抽象包装。
|
c******o
发帖数: 1277 | 14 我知道坏处，我只是觉得好处更大。
当然每个团队要自己衡量。但是你怎么知道一定是110/0的 trade off
我只是说我知道的好处，也没否认别人的坏处。
你急啥.....
你说我说的哪儿不对吧。 我不清楚的一般我也不说话。
【在 z****e 的大作中提到】
: 你最大的问题就是，你一直在说某个东西好，好在哪里
: 而别人总是在跟你说，这个东西坏在哪里，而你总是听不进去
: 现实生活中，各种paradigm都有好处，这也是最初这些东西的本意
: 但是各种paradigm都有坏处，那怎么取舍就显得很重要
: 就好比你一个价值$100的项目，如果你用oop来实现，基本上可以完成
: 如果你加入了其它paradigm，那可能会带来$110的收益
: which也是你一直强调的部分
: 但是同时别人告诉你的是，会有另外一种可能
: 导致这$100的收益打折扣，变成0收益甚至是负收益的时候
: 知道了这个，你还会毫不犹豫地投入使用吗？
|
G***l
发帖数: 355 | 15 没有坏处的语言根本就不存在。能发挥其优点就是好的。
【在 c******o 的大作中提到】
: 我知道坏处，我只是觉得好处更大。
: 当然每个团队要自己衡量。但是你怎么知道一定是110/0的 trade off
: 我只是说我知道的好处，也没否认别人的坏处。
: 你急啥.....
: 你说我说的哪儿不对吧。 我不清楚的一般我也不说话。
|
x****u
发帖数: 44466 | 16 我比较同意你这个观点，另外教练一般都不是比球员更好的职业。
【在 z****e 的大作中提到】
: 所谓做软件工程就犹如带兵打仗或者做教练指挥球队踢球
: 就好比一个教练上来对你说，我只有指挥皇马或者曼联才能赢球
: 我只有指挥顶级强队才能赢球，你觉得这会是一个好教练么？
: 至少我不这么认为，我认为一个好教练，他能让三流队踢赢一线队
: 而不是反过来，那么当一个三流队里面没有c罗也没有梅西的时候
: 该怎么办？嗯
|
p*****2
发帖数: 21240 | 17
node.js没有imuutability, 但是async, concurrency都很不错呀。而且我觉得
immutability性能可能不行，想优化的时候还是需要mutability, 所以Clojure和Scala
都有STM。
【在 c******o 的大作中提到】
: 说得不好，oo不知道，fp肯定有帮助，主要是immutability 和 更好的抽象包装。
|
c******o
发帖数: 1277 | 18 immutability 主要是能帮助下面的common pitfall
Parallel => Cache coherence
Async => Races
Distributed => Versioning
性能倒是有可能的，但是主要是当data structure 非常大的时候。
scala的immutable collection 不比 mutable差，有时候还更好。
http://www.scala-lang.org/docu/files/collections-api/collection
Scala
【在 p*****2 的大作中提到】
:
: node.js没有imuutability, 但是async, concurrency都很不错呀。而且我觉得
: immutability性能可能不行，想优化的时候还是需要mutability, 所以Clojure和Scala
: 都有STM。
|
c******o
发帖数: 1277 | 19 比喻不恰当啊，你要证明能以三流队踢赢一线队。
一个三流的java团队会比一流的的scala团队好么？
一流的scala团队本身多数就是一流的java团队。
我觉得合适的比喻是， 你愿意做风险100倍的option呢？ 还是10倍的股票呢？
两个都能赚，也能亏，你觉得能handle option，就做呗。如果你控制风险好，会hedge
那就更好了，选option呗。
【在 z****e 的大作中提到】
: 所谓做软件工程就犹如带兵打仗或者做教练指挥球队踢球
: 就好比一个教练上来对你说，我只有指挥皇马或者曼联才能赢球
: 我只有指挥顶级强队才能赢球，你觉得这会是一个好教练么？
: 至少我不这么认为，我认为一个好教练，他能让三流队踢赢一线队
: 而不是反过来，那么当一个三流队里面没有c罗也没有梅西的时候
: 该怎么办？嗯
|
z****e
发帖数: 54598 | 20 这么说，是三线队还是一线队，看的是你team里面人的水平
如果水平不行，铁桶加反击其实很强大，怕就怕不是一线队，又上一线队的战术
那郑智什么，你指望它做孔卡做梅西，那是不现实的
三流的java团队可以把项目做成，这就可以了，这样就能在市场上跟一线团队掰掰手腕
实际上我用fp最多的是在ui里面，等java8出来
lambda第一个应用我估计就是javafx里面的eventhandler
前几天oracle更新了一下java的tutorial，我看lambda里面的例子就拿了javafx做例子
很直接，也很清晰，但是java的gui做得一直是最烂的一块，我维护过swing代码
写得那叫一个烂哟，我做java其它任何部分都没有遇到过那么垃圾的代码
另外就是，少写几个单词其实不会对productivity有多大影响
多写几个单词，其实也慢不到哪里去，但是少写几个单词
却有可能导致维护成本大幅上升，所以trade off下来，expected value很可能是
negative
现在python对ruby/perl的进逼也多少说明了这一点
hedge
【在 c******o 的大作中提到】
: 比喻不恰当啊，你要证明能以三流队踢赢一线队。
: 一个三流的java团队会比一流的的scala团队好么？
: 一流的scala团队本身多数就是一流的java团队。
: 我觉得合适的比喻是， 你愿意做风险100倍的option呢？ 还是10倍的股票呢？
: 两个都能赚，也能亏，你觉得能handle option，就做呗。如果你控制风险好，会hedge
: 那就更好了，选option呗。
|
|
|
z****e
发帖数: 54598 | 21 这个主要是文体明星曝光率高
如果比喻成工程师和民工的话，那就是另外一回事了
我们不能指望所有民工都懂西洋艺术，如何造性美观那是建筑师的事
让我想起以前国内外企一个笑话
某台湾的高管，装逼，用英文写邮件
结果下面人回说看不懂，高管怒，斥之不懂洋文
下属亦怒，回曰：你见过一个月只拿两千不到的人懂英文的吗？
【在 x****u 的大作中提到】
: 我比较同意你这个观点，另外教练一般都不是比球员更好的职业。
|
z****e
发帖数: 54598 | 22 实际上编程语言发展到今天，指望通过某一种paradigm达到几倍效率的目的
其实是不现实的，十多年前，其实我就感觉，oop已经把很多东西做到了极致
再往后，要通过改变paradigm来实现数倍的效率提升，这是不太可能的
只能说改一点，优化一点，这就是rod johnson为什么说
我不认为将来会出现跟java一样如此大面积使用的语言
实际上java之前也就是c达到了这个程度
hedge
【在 c******o 的大作中提到】
: 比喻不恰当啊，你要证明能以三流队踢赢一线队。
: 一个三流的java团队会比一流的的scala团队好么？
: 一流的scala团队本身多数就是一流的java团队。
: 我觉得合适的比喻是， 你愿意做风险100倍的option呢？ 还是10倍的股票呢？
: 两个都能赚，也能亏，你觉得能handle option，就做呗。如果你控制风险好，会hedge
: 那就更好了，选option呗。
|
x****u
发帖数: 44466 | 23 国内总是有人幻想通过xx技术，民工就可以懂英文了。
【在 z****e 的大作中提到】
: 这个主要是文体明星曝光率高
: 如果比喻成工程师和民工的话，那就是另外一回事了
: 我们不能指望所有民工都懂西洋艺术，如何造性美观那是建筑师的事
: 让我想起以前国内外企一个笑话
: 某台湾的高管，装逼，用英文写邮件
: 结果下面人回说看不懂，高管怒，斥之不懂洋文
: 下属亦怒，回曰：你见过一个月只拿两千不到的人懂英文的吗？
|
d******3
发帖数: 70 | |
