这是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。
下一代(大众)语言霸主应该具备的条件
语法的延续性?
静态类型安全?
-----
有一本书叫做 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。