Scala難在哪里？
本文是從 Yes, Virginia, Scala is hard 這篇文章翻譯而來。
首先要說的是，我是一個Scala粉絲，我作為一個Scala語言的倡導者差不多有5年歷史了。我寫了不少Scala語言方面的書和文章。我曾在數十個公司里做過Scala和Lift框架項目的開發。我對很多的Scala項目進行過代碼審查。
我過去以為Scala很簡單。它過去確實很簡單，而且一直很簡單，它是治療Java里很多問題的良方。從“有些使用Java顯的異常的困難或不可能的事,使用Scala卻非常容易”的角度，Scala是一種非常簡單的語言。Scala處理集合問題超級的容易。業務邏輯的相互獨立會使程序變得更容易維護，Scala相對Java來說更方便達到這樣的目標。
51CTO推薦專題：Scala編程語言
那么，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的強大能力。類型系統以及相關的文檔需要一種更簡化的形式，把復雜性隱藏在程序包內，對最終用戶要表現出簡單的接口。（Adobe架構師談Scala：功能強大但令人困惑）
◆ 當新程序員來維護老程序員寫的Scala代碼時，需要去理解代碼中的風格和模式。Scala的代碼會使業務邏輯直接表現在最外層(而不是循環語句或復雜IF語句四處分布)，如果代碼中存在風格習慣，業務邏輯就不是那么直接。沒有風格也是個問題，但最終，整個團隊需要統一接受這樣的風格模式。在Ruby和Rails編程中也是這樣，hashmap替代了所有其它種的編程方法。但在Rails里，風格是統一的(盡管沒有類型檢查)，人們很容易理解，因為它就是這種“方式”。在Java里，代碼模板由IDE生成，程序員養成了很容易發現其中的模式的能力。但在Scala中卻不是這樣，各種風格迥異，每個開發團隊里都不相同。
我知道有很多的開發團隊，在他們的團隊組織形式里，采用Scala語言會比使用Java或Ruby或其它語言要合適的多，Twitter公司就是這樣的一個典型例子。他們需要一個簡潔的，具有類型檢查的，高性能的語言和運行環境。Scala滿足了他們的這些需求。Foursquare公司以Scala的難度作為一種過濾制度。你只有學好了Scala語言才能在這個公司立足。
但如果你的團隊的技術水平很一般，Scala也許對你們公司來說并不是一個好的選項。Scala的難度導致很陡的學習曲線，會遭到原有的程序員的反對，形成不了統一的風格。你需要一個強有力的CTO或架構師來強迫這種風格，而不是讓他們自己從書中學習。
那么，如何能看出Scala在你們的團隊中會是很“簡單”還是很“難”呢?
◆ 如果你的公司在JavaOne大會，或OSCON，Strangle Loop，或QCon大會上有出席發言的人：Scala對于你們來說會很簡單
◆ 如果吃飯時間你們還在討論如何從一個普通程序員成長成高級程序員：Scala對你們來說會很難
◆ 如果需要的話，你可以用NotePad編程：容易
◆ 當看到”Zed Shaw”時，你的程序員面無表情或連說3聲“萬福瑪利亞!”：Scala==難
◆ 程序員在Twitter上關注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的難度。
◆ 我并不懷疑閱讀這篇文章或看我的Twitter的人都是很有水平的程序員，Paul Snively，你水平這么高，Scala對你來說是小兒科了。
【編輯推薦】
