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做為一種動態語言，在這方面的優勢就顯露出來了。
方便修改過的代碼進行回歸測試：兩者都可以。測試是軟件開發必不可少的環節。如果僅僅是采用手工測試的話，則工作量太大，不切實際。因此可以采用一些自動化的測試，如進行單元測試、集成測試等?？上驳氖牵?/span>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。