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

創(chuàng)新互聯(lián)自2013年創(chuàng)立以來,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項目網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元東山做網(wǎng)站,已為上家服務(wù),為東山各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108
首先要說的是,我是一個Scala粉絲,我作為一個Scala語言的倡導(dǎo)者差不多有5年歷史了。我寫了不少Scala語言方面的書和文章。我曾在數(shù)十個公司里做過Scala和Lift框架項目的開發(fā)。我對很多的Scala項目進行過代碼審查。
我過去以為Scala很簡單。它過去確實很簡單,而且一直很簡單,它是治療Java里很多問題的良方。從“有些使用Java顯的異常的困難或不可能的事,使用Scala卻非常容易”的角度,Scala是一種非常簡單的語言。Scala處理集合問題超級的容易。業(yè)務(wù)邏輯的相互獨立會使程序變得更容易維護,Scala相對Java來說更方便達到這樣的目標(biāo)。
推薦專題:Scala編程語言
那么,Scala難在哪里?下面是我能想出的最主要的幾條:
◆ Scala想要的東西太多。你可以拿Scala像Java那樣編程。這是一種福氣,也是一種詛咒,但我從長遠的角度看,更多的是一種詛咒。關(guān)于它的面向?qū)ο髒s 面向函數(shù)的爭議太多。對于小的開發(fā)團隊,這些爭議和你所采取的選擇關(guān)系不大,但當(dāng)你的團隊有相當(dāng)?shù)娜藬?shù),你試圖教會這些Java程序員使用Scala,而他們又非真心的想學(xué)時,這成了相當(dāng)討厭的事。Scala語言的巨大優(yōu)勢會在你使用函數(shù)式編程時不言自明的顯露出來,但如果你只把自己當(dāng)成面向?qū)ο蟮某绦騿T,它的優(yōu)勢你是不可能看到的。對于這種情況,較少功能特征/可選性的語言(例如Java或Ruby)就顯得容易些。你不用費腦筋去做出選擇。
◆ 集成開發(fā)工具對它的支持很弱,而且以后也不會改善。Scala的Eclipse插件很差勁。從此我開始使用Scala語言五年來一直很差勁,它總是讓人感覺“可以做的更好”,但卻一直這樣差勁。IntelliJ對Scala的支持還湊合。但在IDE里需要使用各種模式的人會找不到一個好用的。Scala的模式各式各樣又互不關(guān)聯(lián),如果你不討厭使用Emacs或Vi或TextMate編程,那使用IntelliJ開發(fā)Scala是個不錯的選擇。如果你期待著一個像Java IDE那樣的東西,你找不到,而且永遠找不到,因為Scala的強大能力是不能通過簡單的模板表現(xiàn)出來的,你需要提供太多的信息資源給IDE,它里面的類型安全(TypeSafe)檢查的復(fù)雜,即使你銀行里有3百萬美元,也沒有公司敢出來擔(dān)保。
◆ Scala的類型系統(tǒng)異常的強大,但它卻讓你茫然不知所措。在ScalaDocs里,類型符號復(fù)雜的讓人恐怖??粗鴉latMap [B, That] (f: (A) ? Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That,是不是會讓你有想逃的感覺?這是一個初學(xué)者每天都會用,一天用20次的方法,很恐怖吧。Scala的文檔須要一種調(diào)整來隱藏它的復(fù)雜度,讓人們在實際使用中更容易的獲取這flatMap的強大能力。類型系統(tǒng)以及相關(guān)的文檔需要一種更簡化的形式,把復(fù)雜性隱藏在程序包內(nèi),對最終用戶要表現(xiàn)出簡單的接口。(Adobe架構(gòu)師談Scala:功能強大但令人困惑)
◆ 當(dāng)新程序員來維護老程序員寫的Scala代碼時,需要去理解代碼中的風(fēng)格和模式。Scala的代碼會使業(yè)務(wù)邏輯直接表現(xiàn)在最外層(而不是循環(huán)語句或復(fù)雜IF語句四處分布),如果代碼中存在風(fēng)格習(xí)慣,業(yè)務(wù)邏輯就不是那么直接。沒有風(fēng)格也是個問題,但最終,整個團隊需要統(tǒng)一接受這樣的風(fēng)格模式。在Ruby和Rails編程中也是這樣,hashmap替代了所有其它種的編程方法。但在Rails里,風(fēng)格是統(tǒng)一的(盡管沒有類型檢查),人們很容易理解,因為它就是這種“方式”。在Java里,代碼模板由IDE生成,程序員養(yǎng)成了很容易發(fā)現(xiàn)其中的模式的能力。但在Scala中卻不是這樣,各種風(fēng)格迥異,每個開發(fā)團隊里都不相同。
我知道有很多的開發(fā)團隊,在他們的團隊組織形式里,采用Scala語言會比使用Java或Ruby或其它語言要合適的多,Twitter公司就是這樣的一個典型例子。他們需要一個簡潔的,具有類型檢查的,高性能的語言和運行環(huán)境。Scala滿足了他們的這些需求。Foursquare公司以Scala的難度作為一種過濾制度。你只有學(xué)好了Scala語言才能在這個公司立足。
但如果你的團隊的技術(shù)水平很一般,Scala也許對你們公司來說并不是一個好的選項。Scala的難度導(dǎo)致很陡的學(xué)習(xí)曲線,會遭到原有的程序員的反對,形成不了統(tǒng)一的風(fēng)格。你需要一個強有力的CTO或架構(gòu)師來強迫這種風(fēng)格,而不是讓他們自己從書中學(xué)習(xí)。
那么,如何能看出Scala在你們的團隊中會是很“簡單”還是很“難”呢?
◆ 如果你的公司在JavaOne大會,或OSCON,Strangle Loop,或QCon大會上有出席發(fā)言的人:Scala對于你們來說會很簡單
◆ 如果吃飯時間你們還在討論如何從一個普通程序員成長成高級程序員:Scala對你們來說會很難
◆ 如果需要的話,你可以用NotePad編程:容易
◆ 當(dāng)看到”Zed Shaw”時,你的程序員面無表情或連說3聲“萬福瑪利亞!”:Scala==難
◆ 程序員在Twitter上關(guān)注Dean Wampler:Scala 簡單
◆ 你的程序員9:15到公司,晚上不看有沒有郵件:難
現(xiàn)在你們知道了。我完全同意這樣的觀點:對于水平一般的團隊,Scala很難。并不是它本身很難,而是因為它在水平一般的團隊中不會產(chǎn)生那種由技術(shù)很好的人組成的團隊中產(chǎn)生的短期或長期的益處。
一些評論:
◆ 不錯,Scala的類型系統(tǒng)很強大,由它產(chǎn)生了很多優(yōu)美的程序代碼,例如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,從一個語言設(shè)計者/程序庫創(chuàng)造者的角度,和從一個普通程序員的角度,他們的需求是不同的。我個人認(rèn)為,在開發(fā)Lift框架時,我認(rèn)為沒有第二種語言能像強大的Scala語言那樣讓我準(zhǔn)確的表達。所以,作為一個程序庫的開發(fā)者,我喜歡Scala語言。我還慢慢認(rèn)識到,Lift框架對于一般程序員來說似乎太難。作為一個懂得類型標(biāo)記(signature)的程序庫使用者,我喜歡Scala。但我不是一個普通水平的程序員,大多數(shù)并不認(rèn)為Scala很難的程序員都不是普通水平。
◆ 不錯,改進ScalaDocs,讓它有“簡單”視角和“架構(gòu)”視角,這將帶來巨大好處。但這些只是個開始,遠沒有結(jié)束。
◆ 我明確的反對“那好,我們找更好的程序員”的做法。我們可以通過提高我們的程序員的水平來解決“Scala很難”的問題。但這不是問題的癥結(jié)。癥結(jié)在于,Scala并不夠足夠的好,沒有能力迫使在培訓(xùn)、教育、招聘領(lǐng)域產(chǎn)生變革,迫使廣大的一般水平的程序員提高技術(shù)來適應(yīng)Scala的難度。
◆ 我并不懷疑閱讀這篇文章或看我的Twitter的人都是很有水平的程序員,Paul Snively,你水平這么高,Scala對你來說是小兒科了。
轉(zhuǎn)載自:http://www.aqee.net/
文章題目:Scala難在哪里?
當(dāng)前路徑:http://www.dlmjj.cn/article/djhdosp.html


咨詢
建站咨詢
