再驳Java消亡论和回应java消亡论的支持者

我的文章由于成文比较仓促，所以确实在文笔上有一些漏洞，遣词造句也不是很妥当。但我认为，一个严肃的辩论者，是不会咬文嚼字的寻找对方文法上的弱点的。否则的话，除了数学公理之外，没什么话可以说了！

对于这样的人，在我眼里，并不是在污辱我的智商（尽管他是这样以为的），而是在侮辱他自己的智商。这说明他完全不具备与人交流的能力。

如果一定要咬文嚼字，那么所有判断句都不可以在文章里用了。Java会消亡吗？废话，一定会。宇宙都会消亡，什么能不消亡？

论点：

透明的意思是，3-5年内，Ruby将占据企业级应用市场的主流。也就是JavaEE和今天的Ruby换个位子。我认为，这是不可能的。Java平台至少能够继续占据、企业级应用市场主流地位10年。

Java平台优势和对动态OO的支持

有人说我不懂Ruby，也不懂Java。这我就不敢苟同了。我是不懂Ruby，但并不代表我不懂Ruby,Python,Smalltalk语言为代表的动态面向对象语言的机制。对于Java，我也许不比某些人懂得多，但也绝不会比一般的Java程序员懂得少。

我对Ruby的认识，仅仅是今年5月Martin Fowler先生在上海交大作的一次演讲中Martin Fowler的Ruby编程演示。我还略为研究过Smalltalk和Python的语法。但是它们的类库，我没有研究过。

因为，我还不打算靠它们吃饭，那厚厚的专用类库对我而言是没有价值的。

Spring的AOP实现需要使用“反射”这种动态技术。这也是促成我当年研究Smalltalk和Python这样的动态面向对象语言的原因。我也十分折服于动态面向对象编程技术的强大能力。我一直认为动态OO技术在未来，将在编程中发挥越来越大的作用，也一直希望JVM能够增加更多的动态技术。我还曾经写过文章为动态OO技术摇旗呐喊过，此初衷依然不改！

Java作为一个平台也确实有这样的能力，而且也正在向这个方面发展，JVM将会支持更多的动态OO技术。

.NET平台当年推出之时，就以支持多种静态面向对象编程语言为卖点。VB.NET,C#，Delphi,托管C++这4种主流的面向对象编程语言都可以在.NET平台上运行。

同样都是静态面向对象编程语言，它们之间除了关键字不同之外，有什么本质上的区别吗？没有！VB.NET和C#是我所熟悉的两种.NET语言。它们之间本质上确实没什么区别。唯一的区别是，.NET平台的技术更新时，C#会先得到支持，VB.NET要晚一些。比如，事件机制，.NET1.1时，VB.NET用的是类似于Java1.0时的机制，C#用的是Java更新版本的机制。我想，应该是因为微软最重视C#的缘故吧。

.NET平台同时支持多种类似的语言，虽然在市场上有吸引VB,C++,Delphi,Java等程序员的作用，但在技术上却导致了开发资源的浪费。一种技术，要提供多个语言的实现。这比Java平台只支持Java这一种静态面向对象编程语言要低效的多。我在发现了微软优先关照C#之后，就决定从VB.NET上转到C#上，以免吃亏！自从Delphi投入.NET平台之后，日渐式微，这也是一个平台上不需要多种类似语言的明证！可以预见，.NET平台上C#独大的趋势还会继续下去。

.NET支持多种类似语言的另一个问题是，分裂了开发者社区。VB.NET,C#，Delphi，还有J#，托管C++，它们的语言原理和能力实际上都差不多，都是静态面向对象语言，但是，由于语法不同，就分裂成了几个开发者社区，彼此交流都不方便。

在我上一篇文章的评论者中，有人说我说错了，Java平台上除了Java之外还有Beanshell等语言。拜托！兄弟，你的理解力没什么问题吧？我说的是Java平台上只有一种官方支持的静态面向对象编程语言。就是和.NET比较而言的。

Java平台官方支持C++,C#,VB.NET,Delphi,J#吗？

Beanshell是一种动态面向对象语言，而且Sun官方可没有支持它！

现在，Java平台正在增强对动态编程能力的支持。目前，开源社区提供了Beanshell,JRuby,JPython,Groovy等面向对象编程语言。我相信，最后，在Java平台上也会只剩下一种主流的动态面向对象编程语言。未来，Java平台上会剩下两种主流的编程语言：静态面向对象编程语言类型是Java；动态面向对象编程语言是上面中的一种，也许是Groovy,也许是JRuby。

将来，我们Java程序员将有2件编程利器：Java和动态OO语言。对于编程问题，将能够更加游刃有余！底层的API类库，既可以是Java，也可以是其它动态OO语言所编写。反正都一样是.class文件，Java和动态OO语言都可以调用。

这就是未来！Ruby和Python这两种平台将会继续惨淡的过日子，也许不会消亡，但成不了主流。不是因为它们的语法不好，机制不行，而是因为它们缺少Java平台上那样多的API，也缺少熟悉这些API的程序员。

它们的灵魂将会飞到Java平台上，以JRuby,JPython的形式生存下来，在Java平台上发展起来。

静态OO语言和动态OO语言的优劣

接下来，再谈一谈静态OO语言和动态OO语言的优劣的问题。

我欣赏动态OO语言，smalltalk虽然出现的很早，开发者甚少，但是在它的社区中却诞生许多著名的程序员和设计模式等思想。MVC模式，XP极限编程等我所尊敬的技术都出自smalltalk。

