Groovy創始人：Java面臨終結 Scala將取而代之
原創Groovy創始人James Strachan前日在其博客（地址在Blogspot，未架好梯子前請勿隨便點擊）上發表了一篇文章，題目為《Scala將取代Java /javac？》。以下是正文部分的翻譯：
【51CTO獨家譯文】不要誤解我的意思——我在過去的這十來年里寫了無數的Java代碼，并且堅信它相對C++和Smalltalk來說是一個巨大的進步（當然，很多其它語言也很有幫助，像JavaScript，Ruby，Groovy，Python等）。但是我還是一直期待著能有javac的替代者出現。我甚至還自創了一門語言（51CTO編者注：此處指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：以開放的心態看看（當你的思維轉過來后）你是否能發現它的美麗之處。
#p#
一些Scala資料的鏈接和在線演示文檔
51CTO編輯推薦：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的簡潔語法）
◆這個例子顯示了如何 創建的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 是一個很有用的例程庫。
另外，順便說一下，對于那些像我一樣一喜歡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》一探究竟吧！
#p#
這篇博文發布后，立刻有很多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
【相關閱讀】
