Halloway 深度剖析 Ruby vs Java 五大迷思：語言生產力與平台生態的權衡

Relevance 顧問公司的 Stuart Halloway 最近撰寫了一系列關於「Ruby vs. Java 迷思」的部落格文章。這個系列文章的靈感，源自他最近從一個從零起步、沒有先前約束的 Ruby 專案轉回一個成熟完備的 Java 專案後的心得體會。Halloway 對以下五個「迷思」進行了探索：

迷思一：Ruby 適合小型專案，而 Java 更適用於大型、複雜的專案

Halloway 主張，對於小型專案來說，未知因素一類的問題可能會使進度表大幅度改動，而如果找到一個成熟完善的程式碼庫則可以使得開發人員幾乎不用編寫多少程式碼。在 Java 方面，這些因素是很大的一個優勢。對於大型專案，Halloway 則稱，語言的生產效率之類的因素會比程式碼庫更為緊要，這也把天平上優勢的砝碼放在了 Ruby 一端。他指出：

當前 Ruby 異常適合的一種小型專案是：由資料庫所支撐的 Web 應用，因為 Ruby on Rails 抵消掉了所有 Ruby 在小型專案方面的不利因素。

迷思二：Ruby 的某某特性使得程式碼難以維護

Halloway 的結論是：如果使用得當，Ruby 的語言特性會使其編寫的程式碼更加易於維護。他給出「易於維護的程式碼」五大定義：理解總體設計、找到需要的程式碼、閱讀程式碼、對程式碼進行變更、檢查變更是否正常運行。兩種語言優勢對比：

• 理解總體設計：無一勝出（良好的抽象概念最關鍵）
• 找到需要的程式碼：Java 勝出（IDE 支援優勢）
• 閱讀程式碼：Ruby 勝出（DRY 原則，程式碼更簡潔）
• 程式碼變更：Ruby 勝出（動態語言修改更容易）
• 檢查變更：不相伯仲（兩者都有優秀測試工具支援）

迷思三：Ruby 太難了

Halloway 反駁：總的來說，程式設計就不是一件容易的事。你不能透過限制語言的特性這種方式來降低難度。

迷思四：要抄襲 Rails 的創意很容易

部分創意確實可以被移植到其他語言，但另一些創意取決於特定的 Ruby 語言特性（如 open class），使得程式碼可讀性顯著提升。

迷思五：這是一場沒有贏家的遊戲

總結：作為一門語言，Ruby 勝出；但作為一個平台，Java 勝出。Halloway 建議：為 JRuby 專案貢獻程式碼，並在未來的 Java 應用中使用 Rake 而不是 Ant 來管理。