Martin Odersky訪談錄所思

ThoughtWorks的「TW洞見」在4月發布了對Scala之父Martin Odersky的訪談。Odersky的回答顯得言簡意赅，仔細分析，仍然能從中收獲不少隱含的信息（雖然可能是負面的信息）。

提問的中心主要是語言之爭。Scala是壹門極具吸引力的語言，似乎天生具備壹種氣質，輕易能夠吸粉，但招黑的能力也不遑多讓。它似乎是從象牙塔裏鑽研出來的，但又在許多大型項目和産品中得到了實踐。有人轉向了她，又有人之後背棄了它。如果說Ruby的助力是Rails，那麽推動著Scala在社區中成長的，其實到處可見Spark的影子。

然而，壹個尴尬的現狀是，Spark的許多源代碼並沒有遵循Scala推崇的最佳實踐。Odersky對此的解釋是：

Spark的API設計是和Scala 集合類設計是壹致的函數式風格，裏面具體的實現爲了追求性能用了命令式，妳可以看到Scala集合裏面的實現函數爲了性能也用了很多var。

這或許是Scala采用多範式的主要原因吧。雖然Scala借鑒了不少函數式語言的特性，例如Schema和Haskell，但Scala並沒有強制我們在編寫代碼時嚴格遵守FP的原則。我們需要在OO與FP之間畫壹條線。在代碼的細節層面，Scala要求我們盡力編寫沒有副作用（引用透明），提供組合子抽象的函數式風格代碼；然而在壹些場景下，又允許我們讓位于OO的統治。

Scala屬于語言中的“騎牆派”，只要妳足夠高明，就能夠在OO與FP中跳轉如意，怡然自得，如魚得水。所謂“騎牆”，反倒成了具有超強適應能力的“左右逢源”，何樂而不爲？

Odersky在訪談中推薦了Databricks給出的Scala編碼規範，還有lihaoyi的文章Strategic Scala Style: Principle of Least Power。

如果我們閱讀Databricks給出的編碼規範，會發現Databricks爲了性能考慮，更傾向于采用命令式方式去使用Scala，例如，規範建議使用while循環，而非for循環或者其他函數轉換（map、foreach）。



然而就我個人的習慣，更傾向于前者（使用zipWithIndex結合map），它采用更加簡潔的函數式風格。魚與熊掌，不可兼得！這是壹個問題！

規範從可讀性角度考慮，不建議使用Monadic Chaining。例如，下面的代碼使用連續兩個flatMap：



规范建议，改写为更具有可读性的方式：



雖然利用模式匹配（Pattern Match）確實是很好的Scala實踐，但就這個例子而言，其實Monadic Chaining的方式可以用for comprehension來改寫。非常簡潔，可讀性極佳：



那麽，這樣的規範是否是好的Scala實踐呢？Odersky用“保守”壹詞來評價這壹規範，不知其本意如何？

lihaoyi的文章Strategic Scala Style: Principle of Least Power不是壹個規範，而是壹份Scala最佳實踐。內容包括對不變性與可變性、接口設計、數據類型、異常處理、異步、依賴注入的分析與建議。值得壹讀。

Martin Odersky言簡意赅地給出了兩個編寫Scala代碼的原則：

盡量用能力弱的功能；

給中間步驟命名。

對于第壹點，我個人的理解是在使用Scala特性的時候，要注意克制，不要去玩弄Scala語法中那些奇技淫巧，從而讓代碼變得晦澀難懂。Twitter的部分工程師之所以對scala抱有怨言，多數吐槽點就是在代碼的可讀性與維護性方面。

第二點同樣是爲了解決此問題。Twitter的文檔Effective Scala用例子闡釋了爲中間步驟命名的重要性。如下例子：



这样的代码虽然简洁，却不能好好地体现作者的意图。如果恰当地给与中间步骤命名，意义就更加清楚了。



Odersky在訪談中談到了壹些對未來Scala的規劃，包括Tasty與Dotty，前者是爲了解決Scala二進制不兼容問題，Dotty則是爲Scala提供新的編譯器。然而，Odersky的回答令人黯然，二者的真正推出還需要等待幾年時間。

幾年時間啊！再過幾年，Scala會否成爲明日黃花呢？至少Java的進化趨勢已經開始威脅Scala了。而JVM的演進是否又會進壹步爲Scala的演進造成障礙呢？如果還要考慮版本兼容問題，Scala的未來版本境遇堪憂啊。想想我都爲Odersky感到頭痛呢。

可是Scala又不能離開JVM，否則Scala與Java兼容帶來的福利就蕩然無存了。龐大的Java社區壹直是Scala可以汲取的資源呢。Scala會否成也JVM，敗也JVM呢？

坦白說，這個訪談沒有提供太多Scala的營養（不知是否翻譯的問題），總覺得Odersky在面對某些有關語言的尖銳問題時，顯得閃爍其詞。雖然Odersky搬出了沃爾沃美國、高盛、摩根斯坦利來壓陣，卻反給我底氣不足的感覺。Scala不好的部分還是太多了，它會妨礙我們對Scala做出正確地判斷。Scala待解決的問題仍然太多了，lightbend任重而道遠。歸根結底，從壹開始，Odersky沒有對Scala特性做出具有控制力的規劃，缺乏收斂，導致許多feature良秀不齊，敗壞了Scala的名聲。

還好有壹個Spark，是Spark拯救了Scala。可惜，Spark的編碼規範卻不具備Scala範兒。

由于附件上传及字数限制，部分图片、内容无法显示，全文详情请见：

http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000360&idx=4&sn=9f77611fe9f4e780cc580a15c9b7474c#rd

欢迎大家一起交流。

扫描以下二维码，获取更多更精美文章！(扫码关注有意向不到的惊喜的哦！！）



关注我们微信订阅号（ uniguytech100） 与服务号（uniguytech），获取更多更精美文章！

也欢迎加入【大家技术网讨论QQ群】，群号码：256175955，请备注你个人的介绍！让我们一起聊聊it的那些事！