但是，静态OO语言一直占据着主流的地位，也不是没有原因的。除了编译型语言的执行速度比解释型语言快之外，静态OO语言还有其它的优势。速度的快慢，在今天来看，并不是十分重要。Java比C++慢一些，但现在测试下来，C++最多比Java快一倍而已（不要跟我说某一个程序速度差很多，我这里指的是一般的程序，不作特别的优化和劣化处理）。只要速度不是相差一个数量级，就不是问题。

静态OO语言意味着更严格的语法，更多的编辑和编译时的检查步骤。更强的纠错能力，不正是编程语言发展的一个标准吗？不是可以更好的提高效率吗？

5月份那次看Martin Fowler先生演示编写Ruby程序，IDE弱弱的报错能力让Martin先生也伤了不少脑筋！

不错，Ruby不需要给变量声明类型。想指向哪个类型，就指向哪个类型。但是，指错了呢？只有在运行时才能发现类型指错了。如果这是个复杂的程序，有很多执行路径呢？如果测试人员没能够穷尽所有这些可能的路径呢？这个错误岂不是会漏给用户？

不错，借助于测试驱动开发，是可以降低出错几率。但是，测试驱动开发也不是测试的银弹，不能保证能够找出所有的错误。而且，静态编程语言也可以使用测试驱动开发技术。

市场预测

我预测，未来3-5年，Java平台和.NET平台都会增加对动态OO语言的支持力度，它们上面的动态OO语言将会达到实用化的程度。而Python和Ruby将会继续维持现在这样的市场规模。仍然处于边缘。Python和Ruby的解释器平台不会得到多大范围的应用。就像今天，Web2.0的那些小网站带来了Web2.0的概念，但最后是门户网站Yahoo,Sina等占据了Web2.0的市场。

DSL特定领域语言

接下来，说说DSL特定领域语言的问题。Matin Fowler最近转调了。我记得原来他非常支持XML格式的作用。但是，最近他说Ruby是最合适的DSL语言。尽管我仍然十分敬佩Martin Fowler先生，但是对他的这个观点，我不敢苟同。我认为，DSL语言还是应该使用xml格式，而不是使用Ruby这种类英语的编程语言来描述。

DSL可以说是一种“元数据”。用来描述程序。现在有2种元数据：标注和配置文件。

1.标注是.net首先引入的。Java在5.0之后也引入了。标注写在源代码中，和关键字一样，只是标注是可以自定义的。

标注的优点是，简单。缺点是表达能力不强。

2.配置文件，一般又分为3种：属性文件，一般文本文件和xml文件。

属性文件中的数据是以“名—值”对的形式表示的。缺乏数据之间的关系结构。表达能力不强。

文本文件，就是直接在文本中按照规定的语法写上一段文本。类似自然语言，只是语法的限制很强。语法检查，是一个大问题。如果没有按照语法写，就会发生运行时错误。

Xml文件，是层次结构的。它的前身是层次数据库。它的格式严谨，语法容易验证，规则容易定义。只是稍微复杂一点，需要写上元素名。

但是，总的来说，XML文件格式的DSL还是功能最强大，语法验证能力最强，目前也是首先的DSL语言的载体。

除了使用元数据之外，直接使用编程语言也是可以实现高等级的功能的。如，传统的不使用xml配置文件的Java编程。Java作为一种编译语言，需要编译，不使用xml等配置，就不是很方便。

而Ruby作为解释型语言，直接修改源代码是非常方便的。我想这大概就是Martin Fowler先生关于使用Ruby作为DSL的原因吧。

但是，使用DSL语言的用户，他懂Ruby吗？懂编程吗？愿意查看和修改源代码吗？我们中国的用户懂英语吗？

我认为，DSL使用XML文件还是首选！

OO就是银弹！

最后，谈谈关于OO的问题。有网友说我“言必OO?OO就是银弹吗?”。这里我回答他：OO就是银弹！

我Blog上的副标题是：“以OO为中心，坚定不移的走Spring道路”。

面向对象编程，给我们带来了多少API类库。Int,String等基本的数据类型，以及顺序、条件、循环3种控制流这样简单、细粒度的元素，通过类被封装了起来，今天已经能够通过层层叠叠的类支持对现实世界的种种对象的模拟和抽象。

借助于类库，众多的DSL特定领域语言已经被广泛使用。今天的java程序员使用了更多的配置文件（这就是DSL）来编程。如Ant配置文件，Hibernate配置文件，Spring配置文件等等。

最近，我正在学习jBPM。jBPM也是一个Java类库。通过Java类，它提供了一个DSL语言框架。我们能够使用xml配置文件，编写DSL语言：jpdl,bpel规范的。实现工作流、BPM等。

当然，除了OOP之外，还有AOP。但是，AOP只是OOP的补充。OOP能够实现绝大部分的抽象模拟任务。

认为OO无用的程序员，可能工作在嵌入式开发等与硬件有关的工作领域。他们的编程领域中，业务逻辑比较简单，不需要过多的抽象层次。

但是，这并不能成为否定OO作用的理由。你用不着OO，并不代表OO没用，并不代表OO不是银弹。

OO已经给我们带来了多大的变化啊！Java的成功就是一例。

还是毛主席的那句话：“没有调查，就没有发言权”。对此我也是深有体会的，曾经也犯过很多错。对于自己不懂的领域，硬是认为别人的说法荒谬。后来，自己真正了解了那个领域之后，才知道“今是而昨非”啊！