Ruby vs Java 的几个误区
http://www.relevancellc.com/2007/6/2/ruby-vs-java-myth-1-project-size
围绕Java与动态语言（比如Ruby、PHP、Perl和Python）之间的争论，虽然一直没有一个确定的答案，但从来没有消失过。随着Java的日趋复杂，动态语言的优势——简化和易用就越加凸显出来。.Ruby是一种好语言，和Rails一起提供了引人注目的新价值(从效率的角度)并且这样的价值还在飞速地增长中。Ruby不一定是最好的语言，但是它也许会是最有可能挑战Java的一种语言。它很有可能首先在一个更小但是却重要的环境中取得好成绩。
然而，在Ruby尚没成为主流的今天，存在着关于Ruby对比Java而言而存在的若干误区，本文将通过对Ruby与Java两种语言而来揭露这些误区。
一、 误区1：Ruby适合于小项目而Java适合于大型复杂项目
这种结论是非常的不切实际的。因为事实上，Java适合开发于小型且明确的项目，而Ruby反而适合于开发大型、复杂及开放性的项目。
Java适合小项目的理由如下：
1． 对于小项目，能找到一些开源且合适的内库，将意味着完成了十之八九了。这样的开发模型效率最高。而Java提供的内库比任何语言都丰富；
2． 小项目的经济预算对于开发语言的不稳定很敏感，希望越成熟越好。而Java语言众所周知，而且开发文档完备；
3． 对于小型项目，开发团队没有足够的时间与财力来学习新的语言，而Java则是大家都很熟悉的开发语言。
而对大型项目，Ruby则更有优势：
1． 由于大型项目的开发难度与任务艰巨，因此语言的开发效率比语言内库的多少显得更加的重要。而Ruby正是这样一种高效的开发语言；
2． 大项目肯定有许多意想不到的事情，因此对于这种变化，要求开发语言有极好的灵活性。而Ruby的灵活性是很好的；
3． 对于大型项目，技术培训将显得很有远见。但很多公司都低估了这一点。大约5天的技术培训，可以提高开发人员约10% 的开发效率，同时，这种培训效果将保持在一年内。Ruby正好适合这样技术长远的培训。
那么，如果上面的神话如此的不切实际，人们为什么还会相信呢？因为到目前为止，Ruby非常成功的应用于一类小型项目的开发：基于数据库的web应用程序。而Ruby on Rails的出现正好弥补了Ruby在开发小型项目方面的不足：
1． Rails正是人们所需要的库；
2． Rails尽量排除小型项目的不稳定性；
3． Rails有广泛的实际经验，开发人员需要额外培训很少。
人们认识到了Ruby on Rails的成功，于是由于思维定势，只看到众多小型成功的Ruby on Rails项目，众多大型成功的Java项目，而没有全面的了解实际的情况。从而就有了上面的认识误区。
二、 误区2：Ruby特性会降低代码的可维护性
Ruby的特性很多，如能写出快速简便的特性，动态调用（dynamic evaluation），支持软件封装规则（soft encapsulation rules），简易的元编程性（easy metaprogramming）及闭包性（closures）。尽管这些特性很不错，但很多初学者常常担心会降低代码的可维护性。
事实上，Ruby丰富的特性如果使用得当的话，将提高代码的可维护性。那么提高可维护性标准是什么呢？
1． 提高整个程序或模块的可理解性；
2． 易于查找代码；
3． 提高代码的可读性；
4． 提高代码的可修改性；
5． 方便修改过的代码进行回归测试。
笔者认为，程序开发人员应用对软件的可维护性负80%的责任，而只有20%的责任是由语言及工具来承担。那么，让我们逐条来看看Java和Ruby两种语言，谁真正做到了上面提到的哪些标准吧。
提高整个程序或模块的可理解性：两者都可以。Java和Ruby其实有很多共同的点：类、继承性、多态性、封装性等。而Java对这些抽象的共同有更好的支持与实现，这主要是通过它的IDE来展现，如IntelliJ IDEA。而Ruby则在结构上更胜Java一筹。则Ruby则更加容易创建DSLs （Domain Specific Languages，领域特定语言），从而能较好的反映与描写程序的设计思路。其实，只有将Java与Ruby各自的特点叠加起来才能真正的提高整个程序或模块的可理解性。
易于查找代码：Java在这方面做得比较成功。它的IDE为它赢得了这一局。
提高代码的可读性：Ruby胜。就单个的类文件与方法这个层面来讲，Ruby编写的代码能更容易保持简洁性与可读性。如果对些有疑问的话，可以在Blub paradox了解更多的这方面的信息。
提高代码的可修改性：Ruby表现理佳。当需要修改代码时，代码维护人员经常丢弃程序最初设计者的初衷。而一旦当最初设计者的假设发生变化或被打破之后，编译器在编译的时候就会碰到问题。此时，Ruby做为一种动态语言，在这方面的优势就显露出来了。
方便修改过的代码进行回归测试：两者都可以。测试是软件开发必不可少的环节。如果仅仅是采用手工测试的话，则工作量太大，不切实际。因此可以采用一些自动化的测试，如进行单元测试、集成测试等。可喜的是，Java和Ruby都支持了自动化的测试。
三、 误区3：Ruby太难学习
很多人都认为，Ruby对于一般的开发人员，其学习曲线比较难。其实这样的结论是很有问题的：
1． 编程本身并不简单。21天学会编程这样的言论无异于天方夜谭。也许学习编程语言本身是一条比较平缓的曲线，但是，任何语言中的难题都需要痛苦的思考才能解决的。
2． “这太难了”在任何领域都不能成为不学习的借口。如果哪一家银行漂亮的营业员说，我们只重复的使用加法来进行计算，因为乘法对我们的初级员工太难了，那还有谁会去这里办理金融业务呢？如果一个外科医生说，我就差10来年就退休了，所以也不用再学习新技术来改进我的手术了，那么大家又做何想法呢？
3． Java跟Ruby一样的难学。笔者经常听到这样的言论：“Java里的反射机制我从来不用，因为它太难搞定了。”
4． 不能通过砍掉语言的特性来降低语言的学习难度。如果某种语言缺少开发人员所需要的某一特性，自持技术高深的牛人就会自己开发类型的特性。对小型项目而言，如果开始没有使用程序块，也许可以通过匿名内部类来实现。对中型项目，可能要用到设计模式来实现。而对大型项目，一开始就使用实际意义不大的方式来构建动态的系统，那到结果就是有可能产生一个巨大的框架，同时需要第二种语言来进行冗长且易错的配置。
Java企业级框架很多而很著名，但其中过半的代码存在很多的局限性，至少在语言层面是这样。很多精明的Java开发人员为当初“Java语言易于学习”的言论所忽悠，一直到后来才发现Java的学习曲线很复杂。
学习Java的学费已经交过了，那么Java当然应该好好的发挥作用了。所以Java社区的开发人员应该为那么多优秀的Java代码感到自豪，尽管当初学习开发Java的代价很大。
那么，Java开发人员就能过河拆桥吗？如今轮到Ruby了，就说Ruby太难了？
四、 误区4：Rails的思想很容易被复制
不管是Rails的狂热粉丝，还是Rails的愤青们，都有一个共识：Rails在Web开发具有很多闪光点，于是很多其它的框架也开始Rials化了。既然我使用的Java开发框架已经有了Rails的思想了，那为何还需关注Rails它本身呢？
很少有其他语言可以完成Rails，或者像Rails那样的。Java不在他们之列。Rails从Ruby中获取了一些妙不可言的东西，尝试用另一种语言复制它不仅是对Rails所做的是一个浪费，对其他语言来说也是一个浪费。但是它的概念一定会在其他非常动态的，动态类型语言中得到很好的应用。如果将Rails的思想复制进Java中，那么Rails的价值会大打折扣。而且如果对Rails了解不够的话，那丢失了什么东西都还不知道呢。
Open classes特性允许扩展类的定义，既可以扩展整个类，也可以扩展某个实例，Cool。
Rails使用open classes特性来构建更加可读的对象模型。例如，可以使用x.black?来代替StringUtilities.isBank（x）。当然，如果只是一个这样的取代并不能紧，但成百上千的使用，则可以大大的提高代码的可读性。
Open classes更重要的应用是创建简单的DSLs（领域特定语言），例如ActiveRecord所宣称的关系与验证：
class Poet < ActiveRecord::Base
has_many :poems
validates_presence_of :name
end
DSLs经常两度的用到open classes特性，首先使用open classes来创建新的声明“statements”，并符合类的声明方式。第二，使用open classes来添加新的方法。当然也可以使用Java Annotations来模拟实现，但工作量巨大。这可以从Rails验证的代码与采用Hibernate或Spring验证的代码来进行比较，就可以发现这种工作量的巨大性。
当然，Rails的争议还是有的。Rails的愤青们认为，Rails的优点只有在Ruby中才能体现，而在Java则成为劣势。例如，Java web应用将业务逻辑与持久层进行严格的分离，这对Java是很好的，除非应用程序变化。而Rails对这种分离进行了放弃，着重强调开发与配置的简易性。这在Ruby环境下是很好的思想，因为开发人员可以随时添加这个分离层。
当然，不能用Java来实现Rails，却并不意味着不能用Java做一些同样优秀的东西。Java的力量可以以一种有趣的、神奇的方式应用到一种全新的框架上。只是还没人做那些事情。每个人都对J2EE这个糕点趋之若骛，以至于没人以一种更加激烈、更加动态的方式来重新考虑问题。尽管有人提出一个基于Java的杀手级框架可以与Rails做同样多工作, 它一定也不能做的象Rails一样。
五、 结论：这是一场走向大同的游戏
Ruby是一种优秀的开发语言，而Java是一个优秀的平台。如果让Ruby运行在Java的虚拟机上，则鱼与熊掌可兼得也。
笔者认为，做为一种开发语言开发普通的任务，Ruby是优于Java的；而做为一种平台，Java则更胜一筹。因为Ruby的运行平台是简单的解释执行（MRI）。通过研读Java平台的源代码，可以发现它确实是一种优秀的平台，这表现在：
1． 字节码指令集；
2． 简便的类文件格式；
3． 强大的线程支持；
4． 十分安全的模型；
5． 众多实践过的部署方案；
难道就不能进行有效的整合，构建一个和谐程序世界？笔者不希望以出身论英雄，不要以开发语言来定位开发人员。而是希望可以采用Ruby、Scheme、Scala或Erlang来编写优秀的程序，但都可以和谐的运行在Java的JVM上。
JRuby则是一个100%的Ruby编程语言的纯Java实现，这种语言在CPL，GPL和LGPL三种开源许可下发行。它是一个1.8.4 Ruby解释器，其中提供了大多数Ruby的内置类。JRuby支持从一个Ruby程序中定义Java类并实现与之交互，另外还对Bean脚本化框架实现支持。JRuby使Ruby程序能够存取Java类，允许它们作为程序内使用的一级对象。如今，JRuby的创始人，Thomas Enebo和Charles Nutter，已经受雇于Sun专门研究开发JRuby。
JRuby允许现有Java开发者充分利用Ruby提供的强有力和易于使用的编程特点，而Ruby开发者将能够自由使用庞大的曾使Java广泛地应用于各个软件开发领域的Java库来进行开发。
如果读者想在这方面了解更多，那么下面的建议可能最有用：
1． JRuby项目；
2． 使用JRuby来编写接下来的部分Java应用。
3． 采用rake来代替ant管理Java应用程序；
4． 对JRuby代码进行单元测试：Test:Unit。