下一代（大众）语言霸主应该具备的条件
这是BJUG里面讨论Java前途，Ruby前景的时候，我写的一篇回复。贴在这里。
下一代（大众）语言霸主应该具备的条件
语法的延续性？
静态类型安全？
-----
有一本书叫做 beyond java。
介绍了java的主要竞争对手。Ruby (Rail), Python, .net ( C Omega)
次要对手，php, lisp, smalltalk (seaside), perl, FP.
那篇Java不适合SOA的文章，主要讲了Java的跨平台的虚拟机在SOA方面没有优势，因为代码不需要移动。（我感觉很奇怪，B/S结构不也是这样）。然后下了一堆结论，不论从任何一个方面看，Java就是不适合SOA。可能是摘要。具体参数例子，没有看到。
最感兴趣的部分就没有看到。
liusong说的Web Service Client，我也有同感。
Web Service Client 绝对是Script的天下。编译语言丑陋的WSDL binding令人难以容忍。
我看了Java, C# 的generated stub，就下定了决心，除非有很多钱赚，不然拒绝采用编译语言作web service client。:D
Web B/S 方面（主要是server side开发），script实现Bean Utils, OGNL之类更容易，还有continuation，这是一点优势，但毕竟是server side，还有大量的数据处理部分，我认为，这些优势还不够保证Server Side的天下。且观望着。
--- 下面回顾一下Java的历史和现状，看看下一代语言霸主应该符合怎样的条件
Java的开发效率从来就没有达到过最高。只是比C++高。而C++是上一代霸主。
Lisp, Smalltalk就一直号称比Java开发效率高。
首先来定义一下，什么样的语言，才能称为霸主。
1. 程序员数目最多。
Web内容管理方面的开源项目，PHP项目的数量和质量都远远超过Java。但是，却和人数不成正比。可见脚本语言的开发效率有多高。
为什么开发效率相对不高，Java为什么还能够保持这么大的程序员数目？
我猜想，可能和静态类型安全有关。也可能和语言的延续有关。
回顾一下语言简短的历史。C语言是 C++之前的语言霸主。
c, c++, java的语法基本一脉相承。
比如，= , ==, 这样的语法。我的个人观点，看上去就是不如 :=, =好看。但是保持了一种延续性。
2. 其他语言都把它作为比较标准。
几乎所有的语言都把Java作为开发效率和运行效率的比较标准。
比Java开发快多少。比Java运行快多少。从以前到现在，从来就没有间断过。
从这点看，Java确实是当之无愧的霸主。
Gosling ：如果你看看它们的程序，你就会发现，它们看起来就像Java程序一样。
殊不知，这正是关键所在。
Ruby, Python, C# 之所以被称为Java的主要竞争对手。是因为他们保持了语言的延续性，就是说，它们看起来像Java。正如Java看起来像C++。
PHP也认识到了这种傍大款的好处，PHP5也开始看起来像Java。只是有些晚。并且对PHP从前的用户并不是很友好。有点 c 到 c++的意味。不过，我还是很看好PHP的，毕竟原有的程序员基数巨大。
----- 静态类型安全的魔咒
动态语言是否能够打破静态类型安全的魔咒, 成为语言霸主?
下一代语言霸主是否还是静态类型语言？
我们来看看，虽然是静态类型，c的类型其实不太安全，c++，Java的类型就比较安全，所以更加流行。以至于很多人依赖于静态类型安全。
复杂系统中，如果没有一个静态类型系统作为保障，很容易迷失方向。
静态类型安全是否必要？
TDD的经验，令很多人改变了看法，不再像以前一样依赖于静态类型安全。尤其是开发经验相当丰富的开发高手。
这里就有一个问题。
静态类型安全目前是适合大众的需求，所以，静态类型安全语言，才能成为大众语言。
高手的摆脱静态类型安全的开发经验（TDD等），能否普及到大众？
大众能否同样摆脱静态类型安全的依赖？这是一个很关键的问题。
如果大众摆脱不了对静态类型安全的依赖，那么动态语言就无法成为大众语言，无法成为语言霸主。（如果是这样，唯一的挑战Java霸主地位的只有C#了）。
我想，时代总是进步的。大众早晚都会摆脱对静态类型安全的依赖。只是早晚的问题。但这个早晚非常重要。比如, Non Static Type的 Smalltalk历史更加久远，更加OO，更加优雅，开发效率更高，但是一直没有成为主流，直到c++ like, static type safe的Java崛起之后抢尽了所有风头，从此smalltalk一蹶不振，错失良机，人数缩水。
这里的时间点问题，就在于，高手的摆脱静态类型依赖的开发经验，能否普及到大众，以便助动态类型语言登上大众语言的霸主宝座。
------ 静态类型确实影响重用
有时候，为了一些通用算法的重用，不得不统一interface，引入类型强制转换，放弃类型安全（我还是反对大量使用目前的Reflection API，因为那套API实在是麻烦）。
(Static Type FP 如 Haskell, OCaml是如何解决这个问题的，由于不熟悉语法，我还没有参透。好像他们的Type相当于Meta Class，Super Type，而Class相当于Data)
放弃了类型安全，还有些不甘心，于是引入运行时类型检查。
Class 之间利用 isAssignable 进行前后代的距离检查，instanceof 进行最后一关检查。以至于引入了一个复杂的Class检查体系。后来我发现，虽然没有使用reflection，但是做的这套工作和Script做的工作也差不多。JavaScript不也是采用 if (o.method) 来进行类型安全检查吗？而在编译里面做运行时类型检查比动态语言费劲多了。
这违反了我的原则 —— 用一门语言应该尽量发挥它的长处，而不是总想着避免它的短处。于是我放弃了这套工作。
静态类型负面效应，最臭名昭著的例子，就是完整的Visitor Pattern里面的 Visited Interface ( Visitable Interface )。里面的双重Type Dispatch。accept( visitor) { visitor.visit(this);}
这就是把静态类型用到极致的后果 （引起的类型循环依赖密集和广泛程度和难以想象，所有的不相关的visited type全都通过visitor interface相互网状交织依赖）
通常这种情况下，我宁可放弃类型安全。采用类型强制转换，也不愿意引入visited interface。 1 楼 buaawhl 2006-07-15 意犹未尽。又回了一贴。也放在这里。
-------------
这个贴子里面, 就属这篇资料最翔实了.
引用
On 7/14/06, David wrote:
查了一下Gosling发表的对于Ruby的言论： http://www.labo-sun.com/resource-fr-news-1045-0-java-vs-dynamic-languages-sun-s-james-gosling-didn-t-get-the-memo-.htm
不过，仔细看进去。这篇文章认为，Gosling对动态语言的评价是傲慢和轻率的。
该文逐字逐句地分析Gosling的评价，一一加以反驳。并没有情绪化，还算是有理有据的。
关于 Dynamic Language only generates web page. scale and performance problem.
大家都知道，Dynamic Language 的power, scale, performance 都是相当强大的。
最有用的领域在于Glue, Loose Coupled Integration等。Groovy就是干这个用的。
相关资料罄竹难书。这里也就不再重复那篇文章关于这些方面的部分。
下面只是列举几个有趣的地方。
关于SOA。
straight-forward systems like REST, Microformats, and Atom are generally considered legitimate alternatives to the vendor/analyst/press peddled technologies like WS-* for a wide range of integration issues.
我想, 这就是人们鼓吹Java不适合SOA的理论依据 -- 更轻量直观的SOA协议出现。
While the benefits of dynamic languages–first realized millions of years ago in LISP and Smalltalk–are well understood in academia, IT managers and Sun certified developers are perfectly accepting of our static = professional / dynamic = amateurish labeling scheme.
这句话揭示了一个普遍的误解. 人们确实普遍认为静态语言才是专业语言，动态语言是业余语言。虽然是误解，是不对的，但是，这个误解是有一定道理的。
因为动态语言的入门太容易，所以大量的业余人员能够轻松入门使用，制造出大量惨不忍睹的scriptlet。
但是，入门容易，不等于掌握和精通容易。掌握和精通动态语言的难度，要超过静态语言。因为没有静态类型的限制，动态语言强大的语法提供了无限的可能，对于新手来说，出错的几率也大大增加。
另一方面，动态语言出大师级程序员的概率也更高。动态语言大师追求的是，在想象力范围内，无限发掘语言的Power和可能性；静态语言大师追求的是，如何work around，因为静态语言的Power有限，能够在有限的时间内发掘完毕，剩下的任务就是突破限制。
--------- 下面还是冒天下之大不韪，说一下自己对rails的看法。
动态语言具有天生的Loose Coupled 优势。而这是静态语言穷毕生而追求的境界。POJO, Unobtrusiveness无侵入性，IoC。人们多年痛苦的摸索，总结出来的经验教训。
但是这些经验教训，在动态语言里面却并不被看重。
（我主要说的是Rails，因为看了那笨深入浅出的好书，对Rails的方方面面有了一些了解。当然，Rails，还有相关书籍都获了大奖。优点很多。这里只是表述自己的个人看法，不一定准确靠谱。即使靠谱，也只是很小的缺点，瑕不掩瑜）
这从某种程度上，也体现了动态语言方面的傲慢。天生的强大的语法优势，使得动态语言程序员，不屑于关心静态语言的现状。听到什么静态语言费了半天劲达到了什么效果，只是懒懒地说，在我使用的语言中，早就做到了，还用那么麻烦。
实际上，静态语言程序员反而能够更深地体会动态语言的好处，能够小心翼翼地避免在动态语言中出现静态语言里面的一些反模式。
--------------- 关于自己的独立想法问题
前面大家有关于自己是否应该有独立想法的争论。
一种说法是，保持自己的独立的想法。
一种说法是，太阳下没有新雪，大部分所谓自己的想法别人早就有了，只是自己不知道。
（还有一种说法，来自一个哲学家和思想家的人物，大家都很熟悉的：所谓自己的想法，只不过是各种势力灌输的结果 -- 给你有限的剪裁资料，引导你那么想）。
我认为，关于这个问题，应该分为两个层次。
1. 做事情上，要保持一定的无知度。
脚本不能做重量级大型系统；Java不能快速开发。等等。hype, myth, buzz, story.
自己做事情的时候，这些断语都不必在意。因为这些方面的正反例子都不胜枚举．
要是全知全能，那么什么事情都做不了。我们这个世界，毕竟是个概率世界。
谁也不知道自己落在小概率，还是大概率范围。
而且做事情关注的主要是领域，而不是语言。赚钱的也主要是从领域赚钱。最终用户才不在乎你使用的是什么语言。一门语言用的得心应手了，就能够超越那些断语．
2.口舌之争。比如，论坛争论。主题讨论。主义之争，培训，咨询。这些方面。确实知道的越多越好。
因为这主要涉及的是，一种大概率事件的普遍适用的论断。那么就需要知道的全面一些。
------------------
以前刚写出fastm的时候，一个主要的反驳观点是，fastm要求显示逻辑写在back end java里面，修改了显示逻辑，就需要重新编译。
我当时的想法就是把fastm移植到动态语言环境。我最先想到的是，PHP 5，因为程序员基数巨大，各种配套的开源项目中，众多。同时，Ruby, Python，都有可能。
我无法确定那种语言更有前途。与其把时间花在某一种语言的移植版本上，不如更深地钻研领域需求。等到动态语言决出胜负的时候，再选择也不迟。
只是到了现在，仍然没有看到哪个动态语言占据绝对优势。目前看来，似乎Ruby呼声最高，因为Ruby最像Java，Rails更像MVC。
不过，经过和一些朋友交流，和自己的粗浅调查，我的一个初步印象是，PHP的OR似乎更加成熟，Python的也不错。
同时，动态语言的 MVC, OR方面的松耦合框架，我也在持续寻找中。 2 楼 leyen 2006-07-18 ruby像java?哪个地方像？ 3 楼 buaawhl 2006-07-18 leyen 写道ruby像java?哪个地方像？
根据我的粗浅了解，ruby, python, php, perl, lisp, smalltalk这些动态语言里面。Ruby最像Java。
Pure OO. Class Native Support。允许{ }写法，构造函数。基本操作符也比较相似。
如果Ruby不像java, rails不像mvc, 也不会吸引很多java界程序员。
每种语言都有自己的资深fans，对于这门语言所有的细节都有很深的理解，满眼里看到的都是不同。我很理解和支持。并对这些不同的地方有更浓厚的兴趣。
