g*****g
发帖数: 34805 | 1 王垠关于OOP跟FP modeling的这部分说得不错。但这些学术界程序语言出身的人，
始终没有意识到，编程首先是个工程问题。从C++到Scala，这些混合型的编程语言
都给程序员造成了很大困惑，因为能切换paradigm本身就意味着，同一个问题可以
存在多种实现。如果一个问题可以切割成10个小的方法实现，而每个方法必须用纯OOP
或者
FP实现的话，一个问题的可能实现就是2^10 = 1024种，很显然，如果团队没有硬性的
规定，
没有两种实现会是一样的。
当程序员都素质比较高，比较有经验的时候，也许这不是问题。当工程越复杂，团队越
大的时候，
就越容易有人不理解或者错误理解其他人的代码，产生bug。这就回到了我一直强调的
短板问题。
大部分语言都有OOP和FP混合的痕迹，纯粹的语言(smalltalk, haskell)在业界基本不
用。
建模和语言设计，始终是个取舍，不用语言取舍不同。Scala是混合的极端，Java是OO
加上极少的非OO部分(primitive，anonymous inner class)。C#, Python, JS等在中间。
很显然，这个没有简单的对错好坏。而跟项目的business case，比如需要维护多长时
间，出bug的影响有多大，团队的素质和大小等等都有关系。但简单地批评一个语言没
有另一个paradigm的feature，造成overhead，同样是短视的。因为虽然不能最合理的
建模，但是可以简化语法，简化编译器，让用户不用切换思维模式，而且，不是所有语
言都是设计为
通用程序语言。到头来，我老是唯结果论者，是骡子是马拉出来遛，活下来的就是合理
的。 |
c****3
发帖数: 10787 | 2 其实啥modeling也不需要管。根据项目，找到最合适的从上到下的方法。项目要求不同
，方法自然可以不同。非要生搬硬套某种现成方法，那是书呆子。
OOP
【在 g*****g 的大作中提到】
: 王垠关于OOP跟FP modeling的这部分说得不错。但这些学术界程序语言出身的人，
: 始终没有意识到，编程首先是个工程问题。从C++到Scala，这些混合型的编程语言
: 都给程序员造成了很大困惑，因为能切换paradigm本身就意味着，同一个问题可以
: 存在多种实现。如果一个问题可以切割成10个小的方法实现，而每个方法必须用纯OOP
: 或者
: FP实现的话，一个问题的可能实现就是2^10 = 1024种，很显然，如果团队没有硬性的
: 规定，
: 没有两种实现会是一样的。
: 当程序员都素质比较高，比较有经验的时候，也许这不是问题。当工程越复杂，团队越
: 大的时候，
|
p*****2
发帖数: 21240 | 3 顶大牛。
我觉得理想的状态是用最合适的语言解决相应的问题。我也是一直往这个方向努力的，
也就是不限于同一种语言。但是我不得不承认没有几个程序员愿意这么做。绝大部分都
是希望保持在一种语言上。虽然某种语言解决某类问题是比较恶心，但是换一种语言可
能overhead更大。最后这个都是取舍的问题，推倒重来的也不是没有。
对于一个程序员来说，最好能做到自身的灵活性，也就是李小龙曾经说过的，程序员是
水的道理。但是对于工程来讲，有非常大的需求能够尽量少的语言解决问题。这也是为
什么goodbug, zhaoce推崇Java的原因了。 |
c****3
发帖数: 10787 | 4 业界做GUI基本都是OO，因为做界面是体力活，项目人员水平肯定参差不齐。OO最容易
控制水平差的那些人，还可以外包出去。而且速度快点慢点没关系。
做嵌入系统和比较底层的，除了大公司，基本没有人用OO的。用OO的会发现最后往往处
于一种尴尬的境地。对这种项目，能多花钱找到水平高的人更重要。 |
p*****2
发帖数: 21240 | 5
现在不是比OO和FP吗？从FP的角度来讲OO就是imperative。
【在 c****3 的大作中提到】
: 业界做GUI基本都是OO，因为做界面是体力活，项目人员水平肯定参差不齐。OO最容易
: 控制水平差的那些人，还可以外包出去。而且速度快点慢点没关系。
: 做嵌入系统和比较底层的，除了大公司，基本没有人用OO的。用OO的会发现最后往往处
: 于一种尴尬的境地。对这种项目，能多花钱找到水平高的人更重要。
|
g*****g
发帖数: 34805 | 6 从现实的角度，我承认一种语言不能解决所有的问题。即使一种语言可以实现，不同领
域的知识差异很大。
比如Android和server backend。语言只是做这个工作要求很小的一部分。
我认为术业有专攻，学得多不如学得深。不追求成为full stack程序员，而追求成为一
个在某需求较大领域的专家。把学不同语言的功夫放在熟悉各种类库上。当然人各有志。
【在 p*****2 的大作中提到】
: 顶大牛。
: 我觉得理想的状态是用最合适的语言解决相应的问题。我也是一直往这个方向努力的，
: 也就是不限于同一种语言。但是我不得不承认没有几个程序员愿意这么做。绝大部分都
: 是希望保持在一种语言上。虽然某种语言解决某类问题是比较恶心，但是换一种语言可
: 能overhead更大。最后这个都是取舍的问题，推倒重来的也不是没有。
: 对于一个程序员来说，最好能做到自身的灵活性，也就是李小龙曾经说过的，程序员是
: 水的道理。但是对于工程来讲，有非常大的需求能够尽量少的语言解决问题。这也是为
: 什么goodbug, zhaoce推崇Java的原因了。
|
d****i
发帖数: 4809 | 7 那是因为GUI本身比较适合用OO，一个窗口，还有菜单，按钮等等，而像系统底层的东
西如果用OO的话就是灾难性的，这也是为什么OS的内核还有嵌入式的代码都是C而很少
用C++的原因。
【在 c****3 的大作中提到】
: 业界做GUI基本都是OO，因为做界面是体力活，项目人员水平肯定参差不齐。OO最容易
: 控制水平差的那些人，还可以外包出去。而且速度快点慢点没关系。
: 做嵌入系统和比较底层的，除了大公司，基本没有人用OO的。用OO的会发现最后往往处
: 于一种尴尬的境地。对这种项目，能多花钱找到水平高的人更重要。
|
c****3
发帖数: 10787 | 8 你不能纯粹从语言或者方法的角度看问题。要从项目和人员的角度看问题，做选择。
OO是讲究抽象，抽象的结果是结构设计的好，傻子也能加入team，一起写代码。
但问题是OO太抽象了，不太符合人的思维习惯，找问题的时候太费劲。因为抽象，很多
问题又隐藏起来，非常难找。
FP是不太合适协作，对人的要求也比较高，但是符合人的思维习惯，找问题相对容易。
所以在嵌入系统和底层，这种需要非常深debug能力的地方，用OO很多问题都要费太多
的力气才能找到原因了。系统一复杂，最后很多都搞不下去了
Fix bug是看项目开发超过50%以上精力的事情，那种方式便于debug，这点一定要考虑
。OO做GUI，bug多反正也能凑合用，以后可以慢慢修。嵌入和底层，bug一多，大家都
要骂娘了。
【在 p*****2 的大作中提到】
:
: 现在不是比OO和FP吗？从FP的角度来讲OO就是imperative。
|
d****i
发帖数: 4809 | 9 嗯，其实保持语言的简洁易读性还是很重要的，尽管可能看上去代码多一点。像Java 8
里面某些人要仿效其他语言加入的lambda就是一个语法糖绣花枕头，匿名内部类用了这
么多年了不是好好的，偏要加一些虚头花脑fancy的东西，实质上编译出来的bytecode
可能还不如匿名内部类有效。
OOP
【在 g*****g 的大作中提到】
: 王垠关于OOP跟FP modeling的这部分说得不错。但这些学术界程序语言出身的人，
: 始终没有意识到，编程首先是个工程问题。从C++到Scala，这些混合型的编程语言
: 都给程序员造成了很大困惑，因为能切换paradigm本身就意味着，同一个问题可以
: 存在多种实现。如果一个问题可以切割成10个小的方法实现，而每个方法必须用纯OOP
: 或者
: FP实现的话，一个问题的可能实现就是2^10 = 1024种，很显然，如果团队没有硬性的
: 规定，
: 没有两种实现会是一样的。
: 当程序员都素质比较高，比较有经验的时候，也许这不是问题。当工程越复杂，团队越
: 大的时候，
|
t*******h
发帖数: 2882 | 10 你这是完全从程序员的角度看问题。从公司角度看，便于开发、易于维护才是最重要的。
【在 p*****2 的大作中提到】
: 顶大牛。
: 我觉得理想的状态是用最合适的语言解决相应的问题。我也是一直往这个方向努力的，
: 也就是不限于同一种语言。但是我不得不承认没有几个程序员愿意这么做。绝大部分都
: 是希望保持在一种语言上。虽然某种语言解决某类问题是比较恶心，但是换一种语言可
: 能overhead更大。最后这个都是取舍的问题，推倒重来的也不是没有。
: 对于一个程序员来说，最好能做到自身的灵活性，也就是李小龙曾经说过的，程序员是
: 水的道理。但是对于工程来讲，有非常大的需求能够尽量少的语言解决问题。这也是为
: 什么goodbug, zhaoce推崇Java的原因了。
|
|
|
g*****g
发帖数: 34805 | 11 这更多是追求效率的原因。我读书的时候做一些网络协议的比较，就用Java做模拟实现
，因为只需要比较相对速度。
【在 d****i 的大作中提到】
: 那是因为GUI本身比较适合用OO，一个窗口，还有菜单，按钮等等，而像系统底层的东
: 西如果用OO的话就是灾难性的，这也是为什么OS的内核还有嵌入式的代码都是C而很少
: 用C++的原因。
|
g*****g
发帖数: 34805 | 12 应该说大多数人都连匿名内部类都不经常写，所以无所谓。但对于一些async,
concurrency类库
开发和使用者就用得很多，他们就希望加入这些feature，这些人的素质也相对高。这
个东西好坏难说，但是加上去了就不能回头。所以从java 7推到java 8，现在还在辩论。
8
bytecode
【在 d****i 的大作中提到】
: 嗯，其实保持语言的简洁易读性还是很重要的，尽管可能看上去代码多一点。像Java 8
: 里面某些人要仿效其他语言加入的lambda就是一个语法糖绣花枕头，匿名内部类用了这
: 么多年了不是好好的，偏要加一些虚头花脑fancy的东西，实质上编译出来的bytecode
: 可能还不如匿名内部类有效。
:
: OOP
|
d****i
发帖数: 4809 | 13 嵌入系统和底层不能用OO的主要原因是：
1. C++比C还是有些overhead
2. C++的编译器很难优化
3. C更接近机器码指令集
4. 底层的东西完全是bare metal的光膀子裸干，就是需要像C这样的猛汉利刃单刀直入
和硬件talk，而不是C++的这种OO的犹抱琵琶半遮面。
【在 c****3 的大作中提到】
: 你不能纯粹从语言或者方法的角度看问题。要从项目和人员的角度看问题，做选择。
: OO是讲究抽象，抽象的结果是结构设计的好，傻子也能加入team，一起写代码。
: 但问题是OO太抽象了，不太符合人的思维习惯，找问题的时候太费劲。因为抽象，很多
: 问题又隐藏起来，非常难找。
: FP是不太合适协作，对人的要求也比较高，但是符合人的思维习惯，找问题相对容易。
: 所以在嵌入系统和底层，这种需要非常深debug能力的地方，用OO很多问题都要费太多
: 的力气才能找到原因了。系统一复杂，最后很多都搞不下去了
: Fix bug是看项目开发超过50%以上精力的事情，那种方式便于debug，这点一定要考虑
: 。OO做GUI，bug多反正也能凑合用，以后可以慢慢修。嵌入和底层，bug一多，大家都
: 要骂娘了。
|
c****3
发帖数: 10787 | 14 你这是书本上的。
实际工作你会发现越是抽象，不符合人的思维习惯，带来的副作用是问题隐藏的越深。
C相对简单，语言特性也少，好处就是直截了当。有啥问题比较容易找，debug也简单点。
【在 d****i 的大作中提到】
: 嵌入系统和底层不能用OO的主要原因是：
: 1. C++比C还是有些overhead
: 2. C++的编译器很难优化
: 3. C更接近机器码指令集
: 4. 底层的东西完全是bare metal的光膀子裸干，就是需要像C这样的猛汉利刃单刀直入
: 和硬件talk，而不是C++的这种OO的犹抱琵琶半遮面。
|
d****i
发帖数: 4809 | 15 这个是我们在工作中的实际经历，我们用过几个不同的公司的嵌入式系统run在不同的
RTOS上的C/C++编译器，C从来没有出过问题，但是德州仪器和GreenHills的C++编译器
都发现过小错误。而且在测试中发现同样的code,C的效率比C++好10%左右。非嵌入式的
台式机上是另外一回事。
点。
【在 c****3 的大作中提到】
: 你这是书本上的。
: 实际工作你会发现越是抽象，不符合人的思维习惯，带来的副作用是问题隐藏的越深。
: C相对简单，语言特性也少，好处就是直截了当。有啥问题比较容易找，debug也简单点。
|
c******o
发帖数: 1277 | 16 OOP和FP都会总是好的，我学的FP让我回头改Java/Ruby code的时候也受益非浅
我只是觉得application developer 实在是没啥意思，还是那些system/library
designer有意思，用的东西又有趣又优雅。
大家有精力的，还是在某一个有趣和实用的方面深专研一下，写个有意义的Open
Source library/system, 绝对名利双收。很多有意义的Open Source library/system
其实主创就一两个，你要是看他们的code,就知道，虽然不错，但是一遍一遍改，大部
分码工也能写出来，就是用不用心，花不花时间的问题。
其实我们争论的东西也基本都是大部分code monkey 用不到的。 |
z****e
发帖数: 54598 | 17 现在做嵌入系统和比较底层的市场一天比一天小
ee都开始批量转行cs
这也没啥好奇怪的，很多东西，第三世界国家，比如天朝
都很容易抄袭过去，只要没有真正意义上的突破
但是底层这些东西，从某种意义上说也没啥好突破的
os再突破又能做啥？还不就是os那些东西
os之后做jvm，jvm之后做app server，这两个阶段都花了十年时间
现在app server之后做cloud，算是进入了新领域，旧的领域留下点人慢慢维护就是了
新领域永远都是吸收人手和提供工作机会以及资金涌入的大头
【在 c****3 的大作中提到】
: 其实啥modeling也不需要管。根据项目，找到最合适的从上到下的方法。项目要求不同
: ，方法自然可以不同。非要生搬硬套某种现成方法，那是书呆子。
:
: OOP
|
z****e
发帖数: 54598 | 18 现实生活中我发现，恰恰就是gui用oo用得很糟糕
swing算是很纯粹的oop了，但是现实生活中，包括教材里面的例子
用得一塌糊涂的大有人在，java的gui也是所有模块中最糟糕的一块
awt和swing，现在还有多少人在用这两个东西？
相比之下，反而是server side的oo用得很漂亮，很精准
所以java其它模块爆炸式增长，都发展到cloud上去了
【在 d****i 的大作中提到】
: 那是因为GUI本身比较适合用OO，一个窗口，还有菜单，按钮等等，而像系统底层的东
: 西如果用OO的话就是灾难性的，这也是为什么OS的内核还有嵌入式的代码都是C而很少
: 用C++的原因。
|
g*****g
发帖数: 34805 | 19 gui的决定力量是平台，想想 android.
【在 z****e 的大作中提到】
: 现实生活中我发现，恰恰就是gui用oo用得很糟糕
: swing算是很纯粹的oop了，但是现实生活中，包括教材里面的例子
: 用得一塌糊涂的大有人在，java的gui也是所有模块中最糟糕的一块
: awt和swing，现在还有多少人在用这两个东西？
: 相比之下，反而是server side的oo用得很漂亮，很精准
: 所以java其它模块爆炸式增长，都发展到cloud上去了
|
z****e
发帖数: 54598 | 20 匿名内部类sucks
我从来不用匿名类
除了在做gui时候偷懒时候才用
backend我从来不用这个东西
8
bytecode
【在 d****i 的大作中提到】
: 嗯，其实保持语言的简洁易读性还是很重要的，尽管可能看上去代码多一点。像Java 8
: 里面某些人要仿效其他语言加入的lambda就是一个语法糖绣花枕头，匿名内部类用了这
: 么多年了不是好好的，偏要加一些虚头花脑fancy的东西，实质上编译出来的bytecode
: 可能还不如匿名内部类有效。
:
: OOP
|
|
|
z****e
发帖数: 54598 | 21 所以抽象的东西容错性要求很高
java比c++当初强的一个feature就是exception的处理
实际上大项目没有bug是不可能的
那么出现了bug，要如何保证其不致于把整个系统给拖垮
就显得很重要，软件工程就好比战争
战场上谁都会犯错，那就看谁犯的错少一点，或者说犯的错小一点
点。
【在 c****3 的大作中提到】
: 你这是书本上的。
: 实际工作你会发现越是抽象，不符合人的思维习惯，带来的副作用是问题隐藏的越深。
: C相对简单，语言特性也少，好处就是直截了当。有啥问题比较容易找，debug也简单点。
|
N******K
发帖数: 10202 | 22 我怎么觉得OO才符合人的思维 FP是机器思维
【在 c****3 的大作中提到】
: 你不能纯粹从语言或者方法的角度看问题。要从项目和人员的角度看问题，做选择。
: OO是讲究抽象，抽象的结果是结构设计的好，傻子也能加入team，一起写代码。
: 但问题是OO太抽象了，不太符合人的思维习惯，找问题的时候太费劲。因为抽象，很多
: 问题又隐藏起来，非常难找。
: FP是不太合适协作，对人的要求也比较高，但是符合人的思维习惯，找问题相对容易。
: 所以在嵌入系统和底层，这种需要非常深debug能力的地方，用OO很多问题都要费太多
: 的力气才能找到原因了。系统一复杂，最后很多都搞不下去了
: Fix bug是看项目开发超过50%以上精力的事情，那种方式便于debug，这点一定要考虑
: 。OO做GUI，bug多反正也能凑合用，以后可以慢慢修。嵌入和底层，bug一多，大家都
: 要骂娘了。
|
m******t
发帖数: 635 | 23 如果你看Alan Kay （OO的发明者和先驱）的访谈，会发现他最开始是受到Lisp的启发
，那个时候还没有C和Unix呢。
OO和FP都和机器实现无关，应该说两个都是对世界的一种抽象，OO更多的抽象出世界的
变化的部分，而FP则是试图抽象出世界不变的部分（比如数学规律等等）。对于计算的
抽象也有两个模型：图灵机 和 lambda演算，前者更加接近物理机器的实现，也奠定了
我们目前的计算基础，后者直接引申出FP。扯这么多就想说一句：FP不是机器思维，而
更像数学思维。
【在 N******K 的大作中提到】
: 我怎么觉得OO才符合人的思维 FP是机器思维
|
z****e
发帖数: 54598 | 24 fp更靠近科学的思维
【在 N******K 的大作中提到】
: 我怎么觉得OO才符合人的思维 FP是机器思维
|
z****e
发帖数: 54598 | 25 跛脚的数学，因为数学符号不足以被键盘上的符号所表达
oop和fp的区别就类似工程和科学的区别一样
不过cs这种抽象本身就不是真正意义上的科学，所以这里面还有距离
【在 m******t 的大作中提到】
: 如果你看Alan Kay （OO的发明者和先驱）的访谈，会发现他最开始是受到Lisp的启发
: ，那个时候还没有C和Unix呢。
: OO和FP都和机器实现无关，应该说两个都是对世界的一种抽象，OO更多的抽象出世界的
: 变化的部分，而FP则是试图抽象出世界不变的部分（比如数学规律等等）。对于计算的
: 抽象也有两个模型：图灵机 和 lambda演算，前者更加接近物理机器的实现，也奠定了
: 我们目前的计算基础，后者直接引申出FP。扯这么多就想说一句：FP不是机器思维，而
: 更像数学思维。
|
b*******s
发帖数: 5216 | 26 fp不是很懂，问问现在能解决什么类型的工程问题
【在 z****e 的大作中提到】
: 跛脚的数学，因为数学符号不足以被键盘上的符号所表达
: oop和fp的区别就类似工程和科学的区别一样
: 不过cs这种抽象本身就不是真正意义上的科学，所以这里面还有距离
|
c****3
发帖数: 10787 | 27 每个人思维习惯不一样。大部分人还是觉得FP符合自己的思维习惯。
【在 N******K 的大作中提到】
: 我怎么觉得OO才符合人的思维 FP是机器思维
|
c****3
发帖数: 10787 | 28 就是Functional programming，象C语言这种直上直下的思考，没有抽象，没有类，都
是FP
【在 b*******s 的大作中提到】
: fp不是很懂，问问现在能解决什么类型的工程问题
|
g*****g
发帖数: 34805 | 29 OO接近宏观物理的思维，FP接近数学的思维。世界用物理还是用数学来描述更容易理解
应该是没啥好争议的。
【在 c****3 的大作中提到】
: 每个人思维习惯不一样。大部分人还是觉得FP符合自己的思维习惯。
|
m******t
发帖数: 635 | 30 Haskell这样的学术型FP不实用，不能代表所有的FP语言。早的F#和Ocaml，近的Scala
和Clojure都很有希望。
OO和FP不是一定就互斥的，c#加了很多的FP功能，Java8也会跟着。大家不是吃饱了撑
的这么做的，对吧？
【在 z****e 的大作中提到】
: 跛脚的数学，因为数学符号不足以被键盘上的符号所表达
: oop和fp的区别就类似工程和科学的区别一样
: 不过cs这种抽象本身就不是真正意义上的科学，所以这里面还有距离
|
|
|
b*******s
发帖数: 5216 | 31 主要解决哪个问题域的东西呢？多谢
【在 c****3 的大作中提到】
: 就是Functional programming，象C语言这种直上直下的思考，没有抽象，没有类，都
: 是FP
|
g*****g
发帖数: 34805 | 32 C语言哪能算functional，就是procedure。
【在 c****3 的大作中提到】
: 就是Functional programming，象C语言这种直上直下的思考，没有抽象，没有类，都
: 是FP
|
z****e
发帖数: 54598 | 33 只能说批判性滴接纳一部分功能，有主次之分
我看了haskell的语法倒是挺喜欢的
至少比scala爽点，更靠近数学家的符号
Scala
【在 m******t 的大作中提到】
: Haskell这样的学术型FP不实用，不能代表所有的FP语言。早的F#和Ocaml，近的Scala
: 和Clojure都很有希望。
: OO和FP不是一定就互斥的，c#加了很多的FP功能，Java8也会跟着。大家不是吃饱了撑
: 的这么做的，对吧？
|
z****e
发帖数: 54598 | 34 工程问题解决不了，别指望fp了
oop才是工程学直接拿过来的东西
oo这个概念都不是cs这群人发明的
就是传统工程学发明的概念
造灰机那群人发明的，java里面很多概念都是直接从造灰机那边拿过来的
【在 b*******s 的大作中提到】
: fp不是很懂，问问现在能解决什么类型的工程问题
|
b*******s
发帖数: 5216 | 35 java最初的初衷是智能家电好像
【在 z****e 的大作中提到】
: 工程问题解决不了，别指望fp了
: oop才是工程学直接拿过来的东西
: oo这个概念都不是cs这群人发明的
: 就是传统工程学发明的概念
: 造灰机那群人发明的，java里面很多概念都是直接从造灰机那边拿过来的
|
z****e
发帖数: 54598 | 36 java本来打算做这一块，结果没成
就像随后applet红了一阵之后，结果也没成
最后在server side被发扬光大完全出乎原作者的意料之外
【在 b*******s 的大作中提到】
: java最初的初衷是智能家电好像
|
b*******s
发帖数: 5216 | 37 中间还有个java芯片的阶段，试图解决速度慢的问题
【在 z****e 的大作中提到】
: java本来打算做这一块，结果没成
: 就像随后applet红了一阵之后，结果也没成
: 最后在server side被发扬光大完全出乎原作者的意料之外
|
z****e
发帖数: 54598 | 38 其实这个也解决了，但是成本太高，没人用，就不管了
【在 b*******s 的大作中提到】
: 中间还有个java芯片的阶段，试图解决速度慢的问题
|
N******K
发帖数: 10202 | 39 系统工程科学 用OOP很合适
比如描述控制系统的各个子系统 或者社会的组织模块
【在 z****e 的大作中提到】
: fp更靠近科学的思维
|
p*****2
发帖数: 21240 | 40
的。
大牛你完全没有看全我所说的。
【在 t*******h 的大作中提到】
: 你这是完全从程序员的角度看问题。从公司角度看，便于开发、易于维护才是最重要的。
|
|
|
g*********9
发帖数: 1285 | 41 OOP用起来方便，但读起来费劲，那些overriding和overloading要是被abuse了，一层
套一层读起来累死你，
【在 z****e 的大作中提到】
: 所以抽象的东西容错性要求很高
: java比c++当初强的一个feature就是exception的处理
: 实际上大项目没有bug是不可能的
: 那么出现了bug，要如何保证其不致于把整个系统给拖垮
: 就显得很重要，软件工程就好比战争
: 战场上谁都会犯错，那就看谁犯的错少一点，或者说犯的错小一点
:
: 点。
|
b*******s
发帖数: 5216 | 42 现在谁还用overriding
【在 g*********9 的大作中提到】
: OOP用起来方便，但读起来费劲，那些overriding和overloading要是被abuse了，一层
: 套一层读起来累死你，
|
z****e
发帖数: 54598 | 43 楼上说得对
现在谁还用多态和重载
spring出现之后，都是pojo
如果严重依赖多态和重载的话
说明设计上有问题，现在连ejb都pojo化了
【在 g*********9 的大作中提到】
: OOP用起来方便，但读起来费劲，那些overriding和overloading要是被abuse了，一层
: 套一层读起来累死你，
|
z****e
发帖数: 54598 | 44 oop三个特性里面，其它两个其实无足轻重
最重要的是封装，soa的核心思想也是封装 |
p*****2
发帖数: 21240 | 45
志。
而追求成为一
个在某需求较大领域的专家
大牛说的不错。不过像大牛这么有眼光，20年前就预断到Java干死C++的太少了吧？
【在 g*****g 的大作中提到】
: 从现实的角度，我承认一种语言不能解决所有的问题。即使一种语言可以实现，不同领
: 域的知识差异很大。
: 比如Android和server backend。语言只是做这个工作要求很小的一部分。
: 我认为术业有专攻，学得多不如学得深。不追求成为full stack程序员，而追求成为一
: 个在某需求较大领域的专家。把学不同语言的功夫放在熟悉各种类库上。当然人各有志。
|
h*****a
发帖数: 1718 | 46 我现在感觉语言是比较次要的问题，工具比语言重要。现在不同语言的交互比较容易了。
【在 p*****2 的大作中提到】
: 顶大牛。
: 我觉得理想的状态是用最合适的语言解决相应的问题。我也是一直往这个方向努力的，
: 也就是不限于同一种语言。但是我不得不承认没有几个程序员愿意这么做。绝大部分都
: 是希望保持在一种语言上。虽然某种语言解决某类问题是比较恶心，但是换一种语言可
: 能overhead更大。最后这个都是取舍的问题，推倒重来的也不是没有。
: 对于一个程序员来说，最好能做到自身的灵活性，也就是李小龙曾经说过的，程序员是
: 水的道理。但是对于工程来讲，有非常大的需求能够尽量少的语言解决问题。这也是为
: 什么goodbug, zhaoce推崇Java的原因了。
|
p*****2
发帖数: 21240 | 47
了。
大牛说的太对了。其实我的表达有误。我想表达的正是工具的意思。我认为语言也是工
具。
【在 h*****a 的大作中提到】
: 我现在感觉语言是比较次要的问题，工具比语言重要。现在不同语言的交互比较容易了。
|
l******t
发帖数: 55733 | 48
你理解不了匿名类，pojo和FP的关系
【在 z****e 的大作中提到】
: 楼上说得对
: 现在谁还用多态和重载
: spring出现之后，都是pojo
: 如果严重依赖多态和重载的话
: 说明设计上有问题，现在连ejb都pojo化了
|
z****e
发帖数: 54598 | 49 那你给zkss
【在 l******t 的大作中提到】
:
: 你理解不了匿名类，pojo和FP的关系
|
l******t
发帖数: 55733 | 50
可以这么理解吧，匿名类根本就是为了支持lambda的。pojo基本是lambda的另一种形式
。我记得
programming Scala有章专门讲替代spring的approach。
design pattern的出现基本是因为第一没first order function，第二没type/traits
。有了这两，大部分design pattern 都不需要了。
Oop应该算托密勒地心说。FP就是哥白尼。
【在 z****e 的大作中提到】
: 那你给zkss
|
|
|
g*****g
发帖数: 34805 | 51 Design patterns are simply common practices to solve a problem in a given
language. Every language has them, though differently. Scala is more
expressive than java, but not expressive enough to require no pattern or
framework.
http://jonasboner.com/2008/10/06/real-world-scala-dependency-in
Ironically, it use a so called cake pattern to do DI, in an ugly way. There'
s no doubt a separate DI framework like spring would make it cleaner, no
trait is thrown left and right.
The point is, a language cannot do all the heavy lifting, it's up to the
frameworks or it's an reinvented wheel. An reinvented wheel may be written
in 100 lines or 10K lines, neither makes it better than an existing well-
tested wheel.
traits
【在 l******t 的大作中提到】
:
: 可以这么理解吧，匿名类根本就是为了支持lambda的。pojo基本是lambda的另一种形式
: 。我记得
: programming Scala有章专门讲替代spring的approach。
: design pattern的出现基本是因为第一没first order function，第二没type/traits
: 。有了这两，大部分design pattern 都不需要了。
: Oop应该算托密勒地心说。FP就是哥白尼。
|
r***e
发帖数: 1840 | 52 很久不干technique我out了？override现在没人用了？而且到无足轻重的地步了。 |
g*****g
发帖数: 34805 | 53 Spring framework is heavily using override by itself. Interface, abstract
class, a few common used implementations. So you can use default most of the
time, and you have the flexibility to swap with your own where needed.
【在 r***e 的大作中提到】
: 很久不干technique我out了？override现在没人用了？而且到无足轻重的地步了。
|
r***e
发帖数: 1840 | 54 That's what I was saying. Overriding is still largely used. The other guys
scared me.
the
【在 g*****g 的大作中提到】
: Spring framework is heavily using override by itself. Interface, abstract
: class, a few common used implementations. So you can use default most of the
: time, and you have the flexibility to swap with your own where needed.
|
g*****g
发帖数: 34805 | 55 I guess enterprise developers don't use it as much these days. Composition
over inheritance does give you better decoupling in service design.
【在 r***e 的大作中提到】
: That's what I was saying. Overriding is still largely used. The other guys
: scared me.
:
: the
|
r***e
发帖数: 1840 | 56 depends on what kind company you are working in. And how complicated the
application is.
We cannot emphasize more on the overriding. Like you said the key is the
ability to swap in and out objects. Changing the behavior of the application
in a very short time.
Sorry to deviate your subject. Let's back to OO and FP discussion
instead of discussing these basic designs.
【在 g*****g 的大作中提到】
: I guess enterprise developers don't use it as much these days. Composition
: over inheritance does give you better decoupling in service design.
|
z****e
发帖数: 54598 | 57 恰好我还知道这些个概念
你给zkss pojo是lambda的另外一种形式是怎么来的
匿名类是为了支持lambda还比较make sense
但是pojo跟lambda扯上我还是第一次听说
另外对于高阶函数，用反射不就行了，又不是什么很难的事
表告诉我你不会反射
traits
【在 l******t 的大作中提到】
:
: 可以这么理解吧，匿名类根本就是为了支持lambda的。pojo基本是lambda的另一种形式
: 。我记得
: programming Scala有章专门讲替代spring的approach。
: design pattern的出现基本是因为第一没first order function，第二没type/traits
: 。有了这两，大部分design pattern 都不需要了。
: Oop应该算托密勒地心说。FP就是哥白尼。
|
l******t
发帖数: 55733 | 58
pojo可以理解成代入。
如果反射就可以，java还搞什么匿名类？
【在 z****e 的大作中提到】
: 恰好我还知道这些个概念
: 你给zkss pojo是lambda的另外一种形式是怎么来的
: 匿名类是为了支持lambda还比较make sense
: 但是pojo跟lambda扯上我还是第一次听说
: 另外对于高阶函数，用反射不就行了，又不是什么很难的事
: 表告诉我你不会反射
:
: traits
|
z****e
发帖数: 54598 | 59 因为反射是后来才加上去的
匿名类是一开始就有的
【在 l******t 的大作中提到】
:
: pojo可以理解成代入。
: 如果反射就可以，java还搞什么匿名类？
|
z****e
发帖数: 54598 | 60 pojo理解成代入？你给zkss
最好有例子
【在 l******t 的大作中提到】
:
: pojo可以理解成代入。
: 如果反射就可以，java还搞什么匿名类？
|
|
|
l******t
发帖数: 55733 | 61
There'
你说的很有道理。
我说的design pattern是‘那些’design patterns，比如4流氓的提出的20几个，或者
spring搞的IOC。这些东西在FP看来基本都是一些非常simple的特例或者脱了放。实际
上从学习FP的角度看，知道那些design pattern反而是毒药。FP中的一些最基本的东西
，像万能的map/fold，在OO中没有对应的概念或者pattern，难以抽象。再比如java自
傲的adaptor，listener这样的东西，明明就是first order function，硬要包装成
Object，可以说不知所云，最后还要搞匿名类。
一个FP视角下的4流氓patterns的讨论，我个人感觉，虽然FP存在了N多年，4流氓和Rod
在当年都不知道啥是FP。
http://blog.ezyang.com/2010/05/design-patterns-in-haskel/
以我看，OO是世界的直觉描述，FP是世界的本质描述。用OO就像是隔着太空服挠痒，FP
就是解牛的剔骨刀。
【在 g*****g 的大作中提到】
: Design patterns are simply common practices to solve a problem in a given
: language. Every language has them, though differently. Scala is more
: expressive than java, but not expressive enough to require no pattern or
: framework.
: http://jonasboner.com/2008/10/06/real-world-scala-dependency-in
: Ironically, it use a so called cake pattern to do DI, in an ugly way. There'
: s no doubt a separate DI framework like spring would make it cleaner, no
: trait is thrown left and right.
: The point is, a language cannot do all the heavy lifting, it's up to the
: frameworks or it's an reinvented wheel. An reinvented wheel may be written
|
z****e
发帖数: 54598 | 62 你们说得是一个东西么？
你说的这些，都是gui的部分
gui最重要的模式不是adapter/listener
而是mvc
尤其在对付不同环境的时候
比如从desktop->android
或者反过来，mvc代码复用率极高，理论上只需要修改v和c就可以了
而你把lambda利用上了之后，反而破坏了mvc的结构
等你migrate你的代码的时候，就会pain in the ass鸟
不过理论上java说，我帮你搞定垮平台问题
但是实际上往往没搞定
Rod
【在 l******t 的大作中提到】
:
: There'
: 你说的很有道理。
: 我说的design pattern是‘那些’design patterns，比如4流氓的提出的20几个，或者
: spring搞的IOC。这些东西在FP看来基本都是一些非常simple的特例或者脱了放。实际
: 上从学习FP的角度看，知道那些design pattern反而是毒药。FP中的一些最基本的东西
: ，像万能的map/fold，在OO中没有对应的概念或者pattern，难以抽象。再比如java自
: 傲的adaptor，listener这样的东西，明明就是first order function，硬要包装成
: Object，可以说不知所云，最后还要搞匿名类。
: 一个FP视角下的4流氓patterns的讨论，我个人感觉，虽然FP存在了N多年，4流氓和Rod
|
l******t
发帖数: 55733 | 63
有很多角度可以探讨一下。
比如Spring，Spring的config/context xmls本身看可以看成是一种DSL，这些pojo，就
是DSL中的function/data。一个如何从FP的角度理解DSL的blog，
http://www.defmacro.org/ramblings/lisp.html
再换个说法，lambda本身被证明可以产生任何算法，所以任何算法都可以从lambda角度
描述。这不是大而化之。OO的很多东西从FP来看是很straightforward和intuitive的。
用OO只能说是做job，用FP是有快感的。老赵还没去试试FP？
【在 z****e 的大作中提到】
: pojo理解成代入？你给zkss
: 最好有例子
|
c******o
发帖数: 1277 | 64 我觉得你说的不对，
FP/OO都是世界的一种描述，没啥优劣之分。
事实上，FP的monad在很多场合(state/IO) 也是很ugly, 从imperative的角度简直是自
作自受。
每个编程方式都是有它最适用的一面的。
Rod
【在 l******t 的大作中提到】
:
: 有很多角度可以探讨一下。
: 比如Spring，Spring的config/context xmls本身看可以看成是一种DSL，这些pojo，就
: 是DSL中的function/data。一个如何从FP的角度理解DSL的blog，
: http://www.defmacro.org/ramblings/lisp.html
: 再换个说法，lambda本身被证明可以产生任何算法，所以任何算法都可以从lambda角度
: 描述。这不是大而化之。OO的很多东西从FP来看是很straightforward和intuitive的。
: 用OO只能说是做job，用FP是有快感的。老赵还没去试试FP？
|
l******t
发帖数: 55733 | 65
OO可以对应中医，FP可以是西医。
为啥我觉得monad很elegant。。impure code在FP看来是非常的烫手非常的毒。
【在 c******o 的大作中提到】
: 我觉得你说的不对，
: FP/OO都是世界的一种描述，没啥优劣之分。
: 事实上，FP的monad在很多场合(state/IO) 也是很ugly, 从imperative的角度简直是自
: 作自受。
: 每个编程方式都是有它最适用的一面的。
:
: Rod
|
s*******8
发帖数: 12734 | 66 ????
你说啥?
【在 z****e 的大作中提到】
: 你们说得是一个东西么？
: 你说的这些，都是gui的部分
: gui最重要的模式不是adapter/listener
: 而是mvc
: 尤其在对付不同环境的时候
: 比如从desktop->android
: 或者反过来，mvc代码复用率极高，理论上只需要修改v和c就可以了
: 而你把lambda利用上了之后，反而破坏了mvc的结构
: 等你migrate你的代码的时候，就会pain in the ass鸟
: 不过理论上java说，我帮你搞定垮平台问题
|
z****e
发帖数: 54598 | 67 我关注的点跟你不一样
我更看重如何利用fp作为现有oop的补充
写代码本身没有太多快感，很多时候感觉很boring
但是实现一个软件本身倒是很有成就感
我更看重能做什么
【在 l******t 的大作中提到】
:
: OO可以对应中医，FP可以是西医。
: 为啥我觉得monad很elegant。。impure code在FP看来是非常的烫手非常的毒。
|
z****e
发帖数: 54598 | 68 oop是西医，主流医学，其他都是辅助
养生时候用中医，如果明确了问题，西医基本上都是切割下去
简单，见效快，适用范围广
【在 l******t 的大作中提到】
:
: OO可以对应中医，FP可以是西医。
: 为啥我觉得monad很elegant。。impure code在FP看来是非常的烫手非常的毒。
|
z****e
发帖数: 54598 | 69 我选择各种p只有一个目的
代码分离
只要能实现代码分离的p就是好p
否则，人一多，很容易起冲突
最好的p就是你写你的，我写我的，别互相干扰
你用你的p，我用我的p
所以我一直都比较欣赏aop
因为不会对各种现有流程代码造成不必要的侵入和破坏
【在 c******o 的大作中提到】
: 我觉得你说的不对，
: FP/OO都是世界的一种描述，没啥优劣之分。
: 事实上，FP的monad在很多场合(state/IO) 也是很ugly, 从imperative的角度简直是自
: 作自受。
: 每个编程方式都是有它最适用的一面的。
:
: Rod
|
j********3
发帖数: 245 | 70 大牛们，我想问一个初级问题可以吗？最近在上java的课，做Applet,大约十几个类一
起工作，结果在网页上运行时就总是失败，"java.lang.reflect.
invocationtargetexception",但在Eclipse里就可以运行，在网上搜，有人说是构造函
数的问题，例如： Method method = ... method.invoke(instance, ...)但是不知道
怎么改，还请大牛们赐教。不胜感激。 |
|
|
q*c
发帖数: 9453 | 71 写代码这种劳动竟然有了快感， 你就知道这些同学幻想和不切实际到了何种地步。
更何况， 好的语言， 不是让写代码的人有快感， 而是让debug 的人， 让读的人，
让扩展的人， 有快感。
long run 里面能赢的语言， 都是这样。
这更加印证了我的印象， 喜欢 FP 的同修们基本都是自我中心， 没啥和别人大团队合
作大项目的同学。
其实 FP 的各种feature, 当年都是血泪教训， 今天又被 re-invent 了。。。
人这种地等生物记忆不能遗传，不断的犯同样的错误， 那是没办法。
【在 z****e 的大作中提到】
: 我关注的点跟你不一样
: 我更看重如何利用fp作为现有oop的补充
: 写代码本身没有太多快感，很多时候感觉很boring
: 但是实现一个软件本身倒是很有成就感
: 我更看重能做什么
|
q*c
发帖数: 9453 | 72 没有优劣之分， 但是有适用范围之分。 鉴于人这种生物能力地下，
多一种实现方式有巨大的成本付出， 因此不同的范围， 本身就
表明了优劣。
【在 c******o 的大作中提到】
: 我觉得你说的不对，
: FP/OO都是世界的一种描述，没啥优劣之分。
: 事实上，FP的monad在很多场合(state/IO) 也是很ugly, 从imperative的角度简直是自
: 作自受。
: 每个编程方式都是有它最适用的一面的。
:
: Rod
|
c******o
发帖数: 1277 | 73 适用范围不是一个包括一个的。
也就是各有所长。
【在 q*c 的大作中提到】
: 没有优劣之分， 但是有适用范围之分。 鉴于人这种生物能力地下，
: 多一种实现方式有巨大的成本付出， 因此不同的范围， 本身就
: 表明了优劣。
|
q*c
发帖数: 9453 | 74
Rod
FP
世界的本质就是 OO. 你要是能找到一个不是 Object 的客观存在， 你就比 Einstein
还要伟大。
FP 是队世界的抽象 － 抽象总要省略大量细节。 抽象的东西总是远看很美， 因为大量
丑恶细节抽象掉了嘛。
一旦你对付的问题需要这些细节的时候, FP 的丑恶就出来了， hoho
【在 l******t 的大作中提到】
:
: OO可以对应中医，FP可以是西医。
: 为啥我觉得monad很elegant。。impure code在FP看来是非常的烫手非常的毒。
|
c*******9
发帖数: 9032 | 75 世界有什么本质？oo只是人的思维惯性。
Einstein
大量
【在 q*c 的大作中提到】
:
: Rod
: FP
: 世界的本质就是 OO. 你要是能找到一个不是 Object 的客观存在， 你就比 Einstein
: 还要伟大。
: FP 是队世界的抽象 － 抽象总要省略大量细节。 抽象的东西总是远看很美， 因为大量
: 丑恶细节抽象掉了嘛。
: 一旦你对付的问题需要这些细节的时候, FP 的丑恶就出来了， hoho
|
z****e
发帖数: 54598 | 76 这个很少有人能回答你，因为applet是java最弱的一块
虽然最初在m$的帮助下辉煌过，但是那是快二十年前的事了
现在很少有人有类似的经验，自己琢磨吧
学完之后估计你很快就会忘记这个东西
还有光看异常，这个不是初级问题，这个是reflection的问题
【在 j********3 的大作中提到】
: 大牛们，我想问一个初级问题可以吗？最近在上java的课，做Applet,大约十几个类一
: 起工作，结果在网页上运行时就总是失败，"java.lang.reflect.
: invocationtargetexception",但在Eclipse里就可以运行，在网上搜，有人说是构造函
: 数的问题，例如： Method method = ... method.invoke(instance, ...)但是不知道
: 怎么改，还请大牛们赐教。不胜感激。
|
z****e
发帖数: 54598 | 77 fp才是人的思维惯性吧
学数学都学出翔来了
oo是唯物主义，万事万物都是由小原子分子组成的
这些都是球体，就是object
【在 c*******9 的大作中提到】
: 世界有什么本质？oo只是人的思维惯性。
:
: Einstein
: 大量
|
c*******9
发帖数: 9032 | 78 什么球体都是一种方便的想像，你看见了还是实验证实了光子，电子是球体?不要用庸
俗化的唯物论来说明近代科学的楖念。
【在 z****e 的大作中提到】
: fp才是人的思维惯性吧
: 学数学都学出翔来了
: oo是唯物主义，万事万物都是由小原子分子组成的
: 这些都是球体，就是object
|
z****e
发帖数: 54598 | 79 如果方便人想象那就说明其有被广泛接受的价值
【在 c*******9 的大作中提到】
: 什么球体都是一种方便的想像，你看见了还是实验证实了光子，电子是球体?不要用庸
: 俗化的唯物论来说明近代科学的楖念。
|
g*****g
发帖数: 34805 | 80 宏观物理不用考虑电子光子这些，就是物体加力学。物体就是Object, 力学就是method。
【在 c*******9 的大作中提到】
: 什么球体都是一种方便的想像，你看见了还是实验证实了光子，电子是球体?不要用庸
: 俗化的唯物论来说明近代科学的楖念。
|
|
|
c******o
发帖数: 1277 | 81 你这说的， 那我能不能说fp是牛顿定律。
物体是type,有质量速度属性，而最简的一组operation就是牛顿三定律。
method。
【在 g*****g 的大作中提到】
: 宏观物理不用考虑电子光子这些，就是物体加力学。物体就是Object, 力学就是method。
|
g*****g
发帖数: 34805 | 82 得，有质量速度属性很好，可这速度属性可变，用OO很容易建模。
用FP你建模一个看看？
速度变了，物体就不是原来的物体。数学上也许说得通，但物理显然不是
这么建模的，否则岂不是在不同参照系里看到的物体都不一样了。
FP没法建模物体，只能把物体当作矢量状态机穷举。
【在 c******o 的大作中提到】
: 你这说的， 那我能不能说fp是牛顿定律。
: 物体是type,有质量速度属性，而最简的一组operation就是牛顿三定律。
:
: method。
|
c*******9
发帖数: 9032 | 83 你的程序全部针对具体物体？
method。
【在 g*****g 的大作中提到】
: 宏观物理不用考虑电子光子这些，就是物体加力学。物体就是Object, 力学就是method。
|
c*******9
发帖数: 9032 | 84 不否定其价值，但说它是本质就有问题了。比如光的波粒二象性能简单的把光子当小球
吗。
【在 z****e 的大作中提到】
: 如果方便人想象那就说明其有被广泛接受的价值
|
q*c
发帖数: 9453 | 85 就是啊， 还人的思维惯性。
好像他／她不思维， 原子就不存在， 原子的各种 property 就没有了，变成一堆函数
一样。
atom = new Atom(Type type);
atom.size = 10^-10; // meter
atom.weight = 10^23; // gram
atom.electrons = new List(8);
...
半文盲都知道上面是啥。
这宇宙， 就是个标准的 OO 的世界。 这也是为什么 OO 一定干死 其他一切不自然的
语言的基本原因。
【在 z****e 的大作中提到】
: fp才是人的思维惯性吧
: 学数学都学出翔来了
: oo是唯物主义，万事万物都是由小原子分子组成的
: 这些都是球体，就是object
|
q*c
发帖数: 9453 | 86 你的程序基本针对的应该是现实问题。
否则。。。你还是赶紧改 resume 比较安全，呵呵，
【在 c*******9 的大作中提到】
: 你的程序全部针对具体物体？
:
: method。
|
q*c
发帖数: 9453 | 87 不是小球－ 但是也是一个实体， 有大小，范围， 能量， 状态， 速度等等等等各种
属性， 而且可以变化。
这是个物资的世界， 否定对象的实体性， 就是逆天行事， 呵呵。
你要逆天吗？!
【在 c*******9 的大作中提到】
: 不否定其价值，但说它是本质就有问题了。比如光的波粒二象性能简单的把光子当小球
: 吗。
|
N*n
发帖数: 456 | 88 难怪你物理学不好。。
【在 q*c 的大作中提到】
: 就是啊， 还人的思维惯性。
: 好像他／她不思维， 原子就不存在， 原子的各种 property 就没有了，变成一堆函数
: 一样。
: atom = new Atom(Type type);
: atom.size = 10^-10; // meter
: atom.weight = 10^23; // gram
: atom.electrons = new List(8);
: ...
: 半文盲都知道上面是啥。
: 这宇宙， 就是个标准的 OO 的世界。 这也是为什么 OO 一定干死 其他一切不自然的
|
N*n
发帖数: 456 | 89 Q霸风格又来了。
等你自己明白那一天吧
【在 q*c 的大作中提到】
: 不是小球－ 但是也是一个实体， 有大小，范围， 能量， 状态， 速度等等等等各种
: 属性， 而且可以变化。
: 这是个物资的世界， 否定对象的实体性， 就是逆天行事， 呵呵。
: 你要逆天吗？!
|
N*n
发帖数: 456 | 90 clojure 算 FP 吧? 用来建模如何？
以前啃过一点LISP.. 看Clojure 是lisp 的核，而且架在
ＪＶＭ想学学看。。ＯＯＰ 建模不也是一个feature一个
feature 得穷举吗？
【在 g*****g 的大作中提到】
: 得，有质量速度属性很好，可这速度属性可变，用OO很容易建模。
: 用FP你建模一个看看？
: 速度变了，物体就不是原来的物体。数学上也许说得通，但物理显然不是
: 这么建模的，否则岂不是在不同参照系里看到的物体都不一样了。
: FP没法建模物体，只能把物体当作矢量状态机穷举。
|
|
|
g*****g
发帖数: 34805 | 91 The key difference between OOP and FP is whether state is mutable.
I think we can all agree now in physics, speed is mutable. A new object wasn
't created when the object changes the speed.
【在 N*n 的大作中提到】
: clojure 算 FP 吧? 用来建模如何？
: 以前啃过一点LISP.. 看Clojure 是lisp 的核，而且架在
: ＪＶＭ想学学看。。ＯＯＰ 建模不也是一个feature一个
: feature 得穷举吗？
|
z****e
发帖数: 54598 | 92 定义建模
如果是数学建模，还是不错的
但是如果建模是用来映射现实世界的话
那还是oo吧，否则都不知道怎么描述物体
【在 N*n 的大作中提到】
: clojure 算 FP 吧? 用来建模如何？
: 以前啃过一点LISP.. 看Clojure 是lisp 的核，而且架在
: ＪＶＭ想学学看。。ＯＯＰ 建模不也是一个feature一个
: feature 得穷举吗？
|
c******o
发帖数: 1277 | 93 well, state monad can take care of that.
If we only talk about modeling, FP is the same as OO/imperative, FP is a
COMPLETE paradigm, in that it can solve any problem that OOP/imperative can
solve.
But whether it is good to use state monad to model stateful things, is
up for debate
wasn
【在 g*****g 的大作中提到】
: The key difference between OOP and FP is whether state is mutable.
: I think we can all agree now in physics, speed is mutable. A new object wasn
: 't created when the object changes the speed.
|
g*****g
发帖数: 34805 | 94 FP is turning complete. I give you that. But I double Physicists understand
state monad. And if they don't, I doubt they are capable to describe the
world in FP way.
can
【在 c******o 的大作中提到】
: well, state monad can take care of that.
: If we only talk about modeling, FP is the same as OO/imperative, FP is a
: COMPLETE paradigm, in that it can solve any problem that OOP/imperative can
: solve.
: But whether it is good to use state monad to model stateful things, is
: up for debate
:
: wasn
|
q*c
发帖数: 9453 | 95 why physicist? Normal people counts, because all programmers (or 99.99% of
them) are normal people, or at least raised up as normal people.
normal people for sure understand what an Object is, and what it looks like,
and how it behaves much much easier than some state monad.
understand
【在 g*****g 的大作中提到】
: FP is turning complete. I give you that. But I double Physicists understand
: state monad. And if they don't, I doubt they are capable to describe the
: world in FP way.
:
: can
|
c******o
发帖数: 1277 | 96 FP is based on lambda calculus, and it is in fact equivalent to turing
machine.
Which means, anything turning machine can do (OOP/Imperative can do), FP can
do.
It may not be a good way for some of the problems, but it can do everything.
Also, I bet most Physicists understand category theory better than us do, it
is
closely related to the micro world modeling (the abstract algebra is a key
part of quantum physics)
understand
【在 g*****g 的大作中提到】
: FP is turning complete. I give you that. But I double Physicists understand
: state monad. And if they don't, I doubt they are capable to describe the
: world in FP way.
:
: can
|
c******o
发帖数: 1277 | 97 Just like normal people can much easier understand
how multiple parallel immutable transformation can compose with each other
than a completely mess of lock/semaphore/mutex.
like,
【在 q*c 的大作中提到】
: why physicist? Normal people counts, because all programmers (or 99.99% of
: them) are normal people, or at least raised up as normal people.
: normal people for sure understand what an Object is, and what it looks like,
: and how it behaves much much easier than some state monad.
:
: understand
|
g*****g
发帖数: 34805 | 98 There is a big big difference between turning complete and actually modeling
it that way. Maybe physicists do know category theory well, but they don't
describe the world using monad. They use objects, stateful attributes and
their interactions instead. It's not hard to figure that out from textbook.
can
everything.
it
key
【在 c******o 的大作中提到】
: FP is based on lambda calculus, and it is in fact equivalent to turing
: machine.
: Which means, anything turning machine can do (OOP/Imperative can do), FP can
: do.
: It may not be a good way for some of the problems, but it can do everything.
: Also, I bet most Physicists understand category theory better than us do, it
: is
: closely related to the micro world modeling (the abstract algebra is a key
: part of quantum physics)
:
|
c******o
发帖数: 1277 | 99 you did not see how state monad in action, it looks just LIKE what
imperative programming looks like, except, it is all immutable inside. I do
not think it is a better way, as you can do it just use stateful code to do
it simpler.
But it is good if it is parallel env, much easier to reason the code as it
is all immutable.
for {
_ <- set(List("foo", "bar"))
parsed <- parseInt("1")
state <- get[List[String]]
_ = println("sneaky peek at the state: " + state)
doubled = double(parsed)
meaning <- meaningOfLife(doubled)
} yield meaning
modeling
t
【在 g*****g 的大作中提到】
: There is a big big difference between turning complete and actually modeling
: it that way. Maybe physicists do know category theory well, but they don't
: describe the world using monad. They use objects, stateful attributes and
: their interactions instead. It's not hard to figure that out from textbook.
:
: can
: everything.
: it
: key
|
g*****g
发帖数: 34805 | 100 Let me say this again. Change (mutability) is a concept universally used in
Physics. Achieving the equivalent using monad doesn't make it the modeling
language in textbook. This is not a backlash to FP, merely a fact.
do
do
【在 c******o 的大作中提到】
: you did not see how state monad in action, it looks just LIKE what
: imperative programming looks like, except, it is all immutable inside. I do
: not think it is a better way, as you can do it just use stateful code to do
: it simpler.
: But it is good if it is parallel env, much easier to reason the code as it
: is all immutable.
: for {
: _ <- set(List("foo", "bar"))
: parsed <- parseInt("1")
: state <- get[List[String]]
|
|
|
c*******9
发帖数: 9032 | 101 搞量子引力的一些物理学家已经开始用category的一些理论。
in
【在 g*****g 的大作中提到】
: Let me say this again. Change (mutability) is a concept universally used in
: Physics. Achieving the equivalent using monad doesn't make it the modeling
: language in textbook. This is not a backlash to FP, merely a fact.
:
: do
: do
|
c*******9
发帖数: 9032 | 102 你的物理只学到初中？
【在 q*c 的大作中提到】
: 就是啊， 还人的思维惯性。
: 好像他／她不思维， 原子就不存在， 原子的各种 property 就没有了，变成一堆函数
: 一样。
: atom = new Atom(Type type);
: atom.size = 10^-10; // meter
: atom.weight = 10^23; // gram
: atom.electrons = new List(8);
: ...
: 半文盲都知道上面是啥。
: 这宇宙， 就是个标准的 OO 的世界。 这也是为什么 OO 一定干死 其他一切不自然的
|
q*c
发帖数: 9453 | 103 世界上99.99% 重要得日常事情其实都只到高中。
计算机为了99.99% 得人和问题服务， 不是为了 0.001% 得人和问题服务得。
【在 c*******9 的大作中提到】
: 你的物理只学到初中？
|
l******t
发帖数: 55733 | 104 FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
甚至是多个(数学)系统(算法)后面的本质。
所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
。haskell就是基于typed lambda的。
OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
Open-closed，Liskov substitution， interface segregation, Dependency
inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
都是type class/trait/mixin的好注解。其根本原因还是因为对象在计算机中并没有真
实存在，对象是靠一组算法/操作定义的。有同样算法的被归为一类，这恰恰是是
categorize，是type class/trait。
OO和其他非FP语言经过演化后功能概念原则功能都往FP靠拢是有必然性的。因为FP代表
的是算法的终极描述。 |
m*******l
发帖数: 12782 | 105 大牛说的太好了
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
N*n
发帖数: 456 | 106 什么叫category 建模？Lisp 的谓词结构算吗？
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
N*n
发帖数: 456 | 107 其实也不是不可以吧。。 物体只是相互作用的端点。
ＦＰ描述是以相互作用（函数）为主，ＯＯＰ描述是以物体为主。
从这个角度来说用 ＦＰ 对世界建模是有可能的。 |
N*n
发帖数: 456 | 108
wasn
我自己查了一下。。总算明白immutable 所指
以下转引
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
FP中的函数中的所有变量不允许进行再绑定。在FP中一个变量x当他被赋予一个值1以后
他永远就是1。那么x就被称为是immutable的。相反在imperative语言的里x却是
mutable的，那么当你执行imperative 语言中的某个函数A(x,y)。其x,y会受到某个"遥
远"变量的影响而使得A的结果出现任何一种你未曾经预料到的情况。这称为"side-
effection"-边界效应。而FP中A(1,2)的结果是不会改变的，有什么样的输入一定会有
什么样的输出，因此他是"no side-effection"。
Ajoo这位前人对immutable编程的经验
1。对象状态不会变化，程序bug就会少很多。有一个mutable set函数，在set前和set
后对象就处于两个不同的状态。所以说immutable减少了对象的状态。
2。没有变化，就没有线程同步问题。对象自然是线程安全的。这和用同步（包括用
shared_ptr)不同，后者是通过额外的，需要一定运行时开销的，可能出现bug的程序逻
辑来达到安全，前者根本就可以忘掉线成的存在。
3。immutable对象可以用做其它immutable对象的子对象，也可以用作mutable对象的子
对象（通过指针赋值就可达到变化的目的）；而mutable对象只能用在mutable对象中，
于是immutable对象的应用范围更广。（这也隐含着表示：如果一个类可以设计成
mutable的，也可以做成immutable的，immutable优先。）
4。共享。immutable对象方便了共享，有些场合可以提高效率和空间利用率。
5。克服一些类型上的困难。著名的正方形不是长方形的例子，如果长方形是immutable
的，setWidth, setHeight都是functional update（这也是更加数学意义的长方形定义
），那么正方形就可以是一个长方形。
6。天然的异常安全。
7。天然地支持undo-redo。不需要费力做momento，纪录undo operation。
【在 g*****g 的大作中提到】
: The key difference between OOP and FP is whether state is mutable.
: I think we can all agree now in physics, speed is mutable. A new object wasn
: 't created when the object changes the speed.
|
N*n
发帖数: 456 | 109 找到下面的ｗｉｋｉ页。可是看不太明白。
http://en.wikipedia.org/wiki/Product_(category_theory)
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
N******K
发帖数: 10202 | 110 怎么用category来对雷达控制系统进行建模？
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
|
|
G***l
发帖数: 355 | 111 这个贴子说的很好。我以前就说过，从建模角度来说OO描述data和data之间的关系很好
，但是描述behavior就有所不足。Design pattern里面，绝大多数都是用来弥补OO在
behavior建模上的不足的，这里面绝大多数FP都不需要。FP描述data没有OO简单直接，
但是当模型复杂的时候，behavior建模上强太多了。
关于继承我也很赞同。interface继承是类似FP的，因为interface只是标识了（多个）
function的signature。在OO里依赖一个interface，几乎和FP里依赖一个或者多个函数
type一样。class的继承完全不同。不知道你们有没有这个发现。我自己的经验是，用
java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
的是越来越少了。
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
N******K
发帖数: 10202 | 112 OO的继承 字面上确实是个伪概念 用来定义object的共性 而不是所谓传承关系
FP能对银行的业务逻辑建模？还是对 控制系统建模？
【在 G***l 的大作中提到】
: 这个贴子说的很好。我以前就说过，从建模角度来说OO描述data和data之间的关系很好
: ，但是描述behavior就有所不足。Design pattern里面，绝大多数都是用来弥补OO在
: behavior建模上的不足的，这里面绝大多数FP都不需要。FP描述data没有OO简单直接，
: 但是当模型复杂的时候，behavior建模上强太多了。
: 关于继承我也很赞同。interface继承是类似FP的，因为interface只是标识了（多个）
: function的signature。在OO里依赖一个interface，几乎和FP里依赖一个或者多个函数
: type一样。class的继承完全不同。不知道你们有没有这个发现。我自己的经验是，用
: java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
: 的是越来越少了。
|
k**********g
发帖数: 989 | 113
The concept of FP is good for understanding "pure computation". Radar
control involves a lot of stream processors. Once a piece of data is handed
over from one stream processor to another, it will never get back. (Each
processor is sort of "specialized" for a single step of algorithm.)
Thus, mutability only works within the scope of a single processor. In the
greater scheme, it requires FP-like thinking (not relying on mutability,
persistent data store, or references (pointers) ) to understand how to
program a large grid of such processors.
A bit similar to Twitter Storm or Complex Event Processing.
【在 N******K 的大作中提到】
: 怎么用category来对雷达控制系统进行建模？
|
z****e
发帖数: 54598 | 114 "不知道你们有没有这个发现。我自己的经验是，用
java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
的是越来越少了。"
对，这就是为什么前面说的，override用得越来越少的缘故
interface是不得不用，但是abstract class越来越没有意义了
下一个版本的java里面有了default关键字，直接替换掉abstract class里面的具体方法
实际上多重继承，尤其是abstract class里面的继承并不会加强代码复用的效率
相反，会严重影响代码可读性，往上一层套着一层，我现在的系统，只套了4层
就使得代码几乎不可阅读，这种legacy code基本上都是屎坑，周围人躲之不及
【在 G***l 的大作中提到】
: 这个贴子说的很好。我以前就说过，从建模角度来说OO描述data和data之间的关系很好
: ，但是描述behavior就有所不足。Design pattern里面，绝大多数都是用来弥补OO在
: behavior建模上的不足的，这里面绝大多数FP都不需要。FP描述data没有OO简单直接，
: 但是当模型复杂的时候，behavior建模上强太多了。
: 关于继承我也很赞同。interface继承是类似FP的，因为interface只是标识了（多个）
: function的signature。在OO里依赖一个interface，几乎和FP里依赖一个或者多个函数
: type一样。class的继承完全不同。不知道你们有没有这个发现。我自己的经验是，用
: java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
: 的是越来越少了。
|
z****e
发帖数: 54598 | 115 design pattern你们也不要乱喷
pattern也分为很多种，behavior 只是其中一类
另外的结构类pattern其实fp也解决不了，而且结构类的pattern就是针对大项目的困难
而造
跟fp没有必然联系，实际上fp还会更依赖结构类的pattern
因为如果没有结构类的pattern，要想做fp也不容易
java8里面对于fp的lambda就采用了特殊的一个interface
【在 G***l 的大作中提到】
: 这个贴子说的很好。我以前就说过，从建模角度来说OO描述data和data之间的关系很好
: ，但是描述behavior就有所不足。Design pattern里面，绝大多数都是用来弥补OO在
: behavior建模上的不足的，这里面绝大多数FP都不需要。FP描述data没有OO简单直接，
: 但是当模型复杂的时候，behavior建模上强太多了。
: 关于继承我也很赞同。interface继承是类似FP的，因为interface只是标识了（多个）
: function的signature。在OO里依赖一个interface，几乎和FP里依赖一个或者多个函数
: type一样。class的继承完全不同。不知道你们有没有这个发现。我自己的经验是，用
: java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
: 的是越来越少了。
|
z****e
发帖数: 54598 | 116 这就是我想知道的
怎么定义点？这个点不是对象不是物体是什么？
是完全抽象的点？那还是个对象
实际上对于fp有一种方式可以帮助理解
就是假设有一个上帝之手，在操纵着众多物体
这样可以避开多线程里面给每一个线程定义一个自主ai的互相干扰
【在 N*n 的大作中提到】
: 其实也不是不可以吧。。 物体只是相互作用的端点。
: ＦＰ描述是以相互作用（函数）为主，ＯＯＰ描述是以物体为主。
: 从这个角度来说用 ＦＰ 对世界建模是有可能的。
|
z****e
发帖数: 54598 | 117 oo固然在计算机中并非真实存在
但是function难道就真实存在？
我一直力图使fp变成oop的延伸，而非冲突或者替换
因为oop的成功已经被证明，而fp的失败也已经被证明了，如果小菊花说的历史是对的话
但是这个时候如果fp还在继续冒出来，那说明fp有其可取的地方
取其精华，弃其糟粕，那问题就在于如何切割开这两者
这就好比一个外科手术的主刀医生，一个人身体里面有好的器官
也有肿瘤，一刀下去，把肿瘤给割掉，现在就看怎么切了
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
p*****2
发帖数: 21240 | 118
的话
都是compromise。不要玩纯就好。然后就要看是多少OO，多少FP了。像Scala就是50%
OO，50% FP。Clojure 15% OO, 85% FP。
【在 z****e 的大作中提到】
: oo固然在计算机中并非真实存在
: 但是function难道就真实存在？
: 我一直力图使fp变成oop的延伸，而非冲突或者替换
: 因为oop的成功已经被证明，而fp的失败也已经被证明了，如果小菊花说的历史是对的话
: 但是这个时候如果fp还在继续冒出来，那说明fp有其可取的地方
: 取其精华，弃其糟粕，那问题就在于如何切割开这两者
: 这就好比一个外科手术的主刀医生，一个人身体里面有好的器官
: 也有肿瘤，一刀下去，把肿瘤给割掉，现在就看怎么切了
|
N*n
发帖数: 456 | 119 这个说地太好啦！
handed
【在 k**********g 的大作中提到】
:
: The concept of FP is good for understanding "pure computation". Radar
: control involves a lot of stream processors. Once a piece of data is handed
: over from one stream processor to another, it will never get back. (Each
: processor is sort of "specialized" for a single step of algorithm.)
: Thus, mutability only works within the scope of a single processor. In the
: greater scheme, it requires FP-like thinking (not relying on mutability,
: persistent data store, or references (pointers) ) to understand how to
: program a large grid of such processors.
: A bit similar to Twitter Storm or Complex Event Processing.
|
N*n
发帖数: 456 | 120 ：interface的继承还在用，但是class的继承用
：的是越来越少了。
这个挺好。。 我想也许因为 class 里有太多的implementation/definition 是不见得
可以安全继承的。。而interface 基本就是接口定义？
【在 G***l 的大作中提到】
: 这个贴子说的很好。我以前就说过，从建模角度来说OO描述data和data之间的关系很好
: ，但是描述behavior就有所不足。Design pattern里面，绝大多数都是用来弥补OO在
: behavior建模上的不足的，这里面绝大多数FP都不需要。FP描述data没有OO简单直接，
: 但是当模型复杂的时候，behavior建模上强太多了。
: 关于继承我也很赞同。interface继承是类似FP的，因为interface只是标识了（多个）
: function的signature。在OO里依赖一个interface，几乎和FP里依赖一个或者多个函数
: type一样。class的继承完全不同。不知道你们有没有这个发现。我自己的经验是，用
: java, c++, c#写OO的code这么多年来，interface的继承还在用，但是class的继承用
: 的是越来越少了。
|
|
|
N*n
发帖数: 456 | 121 结构类pattern 的英文是什么？
【在 z****e 的大作中提到】
: design pattern你们也不要乱喷
: pattern也分为很多种，behavior 只是其中一类
: 另外的结构类pattern其实fp也解决不了，而且结构类的pattern就是针对大项目的困难
: 而造
: 跟fp没有必然联系，实际上fp还会更依赖结构类的pattern
: 因为如果没有结构类的pattern，要想做fp也不容易
: java8里面对于fp的lambda就采用了特殊的一个interface
|
g*****g
发帖数: 34805 | 122 这不扯蛋吗，恰恰是直觉的东西才容易理解。世界本质还是原子组成的，难道就得用原
子建模？
【在 l******t 的大作中提到】
: FP不用Object建模，FP用category建模。category theory超越了OO揭示了在直觉后面
: 甚至是多个(数学)系统(算法)后面的本质。
: 所有Object属性在计算机都是某种数学描述。属性数学化后更抽象的描述就是FP做的。
: FP不以属性为重并不意味着没有属性。为了支持属性实现了typed lambda calculas。
: 去看看如何用lambda定义boolean，int是很有趣的。属性lambda化后通过应用已有的
: lambda算法库可以产生很多新的算法用法，其简洁明快深刻强大是OO中根本无法想象的
: 。haskell就是基于typed lambda的。
: OO的另一个核心概念继承也是伪概念，如果我们审视SOLID(Single responsibility，
: Open-closed，Liskov substitution， interface segregation, Dependency
: inversion)这样OO的精华原则，你会发现是全面否定继承而趋向FP的。SOLID中的前4项
|
q*c
发帖数: 9453 | 123 Rod 说 scala 社区里面臭名昭著得苗头是
“if you are not smart enough to understand my code, it is your problem".
scala, FP 这些东西真是放大个人的自大感觉的利器。 一班人基本没啥机会表现比别
人的优越感， fp 这些抽象曲折的东西， 简直是太方便达到这个目的了。
简单得东西就是好的， 能解决问题的最简单的东西就最好。 抽象的东西比简单的东西
就复杂， 越抽象的东西就越复杂 － 尽管这些抽象的东西看上去很精炼， 但是就是复
杂。
【在 g*****g 的大作中提到】
: 这不扯蛋吗，恰恰是直觉的东西才容易理解。世界本质还是原子组成的，难道就得用原
: 子建模？
|
l******t
发帖数: 55733 | 124 Rod到底懂不懂FP
【在 q*c 的大作中提到】
: Rod 说 scala 社区里面臭名昭著得苗头是
: “if you are not smart enough to understand my code, it is your problem".
: scala, FP 这些东西真是放大个人的自大感觉的利器。 一班人基本没啥机会表现比别
: 人的优越感， fp 这些抽象曲折的东西， 简直是太方便达到这个目的了。
: 简单得东西就是好的， 能解决问题的最简单的东西就最好。 抽象的东西比简单的东西
: 就复杂， 越抽象的东西就越复杂 － 尽管这些抽象的东西看上去很精炼， 但是就是复
: 杂。
|
g*****g
发帖数: 34805 | 125 FP强调immutable，这个东西做复杂多线程的东西确实是利器。用锁很容易出问题，而
且出问题了不容易debug。现在这波FP的Momentum，主要也在多线程的东西上。akka，
storm之类。
但推而广之说啥都适合FP就是瞎说了。FP比OOP出现得还早，要能流行早流行了。
【在 q*c 的大作中提到】
: Rod 说 scala 社区里面臭名昭著得苗头是
: “if you are not smart enough to understand my code, it is your problem".
: scala, FP 这些东西真是放大个人的自大感觉的利器。 一班人基本没啥机会表现比别
: 人的优越感， fp 这些抽象曲折的东西， 简直是太方便达到这个目的了。
: 简单得东西就是好的， 能解决问题的最简单的东西就最好。 抽象的东西比简单的东西
: 就复杂， 越抽象的东西就越复杂 － 尽管这些抽象的东西看上去很精炼， 但是就是复
: 杂。
|
g*****g
发帖数: 34805 | 126 Rod在TypeSafe混，你觉得呢？
【在 l******t 的大作中提到】
: Rod到底懂不懂FP
|
l******t
发帖数: 55733 | 127 从spring看他不懂
【在 g*****g 的大作中提到】
: Rod在TypeSafe混，你觉得呢？
|
g*****g
发帖数: 34805 | 128 从spring看，他是工程的大大牛，能把东西做好做大的。发明语言容易，
做大语言才难。
【在 l******t 的大作中提到】
: 从spring看他不懂
|
l******t
发帖数: 55733 | 129 依然不改变他不懂FP
【在 g*****g 的大作中提到】
: 从spring看，他是工程的大大牛，能把东西做好做大的。发明语言容易，
: 做大语言才难。
|
g*****g
发帖数: 34805 | 130 人被邀请在conference上谈scala，等你也做到了再说吧。
【在 l******t 的大作中提到】
: 依然不改变他不懂FP
|
|
|
c*******9
发帖数: 9032 | 131 这个原子论是朴素惟物论，已经不适合近代科学了。
【在 g*****g 的大作中提到】
: 这不扯蛋吗，恰恰是直觉的东西才容易理解。世界本质还是原子组成的，难道就得用原
: 子建模？
|
l******t
发帖数: 55733 | 132 依然不改变他不懂FP
【在 g*****g 的大作中提到】
: 人被邀请在conference上谈scala，等你也做到了再说吧。
|
G***l
发帖数: 355 | 133 我说design pattern主要是解决oo里对behavior建模的不足有什么不对？哪里乱喷了。
gof二十几个，十几个是behavioral,creational，这两个都是行为。那剩下几个所谓结
构性的，只是用某种oo的结构解决behavior模型的问题，adapter,decorator,bridge这
些，哪个不是用来补充对behavior的建模的？可能只有composite，flyweight这两三个
关于data更多点。flyweight还是关于share data的，重点在share，还是一种对
behavior的建模。
【在 z****e 的大作中提到】
: design pattern你们也不要乱喷
: pattern也分为很多种，behavior 只是其中一类
: 另外的结构类pattern其实fp也解决不了，而且结构类的pattern就是针对大项目的困难
: 而造
: 跟fp没有必然联系，实际上fp还会更依赖结构类的pattern
: 因为如果没有结构类的pattern，要想做fp也不容易
: java8里面对于fp的lambda就采用了特殊的一个interface
|
z****e
发帖数: 54598 | 134 结构不比行为少多少
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
行为模式其实一直都不是问题
主要问题在数据上，瓶颈一般都发生在db上
app server的负载很早以前就远远超过db的负载了
所以才会有了近些年的nosql，就是因为人们对db的能力不满意
而相比之下，很多轻量级的framework都在web公司跑得很欢快
你do知道这些framework其实比起jboss这些来说，其实只是其中的子集
一个组件，right？
【在 G***l 的大作中提到】
: 我说design pattern主要是解决oo里对behavior建模的不足有什么不对？哪里乱喷了。
: gof二十几个，十几个是behavioral,creational，这两个都是行为。那剩下几个所谓结
: 构性的，只是用某种oo的结构解决behavior模型的问题，adapter,decorator,bridge这
: 些，哪个不是用来补充对behavior的建模的？可能只有composite，flyweight这两三个
: 关于data更多点。flyweight还是关于share data的，重点在share，还是一种对
: behavior的建模。
|
z****e
发帖数: 54598 | 135 还有你do知道j2ee core patterns几乎都是结构和数据
right？
http://www.corej2eepatterns.com/
【在 G***l 的大作中提到】
: 我说design pattern主要是解决oo里对behavior建模的不足有什么不对？哪里乱喷了。
: gof二十几个，十几个是behavioral,creational，这两个都是行为。那剩下几个所谓结
: 构性的，只是用某种oo的结构解决behavior模型的问题，adapter,decorator,bridge这
: 些，哪个不是用来补充对behavior的建模的？可能只有composite，flyweight这两三个
: 关于data更多点。flyweight还是关于share data的，重点在share，还是一种对
: behavior的建模。
|
z****e
发帖数: 54598 | 136 fp所谓的模式不需要，是错误的
更需要结构模式来帮助定位fp的领域
否则fp就是灾难，过于强调行为就跟过于强调数据一样
都是错误的，任何一个领域，我们都要抓，都要控制住
甚至presentation，否则系统会挂，凡事过犹不及 |
z****e
发帖数: 54598 | 137 fp要求不传状态，这本身就是一个最大的trade off
这个trade off有些太大了，以至于把一些很简单的问题都复杂化了
如果oop的pattern可以优化传状态的行为的话
为什么不？
甚至你可以认为不传状态本身也是一种大pattern
那我能不能不要不传状态呢？ |
G***l
发帖数: 355 | 138 所谓结构性的是有好几个，但是再说最后一遍，他们大都是关于提高OO对behavior建模
不足的。Adapter, Decorator, Bridge这些"structural"的pattern都是做这种事的，
我前面的贴子已经说过了，不再重复。
还要我之前说的是design pattern，更多的是class/function level的东西，也是FP/
OO带来不同的地方。系统架构上用rest/soap, sql/no sql, browser/desktop这些，对
底层实现用fp还是oo一毛钱关系都没有。你说的什么db, nosql什么的，他们是更高架
构层面的东西，和oo/fp不是一个层面的思考，完全跑题了。
【在 z****e 的大作中提到】
: 结构不比行为少多少
: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
: 行为模式其实一直都不是问题
: 主要问题在数据上，瓶颈一般都发生在db上
: app server的负载很早以前就远远超过db的负载了
: 所以才会有了近些年的nosql，就是因为人们对db的能力不满意
: 而相比之下，很多轻量级的framework都在web公司跑得很欢快
: 你do知道这些framework其实比起jboss这些来说，其实只是其中的子集
: 一个组件，right？
|
z****e
发帖数: 54598 | 139 喂，这里底层实现怎么定义？
如果底层实现的话，很多东西其实没有必要讨论
我管你什么语言写的产品，能用就行了
难道你写的是商业产品？现在都服务了，做产品的越来越少
很重要一个原因是产品大部分都开源了
实际上我一直说的都是服务用什么来写
而不是产品用什么来写，写产品的话，你爱用什么就用什么
但是我用产品，很多时候就是oop的主要的去处
【在 G***l 的大作中提到】
: 所谓结构性的是有好几个，但是再说最后一遍，他们大都是关于提高OO对behavior建模
: 不足的。Adapter, Decorator, Bridge这些"structural"的pattern都是做这种事的，
: 我前面的贴子已经说过了，不再重复。
: 还要我之前说的是design pattern，更多的是class/function level的东西，也是FP/
: OO带来不同的地方。系统架构上用rest/soap, sql/no sql, browser/desktop这些，对
: 底层实现用fp还是oo一毛钱关系都没有。你说的什么db, nosql什么的，他们是更高架
: 构层面的东西，和oo/fp不是一个层面的思考，完全跑题了。
|
G***l
发帖数: 355 | 140 我说的底层就是需要设计interface/class/function/algorithm,以及实现测试他们的
地方。各种对业务逻辑的建模，设计和实现。比如一个apache web server如何处理特
定的request，os如何调度若干个任务，google在你的浏览器上显示什么广告，amazon
如何处理你的order，如何进行仓库的调度，基金公司如何计算某个证券的收益和风险
，汽车保险公司怎么算出一个customer的quote，travel网站如何获取最“好”的机票
租车酒店。所有这些现实世界的东西，都需要设计和实现。这跟做产品还是服务有什么
关系？
【在 z****e 的大作中提到】
: 喂，这里底层实现怎么定义？
: 如果底层实现的话，很多东西其实没有必要讨论
: 我管你什么语言写的产品，能用就行了
: 难道你写的是商业产品？现在都服务了，做产品的越来越少
: 很重要一个原因是产品大部分都开源了
: 实际上我一直说的都是服务用什么来写
: 而不是产品用什么来写，写产品的话，你爱用什么就用什么
: 但是我用产品，很多时候就是oop的主要的去处
|
