Why OO sucks

状态是不是便于编程,与是否有线程没多大关系,Event driven 上我看不出状态有利在那里.很多人恐怕从没有想到过的是,赋值语句实则上就是一种IO(为什么呢?可以仔细的想一想).但凡IO,必定是并发的.这才是OO或者说是命令语言的根子所在.

不自量力的提醒一下 T1 兄，OCaml 为 OO 的 Caml，可见 fp 和 oo 是可以兼容的。

赋值语句的存在和机器环境有关系，假如我采用 erlang 这样的环境来做 oo，那我也可以把赋值语句砍掉（就变成 ets 了，ets 其实也是赋值，只不过将“脏”操作控制在 ets 模块而已）。

赋值语句，可能会改变状态（第二次以上赋值的时候）。不过，赋值不应该是I/O。
I/O应该是指：访问本进程内存之外的设备。赋值还是在本进程内存中发生，为什么是I/O呢？

你的意思是说。能够赋值（第二次以上），从而“有状态、有I/O、有副作用”，才是命令语言（包括OO）的本质？

我没有说OO和FP不能兼容.
但是OO的在什么条件下能呈现他的好处?这是问题的关键所在.在我看来,以目前的趋势来看，这种条件会越来越弱.

赋值语句的确和机器环境有关系,换而言之,目前的计算机模型带给我们带来的不是更多的便利而是更加坚固的枷锁.几乎所有的并发编程的困难都由此而来，因此针对这个根子我们从理论上来说就需要从新选择计算模型，在实践上来讲就需要在目前的计算机上构建一个对应的模拟环境.

T1 兄的观点这里的各位帅哥都很熟悉了，有状态变化就会有副作用，但对于 oo => 状态变化，我还没领教过。

远不止副作用那么简单，副作用只是冰山一角.这里有一个党指挥枪,还是抢指挥党的问题.

OO 的好处就是，它把一组（！）状态和一组（！）函数打包在一起，比较适合表达现实世界。同时，oo 提供创建闭包的便捷方法 “类, 继承”等模板性质的语法，这样我们在创建组合数据的时候就方便多啦，好比 lisp 的 cons 语句，变成 (ele1, ele2,ele3,... )后，比直接用 cons 就好用多了。

这几乎是不可能的,前辈从指令顺序执行到搞出指令流水线,就是想让计算机运行得再快一些.
如果要把并发编程的困难从根子上解决,那无非是搞成即使是赋值操作这种语句,都得一次执行完.想当于把现在的多个指令合并为一个,那流水线还有什么用.我们又返回到玩红警坦克一多就看炮弹飞行轨迹的年代?

你没看见月亮，月亮就不存在?

个人感觉。从来没有觉得对象能够表达现实世界的任何东西。对象只能表达编程元素。
能够打包，确实是OO的好处。尤其是带有多态的打包。
打包很简单。C语言、FP语言都可以打包（放到Tuple、Array里面）。

打包是为了啥呢？为啥OO的打包就那么特殊呢？OO打包的特点在于多态。
多态是为了啥呢？是为了 callback 模式形式的重用。也叫做Template模式。
在callback (or template) 重用模式下，OO是无敌王者。

template( callback) { // 这里重用的是template
.....

callback.run(....)
.....
}

可惜，只依靠这一点，并不足以击败FP。FP的函数直接就可以作为参数和返回值，在callback重用模式更有优势。
OO只能依靠来可重复赋值（有状态）特性来击败FP（C语言也有这个特性，命令语言都有这个特性）。
OO的打包可以很自然地携带数据（有状态），同时具有多态。

FP的打包，可以分为两种。
(1) Function本身。这种情况下，callback重用有优势。甚至优于OO对象。但是，携带数据不方便，只能依靠闭包。而闭包是很麻烦，很不直观的。

(2) Tuple, Array里面放数据和函数。这种情况下，callback重用就比较麻烦，必须自己在template函数外部手工替换Tuple中的某一个Function。而不能达到OO多态那样的自然简单效果。