經常看到一些文章在談論語言，例如“哪個語言更有前途”，“語言選擇是否關鍵”。我是個語言粉絲，但是看到這些文章總有一些奇怪的感覺。因為在我看來，這些文章談的東西都不是我眼中的語言——可能與國內技術環境有關，語言本身被淡化了，例如，談語言的時候涉及更多的卻是“平臺”方面的內容（例如馮老大的《編程語言的選擇并非無關緊要》）。那么我現在便來描述一下我眼中的“語言”該如何談論吧——下次在我猛砍Java語言時也好有個參考。

語言

語言是給人看的，人們設計出各種各樣的語言，最終會通過某些工具變成機器可以執行的形式。人們設計出語言，是為了進行大規模的程序開發，否則使用機器碼來0110著寫，估計只有神仙才能寫出如今動輒數十萬數百萬行高級語言的項目來——即便是“高手”也得用匯編哪。但可惜的是，如果僅僅使用匯編，估計程序員的思維永遠無法跳出“子過程”這個抽象級別，什么面向對象設計，函數式編程幾乎無從談起。人們在學習和生產過程中會引發一些需求，因而需要產生一些工具來輔助學習和生產，而“語言”便是此類工具之一。只有利用高級語言，人們才能有效地把真實事件抽象成計算機這些機器盒子能認識的東西。

顯然，不同的語言適合不同的領域——尤其是那些所謂的“領域特定語言（Domain Specific Language）”，因為在不同領域中所需要的思考方式可能會不一樣，對于語言來說就有特定的抽象方式與之應對。不過，對于廣大程序員來說接觸到的更多的應該是“通用目的語言（General Purpose Language）”，例如C，C++，Java，C#，Ruby，Python，F#……它們都是通用目的語言。對于這些語言來說，它們是為了解決廣泛問題而存在的。當然，由于通用目的語言的語言特性不同，它們也是有一定“傾向性”的。例如，F#的Workflow特性尤其適合異步編程，而函數式編程語言可能更適合科學計算或金融方面的應用，因為它們和那些問題（業務）的思維方式比較接近——假如使用Java這樣的面向對象語言來說可能就要使用一些奇怪的模式了。

因為語言是用來解決問題的，因此在談論語言的時候，其實我們主要還應該把關注點放在語言抽象或描述事物（包括“思維”等等）的能力上面，以及用它們解決問題的時候是否方便，是否“舒適”——這可能有“感覺”的因素在里面，但的確也有一些客觀的，可以衡量的標準在里面。例如《Concepts of Programming Languages》一書中就提出了以下一些標準：

• 可讀性：讀代碼的次數比寫代碼要多得多，可讀性自然是非常重要的評判標準。例如Perl語言就比Python要難讀的多，可謂是一種著名的Write Only語言。
• 可寫性：例如，使用Fortran 77這種不支持指針和動態內存管理的語言中，實現一個二叉樹結構會很困難。還有，雖然使用while可以實現任何循環需求，但是沒有for語句的語言寫起來便會麻煩不少。此外，表達同樣的邏輯，代碼是否緊湊？如C#或Java等需要相當“架子代碼”的語言，同樣實現面向對象編程就不如F#或Scala來的緊湊。
• 可靠性：語言特性是否易于寫出正確可靠的代碼，如異常處理，靜態/動態類型，強/弱類型都是和可靠性有關的特性。此外，一些腳本語言，如PHP或JavaScript中經常被人詬病可靠性不佳，便是由于一些操作（如相等或相加操作）過于“寬容”，容易出錯。
• 代價：例如，語言規則是否太多？是否自然？學習起來是否容易？

通俗來講，我們考察語言，關注點應該放在它的“語言特性”上。語言特性哪里來？自然是語言制定時定下的，例如Java和C#都有其規約（Specification），其中定制了關于語言的方方面面。但是如Ruby和Python，它們都只有各自的“參考實現”（CPython及MRI），并沒有明確的規約文檔——有人認為這是個比較重要的問題，因此如Ruby社區便開展了RubySpec項目希望定制一個嚴格的Ruby語言規約。

我認為，語言規約（再擴大一點，也僅僅包括其標準庫）是討論語言，比較語言的唯一依據——這也是我在談論語言（如討論Java語言之低劣）的思考準則。

平臺

當然，語言設計的最終目的是讓計算機進行計算，因此我們不可能回避其他方面，僅僅談論語言規約。我這里把除了語言規約外語言實現的其他方面統稱為“平臺”。因此，這個平臺其實包括多種東西，例如：

• 將程序文本轉化為二進制形式的：編譯器（包括解釋器，Linker等等）。打個比方，主流C++編譯器有VC++，GCC；C#編譯器也有微軟實現的CSC及Mono上的MCS。同樣的源文件交由不同的編譯器，得到的結果會有不同，而最終也會影響程序性能等因素。但是，我們可以簡單認為，這些編譯器最終生成的結果是符合一個統一標準的，也就是說它們得到的結果可以用相同的規則來識別與執行。
• 運行時也是平臺的重要組成部分。例如，使用微軟的CSC編譯出的程序集可以在微軟的CLR或Mono提供的運行時上執行，同樣Sun的Java編譯器生成的Byte Code也可以在Sun和IBM兩種JVM上運行。由于運行時實現不同，所涉及的標準庫也有不同，其程序執行的性能和穩定性都會有所區別。
• 在不同的執行環境下，可以利用的周邊事務是不同的。例如，IronPython便非常容易和.NET程序進行互操作，而JRuby便可以利用Java平臺上的各類框架。而一個C語言程序本身也是一個合法的Objective-C程序，但是在Mac OS X上編寫Cocoa程序利用的也是不同的環境（不確定，求證）。
• 技術以外的方面，如社區活躍度等等。

