| 編程思想碰撞 Scala不是改良的Java[2010/8/9] |
| 【字體:大 中 小】【列印】 |
Scala 2.8的發佈又一次帶來Scala和Java區別與聯繫的熱烈討論。Scala編程語言擁有所有Java的語言特徵,而且還支援所有的新興的有趣的概念,例如閉包,higher-kinded類型,內聯XML。如果你要創建一個JVM上的新項目,你是否會考慮使用Scala? Scala編程環境非常的有意思,在2.8版本中,編譯器會為帶有unboxed的基本資料類型的函數編譯出多個版本——這樣泛型函數就免去了性能昂貴的unboxing和boxing操作了。 Scala允許操作符重載,通過它隱含的機制,你甚至能在實例化後的物件裏動態的添加新的方法。 這些功能使你編碼時感到更方便。你基本上不需要再顯式的把陣列和其他的序列類型區分開,不需要把未封裝的double類型和其他數位類型區分開。JVM上的陣列、基本資料類型和其他相關類型的“平常化“在某種程度上減少了使用這些類型的複雜度。 雖然與Scala的第一次親密接觸會讓你感覺到Java如影隨形,但這些理念從根本上與Java之所以成為Java的原因相抵觸。Scala把自己定位為旨在以一種簡潔、優雅的方式表現常見編程模式的多範式編程語言。Java從文化上反對這些理念:Java慎重的簡單。 Java設計團隊研究了“現代”C和C++語言的各個方面後才決定了在現代面向物件編程語言環境中哪些功能特徵應該被取消,同時又要保留C++相類似的語法。 特別的,一個已知的原則,任何事情都必須非常的直接明瞭: C和C++裏一個主要的麻煩是,你需要在大量的語境中去理解他人的代碼:在理解一段程式之前,你必須閱讀所有相關的頭檔,所有相關的#defines, 所有相關的typedefs。本質上,使用#defines和typedefs編程會導致每個程式師都像是在發明一種新編程語言,只有開發的人自己能理 解,這種情況不符合好的編程過程的設計目標。 這種對好的編程過程的理念正是Scala極力反對的。在核心中集成領域特定語言(domain specific languages)的能力被Scala當作一種積極因素被提倡。 按我的觀點,判斷好的編程過程的依據應該考慮是否能產生好的結果這個因素。HotJava實驗失敗後,我們應該承認,所有的三種主要的web瀏 覽器(Mozilla Gecko, Webkit, 和 Internet Explorer)都是用C++寫成的,這是人們根據結果來選擇編程語言的行為,而不是根據了一種習慣經驗。 Java被認為是從小語言慢慢長壯大的,是一種從Lisp和Smalltalk之類的語言獲取了積累經驗的果實。 Scala自豪於擁有強大的higher-kinded類型,Java自豪於去除了多重繼承。它們更本不是相互的競爭者:它們的文化取向差異巨大。 在《Java,正在老去的王者》一文中,我們分析Java的未來在於JVM語言的繁盛和興起,也許Scala可以推動JVM跟其他的平臺進行競爭。它有一些好的Web公司支持它(例如Fourquare),作為一種具有強類型校驗的面向物件的腳步語言,它是很稱職的。 Java是有意設計成非面向程式師的。這就是Java的特點——它是專門被設計成防止那些有問題的程式師給自己製造麻煩。如果你討厭JVM,我想問題應該是:多少防護措施對你的程式師是合適的?Scala給出的答案本質上和Java是相反。 |








