Why OO sucks

为什么OO很恶心

原文： http://www.sics.se/~joe/bluetail/vol1/v1_oo.html
作者：Joe Armstrong

当我第一次知道OOP的概念时，我非常疑惑，但是不知道为啥——它仅仅在感觉上“不对”。
在OOP问世之后变得粉流行（稍后解释为什么），而批评OOP就像“在教堂里咒骂”。
OO成为了每个受尊敬的语言必须具备的一部分。

而当Erlang变得越来越流行时，我们经常问一个问题“Erlang是OO的吗？”
当然正确的答案是“当然不是”——但是我们没有大肆宣扬——我们只是换了种精心设计的说法，Erlang是某种OO但不是真的是。

这时我想起在法国巴黎时IBM的老板在7th IEEE逻辑编程大会上的演讲。
IBM prolog添加了许多OO扩展，当人们问起时他说：“我们的客户想要OO的prolog，所以我们构建了OO的prolog”

我想到了“多么简单，没有良心的疑虑，没有灵魂的搜索，没有‘这是正确的事情’的问题。。。”

为什么OO很恶心

我对OOP的反对原则源自一些基本的概念，我将概述其中一些反对意见。

反对之一——数据类型和方法应该绑定在一起
对象将方法和数据结构绑定在一起成为不可分割的单元。我认为这是基本的错误，因为方法和数据结构属于完全不同的世界。为啥哩？

1，方法做事情。它们是输入和输出。输入和输出的是方法所改变的数据结构。
在大部分编程语言里，方法由命令式语句顺序构建：“做这件事然后那件事。。。”
理解方法首先得理解做事情的顺序（在懒惰函数编程语言和逻辑语言中这个限制被放宽了）
2，数据结构是结构。它们不做任何事情。它们本质上是声明。“理解”数据结构比“理解”方法简单多了。

方法作为黑盒子来转换输入和输出。如果我理解输入和输出，这样我就理解了方法。这并不意味着我可以写这个方法。

方法通常理解为在一个计算系统里用来将数据结构T1转换为数据结构T2的东西。

既然方法和数据结构是完全不同类型的动物，那么将它们锁在一个笼子里就是完全错误的。

2，反对之二——任何东西都必须为对象
考虑“时间”。在OO语言里“时间”也必须是对象。但是在非OO语言里一个“时间”是一个数据结构的实例。
例如，在Erlang里有许多不同类型的时间，它们可以使用类型声明来明确指定：

-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...

注意这些定义不属于任何特殊的对象。它们很普遍，并且数据结构表示的时间可以被系统中的任何方法处理。

没有相关联的方法。

反对之三——在一个OOP语言里数据类型定义散布到任意位置
在OOP语言里数据类型定义属于对象。
这样我就不能在一个地方找到所有的数据类型定义。
在Erlang或者C里我可以在一个单独的include文件或数据字典里定义我所有的数据类型。
在一个OOP语言里我不能——数据类型定义散布到任意位置。

让我举一个例子。假设我想定义一个通用的数据结构。通用数据类型是一个数据类型，它在系统中的任意位置出现。

lisp程序员知道，拥有一个较小数量的通用数据类型和在它上面的大量的小方法会更好。

通用数据类型就比如linked list，或者一个array或者一个hash table或者更高级的对象如time或者date或者filename。

在一个OOP语言里我不得不选择一些base对象来在里面定义通用的数据结构，所有其他想使用这些数据结构的对象必须继承该对象。
假设现在我想创建一些“time”对象，那么它应该属于哪个对象呢。。。

反对之四——对象拥有私有状态
状态是所有罪恶的根源。特别是有副作用的方法应该避免。

在编程语言里状态是令人讨厌的，而真实世界里状态却千奇百怪的存在着。
我对我的银行账户的状态很感兴趣，当我从我的账户存钱或取钱时我希望我的银行账户状态成功更新。

既然状态在真实世界里存在，那么编程语言应该提供什么能力来处理状态呢？

