2010-08-11 16:22 | 3587次閱讀 | 【已有11條評論】發表評論 來源：51CTO | 收藏到我的網摘 Groovy創始人James Strachan前日在其部落格（地址在Blogspot，未架好梯子前請勿隨便點選）上發表了一篇文章，題目為《Scala as the long term replacement for java/javac? 》。以下是正文部分的翻譯： 不要誤解我的意思——我在過去的這十來年裡寫了無數的Java程式碼，並且堅信它相對C++和Smalltalk來說是一個巨大的進步（當然，很多其它語言也很有幫助，像JavaScript，Ruby，Groovy，Python等）。但是我還是一直期待著能有javac的替代者出現。我甚至還自創了一門語言（編者注：此處指Groovy）好讓我暫時滿足一下這種期望。 Java是一種令人驚歎的複雜語言（它的語法規範長達600頁，我懷疑到底有沒有人能真正理解它），它有自動裝箱(Autoboxing)，空指標異常(NPE)往往就是這時丟擲的。其中的基本型別(primitive type)，字串/文字/緩衝器/集合類(collections)以及陣列缺乏多型性，以至於處理任何資料結構都需要冗長的語法；而且，由於Bean 屬性和對閉包支援的缺失（甚至在JDK 7裡也仍然還不支援），這會讓你的程式碼裡充滿了 try/catch/finally 這些語句（除非你使用框架和新的自定義API）。除了這些還有好多數不清的麻煩問題。Java倒是有型別推斷（type inference）功能但卻不用，使得我們要多輸/讀如此大量的程式碼。 這個問題在沒有Java7後變得更加緊迫 （在Snorcle之後它變得更加重要：我不知道javac是不是要被jdkc 取而代之了？）。所以我猜javac可能已經走到了盡頭，它看起來根本就沒有什麼進展或簡化了。 那麼，從長久來看，誰能取代javac 呢？當然，像Ruby，Groovy，Python，還有JavaScript這些動態語言在過去幾年裡很受歡迎——很多人喜歡他們。 我認為將來可能替代javac的就是Scala 。它實在太讓我印象深刻了。我甚至可以誠實地說，如果有人在2003年把Martin Odersky，Lex Spoon以及Bill Venners寫的那本《Programming in Scala》拿給我看了的話，那我根本就不會再去發明Groovy了。 那麼，為什麼我會看好Scala呢？Scala是靜態型別的，它可以被編譯成與Java同樣快速的位元組碼，所以它的速度與Java不分上下（有時快一點，有時慢一點）。你可以看看 Scala 在與 groovy 或jruby一起進行測試時表現有多好。注意：速度並不是我們追求的唯一目標——有時候我們可能寧肯讓程式碼慢上十倍，也要寫得簡潔一點；但是如果要取代 javac，速度當然還是很重要的。 Scala已有型別推理(type inference)功能，因此它和Ruby/Groovy一樣簡潔，但是它完全是靜態型別的。這是很有好處的，它使得理解程式碼、閱讀程式碼以及編寫文件都簡單多了。在任何片段(token)/方法/符號上點選，你都可以跳轉到相應的程式碼或文件中去瀏覽。不需要打那些怪異的補丁，也不用操心誰什麼時候新增了一個方法——這對於那些需要一個團隊一起長期開發的大專案是很有好處的。Scala似乎已經實現了動態語言(dynamic language)的那種簡潔，而實際上它是完全靜態型別的。所以，我根本不需要去記哪些魔術方法可用——或是在shell裡執行指令碼來檢視這些物件—— IDE/編譯器在你編輯程式碼時就已經知道這些了。 Scala已經提供了對高階函式和閉包的支援，另外還支援序列解析（sequence comprehensions) ，這樣你就可以很容易用Scala寫出漂亮簡潔的程式碼。Scala還把函式式和麵向物件的程式設計思想很好地統一到了一種語言裡，它比Java要明顯簡單一些（雖然它的型別體系(type system)和泛型(generics)需要花費差不同一個數量級的時間去理解，但是，它通常是框架開發者才需要考慮的問題，應用程式開發人員並不需要涉及）。它也使得從傳統的面向物件/Java程式設計模式向函數語言程式設計的轉變變得更加容易——這對於編寫並行或非同步程式的開發人員尤其意義重大（這是因為現在晶片的主頻已經達到了數個GHz，很難再有提升了；而晶片整合的核心數則在快速增長。51CTO之前曾釋出過哪種語言將統治多核時代 再看函式式語言特性一文，對於函式式語言在多核時代的潛力做了相當深入的分析）。你可以在最開始用面向物件的方法程式設計，然後當你需要它的好處時，就可以遷移到用不變狀態(immutable state)函數語言程式設計正變得越來越重要，因為我們總是希望能把問題變簡單，並且在一個更高的層次上解決它（如閉包，高階函式，模式匹配，單子 (monad)等），同時我們還需要通過不變狀態(immutable state)實現併發和非同步。 Scala也有適當的混入(mixin)（特性(trait)） ，所以你不必去擺弄面向物件程式設計的缺陷來獲得模組化的程式碼。如果你確實需要一些鴨子型別(duck typing)，Scala甚至能為你提供構造型別(structural type)。 最讓我印象深刻的一點就是它的核心語法極其精練簡潔（它的語法手冊只有大概Java的四分之一），但是其方式卻更加強大和靈活，而且非常容易通過庫來擴充套件，新增新的語義和功能。可以看看這個例子：Scala Actors。因此它非常適合用於建立嵌入式DSL或外部DSL 。有了它以後就真沒必要再用Java，XPath ，XSLT，XQuery，JSP，JSTL，EL和SQL這些東西了——你可以在各種各樣的場合使用DSL。 Scala確實需要花點時間去習慣——我承認第一次我看Scala時並不覺得順眼——用了Java之後你就會習慣用一堆冗長的程式碼來做一點點事，剛開始時我們也都不會一看到幾個符號就覺得有多驚訝。（我花了好長一段時間才習慣Scala裡用_作“萬用字元”，因為在Scala裡是用作識別符號/方法）。 如果你一直在寫Java，那麼最開始確實會覺得Scala很不一樣（如在宣告方法/變數/引數時在型別或識別符號上加上階，雖然那樣做的原因是為了能更方便地略去一多餘的型別資訊）。 例如，在Java中的寫法： List< String> list = new ArrayList< String>() 在Scala中的寫法： val list = new List[String] 或者，如果你要指定確切的型別的話： val list : List[String] = new List[String] 但是如果你堅持用上一段時間，Scala優美的一在很快就顯現出來。它對Java裡的許多地方進行了簡化，讓你可以用非常簡潔的程式碼就描述出意圖，而不用花上大段程式碼去實現細節——同時還為你提供了一條遷移到函數語言程式設計的不錯途徑，這對於編寫併發和分散式程式是非常有利的。 我強烈建議你學習一下Scala：以開放的心態看看（當你的思維轉過來後）你是否能發現它的美麗之處。 一些Scala資料的連結和線上演示文件 > 我強烈推薦由 Martin Odersky，Lex Spoon 和 Bill Venners編寫的《Programming in Scala》 一書。它非常好地介紹了Scala的特點以及設計時的選擇。這本書相當厚，但是你可以先跳著讀，必要時再深入細節。 > 《O'Reilly Scala book》這本書我只跳著讀了一點，但是看起來也非常不錯。 > 如果你想在短時間內就知道個大概語法，那麼可以看看《Tour of Scala》。不過看了之後你也還得花上一些時間來真正理解為什麼它跟Java會有這樣那樣的不同。 > Martin Odersky 的JavaOne 2008上關於Scala的演說 >Jonas Bonér在Real-World Scala上作的報告 > Gert's的關於他如何建立 Apache Camel DSL for Scala 的介紹 > 用於JDBC型別安全查詢的一個Scala版LINQ，順便再瞭解下DBC。 > 一份非常不錯的報告，介紹了把Scala 和OSGi 與DSL結合使用 > 如何使用Scala和XML （ 語言裡已經自帶了處理XML，XPath ， XSLT， XQuery的簡潔語法） > Scala的例子 > Scala快速參考表 > 這個例子顯示瞭如何建立的bean風格的屬性（或C ＃風格的getter函式） > 建立一個用Lift實現的聊天演示程式或檢視Lift網站上的更詳細介紹 如果你還有一些空餘時間的話，這些視訊資料也非常不錯 > Bill Venners所發表的The Feel of Scala > Lex Spoon所作的Scala： 把未來的語言帶到JVM裡來 好用的Scala框架和庫 > liftweb ：Scala的rails > 語言規範和ScalaTest for BDD 以及其它一些入門測試(literate testing)能讓你體會到型別安全的DSL對於編寫IDE友好 的簡潔程式碼有多大幫助。 > scalaz 是一個很有用的例程庫。 > 用HTTP /JSON服務進行排程 另外，順便說一下，對於那些像我一樣一喜歡JAXRS的，現在可以通過jersey-lift模組使用lift模板和Jersey了。 作為這的例項，你可以看看RestMQ，這是一個我最近也參與了的開源專案，它旨在為面向訊息的中介軟體提供REST風格的API和Web控制檯，它也是基於JAXRS（Jersey），Scala，Lift構建的。 至於開發工具方面，有Ant/Maven外掛，它帶有一個互動式Scala控制檯（REPL）和一個用於IDEA的IDE外掛，還有 Eclipse，NetBeans，以及TextMate，Emacs這些通用編輯器，都可以供你選擇。在IDE外掛的豐富程度上與Java還是有差距的，但是這些工具所提供的程式碼導航和自動補全功能還是很有用的。 我試用過NetBeans，Eclipse和IDEA這幾個IDE上的外掛，它們都各有優劣。看起來，Scala的追隨者也因為這些工具分裂成了幾派。如果要程式碼導航和自動補全，那我發現IDEA非常不錯。當你開啟一個Maven pom.xml，它好像就能非常好地自動解析程式碼，找出Scala源，那樣你就能很方便地在任意的型別/方法以及它們對應的文件/原始碼中跳轉瀏覽。（通常你必須在執行/除錯任務裡手動新增Scala）。不過IDEA在錯誤程式碼高亮上並不是最好的。在作上一些彌補後，它們都能變得與對應的Java工具一樣好用。試試這幾個工具吧，找出你最習慣的那個。 Scala Nit 任何一種語言都有你喜歡的一面，也有你不是那麼熱衷的一面。Scala給你的最初印象可能確實是符號太多了點，但是你並不需要使用所有的這些符號 ——如果你喜歡的話，你可以繼續沿用很多Java裡的東西。但我想到了那個時候最好還是用符號來實現“特殊任務”以避免識別符號衝突。 我對巢狀的引入宣告不太感冒，使用_root_.java.util..List來把一個”全域性“引入和相對引入區別開來。我還更願意使用子引入。例如，如果你引入了com.acme.cheese.model.Foo，然後，為了引入model.impl.FooImpl，我就更喜歡用一個明確的相對字首，就像：import _.impl.FooImpl。這對簡化任務有一些好處，對於保持和Scala的簡潔性就更有幫助了。 然而，和Java裡大把的毛病相比，再考慮到Scala的優美，簡潔和強大，Scala的這一些負面因素和根本不算什麼了。 結語： 既然 MrJava（Adam Bien），MrJRuby（Charles Nutter） 和 MrGroovy（作者本人） 都認為Scala將會是javac的的替代者，那肯定是有些原因的。那你還在等什麼呢？趕快去買《Programming in Scala》 或 《O'Reilly Scala book》一探究竟吧！ 這篇博文釋出後，立刻有很多Scala，Groovy和Java開發者進行了回覆。Scala的創始人Martin Odersky也對這篇文章發表了自己的讚賞之詞。以下是Martin的留言： James，感謝你的認可！這對我來說意義重大。我相信，如果我們一起努力向Java開發者們展示現在在JVM上更加美好的語言選擇，我們大家都會因此而得到好處。感謝你在這方面帶了個好頭。 根據我對Groovy的瞭解（很可惜的，我的瞭解沒有你瞭解Scala那樣多），它看起來並非是意圖填補同一塊領域的。Groovy的吸引力在於它是一個語法接近Java的動態指令碼語言。Scala的吸引力在於它是一個強型別的，靜態的，結合函式式和麵向物件的語言。 此外還有很多精彩的評論，51CTO譯者對這些評論進行了一些篩選，挑出部分翻譯如下： Scala的體驗 去年，我在做一些調查專案時把Scala引進到了我的小Java車間裡。 如今Scala成為了我們最主要的程式語言。 通過使用Scala，我們現在可以構建型別系統(type system)，跟蹤總結以前所做專案的經驗教訓，並用它來替代我們過去以模型為導向(model-driven)的開發方式。然後，我們利用函式分發 (pass around functions)的特性來改進元件的引數化。 總之，對於建立可重用的元件，Scala提供了一套比Java更好的機制。 C#和Java？ 我覺得你可以去看看C#。它解決了你在Java中遇到的許多問題。如果你不喜歡微軟的話，就可以試試.NET的開源替代版本Mono。 有關Scala和F# 其實，在.NET平臺裡與Scala對應的語言並不是C#，而是F#。不管什麼時候，我都更傾向於使用Scala，而不是F#，原因如下： 1 ）在F#文化裡，面向物件看起來並不重要。在所有講F#的書裡，都必定有一章介紹類，然後，剩餘部分就是專門講解函式式。相比之下，Odersky在發明 Scala時，並沒有照搬Java的這一套機制，而是通過物件型別、特性(trait）、增強的可見性規則(visibility rule)等概念擴充套件並超過了Java的這一套機制。Scala使得像我這樣有根深蒂固面向物件思想的開發人員覺得很舒適，它提供的函式式語法特性讓我可以用來把程式碼變得非常簡潔。 2 ）F#比Scala看起來更接近人類語言，初看起來這似乎是好事。不幸的是，由於開發者很少需要寫型別說明(type annotation)，大部分程式碼裡也都沒寫，這就使得程式碼變得更加難於理解。在Scala裡，至少要宣告引數型別，而且最好也宣告一個方法的返回型別，除了那些一目瞭然的情況。 3 ）F#一直力求儘量往OCAML的語法靠攏，所以它在語法也真是沒有什麼創新之處。而Scala則是博取眾長，吸納了各種語言的優點。此外，它還讓人感覺有些機制並不是必須的，而是為了讓開發者更好地表達意圖而加入的。通過加入隱式轉換(implicit conversion)，析取器(extractor)這些功能，Martin從我這裡得到了很大的幫助。 4 ）在我看來，Java程式設計師學會Scala比從C#到F#的過渡要容易得多。大體上來說，原因是Java程式設計師不需要花很大的代價入門，Scala可以直接被當作一門少了些模板(boilerplate)的Java使用。當程式設計師漸漸熟練後，他就可以開始發掘函數語言程式設計的威力了。在其它任何的面向物件/函數語言程式設計語言裡我都找不出可以這樣過渡學習的。 Groovy蓋棺定論了？ James，我一直在留意你的部落格，這篇文章寫得棒極了，堪稱高超。你發過一份宣告說不會再繼續把Groovy開發得更強大了（51CTO編者注：James Strachan在寫這篇博文之前很久已經離開了Groovy開發團隊），這份宣告影響力很大，而且幾乎可以說是給Groovy蓋棺定論了。 我們有一個面向終端使用者的資料處理軟體，然後我們選擇的是Groovy （而沒用Jython和JRuby ）來作為實現各種功能擴充套件（從對變數編寫公式到編寫指令碼）的途徑。你們在開發Groovy所寫的程式碼很多都是粘合程式碼(glue code)(對核心語言起補充作用）。我們充分利用Groovy所支援的這些特性與MS Office產品和Web服務進行整合。我真的希望，如果你們的開發團隊更中意Scala的話，也請儘量讓我們到時候在Scala裡也能用上這些有用的庫。 James Strachan對上文的回覆 我不認為任何一種主要的JVM語言會消失，肯定會一直有一大幫人繼續維護Groovy, Jruby, Cojure, Jython, Rhino等。 JVM中最大的一點好處就是這些語言很容易共存，重用另一種語言的程式碼也非常容易。因此，只要相信大眾的選擇，就不用擔心會選錯開發語言。 而且我也並不認為Scala會是Ruby/Groovy/Fan這些動態語言的替代者；大多數情況下效能還是很重要的。對於一個快速、靜態型別的編譯器來說，過去Java顯然是第一選擇——但是現在，Scala才是首選——這是因為Java已經顯出老態了。（它可能永遠也不會支援閉包，永遠也不會考慮支援型別推斷等新特性）。 自從發現了型別推斷的威力之後，我實際上越來越覺得動態型別(就是很簡潔的程式碼實現功能）的動機變得越來越難以琢磨了。比如說，你可以用Scala 寫一些指令碼，它就會像Ruby/Groovy一樣進入”讀取-執行-列印 迴圈“(Read-Evaluate-Print Loop, REPL)。 但是我發這篇文章的目的並不是要挑起Scala擁護者和Ruby/Grovy/Clojure/JavaScript這些動態語言支持者之間的戰爭 ——我只是想讓被Java一葉障目的開發者們意識到，這個世上已經有了比Java更好的靜態型別語言：這門語言有他們所想要的全部功能（還附帶有Java 最需要增強的功能）。所有這一切，都能在這門語言裡用簡潔、優美的程式碼表示出來（儘管這門語言和Java確定有些不太一樣，並且需要你經歷一個學習曲線）。 附錄：有關Scala程式語言的其他言論 > Java的不足可以比作大量的毛疣，那麼同樣在Scala中，這些地方正是表現了Scala的美、簡化和強大。——James Strachan > 在一個社群（java.net booth）舉辦的和James Gosling對話會議上，一個與會者問了一個非常有意思的問題：“除了Java，現在你會把哪種語言運行於JVM之上？”。答案是驚人地快速簡潔：Scala。——Java之父James Gosling > 我必須說Scala看起來是是現在Java王座的繼承人。其他在JVM的語言看起來不可能有Scala那樣的能力來取代Java，Scala背後的推動力是無可置疑的。Scala還不是一個動態語言，但是它有許多流行動態語言的特性，例如它的靈活富型別系統，稀疏和簡潔的語法，函式式語言和麵向物件正規化的完美結合。Scala的缺點：“太複雜”或者“太豐富”，但這些可以通過編碼規範很好避免，從而構建更健壯的編輯器和工具，以及指導多語言開發者明白如何更好地使用Scala。Scala是JVM上靜態語言的重生，它也像JRuby那樣延伸平臺的效能，這些都是Java做不到的。——JRuby核心開發者 Charles Nutter 【CSDN小百科】 James Strachan James Strachan，Groovy創始人，是Apache ActiveMQ、Apache Camel、Apache ServiceMix等開源專案創始人之一。現工作於FuseSource。 原文連結：http://developer.51cto.com/art/200907/134785.htm