Why OO sucks

你无非想引我说借助了很多用数学才设计出来的工具，其实这真是个可笑的问题，我已经说了，我不需要学数学才知道水龙头会流出水来。

你搞清楚因果，人类是在现实世界观察了水后，分析其物理特性后，形成数据，对照水星的观测结果，才知道水星没有水。并非凭空思考，构造了水的函数后，对水星做映射，之后 return false。

数学是工具，并不是先验哲学。

class A(object):    # A must be new-style class
  def __init__(self):
   print "enter A"
   print "leave A"

class B(C):     # A --> C
  def __init__(self):
   print "enter B"
  super(B, self).__init__() 
   print "leave B"


Python 这种土了八级的语法都能叫OO,我这个就不是OO了?套用一句赵本山的话说,小样的你穿个马甲我就不认识你了?

那不是 OO 的错误，只是有的项目把 OO 用的太绝对了。

其实应该 OO 与面向过程结合着使用。

那不是 OO 的错误，只是有的项目把 OO 用的太绝对了。

其实应该 OO 与面向过程结合着使用。

老大，那是构造函数。而且是需要调用父方法的构造函数。
普通函数就不需要这样了。上述讨论的代码都是非构造函数的普通函数。

你不是在重复我的话么？

我说的跟Pattern Match 没有关系






John Backus的 1976年的图林奖领奖演说<Can Programming Be Liberated from the von Neumann Style?>

面向过程,面向对象，这些东西是不是Von Neumann 模型的产物.我说了不算,有疑义的倒是可以和Backus老爷去较较真,这位大爷当年可是Von Neumann的老部下,结构化编程的发明人.

看来，赋值语句是万恶之源。
有赋值语句的语言，就是命令式语言？就是Von Neumann 模型？
FP不是Von Neumann 模型？
FP是什么模型？

赋值这东西，确实会引起很多问题。尤其在多线程多核并行环境中。

--------------------------------

没有了赋值，就没有了IoC，没有了IoC，Template Reuse就不好写了。
FP要用好Template Reuse，就只能依靠闭包。


如果FP里面可以定义一个隐含参数 this 就好了。这个this指向本函数的外层容器。

Tuple = {A, B, F1, F2}

F1, F2 是两个函数，都有隐藏参数 this。
this指向 Tuple。
这只是一种 Hashtable方式的OO。

可以进一步模拟 VTable方式。

VTable = {F1, F2}
Tuple = {A, B, VTale}
F1, F2 是两个函数，都有隐藏参数 this。
this指向 Tuple。
这就是 VTable的OO了。

如果 FP 可以这么用，就可以完美解决 Template Reuse 的问题。

赋值是一个与时序相关的操作,也就是具有并发性的IO(以运算器的视角).
赋值不是绝对不能用的，相反是绝对必需的.
赋值不是FP能够解决的问题,赋值与FP是互相独立没有交集的,因为lambda演算和图林机一样从来不关心IO问题.
赋值也不是十恶不赦的，十恶不赦的只是那些企图掩盖他并发性的方法,比如Von Nnumann 结构.

只要正确地引入并发性,那么所有原先由赋值操作来完成的功能,都能找到对应的方案。比如Erlang 的genserver就是一种Ioc,template reuse.与Java IOC相比较,java的方案是一个平面化的方案,而genserver则是一个立体的方案.

跟技术无关  跟人有关