當然，上面舉的編譯器和運行時都是最為典型的例子。事實上，很多平臺并沒有如此明顯的劃分，它們的編譯器和運行時都是一體的。例如Python語言的實現有傳統的CPython，.NET平臺上的IronPython，Java平臺上的Jython，以及追求比CPython更高性能與靈活性的PyPy。此外，JavaScript語言除了在各瀏覽器引擎中不同的原生實現外，現在又有了神奇的Node.js，可以在服務器端使用JavaScript編寫高性能的服務器端程序。

當我們談論到一門語言“能做什么”，“性能如何”時，往往就是在討論的就不（僅僅）是語言，而是平臺了。語言里的概念和平臺實現并非完全相關，例如在Scala語言中，1 + 2并不是一個表達式，它其實表示的是1.+(2)，也就是一個整型對象上的“加”方法的調用。但是在編譯器的實現上，出于性能考慮就會盡量將其編譯成原生的整數加法操作。當然，語言中的很多部分也在真切地影響其平臺相關的部分，例如C語言的目標是系統語言，因此便盡可能的接近計算機體系結構，沒有高級的語言特性，要把很多細節都交由程序員去控制。而如C#或Java這樣的語言，從語言特性上就注定了其執行環境需要GC能力，這樣對于一些空間密集型的場景可能就比不上如C語言般精細控制所帶來的性能；同樣，C/C++這樣的語言可能并不適合高性能計算，因為它的語言設計注定了會遇上“別名檢測（alias detection）”方面的問題，于是編譯器便無法像一些無副作用的函數式編程語言那樣進行自動并行，或者生成充分利用系統緩存的高性能指令。

吵架

以上，我承認語言與其平臺其實有著密切聯系，但是在很多情況下我們可以忽略平臺而僅僅談論語言。

例如，因為CLR和JVM的性能和可靠性是相同的（您有不同意見？嘿嘿，這里不討論這個），所以我們便可以比較C#與Java（甚至F#與Scala）；因為Rails和Django的能力不分上下，因此我們可以比較Ruby和Python語言在業務邏輯實現方面的優劣；因為它們都在JVM上執行，因此我們便可以引發Java，Scala，JRuby，Jython，Jaskell，Groovy及Clojure的混戰。由于我們“求同”，那么“存異”也就有了意義，因為此時語言也是進行技術選型的重要方面了。

語言引發的爭吵不計其數，這點有目共睹。我寫這篇文章的目的也是希望可以減少這方面的無謂爭論。例如我在猛砍Java時，有朋友會回應到：

• 做項目不能只考慮語言——沒錯，這并不影響我說Java語言差，我也不想以此讓您來用.NET。
• JVM成熟——沒錯，但這并不代表Java語言就好了，您可以用Scala，Clojure等語言。
• 語言不重要，談語言層次太低了——呃，吵不過您，我媽叫我回家吃飯，吃好飯我就洗洗睡了。
• ……

其實有時候，我也只是想單純討論一下語言罷了——哥談的是語言，不是寂寞。

廣告時間

大腕云集的QCon Beijing 2010又要開始了，本次QCon更增加了語言這個主題：

以前，語言還幾乎等同于平臺，選擇了平臺也就自然而然地確定了語言。如今，在相同的平臺或運行時上已經有多種成熟語言可供選擇。以前，語言常被認為是一種單純的工具。如今，語言更進一步被賦予了文化的意味。正因為如此，目前越來越多的團隊在語言的選擇上投入了更多的考慮，甚至已經在多種語言的混合編程上獲得了成功經驗。那么，您是否想了解他們為什么選擇這門語言，他們在語言的設計、選擇或使用方面又有哪些體會的呢？相信這部分內容可以讓您滿意。

繼去年大受好評的“豆瓣網架構變遷”之后，洪強寧將帶來Python語言在豆瓣網中的使用案例。同時，被孟巖譽為年輕一代四大高手的鄧草原也會比較Scala與Erlang兩者的Actor模型在生產環境下的效果。此外還有一些不知名的老外，如Paul King（Groovy頂級貢獻者、《Groovy In Action》的作者）會討論“動態語言的敏捷開發實踐”及“Groovy中的強大功能”，JCP主席Patrick Curran也會來談論有關一致性測試方面的話題。

現在撥打訂票熱線還可以享受XXXX的優惠，機不可失，失不再來，您還在等什么，還不趕快訂票？

轉載于:https://www.cnblogs.com/JeffreyZhao/archive/2010/02/20/programming-languages-platform.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的哥谈的是语言，不是寂寞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。