上一篇
下一篇
下一代（大众）语言霸主应该具备的条件(转)
作者:journey 日期:2006-12-09
下一代（大众）语言霸主应该具备的条件
语法的延续性？
静态类型安全？
-----
有一本书叫做 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。
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。
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�Cfirst realized millions of years ago in LISP and Smalltalk�Care 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方面的松耦合框架，我也在持续寻找中。
请记住本文永久地址:
http://www.javaresource.org/java-news/java-news-73958.html
语法的延续性？
静态类型安全？
-----
有一本书叫做 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。
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。
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�Cfirst realized millions of years ago in LISP and Smalltalk�Care 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方面的松耦合框架，我也在持续寻找中。
请记住本文永久地址:
http://www.javaresource.org/java-news/java-news-73958.html
[本日誌由 journey 於 2006-12-09 07:32 PM 編輯]
文章来自: 本站原創
引用通告: 查看所有引用 | 我要引用此文章
Tags: 下一代语言 大众语言 语言霸主 下一代语言霸主
文章来自: 本站原創引用通告: 查看所有引用 | 我要引用此文章Tags: 下一代语言 大众语言 语言霸主 下一代语言霸主 评论: 0 | 引用: 0 | 查看次数: -
发表评论