Scala很難

本文是從 Yes, Virginia, Scala is hard 這篇文章翻譯而來。

首先要說的是，我是一個 Scala 粉絲，我作為一個 Scala 語言的倡導者差不多有5年歷史了。我寫了不少 Scala 語言方面的書和文章。我曾在數十個公司里做過 Scala 和 Lift 框架項目的開發。我對很多的 Scala 項目進行過代碼審查。

我過去以為 Scala 很簡單。它過去確實很簡單，而且一直很簡單，它是治療 Java 里很多問題的良方。從“有些使用 Java 顯的異常的困難或不可能的事，使用 Scala 卻非常容易”的角度，Scala 是一種非常簡單的語言。Scala 處理集合問題超級的容易。業務邏輯的相互獨立會使程序變得更容易維護，Scala 相對 Java 來說更方便達到這樣的目標。

那么，Scala 難在哪里？下面是我能想出的最主要的幾條：

• Scala 想要的東西太多。你可以拿 Scala 像 Java 那樣編程。這是一種福氣，也是一種詛咒，但我從長遠的角度看，更多的是一種詛咒。關于它的面向對象 vs 面向函數的爭議太多。對于小的開發團隊，這些爭議和你所采取的選擇關系不大，但當你的團隊有相當的人數，你試圖教會這些 Java 程序員使用 Scala，而他們又非真心的想學時，這成了相當討厭的事。Scala 語言的巨大優勢會在你使用函數式編程時不言自明的顯露出來，但如果你只把自己當成面向對象的程序員，它的優勢你是不可能看到的。對于這種情況，較少功能特征/可選性的語言(例如 Java 或 Ruby)就顯得容易些。你不用費腦筋去做出選擇。
• 集成開發工具對它的支持很弱，而且以后也不會改善。Scala 的 Eclipse 插件很差勁。從此我開始使用 Scala 語言五年來一直很差勁，它總是讓人感覺“可以做的更好”，但卻一直這樣差勁。IntelliJ 對 Scala 的支持還湊合。但在 IDE 里需要使用各種模式的人會找不到一個好用的。Scala 的模式各式各樣又互不關聯，如果你不討厭使用 Emacs 或 Vi 或 TextMate 編程，那使用 IntelliJ 開發 Scala 是個不錯的選擇。如果你期待著一個像 Java IDE 那樣的東西，你找不到，而且永遠找不到，因為 Scala 的強大能力是不能通過簡單的模板表現出來的，你需要提供太多的信息資源給 IDE，它里面的類型安全(TypeSafe)檢查的復雜，即使你銀行里有3百萬美元，也沒有公司敢出來擔保。
• Scala 的類型系統異常的強大，但它卻讓你茫然不知所措。在 ScalaDocs 里，類型符號復雜的讓人恐怖。看著flatMap [B, That] (f: (A) ? Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That，是不是會讓你有想逃的感覺？這是一個初學者每天都會用，一天用20次的方法，很恐怖吧。Scala 的文檔須要一種調整來隱藏它的復雜度，讓人們在實際使用中更容易的獲取這 flatMap 的強大能力。類型系統以及相關的文檔需要一種更簡化的形式，把復雜性隱藏在程序包內，對最終用戶要表現出簡單的接口。
• 當新程序員來維護老程序員寫的 Scala 代碼時，需要去理解代碼中的風格和模式。Scala 的代碼會使業務邏輯直接表現在最外層(而不是循環語句或復雜 IF 語句四處分布)，如果代碼中存在風格習慣，業務邏輯就不是那么直接。沒有風格也是個問題，但最終，整個團隊需要統一接受這樣的風格模式。在 Ruby 和 Rails 編程中也是這樣，hashmap 替代了所有其它種的編程方法。但在 Rails 里，風格是統一的(盡管沒有類型檢查)，人們很容易理解，因為它就是這種“方式”。在 Java 里，代碼模板由 IDE 生成，程序員養成了很容易發現其中的模式的能力。但在 Scala 中卻不是這樣，各種風格迥異，每個開發團隊里都不相同。

我知道有很多的開發團隊，在他們的團隊組織形式里，采用 Scala 語言會比使用 Java 或 Ruby 或其它語言要合適的多，推ter 公司就是這樣的一個典型例子。他們需要一個簡潔的，具有類型檢查的，高性能的語言和運行環境。Scala 滿足了他們的這些需求。Foursquare 公司以 Scala 的難度作為一種過濾制度。你只有學好了 Scala 語言才能在這個公司立足。

但如果你的團隊的技術水平很一般，Scala 也許對你們公司來說并不是一個好的選項。Scala 的難度導致很陡的學習曲線，會遭到原有的程序員的反對，形成不了統一的風格。你需要一個強有力的 CTO 或架構師來強迫這種風格，而不是讓他們自己從書中學習。

那么，如何能看出 Scala 在你們的團隊中會是很“簡單”還是很“難”呢？

• 如果你的公司在 JavaOne 大會，或 OSCON，Strangle Loop，或 QCon 大會上有出席發言的人：Scala 對于你們來說會很簡單
• 如果吃飯時間你們還在討論如何從一個普通程序員成長成高級程序員：Scala 對你們來說會很難
• 如果需要的話，你可以用 NotePad 編程：容易
• 當看到”Zed Shaw”時，你的程序員面無表情或連說3聲“萬福瑪利亞！”：Scala==難
• 程序員在 推ter 上關注 Dean Wampler：Scala 簡單
• 你的程序員9：15到公司，晚上不看有沒有郵件：難

現在你們知道了。我完全同意這樣的觀點：對于水平一般的團隊，Scala 很難。并不是它本身很難，而是因為它在水平一般的團隊中不會產生那種由技術很好的人組成的團隊中產生的短期或長期的益處。

一些評論：

• 不錯，Scala 的類型系統很強大，由它產生了很多優美的程序代碼，例如 Scala 的集合。參考 See http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-histo 和 http://www.scala-lang.org/docu/files/collections-api/collections-impl.html。但是，對于 Scala，從一個語言設計者/程序庫創造者的角度，和從一個普通程序員的角度，他們的需求是不同的。我個人認為，在開發 Lift 框架時，我認為沒有第二種語言能像強大的 Scala 語言那樣讓我準確的表達。所以，作為一個程序庫的開發者，我喜歡 Scala 語言。我還慢慢認識到，Lift 框架對于一般程序員來說似乎太難。作為一個懂得類型標記(signature)的程序庫使用者，我喜歡 Scala。但我不是一個普通水平的程序員，大多數并不認為 Scala 很難的程序員都不是普通水平。
• 不錯，改進 ScalaDocs，讓它有“簡單”視角和“架構”視角，這將帶來巨大好處。但這些只是個開始，遠沒有結束。
• 我明確的反對“那好，我們找更好的程序員”的做法。我們可以通過提高我們的程序員的水平來解決“Scala 很難”的問題。但這不是問題的癥結。癥結在于，Scala 并不夠足夠的好，沒有能力迫使在培訓、教育、招聘領域產生變革，迫使廣大的一般水平的程序員提高技術來適應 Scala 的難度。
• 我并不懷疑閱讀這篇文章或看我的 推ter 的人都是很有水平的程序員，Paul Snively，你水平這么高，Scala 對你來說是小兒科了。