这是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。