一门天生就能损害人眼视力的语言－>Erlang

不说什么太高深的东西，如果只是看LZ给出的代码，还是比较容易看得懂的，逻辑相当清晰。PS：刚看了一个星期的erlang，之前没有接触过FP语言。

Scala的Actor有两种实现，一种是每个Actor基于一个自己的thread，另一种是基于Events的与Erlang类似的自己管理的轻量Actor，后者可以支持成千上万个并行的Actors。

基于Thread的Actor是对JVM thread的良好封装，而基于Events的Actor则提供了很好的伸缩性，你可以按照自己的需要选取其中一种。

我觉得真正损害眼睛的是
几k行的macro define
上W行的C语言的数据字典dbdict 全是0x1f0d4c这种
那才真叫痛苦啊

这个帖子居然有七页了。

Erlang这门语言在创建时受了Prolog的影响，第一个runtime好像还是在Prolog上写的。在语法上也受了Prolog的影响。Armstrong也承认Erlang的语法不那么modern，但是erlang的语义还是很有价值的，有劲的人把haskell的语法移植过来啊，编译成erlang instruction来跑。

我的意思是,JVM这种VM架构本质上不适合Message Passing和Actor这种模型.所以Scala只能依靠Thread Pool+event driven来模拟Actor模型,使用event driven后果就是在concurrency上用户代码的执行会干预调度,更重要的事是无法将代码平滑的迁移到parallelism更不用说distribute.
我在另外一个帖子里也说过了,现在很多语言在面对multi-core的问题上都存在比较大的方向问题,把Concurrency和Parallelism等同起来.在multi-core上真正有意义的是Parallelism而不是concurrency.在Parallelism上,搞对方向是一个很重要的问题.这里的方向不仅仅是编程模型上是否方便解决问题,更重要的是底层的VM架构和上层语义上是否搞对方向.你选择什么样的VM,上层适用的语义模型会随之而改变，语义模型的改变直接就导致编程模型的改变，或者反过来说也正确你要选择什么样的编程模型你就要选择什么样的语义模型，什么样的语义模型就会会决定什么样的VM模型.比如说JVM或者CLR这种VM，上层的语义就天生应该选择static,strong并且支持type inference的类型系统,这样就可以像Haskell那样依靠编译器静态分析，支持STM+continuation.而你要选择Erlang那样的编程模型,那么你最好就应该选择dynamic type+FP,这样就可以使用支持hybrid Heap的VM.
而我之所以欣赏Erlang,并不是因为他是一个FP语言,而是它从上层的编程模型到语义模型到VM模型配合的严丝合缝，而在其他语言上很少有看到这一点,Haskell可以算另外一个,C#可以算半个.

所以Robbin在隔壁问我,那些动态语言在Parallelism上有希望.我说,在我看来除了Erlang之外，搞对方向的也就只有MS一家而已,C#现在俨然是半个Haskell了.而其他的语言在我看来这些语言要么是在先天不足的VM上架了一套完全不合适的编程模型(比如Ruby+reactor),要么是在一个正确的VM上做出了一错误的决定(比如Scala).





如上所述,我觉得Haskell的那种non-strict语义并不适合Erlang VM.Haskell和Erlang是完全两种不同的方向.在Haskell上我觉得最大的亮点就是并行规约.
如果有空的话,可以看看这篇papaer,我觉得写得非常不错,可以特别关注一下2.2和2.3节,用Monadic+CPS的方式整合Thread model和Event Model.它可以依靠Haskell compiler把Monad语法包装的continuation分析成Thread调度器执行的system trace call tree.Thread首先会从Tree的入口开始遍历,当每次遍历一个节点就对该节点进行force 求值,如果节点所需要的事件达到那么Thread主动进入continuation drive指令代码，而这些非节点上的代码最大的特性就是可以在multi-core上进行并行规约,这种规约一直进行到下一个Event节点等待由lazy evaluation来等待未知的事件并且将当前的continuation移出Thread.当event到来的时候则可以有机会让event来主动把当前的continuation push到thread里继续往下执行.

这种模型需要完全建立在对Moand静态类型的分析上的.Monad类型把IO和computation完全分开了.System trace call tree的节点都是天然无法并行的IO代码,而除了这些节点之外的continuation则可以进行并行规约.也就是说这种模型把Task driven的并行模型转化成了Concurrency+Instruction driven Parallelism的并行模型.

FP提供并行规约,Monad提供静态分析,STM+CPS提供concurrency,这套东西无论从编程模型还是语义模型还是底层的VM,对Concurrncy和Parallelism来说,恐怕是我目前为止看到最漂亮的的最完美的整合.甚至Erlang的模型都无法与之相比,Erlang没有强类型系统,也就是导致了它无法自动decompose computation,当然并行规约我觉得还是可以做的.

至于在Scala Actor那种换汤不换药的空架子下,在接收到event以后程序员仍然要关心如何把代码切分成足够小的代码片，仍然要关心这些代码片是否能够真正调度到multi-core下进行并行处理.这也是我说Scala没有搞对方向的原因,一个强大的类型系统只是为了提供编程上的遍历而忽略对程序的静态分析可谓是舍本逐末，买椟还珠.至于Ruby,Python这些当红语言，dynamic的类型系统就当然就根本无法做到编译器静态分析了,而其本身是一个imperative语言,即无法进行并行规约，又享受不了Erlang VM那种模型带来的性能优势可谓是鸡肋,其未来的作用可能只是像APP Engine中那样的插件语言的形式存在.

emacs 的翻屏应该是 Ctl+v/Alt+v吧。
emacs用熟了，还是不错的。