白話scala系列三 Scala程式設計難點解析
一直想找一篇關於scala和其他語言相比難點分析的文章,今天終於找到一篇,雖然有點囉嗦,但仔細閱讀後還是會有所體會。
原文連結:http://www.blogjava.net/hechi158/archive/2012/02/28/370902.html
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中卻不是這樣,各種風格迥異,每個開發團隊裡都不相同。