1，OOP语言说“将状态隐藏”。状态仅仅通过访问方法来隐藏和可见。
2，传统编程语言（C，Pascal）说状态的可见度由语言的scope规则来决定。
3，纯声明式语言说没有状态。系统的全局状态转移到方法里然后从方法里出来。
类似于monad(函数式编程语言)和DCG(逻辑语言)等机制被用来隐藏状态，这样它们可以像“有没有状态无所谓”一样来编程，但是对系统状态的完全访问是必需的。

OOP语言所选择的“隐藏状态”可能是最坏的选择。
它们不是将状态显示出来并寻找减少状态的坏处的方式，而是将状态隐藏起来。

为什么OO粉流行？

1，原因1——它被认为很容易学
2，原因2——它被认为让代码更易重用
3，原因3——它被大肆宣传
4，原因4——它创建了一个新的软件工业

我看不到原因1和原因2的证据。原因看起来像是技术背后的驱动力。
如果一个编程语言技术如此之差，然后它创建了一个新的工业来解决它自己本身的问题，则它会成为想从中牟利的人的好工具。

这就是OOP背后真正的驱动力。

以及一篇回复：Why "Why OO Sucks" Sucks

评论

73 楼 jiming 2008-08-22  

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

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

72 楼 Trustno1 2008-08-22  

引用

至于Haskell类型是否支持继承，是否支持单继承，多继承。从代码里面看不出来。
get_type (Image_Button a parent)="Image_Button" ++ get_type(parent)
这条代码是采用手工的方式调用另一个类型的get_type.和继承无关。有些类似于包含方式，Proxy or delegate.

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了?套用一句赵本山的话说,小样的你穿个马甲我就不认识你了?

71 楼 inshua 2008-08-22  

Trustno1 写道

引用

有办法：现场探索。

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

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

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

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

70 楼 buaawhl 2008-08-22  

Trustno1 写道

最简单的一个问题,OO的多态和if else的共同点在那里?或者说他们都是在处理什么东西?

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。

69 楼 Readonly 2008-08-22  

Trustno1 写道

引用

有办法：现场探索。

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

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

68 楼 Trustno1 2008-08-22  

引用

有办法：现场探索。

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

67 楼 inshua 2008-08-22  

Trustno1 写道

引用

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

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

引用

请告诉我天狼星上有没有水。

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

有办法：现场探索。

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

66 楼 buaawhl 2008-08-22  

Trustno1 写道

buaawhl 写道

这是Haskekell的类型定义吧。
能不能给一个类型继承的例子。OO多态就是依靠inherit（对于interface叫做implement）来实现的。

所谓的继承不过就是rescursive type罢了

data Window_obj a=Object a|Window a (Object a)
                  |Button a (Window a)
                  |Image_Button a (Button a)

class Window_action a where   
get_type :: a -> String

class Image_action a where
show_image ::a->IO ()

instance  Window_action Window where

get_type (Window a parent)="window"


instance  Window_action Button where

get_type (Button a parent)="Button" ++ get_type(parent)


instance  Window_action Image_Button where

get_type (Image_Button a parent)="Image_Button" ++ get_type(parent)


instance Image_action Image_Button  where

show_image (Image_Button a parent)=......

没有任何模拟,全部是FP的first class的语言特性.

