Relevance咨詢公司的Stuart Halloway最近編寫了一個關於“Ruby vs. Java之怪談”的系列博客文章。這個系列文章的靈感，源自他最近從一個從零起步、沒有先前約束的Ruby項目轉回一個成熟完備的Java項目後的心得體會。在這個歷時多日的項目過程中，Halloway對以下幾個“誤區”進行了探索：
誤區之一：Ruby適合小型項目，而Java更適用於大型的、復雜的項目。
概括起來，Halloway主張，對於小型項目來說，諸如未知因素一類的問題可能會使進度表大幅度改動，而假如找到一個成熟完善的代碼庫則可以使得開發人員幾乎不用編寫多少代碼。在 Java方面，這些因素是很大的一個優勢，因為它背後有一個成熟強大的社區和一群非常有經驗的開發人員所支持。對於大型項目，Halloway則稱，諸如語言的生產效率之類的因素會比代碼庫更為緊要，這也把天平上優勢的砝碼放在了Ruby一端。他指出，目前事實已經發生逆轉，並解釋說：
以下是引用片段：
當前Ruby異常適合的一種小型項目是：由數據庫所支撐的Web應用，因為Ruby on Rails抵消掉了所有Ruby在小型項目方面的不利因素。
誤區之二：Ruby的某某特性使得代碼難以維護
針對這個熟悉誤區，Halloway的結論是：假如使用得當，Ruby的語言特性會使用其編寫的代碼更加易於維護。對於“易於維護的代碼”的概念，他給出以下定義：
1. 理解應用程序或者模塊的總體設計思路
2. 找到你所需要的代碼
3. 閱讀代碼
4. 對代碼進行變更
5. 檢查變更是否正常運行
下面是兩種語言的優勢對比：
理解應用程序或者模塊的總體設計思路：無一勝出
以下是引用片段：
[...]我的經驗表明，在這個方面沒有哪個語言能幫上很多忙，但良好的抽象概念會有所幫助。Java和Ruby包含很多相同的抽象概念：實現繼續、類、多態和封裝等等。
查看你所需要的代碼：Java勝出
由於IDE的有效支持，Java在這個方面勝出。
閱讀代碼：Ruby勝出
結論：Ruby代碼更輕易保持DRY原則，因此更輕易閱讀。
對代碼進行變更：Ruby勝出
結論：在動態語言中進行代碼變更更為輕易。
檢查變更是否正常運行：不相伯仲
Ruby和Java都提供了對單元測試、驗收測試和持續集成等方面的良好支持。
誤區之三：Ruby太難了
有些人，比如Cedric Beust主張說，對於普通開發人員Ruby的難度太大。Halloway反駁到，總的來說，編程就不是一件輕易的事情。盡管有些叢書以“21天學會編程”的旗號為噱頭，但這是不可能的。因此，使用Java和Ruby編程都不是一件輕易的事情。他主張說：
以下是引用片段：
[...]你不能通過限制語言的特性這種方式來降低難度[...]
誤區之四：要抄襲Rails的創意很輕易
Halloway提出，這個誤區需要慎重看待，因為它說的確實有一部分是真的。Rails的許多創意是可以被抄襲到其它任何語言上去的。但是，對於這個觀點的反駁也存在：
以下是引用片段：
[...]另外一些創意則取決於特定的Ruby語言特性。Rails使用了open class，使得我們可以寫出更好的、可讀性更強的對象模型。舉例而言，你可以寫出x.blank？這樣的代碼，而不是這樣：StringUtilities.isBlank(x)。單獨來說，這樣的區別並不會產生很大的意義，但是隨著它們積少成多了以後，代碼的可讀性就會得到顯著的提升。[...]
誤區之五：這是一場沒有贏家的游戲
最後是系列文章的總結陳詞：作為一門語言，Ruby勝出;但作為一個平台，Java勝出——
以下是引用片段：
那麼，我們所有人難道不能和睦相處麼？我多希望在我所生活的世界中，對語言的偏好並不會給一名程序員貼上什麼標簽。我們可以用Ruby、Scheme、Scala或者Erlang來編寫代碼，而且任何地方的JVM都是我們所可以生存的和諧社會。
為了讓這樣的和諧氛圍得以延續，Halloway對應當采取的行動給出了以下建議：為JRuby項目貢獻代碼，並在今後的Java應用中使用Rake而不是Ant來治理。
