你不能比較語言特性，只能比較語言

　　英文原文：You can’t compare language features, only languages

　　譯/臘八粥

　　很多編程語言的爭論方式是“X特性真的不錯，每種語言都需要它”，或“X特性比與之相對的Y特性要好很多”。經典例子是靜態 VS 動態類型，不過還有很多例子，比如元編程的不同類型等。

　　我經常發現自己被扯在這些辯論中的不同方向，因為我對 Haskell 和 Python 稍微有些不公平了。但是我想提議的是，做這種抽象的比較、而沒有基于具體的語言，是一種誤導，原因如下：

　　就我的經驗看，Haskell 里的靜態類型與C的靜態類型幾乎完全不同，與C#1.0 就更不同了，據我所知，與C#5.0 的靜態類型更加不一樣。把這些靜態類型混在一起真的有意義嗎？

　　類似地，Shell 腳本、PHP、Python 和 Lisp 里的動態類型或許比它們本來的樣子更加不同。你甚至不能把它們放在一個范圍內——例如，與 PHP 相比，Python 不是簡單的‘強’類型系統（不能把字符串轉換成數字等），因為它也有支撐更大靈活性和威力（比如基于第一類對象的動態子集）的特性。

　　特性組合是無關緊要的

　　比如，我最喜歡的 Python 特性之一是關鍵字參數。它們經常增加調用代碼的清晰度，以向后兼容方式給函數增加新特性的功能。然而，這些特性只有在和其它特性組合時才有意義。如果你有 關鍵字參數、而沒有傳遞或接受關鍵字參數未知集合的**kwargs 語法，那么這將讓 decorator 變得非常難。

　　如果你正在思考 Python 有多么優秀，那么我不認為它對你把總的關鍵字參數做為殺手級特性去談論有多少幫助。它是在 Python 里運行尤其良好的關鍵字參數。

　　比較語言特性給不好的爭論帶來了很多機會

　　例如：

　　攻擊最糟糕的實現

　　動態類型支持者可能說，靜態類型意味著相對于指示類型（indicate type）太過重復和冗長呆板。這種批評可能應用到 Java，但是它不好應用到 Haskell 和很多其它的現代語言，在你可能需要定義類型的地方，類型推理（type inference）處理了 95% 的情況。

　　保護最好的實現

　　上面謬論的結果就是，如果你僅僅抽象地辯論語言特性，你就能隨便找到你想要的實現來駁斥某個觀點。有人宣稱動態類型給 IDE 支持重構增加了難度，動態類型支持者會以“Smalltalk 不存在這種情況”為反駁——忽略了他們從來不用 Smalltalk 的事實，他們從來沒有用過 Smalltalk，他們選擇的動態類型語言真的表現更好，甚至存在自動化重構上不可解決的問題。

　　保護假設的實現

　　保護最好的實現走得更遠，而你實際上在保護著還不存在的實現。

　　虛構的“足夠聰明的編譯器”就是個例子，另一個例子就是動態類型支持者可能談論的“改進”動態分析。

　　假設的實現對于贏取辯論總是有好處的，尤其是在他們組合了所有語言的所有最好特性的時候，而沒有擔心這些特性將真正適合放在一起，并生成人們真正想用的功能。有時候這種混合產物就像 Hercules，有時候卻像非洲蜂。

　　忽視其它

　　在選擇編程語言時，不只是你不得不考慮語言特性——還有其它一長串因素，比如語言的成熟度、社區、資源庫、文檔、工具、程序員的數量（和質量）等。

　　有時候這些因素的質量受到歷史事件（哪種語言、什么時候流行了）的控制，有時候它們可被追溯到語言設計的特性上。

　　很多語言戰爭的爭論都忽略了所有這些因素。不過更容易出現的是，你是否實際地比較了真正的語言——只是其它方面抽象出來的語言特性。

　　我明白，一下子比較每個方面是困難的，我們總是試圖把事物分解來分析。但是我懷疑，這將離編程語言很遠很遠，因為不同特性彼此交互的方式，還有對其它所有東東發展的方式產生巨大的影響，比如資源庫。

　　結論

　　語言特性存在于語言環境和語言周圍所有因素里。對我而言，在環境外面分析它們的企圖將容易導致錯誤的概括。

　　當然，真正具體地、談論具體語言經常導致更多有其自身陷阱的個人因素！有一種不錯的方法嗎？

　　原文地址：http://lukeplant.me.uk/blog/posts/you-cant-compare-language-features-only-languages/

                    <span id="shareA4" class="fl">                  
                        </span>