所以我说，OO(传统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。

65 楼 inshua 2008-08-22  

Trustno1 写道

引用

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

我有说过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 会是什么样子，相信有助于理解这种理念。

64 楼 Trustno1 2008-08-22  

引用

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

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

引用

请告诉我天狼星上有没有水。

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

63 楼 inshua 2008-08-22  

Trustno1 写道

引用

我想你可能需要换个视角来看，从数学来看，函数是完备的，但是从物理来看呢？ 打一个不恰当的比喻，函数揭示了事物的波本质，而 oo 揭示了事物的粒子特性，物理特性，以及化学特性。

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

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

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

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

62 楼 Trustno1 2008-08-22  

引用

不是，冯诺依曼模型只是一种模型而已，做 dsp 的还用哈佛模型。

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

引用

说了半天,你等于说没说.冯.落衣慢是我们基本的理论前提.是我们现在计算机工业的根本.

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

61 楼 Trustno1 2008-08-22  

引用

我想你可能需要换个视角来看，从数学来看，函数是完备的，但是从物理来看呢？ 打一个不恰当的比喻，函数揭示了事物的波本质，而 oo 揭示了事物的粒子特性，物理特性，以及化学特性。

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

60 楼 inshua 2008-08-22  

terranhao 写道

楼上的挺逗,居然说来说去把OO sucks归根到冯.落衣慢计算机架构sucks.
说了半天,你等于说没说.冯.落衣慢是我们基本的理论前提.是我们现在计算机工业的根本.
照你这么说:
近代经济学一个最基本理论前提就是假设:所有参与到经济行为中的人都是理智的经济人.看看A股,再想想自己,是不是理智的经济人?那这理论前提就是sucks,那现今的经济学全sucks,对不对?
你要说冯.落衣慢架构sucks你先得找一个不sucks的架构给我们看看.我就认为这架构很好
正如我前面说的,我就认为每天拉大便是sucks,因为我觉得如果能进化出不拉大便的能力当然更牛B.说说你的计算机架构.

不是，冯诺依曼模型只是一种模型而已，做 dsp 的还用哈佛模型。T1 非常热爱 PI 演算（注：因为一大批符合逻辑的论文），但其实 oo 和 pi 演算并没有本质的冲突，只要把 object 看做一个闭包就完全理顺了。

59 楼 inshua 2008-08-22  

Trustno1 写道

引用

要滿足 T1 兄所熱愛的并行的pi演算，確實非函數式語言不可

我并非热爱FP或者Pi演算,而是我只接受经过严格论证后的结果.
OO语法自然吗？方便吗?
自然不自然都是相对的,方便不方便都是主观的.
某位仁兄说,
Person.writeName()比wirte(char * PersonName)
更自然，于是汇编->C->OO是越来越更加接近人类的认知方式.
在我看来，Person.writeName()并不比Person 'write' "Name" 来的更自然.
后者完全是FP特性构建出来的.
FP 构建出语义的自然性绝对是OO无法比拟的,其构建自然语义的方便性直观性也是Ruby,Python这样的动态语言望尘莫及的.

这也只是表达方式而已，oo 不是说非得用 o.ma 不可，虽然现在的 oop 语言有这个习俗，但这和oo的本质实际上不相干。你能说你脑海里没有 Person 这个观念？

fp 语言也有很多，也不是每种 fp 语言都支持你的写法，比如你下面的写法，充满了连绵不断的符号，你可能感觉挺爽的，但是别人呢？ 又比如你下面的写法，换成 lisp 来写，或者换成 js 这样的 fp 语言来写，能收到同样的效果吗？不能。

我所解释的 fp 构造对象的方式，是按 sicp 里 cons 的定义构造的，除了 fp 的东西没有牵涉到其它函数以外的知识，是纯粹的 fp 的 oo，没有什么蹩脚的。

oop 语言既然构造闭包，自然能演绎出 curying，monad 等等 fp 的基本特性，所以你那串以为非 fp 莫属的写法在 oop 语言是完全可以实现的，只不过那个语言未必是 java。这个命题是毫无疑问是符合逻辑的。这个推理按形式逻辑是充分前提的推理，按因明是宗因喻齐全的比量，如果你认为这个推理有哪一阶段不符合逻辑，敬请提出。

Trustno1 写道

真正能够说服我的是客观的理论推演，和逻辑论证的结果.
Why OO Sucks?
Because Von Neumann Architecture sucks.

我想你可能需要换个视角来看，从数学来看，函数是完备的，但是从物理来看呢？ 打一个不恰当的比喻，函数揭示了事物的波本质，而 oo 揭示了事物的粒子特性，物理特性，以及化学特性。

我们的确在用数学解释世界，但你能证明数学为何能解释已知未知的一切现实世界吗？

58 楼 terranhao 2008-08-22  

楼上的挺逗,居然说来说去把OO sucks归根到冯.落衣慢计算机架构sucks.
说了半天,你等于说没说.冯.落衣慢是我们基本的理论前提.是我们现在计算机工业的根本.
照你这么说:
近代经济学一个最基本理论前提就是假设:所有参与到经济行为中的人都是理智的经济人.看看A股,再想想自己,是不是理智的经济人?那这理论前提就是sucks,那现今的经济学全sucks,对不对?
你要说冯.落衣慢架构sucks你先得找一个不sucks的架构给我们看看.我就认为这架构很好
正如我前面说的,我就认为每天拉大便是sucks,因为我觉得如果能进化出不拉大便的能力当然更牛B.说说你的计算机架构.

57 楼 Trustno1 2008-08-22  

引用

要滿足 T1 兄所熱愛的并行的pi演算，確實非函數式語言不可

我并非热爱FP或者Pi演算,而是我只接受经过严格论证后的结果.
OO语法自然吗？方便吗?
自然不自然都是相对的,方便不方便都是主观的.
某位仁兄说,
Person.writeName()比wirte(char * PersonName)
更自然，于是汇编->C->OO是越来越更加接近人类的认知方式.
在我看来，Person.writeName()并不比Person 'write' "Name" 来的更自然.
后者完全是FP特性构建出来的.
FP 构建出语义的自然性绝对是OO无法比拟的,其构建自然语义的方便性直观性也是Ruby,Python这样的动态语言望尘莫及的.

零息票债券合约

zcb :: Date -> Float -> Currency -> Contract
-- Zero coupon bond

and :: Contract -> Contract -> Contract
-- 同时购入两张合约

or :: Contract -> Contract -> Contract
-- 在某个时刻购入两张合约中的一张

give :: Contract -> Contract
-- 卖出一张合约

at :: Date -> Contract -> Contract
-- 在特定时间购入指定的合约

zero :: Contract
-- 无效合约

anytime :: Contract -> Contract
-- 在合约过期之前可在任何时候履行指定期权

truncate :: Date -> Contract -> Contract
-- 在特定日期停止履行合约


一张面值100磅 2010年1月1日到期的零息票债券合约
c1 :: Contract
c1 = zcb (date “1 Jan 2010”) 100 Pounds

一张面值100人民币 2010年2月1日到期的零息票债券合约

c2 :: Contract
c1 = zcb (date “1 Feb 2010”) 100 RMB

购入一张面值100磅 2010年1月1日到期的零息票债券合约并且售出一张面值100人民币 2010年2月1日到期的零息票债券合约
c4 = c1 `and` give c2


一张欧式期权
european :: Date -> Contract -> Contract
european t u = at t (u `or` zero)

一个黄金手铐策略,在2010年1月1日到2011年1月1日中的任何时候,履行一份以100美元购入10股微软股票的合约.
golden_handcuff = at (date “1 Jan 2010”)  $ anytime $ truncate (date “1 Jan 2011”) $ (zero `or` (scaleK -100 (one Dollar) `and` scaleK 10 (one MSShare))

这些DSL,全部是函数复合,没有使用任何Tricky特性,类型安全,静态编译.要达到这种效果,Java怎么做?Ruby怎么做?
做到这样自然要花多少精力?

但是这种自然性,便利性无论多么Fancy都无法说服我FP比Java,Ruby更有优势.因为这种自然，便利都是主观的,你看着便利，我看着不便利.对于中国人美国人,Person 'write' "Name"看上去挺便利,但是若是换成日本人Person "Name" write 更便利.

真正能够说服我的是客观的理论推演，和逻辑论证的结果.
Why OO Sucks?
Because Von Neumann Architecture sucks.

56 楼 inshua 2008-08-21  

再舉一個傳遞對象的例子。

如，傳遞一個元組 {lon1 : 113, lon2: 114, lat1 : 22, lat2 : 21}，下面是erlang 現在的做法。

 p_target ! {lon1 : 113, lon2: 114, lat1 : 22, lat2 : 21}   // 很久沒用，語法不對，湊合看看，這個報文表示兩個經緯度坐標

而 oo 化以後，就可以傳遞對象了，則可以寫出如下代碼

p_target ! {lon1 : 113, lon2: 114, lat1 : 22, lat2 : 21, getDistance = function(){...}, getArea = function(){...}}

目標進程可能自己不知道該怎么算兩點之間的距離，但來信已經將計算兩點距離，以及計算兩點組成的矩形之面積的方法都提供了，目標進程根據這個知識可以很輕鬆的計算出距離。

55 楼 inshua 2008-08-21  

Trustno1 写道

buaawhl 写道

这是Haskekell的类型定义吧。
能不能给一个类型继承的例子。OO多态就是依靠inherit（对于interface叫做implement）来实现的。

所谓的继承不过就是rescursive type罢了

data Window_obj a=Object a|Window a (Object a)
                  |Button a (Window a)
                  |Image_Button a (Button a)

class Window_action a where   
get_type :: a -> String

class Image_action a where
show_image ::a->IO ()

instance  Window_action Window where

get_type (Window a parent)="window"


instance  Window_action Button where

get_type (Button a parent)="Button" ++ get_type(parent)


instance  Window_action Image_Button where

get_type (Image_Button a parent)="Image_Button" ++ get_type(parent)


instance Image_action Image_Button  where

show_image (Image_Button a parent)=......

没有任何模拟,全部是FP的first class的语言特性.

所以我说，OO(传统OO)的根子完全不在语义语法上，而是计算机模型上.

從 http://inshua.iteye.com/admin/blogs/231336 這個例子足以看出 oop（某些？）和 fp 是同一回事。


我武斷的認為， oo 的出現，是先從軟件工程開始的，和命令式語言合流，則產生 c++，和函數式語言合流，則產生 ocaml 等語言，至於 java 語言，其形象以命令式語言為主，但其精神已經與函數式語言相通。正如命令式語言如引進 lambda 表達式，則可以視同不純粹的函數式語言，而 oop 語言一旦引入匿名類，也有殊途同歸之妙。

但是，目前的這些語言，包括 lisp 等傳統的 fp 語言，從積極方面來看，都是以圖靈機和 lamda 演算為模型，從消極方面來看，都有修改狀態的行為。命令式語言有這個問題，fp 語言同樣也有，lisp 不修改狀態嗎，看過 sicp 就知道，lisp 也同樣修改，雖然作者了解修改狀態帶來的問題，但是他義無反顧的修改了。

要滿足 T1 兄所熱愛的并行的pi演算，確實非函數式語言不可，但前面已經說了，像 java 這樣的語言，完全可以通過匿名類做到和 fp 一樣的效果，所以，可以想象，oo 同樣可以被跑在 erlang 的虛擬機上。

那么 erlang 上面跑 oo 會產生什麽效果呢。

erlang 是以進程為主的語言，但是，1）進程之間要傳遞數據，有時難免要傳遞匿名函數 fun，這種情況在 oo 的誘惑下將會演變為傳遞對象，收到這個數據的目標進程，同時將收到一組方法，目標進程立刻可以知道，怎么操作這個對象，這和 soap 的精神相似，但演算是放在目標進程而不是源進程進行的。2） 很多進程本身可以視為一個對象，erlang 喜歡用的

recv ->
    new_state

完全可以封裝為一個能發生狀態變化的主動對象。關於這個，可以參考 joe 提出的 !! 運算符。如能視為一個對象，譬如，一個 http 客戶 session 是一個主動對象，屬於 HttpClientSession 類，那么每次創建這個 session 時，就有了一組狀態和函數，用起來也很方便。暫時能想到的就這些，肯定還有很多未知的樂趣。

其實 oo 的教材都是這么說的

軟件 = 對象 + 消息

我第一次看到消息變成了函數調用，還是傻眼了。

54 楼 Trustno1 2008-08-21  

引用

http://erlang-china.org/misc/commentary-on_a-history-of-erlang.html

jackyz 写道

这篇文档所传达的要义(用 Erlang 构造系统的感觉)是：一大堆并行运行着的有限状态机，各处做一做协议验证，彼此松散耦合，通常大部分的有限状态机都处在休眠状态。

http://www.iteye.com/topic/180281

引用

However, although various kinds of packages or modules are defined for many languages, they are not consequences of a general class declaration as in Simula 67.

The coroutine-like sequencing of Simula has not caught on as a general purpose programming tool. A natural development, however, would have been objects as concurrent processes