關于編程語言的爭論雖然此伏彼起，但事實上很少有人真的在做編程語言的比較，同時許多無價值或錯誤的觀點卻在真實的誤導著許多程序員的認識，為此我決定寫這篇文章。

一、前提

本文后述觀點是基于這樣一種前提：只關注語言特性，而忽略標準庫和其他各種商業框架（雖然這些更大程度上決定著人們對語言的選擇）。這必將使這篇文章的觀點更具有理論意義，而非現實意義。但語言特性是編程語言的根本，無論是做語言比較，還是評論語言，都應該以此為出發點，否則將導致討論范圍的無限增大，進而導致討論的無結果。為避免有人找碴，必須預先聲明的一點是，由標準庫實現的語言特性將被看作語言特性，進而列入考慮的范圍。同時這里說的編程語言是指一些通用目的的高級編程語言，比如C/C++,Java,Python,Perl等。

二、80% 與 20%

我學習不同的編程語言時，更多的時候是感覺到其間的共性。于是我對此進行思考，發現這種共性的存在具有必然性。

軟件的根本特性是復雜性，對此Dijkstra告訴我們，“掌握復雜性的技巧早在古代就有了：divide et impera(分解和規則)”。當我們具體進行分解和設定規則時，我們要用到一些分析和設計方法。當代兩大主流分析和設計方法是結構化和OO。結構化設計方法的三種基本結構是順序，分支和選擇。OO的三大基本特性是封裝，繼承和多態。各種設計語言通常都支持這兩種分析和設計方法，其基本語言特性也必然涵蓋上述六個要素。所以從這個角度看不同編程語言必然具有相當多的共性。

可為佐證的首先是《The Art of Computer Programming》這本書。這本書中的算法用低級語言描述的，但其內涵被大多掌握不同編程語言的開發人員所分享。有人評論說，當今軟件開發人員所掌握的絕大多數計算機程序設計的知識都來源于此，這意味著相當多程序設計知識可以具體實現在各種編程語言中。

另一個是《設計模式》，你很難說那個設計模式是專屬于那種語言的，大多的設計模式可以用各種編程語言來實現的。雖然具體的實現上會因為語言特性而做相當的調整。應該可以說不同的編程語言在某個確定的設計模式面前，體現的也是共性。

把上面的內容總結一下就是：很多的場合下，不同的語言是可以互換的。互換的基礎是不同種語言間的共性，而存在這些共性的基本原因是不同的編程語言要支持的根本思想中大部分是相同的。

故老相傳，學到高處，語言間切換是很容易的，很多人的經歷也驗證了這句話。上面說的正是這句話的所以由來。

這里沒有把各種語言等同起來的意思，但編程語言的個性同共性相比反倒是較小的部分。它們往往成為關注的焦點，同時也是存在這么多編程語言的一個主要原因。

大多數人對此的體驗大概來自基本語法，事實上這是讓人非常懊惱的一個方面。基本語法的不同起源于什么無從考證，但根本事實是這種不同在浪費學習者的時間。我們來做個類比大家就知道這種浪費有多么不值得，UML出現前，OO表示法主流上有三種，他們表達意思差不太多，但他們不一樣。學習的人，工作的人要為同一件事花近三倍的力氣（要不然別人用另外的表示法寫的文檔你怎么看的懂），現在這些人得到了解放。但在編程語言領域這種糟糕的事仍然在繼續，差不多每個人都要記住好多種if語句，雖然事實上它們可以統一。

拋卻基本語法不談，其它的方面是真的不多。即使把C++和Python這兩種差別非常巨大的語言放在一起進行類比。一時間能想起的主要差別也只有：①Python內置了list及tuple等一些數據結構作為內置類型（當然還有與此相關的操作）。而C++中要用基本類型對此進行定義。②Python支持函數生成器和函數嵌套定義。而C++不支持。③Python是動態類型語言，先天具有范型能力。而C++要通過模板的概念支持范型。這不是一個完整的列表，如果愿意，這個列表確實可以變長，但另外一張反映共性的標通常會更長。

（注：我沒有參考相應的書籍把兩者的語言特性一一羅列，并徹底的比較其異同，僅是把平常使用時經常用到的語言特性想了一下，寫了上面的東西。如果那位使用過兩種以上的語言，我也建議能用這種方式來確定兩種不同語言的常用部分有多大的重疊度。）

這也正是題目所說的80%和20%的根本含義。不同的語言雖然看起來差別很大，但共性要大于個性。至于是不是4：1的關系，老天知道，那位感興趣，可以統計出一份數據來。

三、結論

（事先聲明，這里是從學習的角度來下這個結論，而非混飯的角度）

好多年前就有這句話：編程語言并不重要，設計思想才重要。這幾年在托鼠標即是編程的大潮中，這句話逐漸被遺忘了。

在這篇文章的結尾，我想對這句話進行一些詮釋。編程語言不是不重要，光有想法，基本語法都搞不清楚的人肯定什么都做不出來。但而后呢？不停的學習新的語言，接觸新的語法么？從上面的分析看，如果你這樣做，那意味著你在做重復勞動，并且沒有實際的進步。真的程序員不該如此墮落，總要學些思想性的東西吧。總不能去研究怎么才能把一個鈕拖到另一個地方的路徑縮到最短吧？

學習編程語言，熟悉基本語法后，一定要關注某些語言特性背后所承載的東西。但

單知道這兩樣仍然是不夠的，還要知道什么時候這些被承載的東西適合使用。這是遠比前兩者更難的東西。

為避免結論過于抽象，舉個例子來描述這三重境界：比如說學習模板的時候，第一步是要把基本語法搞清楚，要能夠確保寫出來的模板類、模板函數沒有語法錯誤，能夠通過編譯。第二步要去理解范型這種思想，去思考范型存在的根本目的是什么？第三步是能夠在碰到具體問題時，來正確的取舍是否需要使用這種特性，用的話又怎么去用。

四、尾聲

程序員作為一個籠統的稱呼，其真正的含義正在分化。Bjarne Stroustrup自稱：“是的，我是一個程序員”。而一個只會拖拖鼠標，完成指定功能的新手，通常我們也稱之為程序員。但事實上這同一個稱呼，其內在含義是不一樣的。

可視化編程和RAD的快速發展所產生的一個明顯后果就是，所謂的軟件藍領離我們是如此之近。并且越來越多的人以閃電般的速度切入這個隊伍。這又是怎么樣一場絢麗卻虛假的繁華。于是許多妖言應勢而生，最為讓人哭笑不得的莫過一句“程序員是吃青春飯的”。這未免太小覷程序員這個職業了，這句話成立的前提是做程序員沒什么難度，不需要什么積累，主要是力氣活。誠然如果程序員只是一個拖鼠標的職業，那么年富力強者具有先天的優勢。但很不幸大多時候他不是，或者說不應該是。

在這里我姑且漠視許多公司對軟件藍領的呼喚，單從個人發展的角度提醒一句，實踐實用主義的同時，莫要忘了什么是編程的根本，莫要忘了提升自己的境界。