b*******s
发帖数: 5216 | |
b*******s
发帖数: 5216 | 2 举个例子，stl的设计就是数据和方法分离的，而oo是数据和方法绑定的强耦合方式。
带来了高度的灵活性和极佳的效率。比如查找，oo的办法要为每种数据组织方法都写一
个处理函数，而stl风格的根本不关心底下数据是如何存放的，一个函数能处理一大堆
各种不同的容器，平均效率还更高。
很多现在的新语言特点，比如duck typing 都是在解oo的毒。或者强调接口，淡化类。 |
d********t
发帖数: 9628 | 3 OO也是数据方法分离
【在 b*******s 的大作中提到】
: 举个例子，stl的设计就是数据和方法分离的，而oo是数据和方法绑定的强耦合方式。
: 带来了高度的灵活性和极佳的效率。比如查找，oo的办法要为每种数据组织方法都写一
: 个处理函数，而stl风格的根本不关心底下数据是如何存放的，一个函数能处理一大堆
: 各种不同的容器，平均效率还更高。
: 很多现在的新语言特点，比如duck typing 都是在解oo的毒。或者强调接口，淡化类。
|
l*********s
发帖数: 5409 | 4 obviously not.
【在 d********t 的大作中提到】
: OO也是数据方法分离
|
g*****g
发帖数: 34805 | 5 你丫缺乏基本功，连个factory pattern都不知道，谈啥 OO好不好不是放屁吗。用啥语
言是其
次的，关键是要实践，光装逼是当不了好程序员的。OO语言牛逼同样是实践出来的，不
是几个傻逼不愿意能改变的。
【在 b*******s 的大作中提到】
: 举个例子，stl的设计就是数据和方法分离的，而oo是数据和方法绑定的强耦合方式。
: 带来了高度的灵活性和极佳的效率。比如查找，oo的办法要为每种数据组织方法都写一
: 个处理函数，而stl风格的根本不关心底下数据是如何存放的，一个函数能处理一大堆
: 各种不同的容器，平均效率还更高。
: 很多现在的新语言特点，比如duck typing 都是在解oo的毒。或者强调接口，淡化类。
|
w**z
发帖数: 8232 | |
g*****g
发帖数: 34805 | 7 方法耦合的是类型，不是数据。就像人呢吃饭，1米的能吃饭，1米8的也能吃饭。但1米
8的柜子就不能吃饭。
【在 l*********s 的大作中提到】
: obviously not.
|
z******g
发帖数: 271 | 8 例子真逗，哈哈
【在 g*****g 的大作中提到】
: 方法耦合的是类型，不是数据。就像人呢吃饭，1米的能吃饭，1米8的也能吃饭。但1米
: 8的柜子就不能吃饭。
|
f*******t
发帖数: 7549 | 9 2333333
【在 g*****g 的大作中提到】
: 方法耦合的是类型，不是数据。就像人呢吃饭，1米的能吃饭，1米8的也能吃饭。但1米
: 8的柜子就不能吃饭。
|
n*w
发帖数: 3393 | 10 这串数字是什么意思？
在OOP兴起时有一帮人也是对OOP痛恨。强调 structure programming是一切解药。和这
个版在OOP和后oop/fp讨论时的态度很像。可以和当初剪辫子，废缠足时某些人捶胸顿
足相比。
【在 f*******t 的大作中提到】
: 2333333
|
|
|
g*****g
发帖数: 34805 | 11 Except FP is way older than OOP, and is having some life now because they
can borrow some libraries from a dominant OO language. You don't have to
like current fashion
style, but being naked doesn't solve the problem.
比。
【在 n*w 的大作中提到】
: 这串数字是什么意思？
: 在OOP兴起时有一帮人也是对OOP痛恨。强调 structure programming是一切解药。和这
: 个版在OOP和后oop/fp讨论时的态度很像。可以和当初剪辫子，废缠足时某些人捶胸顿
: 足相比。
|
N******K
发帖数: 10202 | 12 按照 vtk itk设计思路 方法 是和 数据分离的
不过方法都当做一个filter 是个类
【在 b*******s 的大作中提到】
: 举个例子，stl的设计就是数据和方法分离的，而oo是数据和方法绑定的强耦合方式。
: 带来了高度的灵活性和极佳的效率。比如查找，oo的办法要为每种数据组织方法都写一
: 个处理函数，而stl风格的根本不关心底下数据是如何存放的，一个函数能处理一大堆
: 各种不同的容器，平均效率还更高。
: 很多现在的新语言特点，比如duck typing 都是在解oo的毒。或者强调接口，淡化类。
|
b*******s
发帖数: 5216 | 13 嗯，所有你看不懂的都是外行，问题是，你都不知道别人在说什么
【在 g*****g 的大作中提到】
: 方法耦合的是类型，不是数据。就像人呢吃饭，1米的能吃饭，1米8的也能吃饭。但1米
: 8的柜子就不能吃饭。
|
g*****g
发帖数: 34805 | 14 外行不外行需要我定义吗？是事实好不好？
【在 b*******s 的大作中提到】
: 嗯，所有你看不懂的都是外行，问题是，你都不知道别人在说什么
|
n******t
发帖数: 4406 | 15 OO是一类编程思想，而且也只是一种思想,尤其使用范围。
问题在于这东西和语言没有必然联系，所以在语言层面上面enforce，
没什么意义。
【在 b*******s 的大作中提到】
: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
|
f*******t
发帖数: 7549 | 16 233333是大笑的意思
【在 n*w 的大作中提到】
: 这串数字是什么意思？
: 在OOP兴起时有一帮人也是对OOP痛恨。强调 structure programming是一切解药。和这
: 个版在OOP和后oop/fp讨论时的态度很像。可以和当初剪辫子，废缠足时某些人捶胸顿
: 足相比。
|
b*******s
发帖数: 5216 | 17 我提到很多语言的“必然联系”了吗。我看看
OO只是诸多paradigm之一。比如这文章搞的erlang在whatsapp这个产品上做到了单机百
万稳定会话。显然不是OO的功劳。本版有几个人，只会一两种东西，但霸道得很，喜欢
拿自己的一点知识来误导，比如知道个类厂就得瑟得不行。自己没能力造轮子就把造轮
子说得一无是处。我是很诧异类厂都要专门提，一块钱夹在镜子里当宝。说实话，讨论
层次之低，思维之僵化超出想象
【在 n******t 的大作中提到】
: OO是一类编程思想，而且也只是一种思想,尤其使用范围。
: 问题在于这东西和语言没有必然联系，所以在语言层面上面enforce，
: 没什么意义。
|
b*******s
发帖数: 5216 | 18 不知道web svc多oo
【在 g*****g 的大作中提到】
: 外行不外行需要我定义吗？是事实好不好？
|
g*****g
发帖数: 34805 | 19 factory pattern当然是很基本的东西，所以当傻逼批评一个经典的 factory pattern
是狗屎设计的时候你就知道他不懂 OO设计。同理还有不懂 transaction非要设计12306
。这种事情多次发生外行就是个客气的总结而已。
【在 b*******s 的大作中提到】
: 我提到很多语言的“必然联系”了吗。我看看
: OO只是诸多paradigm之一。比如这文章搞的erlang在whatsapp这个产品上做到了单机百
: 万稳定会话。显然不是OO的功劳。本版有几个人，只会一两种东西，但霸道得很，喜欢
: 拿自己的一点知识来误导，比如知道个类厂就得瑟得不行。自己没能力造轮子就把造轮
: 子说得一无是处。我是很诧异类厂都要专门提，一块钱夹在镜子里当宝。说实话，讨论
: 层次之低，思维之僵化超出想象
|
b*******s
发帖数: 5216 | 20 一万种图形还要坚持类厂，真不知道谁是傻b呢。我用的也是pattern，只是你不知道而已
而且你那地方很牛？我们两百人的一个组一年利润是你们两千多人全部利润的三倍
pattern
12306
【在 g*****g 的大作中提到】
: factory pattern当然是很基本的东西，所以当傻逼批评一个经典的 factory pattern
: 是狗屎设计的时候你就知道他不懂 OO设计。同理还有不懂 transaction非要设计12306
: 。这种事情多次发生外行就是个客气的总结而已。
|
|
|
g*****g
发帖数: 34805 | 21 你丫别傻逼得弄不靠边的前提。谁也不知道要处理什么样的图形，我的能扩展处理你的
，你的不行，就这么简单。设计模式就是这么回事。
我们利润低是因为扩张，再说了，利润高低关我屁事，我只关心工资和股票。你丫就是
白菜命，白粉心。
而已
【在 b*******s 的大作中提到】
: 一万种图形还要坚持类厂，真不知道谁是傻b呢。我用的也是pattern，只是你不知道而已
: 而且你那地方很牛？我们两百人的一个组一年利润是你们两千多人全部利润的三倍
:
: pattern
: 12306
|
b*******s
发帖数: 5216 | 22 就是，癌症还能占据人体呢。
你那股票最后拿到多少再说，下个月我们就发奖金了，今年比工资高
【在 g*****g 的大作中提到】
: 你丫别傻逼得弄不靠边的前提。谁也不知道要处理什么样的图形，我的能扩展处理你的
: ，你的不行，就这么简单。设计模式就是这么回事。
: 我们利润低是因为扩张，再说了，利润高低关我屁事，我只关心工资和股票。你丫就是
: 白菜命，白粉心。
:
: 而已
|
b*******s
发帖数: 5216 | 23 一个字，少装b
【在 g*****g 的大作中提到】
: 你丫别傻逼得弄不靠边的前提。谁也不知道要处理什么样的图形，我的能扩展处理你的
: ，你的不行，就这么简单。设计模式就是这么回事。
: 我们利润低是因为扩张，再说了，利润高低关我屁事，我只关心工资和股票。你丫就是
: 白菜命，白粉心。
:
: 而已
|
g*****g
发帖数: 34805 | 24 嘿嘿，你丫技术不行就别出来丢人。被打脸满地找场子。C++写不好成天 FP FP的，说
的跟 FP你很牛似的。
【在 b*******s 的大作中提到】
: 一个字，少装b
|
g*****g
发帖数: 34805 | 25 你丫工资真低，赶紧跳吧。
【在 b*******s 的大作中提到】
: 就是，癌症还能占据人体呢。
: 你那股票最后拿到多少再说，下个月我们就发奖金了，今年比工资高
|
b*******s
发帖数: 5216 | 26 搞半天你以为我在讲fp? 一个字，井底之蛙
【在 g*****g 的大作中提到】
: 嘿嘿，你丫技术不行就别出来丢人。被打脸满地找场子。C++写不好成天 FP FP的，说
: 的跟 FP你很牛似的。
|
b*******s
发帖数: 5216 | 27 疯了吧
【在 g*****g 的大作中提到】
: 你丫工资真低，赶紧跳吧。
|
g*****g
发帖数: 34805 | 28 你丫说啥不是超过两句就胡说，有区别吗？
【在 b*******s 的大作中提到】
: 搞半天你以为我在讲fp? 一个字，井底之蛙
|
l*******o
发帖数: 250 | |
n*w
发帖数: 3393 | 30 哦，Google了一下。没查到来源。
【在 f*******t 的大作中提到】
: 233333是大笑的意思
|
|
|
n*w
发帖数: 3393 | 31 有点值得思考。1.对新事物的接受度，2.对自己不能掌握的或不知道的事物的态度问题
。3.对不同观点的处理。
【在 b*******s 的大作中提到】
: 我提到很多语言的“必然联系”了吗。我看看
: OO只是诸多paradigm之一。比如这文章搞的erlang在whatsapp这个产品上做到了单机百
: 万稳定会话。显然不是OO的功劳。本版有几个人，只会一两种东西，但霸道得很，喜欢
: 拿自己的一点知识来误导，比如知道个类厂就得瑟得不行。自己没能力造轮子就把造轮
: 子说得一无是处。我是很诧异类厂都要专门提，一块钱夹在镜子里当宝。说实话，讨论
: 层次之低，思维之僵化超出想象
|
q*c
发帖数: 9453 | 32 谈利润就没意思了， 资本主义世界里决定利润的是资本，商业， 权力独裁世界里决定
利润的是权力。
唯独和技术毫无关系啊。
而已
【在 b*******s 的大作中提到】
: 一万种图形还要坚持类厂，真不知道谁是傻b呢。我用的也是pattern，只是你不知道而已
: 而且你那地方很牛？我们两百人的一个组一年利润是你们两千多人全部利润的三倍
:
: pattern
: 12306
|
n******t
发帖数: 4406 | 33 没办法，这年头对程序员的需求远远大于人群中适合学编程的人的数目。导致很多其实
自然就会形成的一些pattern,变成了对很多程序员来说需要学的东西。这种事情的结果
就是，很多人基本上只是背下来了这些pattern，不知道也不关心为什么要这样。
一般来讲，人不懂为什么的东西，一般来说就绝对不允许别人提出任何异议或者改动，
这种例子很多，大家很容易找出各种例子。
【在 b*******s 的大作中提到】
: 我提到很多语言的“必然联系”了吗。我看看
: OO只是诸多paradigm之一。比如这文章搞的erlang在whatsapp这个产品上做到了单机百
: 万稳定会话。显然不是OO的功劳。本版有几个人，只会一两种东西，但霸道得很，喜欢
: 拿自己的一点知识来误导，比如知道个类厂就得瑟得不行。自己没能力造轮子就把造轮
: 子说得一无是处。我是很诧异类厂都要专门提，一块钱夹在镜子里当宝。说实话，讨论
: 层次之低，思维之僵化超出想象
|
t**********h
发帖数: 2273 | 34 大牛，贴w2吧，膜拜一下
【在 b*******s 的大作中提到】
: 就是，癌症还能占据人体呢。
: 你那股票最后拿到多少再说，下个月我们就发奖金了，今年比工资高
|
t**********h
发帖数: 2273 | 35 大牛，贴w2吧，膜拜一下
【在 g*****g 的大作中提到】
: 你丫工资真低，赶紧跳吧。
|
g*****g
发帖数: 34805 | 36 关键是不要本末倒置，工作里写C++却不懂design pattern，被打脸就开口闭口FP如何
如何的，都是傻逼。学通了可以活用，但是连最基本的design pattern都不知道的，都
是假大空来装逼的。说得跟FP就没design pattern似的。
我老说过无数次了，语言牛不牛逼靠的是实践，程序员牛不牛逼靠的也是实践。学了个
HelloWorld就来我懂FP我鄙视OOP的，都是傻逼。本版真正写FP的，就coltzhao和qxc而
已。
【在 n******t 的大作中提到】
: 没办法，这年头对程序员的需求远远大于人群中适合学编程的人的数目。导致很多其实
: 自然就会形成的一些pattern,变成了对很多程序员来说需要学的东西。这种事情的结果
: 就是，很多人基本上只是背下来了这些pattern，不知道也不关心为什么要这样。
: 一般来讲，人不懂为什么的东西，一般来说就绝对不允许别人提出任何异议或者改动，
: 这种例子很多，大家很容易找出各种例子。
|
w***x
发帖数: 105 | 37 OO Sucks，不同意就请逐条反驳原文。
很久以前就看过design pattern，没看过之前觉得好高大上，看完后就觉得不如不看。
OO界，尤其是靠出文章或写书的，胡说八道的太多了。 |
z*******n
发帖数: 1034 | 38 今天的计算机的架构有些细小变化，但始终还是冯诺伊曼架构，
只要计算机是冯诺伊曼架构，包括图灵奖得主在内要挑战冯诺伊曼都不用浪费生命看
更何况一个失败的物理phd
【在 b*******s 的大作中提到】
: http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
|
g*****g
发帖数: 34805 | 39 逐条批驳如何？
1.Objection 1 - Data structure and functions should not be bound together
我老说过了，这根本就是错误的理解，OO说的是这类东西能干什么，而不是说一个数据
能干什么。
2. Objection 2 - Everything has to be an object
宏观物理可以，为啥OO不可以？所谓的例子，物理建模时间无非是个维度，对应OO里一个
property。能把物理推翻可是比做码农牛逼多了。作者想啥呢？
3. Objection 3 - In an OOPL data type definitions are spread out all over
the place
作者有软件工程的基础概念吗？无论什么语言都不希望regression，反复改一个文件不
但使得文件太大难以维护，而且容易出错。而一个源文件没改动连重新编译都不需要。
如果没源码，甚至改都改不了。
类型的查找可以依靠IDE的帮助，不放一起就找不到了？作者属于人生生给尿憋死的类
型。
4. Objection 4 - Objects have private state
这恰恰是OO dominant的精髓，encapsulation。为的是确保对状态的操作不会使多个状
态out of sync，或者进入不合法的状态。圣玛丽就是跟人上床，而不是god把肚子
弄大的。状态的变化依赖操作，而不是直接访问很奇怪吗？
【在 w***x 的大作中提到】
: OO Sucks，不同意就请逐条反驳原文。
: 很久以前就看过design pattern，没看过之前觉得好高大上，看完后就觉得不如不看。
: OO界，尤其是靠出文章或写书的，胡说八道的太多了。
|
r*g
发帖数: 3159 | 40 金融业吗？
【在 b*******s 的大作中提到】
: 就是，癌症还能占据人体呢。
: 你那股票最后拿到多少再说，下个月我们就发奖金了，今年比工资高
|
|
|
l******t
发帖数: 55733 | 41 大牛太多说说我对第一条理解吧。
首先不要用数据实例偷换数据类型的概念。原作者一直说的是类型。
其次 OO(Java) 把一类object该干什么事这事干反了。
复习下category的定义，就是满足一系列“arrow”的"object"。注意这里的抽象主体
其实是arrow。是定义了一系列arrow后object反向绑入category。相对OO来说是逆过程
反直观的。FP是直接map这一定义的。haskell最纯，没有和java class对应的定义。‘
type class’和’data'是互不包含的。type class定义了category，通过提供type
class对某一data type的实现把data归入这一category。scala折衷允许双向包含带来
很多混乱。
OO(Java)至少干错2件半事。
先说半件事，interface是好的，但应该是实现主体，现在的定义全空说明当时设计者
没有意识到和category的对应。
第二是继承。继承是彻底反人类。继承数据还是算法？如果是数据，按照category的定
义，没有算法约束的数据是不能归入同一category的。如果是算法，那么应该在
interface中定义。
第三是abstract class。abstract class做了interface该作的事，可是却被归入了某
类数据类型，也就失去了应用到其他类型的能力。
说远点，factory，DI，mixin等等其本质都是定义算法然后反绑数据，都是朴素的
category。这些pattern出现的根源都是OO(java) anti pattern。
OO和FP就像托勒密和哥白尼。托勒密观察到事实，直观的建了模创建了伟大的缜密的精
确的基于傅里叶变换的系统。任何时候都可以算出结果，如果要更精确就再加几个轮子
继续增加系统复杂度。也是一时权倾信者如云。
后来出了哥白尼。要注意的是哥白尼也被主流冷落打击了很多年，个别信徒甚至被烧死
，其惨不可言说。
大意吧，剃刀法则早晚会工作的。 |
g*****g
发帖数: 34805 | 42 你这说的太不靠谱了，图灵机本身就是个完备自洽的体系，并不需要各种修正，你拿托
勒密来比就是一厢情
愿罢了。
inheritance, composition, mixin只不过是完成同一件事情不同的实现方法，各有利
弊而已。语言的精髓在于取舍，而不在于纯粹，也不在于feature多，feature就导致复
杂度提高。编程语言就跟人类语言一样，有的用主
谓宾，有的用主宾谓，都能表达同样的思想。但是用主谓宾的是主流，哭诉什么主宾谓
更先进是没有意义的。实践科学，都是拉出来遛。编程语言理论是一个总结，而不能
决定语言应该怎么设计。
【在 l******t 的大作中提到】
: 大牛太多说说我对第一条理解吧。
: 首先不要用数据实例偷换数据类型的概念。原作者一直说的是类型。
: 其次 OO(Java) 把一类object该干什么事这事干反了。
: 复习下category的定义，就是满足一系列“arrow”的"object"。注意这里的抽象主体
: 其实是arrow。是定义了一系列arrow后object反向绑入category。相对OO来说是逆过程
: 反直观的。FP是直接map这一定义的。haskell最纯，没有和java class对应的定义。‘
: type class’和’data'是互不包含的。type class定义了category，通过提供type
: class对某一data type的实现把data归入这一category。scala折衷允许双向包含带来
: 很多混乱。
: OO(Java)至少干错2件半事。
|
w****6
发帖数: 796 | 43 俺来这班上最大的乐趣之一就是看各位大牛
打架，好玩又长知识 ;) |
b***e
发帖数: 1419 | 44 It's interesting that you mentioned category theory, to which I'd like to
add my opinions.
First, the category theory arrows, when mapped to functional programming, is
corresponding more to type constructors rather than functions. In other
words, they are functions on types at compile time instead of functions on
runtime values. so I don't think there is a direct parallel between
category theory objects and arrows vs. objects and functions in the context
of discussing OOP vs. FP.
Second, in category theory objects and arrows are dual to each other. for
each category there can be built a cocategory where objects become arrows
and arrows become objects. In that sense, the view of arrows as root may
not be that important. I guess from the view of category theory, we may
be able to define a mathematical duality between OOP and FP, which would be
very interesting and enlightening.
【在 l******t 的大作中提到】
: 大牛太多说说我对第一条理解吧。
: 首先不要用数据实例偷换数据类型的概念。原作者一直说的是类型。
: 其次 OO(Java) 把一类object该干什么事这事干反了。
: 复习下category的定义，就是满足一系列“arrow”的"object"。注意这里的抽象主体
: 其实是arrow。是定义了一系列arrow后object反向绑入category。相对OO来说是逆过程
: 反直观的。FP是直接map这一定义的。haskell最纯，没有和java class对应的定义。‘
: type class’和’data'是互不包含的。type class定义了category，通过提供type
: class对某一data type的实现把data归入这一category。scala折衷允许双向包含带来
: 很多混乱。
: OO(Java)至少干错2件半事。
|
l******t
发帖数: 55733 | 45 你说的这些很对。有时也需要退一步换对方视角看看。
是的图灵机本身完备。现在也并没有lambda机而是转换为图灵机也反证图灵机是完备的。
图灵机缺的是没有抽象和应用的过程。而抽象和应用这是lambda的内质。理论上lambda
式可以自动机器演算判定，编程上FP的代码实现也是高度抽象高度精简比图灵机指令式
表达有效的多。
OO的问题并不是图灵机的的问题而是本身的问题。基础描述不清基本等同口头描述。
Corner case修修补补添加各种轮和地心轮说可以媲美。
算法，代码，语言，feature都可以有好有坏。语言也有high level low level的。目
测fp应该是下一个level。现在的趋势也是各种语言纷纷marry 基本lambda。FP本身并
没有很多feature，lambda，trait，强类型自动推，pattern match，lazy，加几套基
本库，差不多够了吧。scala是被OO兼容搞坏了。
先进也要等主流。太超前的下场就是被烧死。感觉现在主流已经很靠拢。haskell轮子
不够scala还是过渡，java马上20年了已经很长寿了。现在就等一个和c cpp java同等
地位的breaker。现在的分布计算可能就是突破口。一旦出现就会和java当年一样爆发
。到时大家都面临选择是跳船还是死守。
瞎聊各位大牛见笑。主要是菌版无好贴无美女。
【在 g*****g 的大作中提到】
: 你这说的太不靠谱了，图灵机本身就是个完备自洽的体系，并不需要各种修正，你拿托
: 勒密来比就是一厢情
: 愿罢了。
: inheritance, composition, mixin只不过是完成同一件事情不同的实现方法，各有利
: 弊而已。语言的精髓在于取舍，而不在于纯粹，也不在于feature多，feature就导致复
: 杂度提高。编程语言就跟人类语言一样，有的用主
: 谓宾，有的用主宾谓，都能表达同样的思想。但是用主谓宾的是主流，哭诉什么主宾谓
: 更先进是没有意义的。实践科学，都是拉出来遛。编程语言理论是一个总结，而不能
: 决定语言应该怎么设计。
|
N******K
发帖数: 10202 | 46 java不能保证数组连续存储 这一条就自绝于数值计算了
的。
lambda
【在 l******t 的大作中提到】
: 你说的这些很对。有时也需要退一步换对方视角看看。
: 是的图灵机本身完备。现在也并没有lambda机而是转换为图灵机也反证图灵机是完备的。
: 图灵机缺的是没有抽象和应用的过程。而抽象和应用这是lambda的内质。理论上lambda
: 式可以自动机器演算判定，编程上FP的代码实现也是高度抽象高度精简比图灵机指令式
: 表达有效的多。
: OO的问题并不是图灵机的的问题而是本身的问题。基础描述不清基本等同口头描述。
: Corner case修修补补添加各种轮和地心轮说可以媲美。
: 算法，代码，语言，feature都可以有好有坏。语言也有high level low level的。目
: 测fp应该是下一个level。现在的趋势也是各种语言纷纷marry 基本lambda。FP本身并
: 没有很多feature，lambda，trait，强类型自动推，pattern match，lazy，加几套基
|
g*****g
发帖数: 34805 | 47 你说来说去只能说明fp简洁而已，expressive而已，这个并没有人反对。design
pattern所谓修修补补是从软件工程角度出发的，目的是最大化重用，最小化修改，而
不是最简洁。fp根本不可能包含这个内容。结果就是 fp一样需要 design pattern. 如
cake pattern. fp就那么回事吧，离完善差了十万八千里。整个 industry的爆发在于
榜上了 JVM，做了几个并
发轮子很不错。但因为几个轮子就全盘重写就是本末倒置了。这个我老三年前就总结完
了，做并发轮子的Niche. 业界在最初的 hype之后正进入同样的反思，而这个版就比较
后知后觉了。
替代Java的语言早晚会出现的，但现有的都没戏是可以定论了。只能做个补充。我老也
只能向前看十年。
的。
lambda
【在 l******t 的大作中提到】
: 你说的这些很对。有时也需要退一步换对方视角看看。
: 是的图灵机本身完备。现在也并没有lambda机而是转换为图灵机也反证图灵机是完备的。
: 图灵机缺的是没有抽象和应用的过程。而抽象和应用这是lambda的内质。理论上lambda
: 式可以自动机器演算判定，编程上FP的代码实现也是高度抽象高度精简比图灵机指令式
: 表达有效的多。
: OO的问题并不是图灵机的的问题而是本身的问题。基础描述不清基本等同口头描述。
: Corner case修修补补添加各种轮和地心轮说可以媲美。
: 算法，代码，语言，feature都可以有好有坏。语言也有high level low level的。目
: 测fp应该是下一个level。现在的趋势也是各种语言纷纷marry 基本lambda。FP本身并
: 没有很多feature，lambda，trait，强类型自动推，pattern match，lazy，加几套基
|
l******t
发帖数: 55733 | 48
is
context
for
大牛这内涵太多得看半年。
你这个type constructor的说法很好。
type本身的定义也是lambda的一部分。typed lambda就是靠一堆运算定义出已知type。
type constructor本身就是arrow。可以把type看成是lambda的某种语法糖把。
这样的话探讨一下，function本身也是静态compile time决定的，和type constructor
一致。而runtime function apply to value和create data from constructor是等价
的。特别是如果考虑type就是lambda的语法糖的话。
只要运算基于已知type，type level programming可以完备。但type本身不是基本定义
。感觉讨论FP/OOP应该还是可以放弃type只用arrow和object。
很同意OO和category不能完全直接对比。只能类比。
你这个dulity的想法我得消化一下。感觉是需要2次反转。第一次反转可以把OOP反转成
category。但再反转回来时还要面对同样的OOP问题。必须有某种变换。直觉由于OOP的
语义缺陷，这个变换不一定存在。但完全同意这个思路如果成立的话，那OOP和FP的兼
容就不是问题了。scala也许可以消失。vely vely beautiful。
【在 b***e 的大作中提到】
: It's interesting that you mentioned category theory, to which I'd like to
: add my opinions.
: First, the category theory arrows, when mapped to functional programming, is
: corresponding more to type constructors rather than functions. In other
: words, they are functions on types at compile time instead of functions on
: runtime values. so I don't think there is a direct parallel between
: category theory objects and arrows vs. objects and functions in the context
: of discussing OOP vs. FP.
: Second, in category theory objects and arrows are dual to each other. for
: each category there can be built a cocategory where objects become arrows
|
l******t
发帖数: 55733 | 49
fp被你简化成两字，简洁。面对你这超级赛亚人般抽象能力我也是醉了。
cake pattern可能还真算不上个pattern。不像spring一类的DI基本已经成了java本身
的一部分了。或者说没有了DI Java轮子得死一大半把。
当年java的突破也就是在跨平台，write once，run anywhere。这个跨平台和现在的并
发轮子有没点相似之处。
【在 g*****g 的大作中提到】
: 你说来说去只能说明fp简洁而已，expressive而已，这个并没有人反对。design
: pattern所谓修修补补是从软件工程角度出发的，目的是最大化重用，最小化修改，而
: 不是最简洁。fp根本不可能包含这个内容。结果就是 fp一样需要 design pattern. 如
: cake pattern. fp就那么回事吧，离完善差了十万八千里。整个 industry的爆发在于
: 榜上了 JVM，做了几个并
: 发轮子很不错。但因为几个轮子就全盘重写就是本末倒置了。这个我老三年前就总结完
: 了，做并发轮子的Niche. 业界在最初的 hype之后正进入同样的反思，而这个版就比较
: 后知后觉了。
: 替代Java的语言早晚会出现的，但现有的都没戏是可以定论了。只能做个补充。我老也
: 只能向前看十年。
|
g*****g
发帖数: 34805 | 50 因为expressive所以简洁，我觉得没说错呀。
Spring这个东西恰恰证明我的一贯主张，简单的语言可以用轮子补。什么都想写进语言
，写得了吗？Java的突破不在于跨平台，而在于 GC，以及单根和接口的结合解决了多
继承的问题，使得语言很简单。这种突破在写应用上是全领域的改进，而不是拘泥于像
并发一个小领域。
【在 l******t 的大作中提到】
:
: fp被你简化成两字，简洁。面对你这超级赛亚人般抽象能力我也是醉了。
: cake pattern可能还真算不上个pattern。不像spring一类的DI基本已经成了java本身
: 的一部分了。或者说没有了DI Java轮子得死一大半把。
: 当年java的突破也就是在跨平台，write once，run anywhere。这个跨平台和现在的并
: 发轮子有没点相似之处。
|
|
|
l******t
发帖数: 55733 | 51 gc 继承一类小了。用CPP没问题。mfc那时候已经可以监视内存泄露了。这属于语言特
性按你说法不是问题也确实不是太大问题。JVM跨平台是真货。
fp已经够语言的突破。这个并发niche有多小还得观察。
【 FP并没有很多feature，scalaFP并没有很多feature，scala在 goodbug (好虫) 的
大作中提到: 】 |
w***x
发帖数: 105 | 52 1. function是计算的基本单元，它的基本作用就是转化data的状态。一个data
structure可以对应无数的function，OO把这些混在一起，限制了扩展。至于你说的，
我觉得风马牛不相及。
2. 原文说的很清楚，有些概念,简单的定义就能清晰表达，根本无需赴加任何方法属性
，反之纯粹是画蛇添足。你的意思是觉得画蛇添足也没什么不可以。"物理推翻..." 这
又是风马牛不相及的，这么简单点事，玩些大词有意思么？
3. 又是风马牛。。。软件是改出来的，反复改一个文件恰恰是使得文件更容易维护和
合理，看看linux下好多基础性的函数，都是反复改出来的。至于你说的“类型的查找
”，人家说的是design混乱的问题，你以为只有你会用IDE?
4. 这个是OO最大的弊端也是最不可原谅的。你说的情况是bug free的时候，而bug
free是要经过漫长的修改迭代做到的。归根到底,代码的可读性是非常重要的，人脑对
于代码上下文的状态迁跃的承受数量是有限的，OO把很多状态带进了黑盒子里，这对理
解和检查代码的正确性造成了巨大的障碍。这也是为什么真正有经验的程序员最后放弃
了c++而回到c的原因。
一个
【在 g*****g 的大作中提到】
: 逐条批驳如何？
: 1.Objection 1 - Data structure and functions should not be bound together
: 我老说过了，这根本就是错误的理解，OO说的是这类东西能干什么，而不是说一个数据
: 能干什么。
: 2. Objection 2 - Everything has to be an object
: 宏观物理可以，为啥OO不可以？所谓的例子，物理建模时间无非是个维度，对应OO里一个
: property。能把物理推翻可是比做码农牛逼多了。作者想啥呢？
: 3. Objection 3 - In an OOPL data type definitions are spread out all over
: the place
: 作者有软件工程的基础概念吗？无论什么语言都不希望regression，反复改一个文件不
|
h**********c
发帖数: 4120 | 53 建模需要oo
尤其没有domain model，oo肯定很乱
这个版几乎不讨论数据库的anomaly 分析，进而是normal form,
transaction dependency graph
很多oo的问题是oo 用错了，根本就不建模 |
w***x
发帖数: 105 | 54 所谓建模实际上是建立算法的模型，和OO没关系。
这世界是由算法驱动的，OO是算法演算出来的表象。
所以上来就OO，完全是本末倒置。
【在 h**********c 的大作中提到】
: 建模需要oo
: 尤其没有domain model，oo肯定很乱
: 这个版几乎不讨论数据库的anomaly 分析，进而是normal form,
: transaction dependency graph
: 很多oo的问题是oo 用错了，根本就不建模
|
h**********c
发帖数: 4120 | 55 那啥是算法
do something in finite step
A is a self-contained step-by-step set of operations to be performed.
过程话语言上来就要你学画流程图，可能潭浩强的basic pascal你都忘了
oo就是封装流程图 |
b***e
发帖数: 1419 | 56 为什么建模需要OO？建模一般最后都是落实到状态机上，和OO是正交的概念，可以用OO
描述也可以不用。
【在 h**********c 的大作中提到】
: 建模需要oo
: 尤其没有domain model，oo肯定很乱
: 这个版几乎不讨论数据库的anomaly 分析，进而是normal form,
: transaction dependency graph
: 很多oo的问题是oo 用错了，根本就不建模
|
h**********c
发帖数: 4120 | 57 oo的继承状态可以表示数据的normal form order，从而决定模型的atomicity
我老还是低调地加一句，opinion,仅供参考
OO
【在 b***e 的大作中提到】
: 为什么建模需要OO？建模一般最后都是落实到状态机上，和OO是正交的概念，可以用OO
: 描述也可以不用。
|
N******K
发帖数: 10202 | 58 你说的很对
一个对象也可是一个复杂的计算模块
举个例子 图像类是一个数据类 每一种处理算法都是一个类
这些类串起来 组成一个处理流程
状态是很重要的东西 比如kalman滤波 必须存贮状态
【在 h**********c 的大作中提到】
: 那啥是算法
: do something in finite step
: A is a self-contained step-by-step set of operations to be performed.
: 过程话语言上来就要你学画流程图，可能潭浩强的basic pascal你都忘了
: oo就是封装流程图
|
h**********c
发帖数: 4120 | 59 哪里哪里，校长栽培
实际oo应该做到最atomic,这样就可以避免很多coupling 的问题
oo最atomic了，其实就是可以是一个fp，
理想状态只传入数据(literals),
在最地层closure里没有reference
closure 的嵌套要扁平，实际就是domain model
【在 N******K 的大作中提到】
: 你说的很对
: 一个对象也可是一个复杂的计算模块
: 举个例子 图像类是一个数据类 每一种处理算法都是一个类
: 这些类串起来 组成一个处理流程
: 状态是很重要的东西 比如kalman滤波 必须存贮状态
|
g*****g
发帖数: 34805 | 60 GC当然是最大的进步，不用管理内存使得开发维护立马简化了一半。跨平台意义不大，
能在Linux上跑就行。
【在 l******t 的大作中提到】
: gc 继承一类小了。用CPP没问题。mfc那时候已经可以监视内存泄露了。这属于语言特
: 性按你说法不是问题也确实不是太大问题。JVM跨平台是真货。
: fp已经够语言的突破。这个并发niche有多小还得观察。
: 【 FP并没有很多feature，scalaFP并没有很多feature，scala在 goodbug (好虫) 的
: 大作中提到: 】
|
|
|
g*****g
发帖数: 34805 | 61 我老无可辩驳的东西一拿出来，就是风牛马不相及。还软件是改出来的，我老吐了，
fix bug跟加个新类是同一回事吗？我老说过最根本的一句，软件工程强调模块化，就
像其他工程学一样。这个跟OOP建模很相似，FP就不行，所以FP永远没戏。
【在 w***x 的大作中提到】
: 1. function是计算的基本单元，它的基本作用就是转化data的状态。一个data
: structure可以对应无数的function，OO把这些混在一起，限制了扩展。至于你说的，
: 我觉得风马牛不相及。
: 2. 原文说的很清楚，有些概念,简单的定义就能清晰表达，根本无需赴加任何方法属性
: ，反之纯粹是画蛇添足。你的意思是觉得画蛇添足也没什么不可以。"物理推翻..." 这
: 又是风马牛不相及的，这么简单点事，玩些大词有意思么？
: 3. 又是风马牛。。。软件是改出来的，反复改一个文件恰恰是使得文件更容易维护和
: 合理，看看linux下好多基础性的函数，都是反复改出来的。至于你说的“类型的查找
: ”，人家说的是design混乱的问题，你以为只有你会用IDE?
: 4. 这个是OO最大的弊端也是最不可原谅的。你说的情况是bug free的时候，而bug
|
g*****g
发帖数: 34805 | 62 写个算法用状态机也罢，大部分系统设计都是从ER modeling开始，干啥都行，不能避
免存储。你这就是缺乏常识。还真以为matrix哪？说了多少次了，FP跟软件工程格格不
入。OOP建模从名词开始，FP从动词开始。数据库存的是名词的状态。FP天生跟数据库
就八字不合。
OO
【在 b***e 的大作中提到】
: 为什么建模需要OO？建模一般最后都是落实到状态机上，和OO是正交的概念，可以用OO
: 描述也可以不用。
|
g*****g
发帖数: 34805 | 63 从软件工程的角度这种对比早就总结过了。对于写应用来说，OOP无疑是更合适的选择。
http://stackoverflow.com/questions/2078978/functional-programmi
When you anticipate a different kind of software evolution:
Object-oriented languages are good when you have a fixed set of operations
on things, and as your code evolves, you primarily add new things. This can
be accomplished by adding new classes which implement existing methods, and
the existing classes are left alone.
Functional languages are good when you have a fixed set of things, and as
your code evolves, you primarily add new operations on existing things. This
can be accomplished by adding new functions which compute with existing
data types, and the existing functions are left alone.
When evolution goes the wrong way, you have problems:
Adding a new operation to an object-oriented program may require editing
many class definitions to add a new method.
Adding a new kind of thing to a functional program may require editing many
function definitions to add a new case. |
b***e
发帖数: 1419 | 64 ER modeling跟OO有什么必然的联系么？你丫为啥总是说别人缺你丫自己缺的东西？比
如说老魏。你丫不但没有常识，连逻辑都没有。你丫代表软件工程了？你丫充其量代表
了三哥的先进生产力。你丫学不会是你丫傻逼。OOP之前大家不用数据库么？你个傻逼
还真他么什么都敢开牙。
【在 g*****g 的大作中提到】
: 写个算法用状态机也罢，大部分系统设计都是从ER modeling开始，干啥都行，不能避
: 免存储。你这就是缺乏常识。还真以为matrix哪？说了多少次了，FP跟软件工程格格不
: 入。OOP建模从名词开始，FP从动词开始。数据库存的是名词的状态。FP天生跟数据库
: 就八字不合。
:
: OO
|
g*****g
发帖数: 34805 | 65 必然的联系就没有，但entity是名词，relation是动词，现有E再有 R，整个就是个OOP
的自然建模。傻逼你的状态机在哪里呢？你这傻逼完全没词了被打脸了就剩这德行。
OOP之前大家也用FP，so what? FP被OOP挤兑成这样子都是有原因的。你丫还是继续意
淫你的FP吧，三句不离三哥相比被三哥菊花乱入，梦魇了。你丫虽然是太监连自己的菊
花都保不住，不是一般的惨呀。
【在 b***e 的大作中提到】
: ER modeling跟OO有什么必然的联系么？你丫为啥总是说别人缺你丫自己缺的东西？比
: 如说老魏。你丫不但没有常识，连逻辑都没有。你丫代表软件工程了？你丫充其量代表
: 了三哥的先进生产力。你丫学不会是你丫傻逼。OOP之前大家不用数据库么？你个傻逼
: 还真他么什么都敢开牙。
|
b***e
发帖数: 1419 | 66 你丫是不是出生之前在你妈的母狗直肠里被三哥的尿泡的时间长了，黄皮三心了你？刚
把你丫个傻逼狗加屎揭露的体无完肤，你丫回去吃了口咖喱屎撅着个豁了的脓屁眼又
来找 高潮？还没爽够是吧？这回是不是给你换个大号的dildo？肏你妈逼你丫有逻辑么
？我 说的是建模和OO没有必然联系，你妈逼我说哪个自然了么？你妈被狗肏最自然这
是个人 就看的出来。你知道自己傻逼还继续肏你妈。你妈正被三哥三通，没眼儿给你
。就是有 眼儿给你你丫也没鸡巴呀。你丫在这个版上被大家挤兑是有原因的。你丫继
续意淫你妈 Java的母狗屄。你说你一个天阉撸管都没管用的太监，天天关心别人的鸡
巴？人家要不 介“撸（管）”，要不介“管.撸（）”。你妈逼的到你丫这儿“撸（）
”，即没参数 ，也没 对象。你妈逼能编译么？你说你丫个太监有资格讨论这事么？肏
你妈个逼的滚蛋，不， sorry，你丫没有蛋，我重说，肏你妈个比的滚，肛得疤。
【在 g*****g 的大作中提到】
: 必然的联系就没有，但entity是名词，relation是动词，现有E再有 R，整个就是个OOP
: 的自然建模。傻逼你的状态机在哪里呢？你这傻逼完全没词了被打脸了就剩这德行。
: OOP之前大家也用FP，so what? FP被OOP挤兑成这样子都是有原因的。你丫还是继续意
: 淫你的FP吧，三句不离三哥相比被三哥菊花乱入，梦魇了。你丫虽然是太监连自己的菊
: 花都保不住，不是一般的惨呀。
|
g*****g
发帖数: 34805 | 67 操你妈逼你丫这个太监被三哥菊花抽插得不成人样，就剩这屁眼朝天的德行了。
你丫再满地里喷粪的也还是被打脸的命。
【在 b***e 的大作中提到】
: 你丫是不是出生之前在你妈的母狗直肠里被三哥的尿泡的时间长了，黄皮三心了你？刚
: 把你丫个傻逼狗加屎揭露的体无完肤，你丫回去吃了口咖喱屎撅着个豁了的脓屁眼又
: 来找 高潮？还没爽够是吧？这回是不是给你换个大号的dildo？肏你妈逼你丫有逻辑么
: ？我 说的是建模和OO没有必然联系，你妈逼我说哪个自然了么？你妈被狗肏最自然这
: 是个人 就看的出来。你知道自己傻逼还继续肏你妈。你妈正被三哥三通，没眼儿给你
: 。就是有 眼儿给你你丫也没鸡巴呀。你丫在这个版上被大家挤兑是有原因的。你丫继
: 续意淫你妈 Java的母狗屄。你说你一个天阉撸管都没管用的太监，天天关心别人的鸡
: 巴？人家要不 介“撸（管）”，要不介“管.撸（）”。你妈逼的到你丫这儿“撸（）
: ”，即没参数 ，也没 对象。你妈逼能编译么？你说你丫个太监有资格讨论这事么？肏
: 你妈个逼的滚蛋，不， sorry，你丫没有蛋，我重说，肏你妈个比的滚，肛得疤。
|
b***e
发帖数: 1419 | 68 肛得疤公公，你丫那淌这脓的烂玩意还能叫屁眼么？割了吧。给你丫讲，去趟韩国人给
你丫做个新的。别担心，三哥不会介意的，韩国整的屁眼挺紧的，你丫依然能够满足广
大三哥的需求。让你几个三老板先忍忍。你丫以后吧，就找人给你丫做一传，就叫肛蒲
团，人家古人造鸡巴，你丫造肛门。可惜呀，那功夫失传了，你丫这辈子也别想有鸡巴
了。
【在 g*****g 的大作中提到】
: 操你妈逼你丫这个太监被三哥菊花抽插得不成人样，就剩这屁眼朝天的德行了。
: 你丫再满地里喷粪的也还是被打脸的命。
|
z****e
发帖数: 54598 | 69 没有reactive的fp programming也要死一大半
现在大街小巷的go reactive的tab到处都是
感觉最直接的用处就是扔给reactive，然后交给他们一个func
然后搞定了，至于fp其他的部分，我很怀疑有没有用
至少目前看，还没有什么framework出来配合
搞不好最后只是某部分人的自我娱乐罢了
这个其实也只是优化了并发的效率，跟你的逻辑实现木有半毛钱关系
建模还是用oo比较容易做，fp建模太过于抽象
搞不好连维护的monkey都找不到，那这个就很蛋疼了
【在 l******t 的大作中提到】
: gc 继承一类小了。用CPP没问题。mfc那时候已经可以监视内存泄露了。这属于语言特
: 性按你说法不是问题也确实不是太大问题。JVM跨平台是真货。
: fp已经够语言的突破。这个并发niche有多小还得观察。
: 【 FP并没有很多feature，scalaFP并没有很多feature，scala在 goodbug (好虫) 的
: 大作中提到: 】
|
A*******e
发帖数: 2419 | 70
你是说STL的设计带来高度的灵活性和极佳的效率？说完整啊。
【在 b*******s 的大作中提到】
: 举个例子，stl的设计就是数据和方法分离的，而oo是数据和方法绑定的强耦合方式。
: 带来了高度的灵活性和极佳的效率。比如查找，oo的办法要为每种数据组织方法都写一
: 个处理函数，而stl风格的根本不关心底下数据是如何存放的，一个函数能处理一大堆
: 各种不同的容器，平均效率还更高。
: 很多现在的新语言特点，比如duck typing 都是在解oo的毒。或者强调接口，淡化类。
|
|
|
z****e
发帖数: 54598 | 71 关键是fp的主流还不是主谓宾和主宾谓，而是tmd谓语提前的谓主宾结构
这个星球上找到这种语法结构的可能不太多
就是数学系的人都不这么写，语言设计得反人类还是不行
容易导致最后位置感混乱，到底一个单词是动词还是名词都要琢磨半天
【在 g*****g 的大作中提到】
: 你这说的太不靠谱了，图灵机本身就是个完备自洽的体系，并不需要各种修正，你拿托
: 勒密来比就是一厢情
: 愿罢了。
: inheritance, composition, mixin只不过是完成同一件事情不同的实现方法，各有利
: 弊而已。语言的精髓在于取舍，而不在于纯粹，也不在于feature多，feature就导致复
: 杂度提高。编程语言就跟人类语言一样，有的用主
: 谓宾，有的用主宾谓，都能表达同样的思想。但是用主谓宾的是主流，哭诉什么主宾谓
: 更先进是没有意义的。实践科学，都是拉出来遛。编程语言理论是一个总结，而不能
: 决定语言应该怎么设计。
|
A*******e
发帖数: 2419 | 72 哪里？矿工？
【在 b*******s 的大作中提到】
: 就是，癌症还能占据人体呢。
: 你那股票最后拿到多少再说，下个月我们就发奖金了，今年比工资高
|
A*******e
发帖数: 2419 | 73
的。
读了三遍也没看懂要说啥。
lambda
【在 l******t 的大作中提到】
: 你说的这些很对。有时也需要退一步换对方视角看看。
: 是的图灵机本身完备。现在也并没有lambda机而是转换为图灵机也反证图灵机是完备的。
: 图灵机缺的是没有抽象和应用的过程。而抽象和应用这是lambda的内质。理论上lambda
: 式可以自动机器演算判定，编程上FP的代码实现也是高度抽象高度精简比图灵机指令式
: 表达有效的多。
: OO的问题并不是图灵机的的问题而是本身的问题。基础描述不清基本等同口头描述。
: Corner case修修补补添加各种轮和地心轮说可以媲美。
: 算法，代码，语言，feature都可以有好有坏。语言也有high level low level的。目
: 测fp应该是下一个level。现在的趋势也是各种语言纷纷marry 基本lambda。FP本身并
: 没有很多feature，lambda，trait，强类型自动推，pattern match，lazy，加几套基
|
A*******e
发帖数: 2419 | 74 为何不保证呢？那很多算法复杂度分析不就有问题了？
【在 N******K 的大作中提到】
: java不能保证数组连续存储 这一条就自绝于数值计算了
:
: 的。
: lambda
|
z****e
发帖数: 54598 | 75 猫扑啦
大妈您还是回火星吧
地球太危险了
【在 n*w 的大作中提到】
: 哦，Google了一下。没查到来源。
|
z****e
发帖数: 54598 | 76 呵呵
纯粹的fp也差不多
连变量都没有的编程，没多少人真爱
连数学系的人都未必喜欢
而且把简单问题复杂化这个方面上说
fp比dp有过之而无所不及
可以说远远超过pattern
pattern大多数人琢磨琢磨还是能明白的
paradigm的抽象程度要高于pattern的抽象程度
pattern多数都针对某一类问题，比如数据和方法的剥离
否则也不是pattern，但是paradigm更general地想要搞定所有问题
所以如果pattern sucks，那paradigm就要更甚
我现在越来越觉得pure fp是一个扯蛋
有限度的使用fp，尤其是lambda结合observer pattern来使用
才是今后的王道
【在 w***x 的大作中提到】
: OO Sucks，不同意就请逐条反驳原文。
: 很久以前就看过design pattern，没看过之前觉得好高大上，看完后就觉得不如不看。
: OO界，尤其是靠出文章或写书的，胡说八道的太多了。
|
p*****2
发帖数: 21240 | 77 谓主宾 也不是特别糟糕 c 也是这样的
【在 z****e 的大作中提到】
: 关键是fp的主流还不是主谓宾和主宾谓，而是tmd谓语提前的谓主宾结构
: 这个星球上找到这种语法结构的可能不太多
: 就是数学系的人都不这么写，语言设计得反人类还是不行
: 容易导致最后位置感混乱，到底一个单词是动词还是名词都要琢磨半天
|
p*****2
发帖数: 21240 | 78 fp和oo可以完美结合 比如javascript
【在 z****e 的大作中提到】
: 呵呵
: 纯粹的fp也差不多
: 连变量都没有的编程，没多少人真爱
: 连数学系的人都未必喜欢
: 而且把简单问题复杂化这个方面上说
: fp比dp有过之而无所不及
: 可以说远远超过pattern
: pattern大多数人琢磨琢磨还是能明白的
: paradigm的抽象程度要高于pattern的抽象程度
: pattern多数都针对某一类问题，比如数据和方法的剥离
|
b*******s
发帖数: 5216 | |
z****e
发帖数: 54598 | 80 所以c并不接近自然语言
很变扭，如果c能解决问题
也就不会有现在的各种语言了
【在 p*****2 的大作中提到】
: 谓主宾 也不是特别糟糕 c 也是这样的
|
|
|
z****e
发帖数: 54598 | 81 30层的callback hell
【在 p*****2 的大作中提到】
: fp和oo可以完美结合 比如javascript
|
z****e
发帖数: 54598 | 82 不在语言层面上enforce的话，那就需要手下人先认知这个思想
其次严格遵守纪律，我们都知道这很需要training和纪律性
除了德国人，日本人，其他国家人几乎不可能做到
【在 n******t 的大作中提到】
: OO是一类编程思想，而且也只是一种思想,尤其使用范围。
: 问题在于这东西和语言没有必然联系，所以在语言层面上面enforce，
: 没什么意义。
|
z****e
发帖数: 54598 | 83 mvc
【在 b*******s 的大作中提到】
: 不知道web svc多oo
|
z****e
发帖数: 54598 | 84 半斤八两
你觉得嘴巴上挂着fp的人对paradigm了解多少？
实际上现在fp之所以兴起，跟oop里面的observer pattern有很大关系
否则随随便便就掉入callback hell，pure fp写成金字塔的不要太多
括号数起来要屎啊，就是了解了oop，才觉得fp有用
而且恰好是对各种pattern的补充
而不是像fp berserker说得那样，一切都是func，那是胡扯蛋
实际上真正懂fp的人恰恰对oop推崇有加，评价甚高
你先学会oop，再谈fp，这还差不多
菜瓜只看到风清扬手里的树枝是剑，无招胜有招
也拿着树枝上去比划，结果只能找虐
民科和行为艺术太多，早就说过了
【在 n******t 的大作中提到】
: 没办法，这年头对程序员的需求远远大于人群中适合学编程的人的数目。导致很多其实
: 自然就会形成的一些pattern,变成了对很多程序员来说需要学的东西。这种事情的结果
: 就是，很多人基本上只是背下来了这些pattern，不知道也不关心为什么要这样。
: 一般来讲，人不懂为什么的东西，一般来说就绝对不允许别人提出任何异议或者改动，
: 这种例子很多，大家很容易找出各种例子。
|
l******t
发帖数: 55733 | 85
哥你还是花点功夫真正搞搞fp才好。啥pattern都是屎啊
【在 z****e 的大作中提到】
: 半斤八两
: 你觉得嘴巴上挂着fp的人对paradigm了解多少？
: 实际上现在fp之所以兴起，跟oop里面的observer pattern有很大关系
: 否则随随便便就掉入callback hell，pure fp写成金字塔的不要太多
: 括号数起来要屎啊，就是了解了oop，才觉得fp有用
: 而且恰好是对各种pattern的补充
: 而不是像fp berserker说得那样，一切都是func，那是胡扯蛋
: 实际上真正懂fp的人恰恰对oop推崇有加，评价甚高
: 你先学会oop，再谈fp，这还差不多
: 菜瓜只看到风清扬手里的树枝是剑，无招胜有招
|
z****e
发帖数: 54598 | 86 oop还只是加了点pattern
fp干脆就是各种限制了，不要这个不要那个
做起来各种束手束脚的，我又是比较喜欢改变的人
尤其喜欢factory生产出新产品，用fp的immutable很不适应啊
相比之下，observer搭配lambda我觉得够用了
发信人: liliput (粒粒菩提之军委主席), 信区: Programming
标 题: Re: scala很牛啊
发信站: BBS 未名空间站 (Tue Jun 17 00:41:59 2014, 美东)
不需要懂。这玩儿没实战意义。当年老师天天说immutable，monad，stream怎么怎么好
，几十年下来，原来预测的医药和航天、精密仪器等有可能火的行业都没火。
我粗鄙的认为，搞懂function as a first class citizens，懂map, filter, fold足
够了。industry就是industry，不是academia，没必要死楸immutable、monad。
【在 l******t 的大作中提到】
:
: 哥你还是花点功夫真正搞搞fp才好。啥pattern都是屎啊
|
n*w
发帖数: 3393 | |
z****e
发帖数: 54598 | |
n*w
发帖数: 3393 | 89 给大家看的是引用的那两段。以避免在 immutable 和modeling关系被误导。
c#有没有用，wp有没有市场和这个帖子一点关系都没有。
【在 z****e 的大作中提到】
: c#有个鸟用，wp要市场没市场，要利润没利润
: 要多傻才会押宝wp啊？
|
z****e
发帖数: 54598 | 90 能不能用，行不行自己试试就知道了
自己抓个场景来做一次建模就知道顺手不顺手了
谁有病看这种水文啊？
【在 n*w 的大作中提到】
: 给大家看的是引用的那两段。以避免在 immutable 和modeling关系被误导。
: c#有没有用，wp有没有市场和这个帖子一点关系都没有。
|
|
|
n*w
发帖数: 3393 | 91 已经说了给大家看的。你看不看不关心。
【在 z****e 的大作中提到】
: 能不能用，行不行自己试试就知道了
: 自己抓个场景来做一次建模就知道顺手不顺手了
: 谁有病看这种水文啊？
|
z****e
发帖数: 54598 | 92 另外你知道我说的是什么建模？
我说的是数学建模，因为最近数学的东西比较多
所以有感而发，你这种舔阿三的家伙估计不懂啥数学
来，看看数学建模第一步要干嘛
http://zh.wikipedia.org/wiki/%E6%95%B0%E5%AD%A6%E5%BB%BA%E6%A8%
“分析实际问题中的各种因素，使用变量表示”
变量，看到了吗？fp那是解题过程中适用的
还modeling呢，笑死人了
古德霸和我说的建模是一回事？
【在 n*w 的大作中提到】
: 给大家看的是引用的那两段。以避免在 immutable 和modeling关系被误导。
: c#有没有用，wp有没有市场和这个帖子一点关系都没有。
|
z****e
发帖数: 54598 | 93 lol
我也回给大家看的
wp就是没市场没钱途
傻瓜才会押宝wp
【在 n*w 的大作中提到】
: 已经说了给大家看的。你看不看不关心。
|
n*w
发帖数: 3393 | 94 又扯远，我对印度人的看法和对你的看法差不多，不仇恨不热爱。对日耳曼人也差不多。
【在 z****e 的大作中提到】
: 另外你知道我说的是什么建模？
: 我说的是数学建模，因为最近数学的东西比较多
: 所以有感而发，你这种舔阿三的家伙估计不懂啥数学
: 来，看看数学建模第一步要干嘛
: http://zh.wikipedia.org/wiki/%E6%95%B0%E5%AD%A6%E5%BB%BA%E6%A8%
: “分析实际问题中的各种因素，使用变量表示”
: 变量，看到了吗？fp那是解题过程中适用的
: 还modeling呢，笑死人了
: 古德霸和我说的建模是一回事？
|
n*w
发帖数: 3393 | 95 这个应该开个新贴。
【在 z****e 的大作中提到】
: lol
: 我也回给大家看的
: wp就是没市场没钱途
: 傻瓜才会押宝wp
|
l******t
发帖数: 55733 | 96 你举个场景看看
【在 z****e 的大作中提到】
: 能不能用，行不行自己试试就知道了
: 自己抓个场景来做一次建模就知道顺手不顺手了
: 谁有病看这种水文啊？
|
z****e
发帖数: 54598 | 97 比如我们打斗地主
你来写个server，你看看fp麻烦不麻烦
【在 l******t 的大作中提到】
: 你举个场景看看
|
z****e
发帖数: 54598 | 98 我感觉fp做游戏就是天生的不自在
oop很容易，你要在游戏里面建什么
直接object就行了，你要找某个unit做什么，直接object也就好了
fp从func开始，一切都是event driven的
异步还强化了这个流程，所以一旦触发点失去的话
你整个模型就会很被动，像游戏这种需要主动initiate某个动作甚至对象的
就很不适应
【在 l******t 的大作中提到】
: 你举个场景看看
|
p*****2
发帖数: 21240 | 99 fp很适合数据处理
【在 z****e 的大作中提到】
: 我感觉fp做游戏就是天生的不自在
: oop很容易，你要在游戏里面建什么
: 直接object就行了，你要找某个unit做什么，直接object也就好了
: fp从func开始，一切都是event driven的
: 异步还强化了这个流程，所以一旦触发点失去的话
: 你整个模型就会很被动，像游戏这种需要主动initiate某个动作甚至对象的
: 就很不适应
|
b*******s
发帖数: 5216 | 100 oo is good for applications requires bulks of interaction
namely, games, enterprise software, etc
【在 z****e 的大作中提到】
: 我感觉fp做游戏就是天生的不自在
: oop很容易，你要在游戏里面建什么
: 直接object就行了，你要找某个unit做什么，直接object也就好了
: fp从func开始，一切都是event driven的
: 异步还强化了这个流程，所以一旦触发点失去的话
: 你整个模型就会很被动，像游戏这种需要主动initiate某个动作甚至对象的
: 就很不适应
|
|
|
l******t
发帖数: 55733 | 101 fp从声明数据对象开始完全没问题
【在 z****e 的大作中提到】
: 我感觉fp做游戏就是天生的不自在
: oop很容易，你要在游戏里面建什么
: 直接object就行了，你要找某个unit做什么，直接object也就好了
: fp从func开始，一切都是event driven的
: 异步还强化了这个流程，所以一旦触发点失去的话
: 你整个模型就会很被动，像游戏这种需要主动initiate某个动作甚至对象的
: 就很不适应
|
z****e
发帖数: 54598 | 102 没有变量的建模各种不自在
你看数学建模第一步就是建立变量以映射客观现实
我反正很难用fp建模建出来
但是解题过程很清晰的时候
我有办法用fp写出来，因为顺着做就行了
但是解题过程本身，不是建模的关键
是solution，fp擅长操作信息或者说数据，并得出结论
但是建模需要变量
【在 l******t 的大作中提到】
: fp从声明数据对象开始完全没问题
|
