Why OO sucks

第一,理论的论证一定是数学的吗?你怎么知道,从物理的角度Von Neumann Architecture 就不Sucks?
第二,抛开数学，你又如何论证物理和化学特性?
第三,即使不使用数学语言，在日常编程实践里,我们也不断地在Von Neumann Architecture模拟非Von Neumann 结构.

哈佛模型和冯诺依曼模型,之间的区别不是太大.


还是那句话,你没见过月亮,不等于月亮不存在.计算机工业这种词语最好少说，PC/MAC也只是计算机工业的一小部分.

第一，oo != 冯诺依曼模型，你可能以为 one object == one Von Neumann Machine 了。冯诺依曼模型 sucks 不sucks 关我什么事，你能论证生物学按门纲目科的分类到底符合不符合数学吗？

第二，我给你数学，你就能论证出一切物理化学特性？ 请告诉我天狼星上有没有水。

第三，我们做的和冯诺依曼结构没有关系，oo 的哲学是从亚里士多德开始的，不是从冯诺依曼开始的。

我有说过one object ==one Von Neumann Machine ?
不管面向过程也好，结构化编程也好,面向对象也好,面向这些技术的目的是什么?有没有想过?
最简单的一个问题,OO的多态和if else的共同点在那里?或者说他们都是在处理什么东西?

不要用数学 请你来告诉我水星上为什么没有水?

你确实没有说过 one object ==one Von Neumann Machine, 我也只是推测，所以加了“可能”两个字。

后面的问题问的很好，受讨论的启发，昨天正好在整理一篇小文，简单的介绍一下。

按结构学和符号学，神话、小说、电影等艺术形态借助与现实世界同构的符号世界来描述事物，而我们的 code 也一样，code 是一种和现实世界同构的能动的文本。

oo 传承自形而上学，而不是什么数学，之所以敢采用 oo 理念来编写代码，是因为西方科学源自亚里士多德的形而上学，长期的经验表明，这样做是比较能让人放心的。而这也是 oo 很难被数学论证的原因，正如数学无法论证生物按门纲目科分类是否符合数学演绎一样。

oo 的多态是现实世界多态在程序文本中的映射，采取何种方式来实现，并不是 oo 最关心的问题。假如现实世界的 object 没有多态特性，多态也是可以取消的。

最后，需要指出的是，oo 难以论证，是指难以论证其能与现实世界同构，而不是说 oop 语言本身有天生的缺陷，前面已经证明了，oop 语言和 fp 语言，实际上是等价的东西。

另外，在前文我也表述了 erlang 上的 oo 会是什么样子，相信有助于理解这种理念。

Thanks for the code. 我对Haskell语法又多了一点理解。
看过Haskell入门，类型定义那一段没有完全理解。
Haskell类型定义有些类似于 interface 定义。(印象中有个C++ Template的Trait，不知道有没有相似之处)
一个类型定义相当于一组方法（操作该类型）的集合。具体类型则是这些方法的实现。
从这个角度看，Haskell类型至少是支持 implement interface。
至于Haskell类型是否支持继承，是否支持单继承，多继承。从代码里面看不出来。
get_type (Image_Button a parent)="Image_Button" ++ get_type(parent)
这条代码是采用手工的方式调用另一个类型的get_type.和继承无关。有些类似于包含方式，Proxy or delegate.

Haskell代码不是很懂。试图翻译成类似 Python 形式的。
Python的对象方法有个特点是，暴露第一个 self 参数（即this），恰好适合描述FP类型。

class Window
  get_type(Window self)
    return "Window"

  print()
    "hello"
    

class Image_Button < Window
  get_type(Image_Button self) 
    return "button"

  // print() 方法一样，直接继承

这种效果，Haskell类型也许可以达到，也许不可以达到。
不过，继承不继承，确实也无所谓。
Haskell 类型如果有了 implement interface，确实可以多态了。
继承都快成反模式了。有了AOP等，现在流行包含方式，Proxy or delegate。

有办法：现场探索。

提醒一下，我并不是因为学了数学，才知道水龙头会流出水来，我也不需要学数学来证明水龙头流出的是水。

我是在问题,为什么没有水,而不是有没有水.

这个问题太无厘头了吧，偶是不是可以问：
请用数学告诉偶，你为什么叫XX

T1又要祭出Pattern Match的法宝了？
以前的帖子讨论过，Pattern Match 只是 if else 的美化形式，本质是一样的。
OO多态则不同。是质的飞跃。

template(callback) { // OO方式
....
callback.run(...)
....
}

template( data )  { // if else
....
if data is type of A
  doA
else if data is type of B
  doB
...
}

OO多态方式下，如果要多一个（类型）分支，只需要“增加”一个“新”类。不需要修改原有的template代码。
而在if else, 或者 pattern match 方式下，如果要多一个（类型）分支，则需要修改原有的template代码。that is called hard-code。