回答問題的嘗試：為什么有的語言成功了，而其他的卻失敗了？
查看英文原文：Trying to Answer the Question：Why Some Languages Succeed While Others Fail?
來自 UC Berkeley 的兩位研究人員從社會學的角度調查編程語言的推廣情況。本文簡要介紹他們的研究，然后對兩位作者進行了專訪。
Leo Meyerovich 和 Ari Rabkin 都是 UC Berkeley 的研究人員，他們嘗試回答“為什么有的語言成功了，而其他的卻失敗了”這個問題，提出一種基于社會學的編程語言理論，取名 Socio-PLT。他們希望用“Socio-PLT： Principles for Programming Language Adoption（PDF）”這篇論文令軟件社群意識到，編程語言的推廣不可以僅僅當作營銷方面的題目，推廣情況的背后有著社會學的科學理論，并據此提出繼續深入研究各種語言接受現象的行動方案。
Meyerovich 和 Rabkin 的研究基礎，包括針對數千名參與 Berkeley 在線課程的計算機科學專業學士的一次調查，包括超過 13,000名 Slashdot、Hacker News、Reddit 用戶參與的為時兩年的編程語言在線調查，還包括 SourceForge 超過 300,000個項目的倉庫數據。研究者們目前還在消化收集回來的巨量數據，尚未給語言為何成功這個問題找到科學的答案。不過他們已經整理了一批問題和假說，希望有助于打開一條研究道路，運用社會學的研究方法，進一步探討語言設計和接受問題。我們試舉其中幾條問題：
問題 3. 具體是什么東西說服程序員接受一種語言？
問題 5. 語言設計者應該跟蹤觀察什么數據？
問題 9. 我們如何利用社交網絡去說服語言的實現者以及程序員采納最佳實踐？
問題 11. 程序員可以精通和略懂多少種語言？是否存在一種語言上的“飽和”概念，程序員只能期望達到一個適度的水平？
問題 16. 程序員對較長的編譯、解釋時間的敵視程度如何？他們對于用更長的時間換取更完善的錯誤檢查意愿如何？
問題 21. 語言社區的價值觀怎樣隨時間變化？例如，當語言變得較為流行之后，其設計者是對性能的重視程度是更高還是更低？對降低實現負擔的重視程度是更高還是更低？
這里還有一些假說的例子：
假說 2. 編程語言的設計者和使用者都不能正確認識語言的性能和特性的實際表現。
假說 3. 開發者群體本身的人群分布會影響技術分析。
假說 4. 一種語言若不能緊追其競爭對手，及時解決對手已解決的用例，將被程序員拋棄。
假說 8. 相當比例的專業程序員知道函數式編程和并行編程，但并不實際使用。知識并不是接受的屏障。
假說 10. 用戶更容易接受內嵌型的 DSL，更排斥非內嵌型的 DSL，且 DSL 與其所嵌環境越和諧，被接受的可能性越高。
假說 12. 測試一種語言的表達效果和能力，用它實現一個輸入-輸出庫是好辦法。
假說 13. 開源 codebase 往往可以代表性地反映其用戶群體的整個世界。
假說 15. 許多編程語言特性，如模塊化機制，與該特性的社會性用途緊密關聯。
InfoQ 聯系了 Rabkin 和 Meyerovich，談談他們研究的這個語言接受問題。
InfoQ：你們從研究中得到了哪些主要觀點？它們有何意義？
AR：首先我應該說明這項研究還沒完成，最多算剛起步。我們的確收集了不少數據，但分析工作才剛剛開始。
我可以拿一些傳統智慧來回答你的問題，答案的依據只是我本人不科學的個人理解，沒有可靠的數據基礎。
我和同事 Leo 想搞清楚這么一個問題：語言設計者和編程語言研究群體，對于用戶真正想要什么，是否有準確的認識。例如傳統上一般認為靜態類型的優點是善于捕捉錯誤，也有利于提高模塊化水平。
可是當你去調查程序員的看法，他們不見得認同。有些程序員喜歡靜態類型，往往是因為靜態類型能起到文檔說明的作用，還有靜態類型比較容易重構。現在調試一般都結合單元測試來進行。很多情況下類型信息并不是必須的。
我們認為像這樣的例子還有很多，程序員們關心的事情和設計者關心的事情有那么一點偏差。如果我們能找出這些情況然后記錄下來，會是比較重要的貢獻。
LM：還可以拔高一個層次來看：我希望從社會學角度去優化編程語言的研究和設計工作。
我們有相當部分的工作是先找到一些社會學理論，然后對程序員做意見調查，對語言設計者做訪談，看看雙方的意見是否脫節，從而確定我們應該如何看待語言的功用。我們已經有證據提示說，在 DSL、程序模塊、類型安全、語言/API/程序演化等等基本的編程語言議題上，都存在著分裂的（社會性）基礎。
我的第二個目標是開創一種新類型的、能充分利用社會學現象的編程語言。舉例來說，能不能讓程序隨著使用者的增長，自動獲得更高的速度和安全性？如果讓代碼和執行蹤跡通過互聯網共享，我們能不能將現在花2~20分鐘搜索 API 用法的行為變成只花1~2分鐘的智能代碼補全？我們并不想盲目出擊，所以一直在驗證社會學家對于技術的一些想法。工作做得越多，我們越覺得這方面大有可為: )
InfoQ：程序員和編程語言之間存在什么樣的社會關系？
AR：這個題目有一點特別吸引人，用戶和語言之間的社會學關系不是單向的關系。程序員經常自創各種庫，乃至自創各種專門用途的工具去改造手上的編程語言。大多數流行的語言都擁有一套完整的生態系統，可將語言改造為各種截然不同的面貌。例如 Python 配合 NumPy 庫之后變成一種可承擔高性能科學計算任務的語言，這種任務是 Python 語言本身完全不能勝任的。Ruby 如果沒有后來發明的大量工具幫助它拿下復雜大型應用，尤其是 Web 應用的開發任務，它的吸引力不會有現在的那么高水平。
語言設計可以不經意地塑造庫和工具的形態，這一點也很有趣。動態語言很容易做測試用的仿真代碼，而 Java 就難得多。從這些方面看，“語言原本設計的樣子”和它的程序員之間的關系很值得研究。
LM：這個問題的答案是開發性的，其中牽涉的人和過程非常多。
舉個例子，我們應該把語言設計者和他們的資助者身份也納入考慮。現在政府方面（如國家科學基金、國防部、能源部）的資助力度較弱，我們更多地看到企業界的影響（Microsoft、Intel 等等）。這種現象，影響了新語言的設計出來的特性。
單獨一種語言范圍內表現出來的關系也十分有趣。語言設計者和程序員之間的溝通邊界線，因為網絡的關系被抹平。這一方面是好事，另一方面（不具備代表性的）早期用戶和聲音比較大的少數人，很容易被誤認為代表了真實的情況。當語言設計者是語言所屬專門領域的專家的時候，可以相對緩解代表性失準的問題。初涉語言設計的人因為缺乏歷練，不可避免地會在一些基本的設計問題和性能考量上重新發明輪子，同樣不可避免地會搞錯一些重要的方面。像 JavaScript，安全/語義/性能專家不得不在事后大動干戈地改造它，而成效有限。世上不如人意的事情太多: )
從我前面的觀點可以看出來，我預料關系將會發生變化。例如當程序員之間的分享行為越來越普遍，可以想象語言和工具能做的事情也會更多。希望十年后，我們回過頭來看今天上 Google 查開源代碼，上 StackOverflow 問問題之類的行為，會覺得太幼稚。這樣的變化將從社交和技術兩個角度改變編程。
InfoQ：為什么有些語言比別的語言流行度高很多？
AR：關于這一點，我手上真的沒有數據，所以只能說說觀點而不是事實。
一種語言能流行，有的是因為出現了殺手級應用，有的是因為有深厚的業界支持。前一種情況的例子有 Ruby，因為 Rails 而取得成功。還有C，在很長一段時間里，C都是開發 Unix 和 Unix 工具最簡單的高級語言。
后一種情況的例子如 Java 和C#。這兩種語言都沒有什么特別創新的地方——只是在 Smalltalk 和C/C++之間找的折中。它們真正突出的特點是良好的文檔、完善的類庫和跨平臺實現。這幾項都是開發成本高昂的特性，如果沒有 Sun 和 Microsoft 建立“現代”語言平臺的戰略決策，是建立不起來的。
LM：說得對，而且不存在什么成功的保證。用簡單的生態原理推導一下就知道，事情絕不會那么容易：每一種新語言都是對社會資源的一次分流。程序員需要花時間精力去掌握語言，花時間精力去建立各種庫，時間精力都是資源。
Scala 是一種設計的時候就考慮了接受問題的語言榜樣。Java 的政治版圖前景不明，于是 Scala 把自己定位成 Java 的替代者（歷史會證明的！）。雖然 Scala 根本就是一種通用語言，他的開發團隊卻花很多時間去照顧財經領域和初創企業的早期用戶。財經領域和初創企業都是能給 Scala 帶來聲望的垂直細分市場。而且我猜想這類開發者學習新語言沒有障礙，更換語言的成本較低。支持原有的 Java API 和 Java 遺留代碼對開發者很有吸引力。Scala 語言擁有一些在學術上領先的先進特性，但它并不去刻意強調，而是明智地選擇于己有利的意識形態戰場。大多數程序員都不會注意這些方面。諸如此類我還可以繼續說下去：)
InfoQ：為什么有些語言壽命比別的語言長很多？
AR：有個老笑話是這么說的，“我不知道 15 年后工程師會用什么語言，但他們管它叫 FORTRAN。”像 Basic、Fortran 這些古老的語言，從它們現在的模樣已經完全認不出當初發明時的樣子。很難回答“語言可以維持多長時間”。即便是C語言，自K+R 1.0 以來也經歷了持續不斷地改進。
也許可以改為問人們什么時候開始不再在新項目里使用一種語言。很遺憾這方面的數據不多，我不知道怎么畫一根曲線來回答“Modula-2的使用量高峰是什么時候”。我還沒找到好的答案。