huaqiao :分析不错

既然不知道什么跟什么，我也来吐两句，用普通人的普通话

语言好坏：说容错性与动态代码替换，世界上最强的莫过于as2(actionsrcipt 2.0）Adobe搞的as3简直是大粪，而我又不得不用大粪，郁闷！as2是力与美的结合，它几乎完全不出错，即使出错也可以选择优雅的忽略或善意的提醒，而程序还是很正常的运行滴～跟没错误一样。动态代码替换，哪家伙简直是。。。。强tnnd强！把代码封装在swf中独立开来，运行中读取一下就是新的代码，super！抽象方面，我的神哪，你可以用诸如老子，小子关系的类编程，也可以用函数式编程，交叉使用（用句广告语，中西药结合疗效好！）那效果，刚刚的！界面设计那更没得说，哪个语言有这样的界面设计方式，一个字：华丽！（翻译成英文就是一个字啦）并发，那“孙子”（此处不是贬义，下面分解说明）简介好得不得了！运行时在库中实例化一个movieclip，就是一个孙子，每个孙子都是“并发”运行（秒级）。

实际应用：鉴于以上的好处，在实际开发中我是前端用falsh + mdm（air?烂货！不支持as2，当然mdm也烂，不过凑活啦）开发页面和一般应用，后端（这里的后端也是前端，呃怎么表述？～）用其它语言，最近用erlang，解决速度和特殊需求等问题。例如某个小小型财务软件，前面flash，后面erlang并行运算，那个叫爽～！
又如，本地数据库与网络同步，前面flash，远程erlang并行运算，那个叫赞～！

现实中，这种实际运用最厉害的应该算香港人，一句话 粤语英文各半，方便的解决了语言功能不足所带来的问题，当然了，开发一下语言的插件也可以，例如 M 叫 兆，搞定。erlang 字符处理不足，开发一个插件就可以啦 ~ ,但是，插件并不是人人知道的，你推广谁知道，M就是兆？

期望erlang被某家大大企业收购，并继续开发，到时所有弱点就会慢慢解决，故事都会这样发展的～

现在是可选的东西太多，看不清，在以前只有apple II和6502这种语言可选的话……

是好东西就用，不足就补足，这种方式行不通就那种，单一不行就综合，此乃中庸之道也～没有实践试验，纸上谈兵不足道也～

以上p文 至此结束。

2、share nothing不是靠immutable保证的，而是靠process独立内存空间加上copy semantics保证的。copy semantics不是immutable的实现方式。immutable是语言中变量的语法特性，copy semantics是语义动作，完全风马牛不相及。只要是复制语义的，即便不是immutable的照样不会破坏share nothing。

从严格意义上讲，完全在语言层面上满足copy semantics的语言只有Erlang一个，即使是像binary的reference在语义上也可以认为是拷贝的，并且其存在于独立的heap中。另外，对ETS的访问在语义上也是IPC性质的。真正在语言层面上做到share nothing的只有Erlang一个。Scala在语言层面上不具有copy semantics，而只是能够定义immutable的变量，因此严格地讲，Scala不是share nothing的，而是最多可以做到share immutable。要在Scala中做到看上去的share nothing，必须靠设计约定获得。

3、语言越来越复杂（尤其是平台基础和上层特性不匹配时）不是好现象。

trustno1 :
Clojure的STM仍然是需要靠程序员保证 transaction中不出现io.他有一个IO!的宏可以辅助检查.但是这就如我前面提过的C++ try catch特性。没有GC的情况下C++的try catch特性是非常危险的.虽然C++的拥趸们经常说他们可以通过RAII来帮助程序员屏蔽这些问题.但是你可以想象一下在一个大规模的工程里,会出现各种各样RAII这这种粗糙手段无法防止的事情.比如你引用了某个第三方的lib,如果这个lib本身没有对try catch引起的内存问题加以处理。然后你又在上面做了层层的包装.当你把它置于try catch下的时候就会出现莫名其妙的问题.
没有对IO进行类型检查的系统里面.STM可以当作一个花销的摆设,但是绝对派不上用场.这点其实在Erlang当中也存在,比如mensia的transcation就不允许你在其中使用IO.但是mensia相对而言都比较好一些,因为毕竟是数据库属于专业模块不会对程序的全局产生破坏影响.但是STM是一个全局使用的特性,这就需要非常非常严格的检查而不是把这种事情扔给程序员.

Scala本身并不是pure functional的语言，对Side effect没有（也许很难）作全面的封装。我不清楚能否在对Scala的IO系统仔细设计和封装后做到对IO进行类型检查。不过，“没有对IO进行类型检查的系统里面，STM可以当作一个花销的摆设，但是绝对派不上用场”似乎也太绝对，至少，在程序员自己能处理的情况下，把STM限制在系统的某些地方，也还是可以一用的。

Currency和Parallesim是两回事.Erlang本身就不是为计算密集型的Parallesim应用设计的.因此在这个平台上谈论针对计算密集型的处理方法有点文不对题.

假设，大部分人都同意：“Erlang本身就不是为计算密集型的Parallesim应用设计的”。然后，把问题换成：“Erlang能不能用来做计算密集型的Parallesim应用？”，答案就好像没那么直观了。理论底子厚的，可能想一下就明白了，象我这种底子薄的，就得拿几个例子验证一下，然后苦思冥想几个月，似乎明白了点，然后就跑到jackyz的场子里大喊大叫:-)，为什么？高兴呗。

接着，看看这个话题的另一面。如果我说，“现在的Erlang**只**适用于容错的、大规模的、软实时的短信息交换”，估计很多人就开始反对了。如果我还说，“JVM上现在也能很**方便地**实现容错的、大规模的、软实时的短信息交换”，那就更不得了。为什么？JVM不是为“容错的、大规模的、软实时的短信息交换”设计的？同样，我又得拿几个例子验证一下，然后苦思冥想几个月，似乎想明白点，就跑到jackyz的场子里大喊大叫了。

事情就是这样子的。