在7 月上旬的一篇CACM 博客文章中，Doug Meil 談論了《為何有這麼多編程語言？》這個話題。而在1990 年代，曾有一位精通計算機、但並非身為全職開發者的朋友向他提問“為何沒有一種好用的編程語言？”當時他的回答是，編程語言同行為特定的人物或工作語言而設計。

（來自：BLOG@CACM）

從這個意義上說，大多數語言的區別，並不在於它們使什麼成為可能、而更多地表現在它們使什麼變得容易。

幾年前，Doug Meil 有機會參觀了位於加州山景城的計算機歷史博物館。有趣的是，在眾多展品中，有一幅關於編程語言演變的超大號壁紙圖標。

這張圖是如此之大，想必任何編寫過“Hello World”語句人們，都可以在上面找到對應的編程語言。

在本能的趨勢下，人們會忍不住沿著時間的正序方向去查看。但若回頭望，你又會領略到不同的視角。

這張圖表顯示了已經發明的數千種編程語言裡的大約150 種，其中一些較為通用、另一些則是為特定類型的應用程序而設計。

圖表上的箭頭，顯示了較新誕生的語言如何受到了老語言的影響。不過就算複雜如此圖，它也只能算是更大範圍裡的一個樣本。

（圖來自Coding Across America）

軟件世界裡的新語言依然層出不窮，但很少有全新的語言冒出來。回顧早期，計算機的資源內存、存儲和處理能力都相當昂貴且有限。

為此，人們不得不逆風上坡，甚至經常需要通宵熬夜來爭取計算機的使用時間。而1950-1960 年代初始的命名空間，可以精確地處理底層事務。

時至今日，年輕開發者們已鮮有涉足FORTRAN（公式翻譯）、COBOL（通用商業導向語言）、BASIC（初學者通用符號指令代碼）、ALGOL（算法語言）、LISP（List Processor）。

不過就算大多數人可能根本沒有聽說過描述字符串處理算法的SNOBOL 語言（1962）或OBJOL，但只要充分理解了面向對象的編程理念，就不難推測它可以用來幹什麼—— 至少年代的命名模式就是如此。

1964 年的PL/I，致力於成為一種更好用的編程語言。雖然它沒有如設計者預期那樣發展，但早在1960 年代初，人們就已經提出過“為何有這麼多編程語言”的疑問。

時間快速翻到千禧年後，我們陸續迎來了Scala（2003）、Go（2009）、Rust（2010）、Kotlin（2011）和Swift（2014）。

當下的技術環境，似乎所有這些基本語言的屬性，都被重組到了特定的解決方案中。

其能夠滿足任何平台上的所有低級/ 高級功能、過程/ 對象、單線程/ 多線程、編譯/ 腳本需求。

在此情況下，繼續創造新語言的最大因素，反而是出於控制的考量。

1990 年代中期，微軟主要提供了Visual Basic 和Visual C++ 開發語言，兩者都源於計算機歷史博物館壁紙上的舊節點。

VB 流行於為Windows桌面平台構建前端應用程序，但缺乏許多高級語言功能—— 比如數據結構和線程。

VC++ 處於光譜的另一端——開發者幾乎可以做到任何事情，但難點在於語言本身太過複雜。

正因如此，一些人看到了打造一款“中間語言”的機會，於是Java 在1996 年迎來了爆發。

據悉，Java 是一種功能齊全的面向對象語言，且涉及重點之一是跨平台的可移植性，可惜這並不是微軟的首要目標。

隨後Sun Microsystems 和微軟在1997 年陷入了曠日持久的衝突，並最終推動後者在2022 年推出了C# 。

乍一看C# 和Java 很像，但實際上並非如此。其填補了微軟開發堆棧的’中間’位置，且該公司能夠更好地掌控該語言。

最後從總體設計控制角度來看，維護和發展現有系統，很容易變成一項艱鉅的挑戰。而管理編程語言的增長，也是最困難的案例之一。

作為編程語言的用戶，優秀開發者們不僅具有生產力、還能夠以創造性的方式去使用相關特性，即便這麼做並不是語言作者所期望的。

2009 年的Go 語言，就是一個相當有趣的例子。其誕生的一個主要推動因素，就是需要能夠在Google 的容器化雲環境中，高效且可預測地部署。

其次是對強大語言的渴望，尤其在網絡和並發性方面。從人才角度來看，Google 顯然有能力為現有語言構建一套新的編譯器和運行時引擎。但要改變開發者的習慣，則需要費力地改變編程語言的語法和功能—— 尤其是被告知某些事情不再被允許、或必須以不同方式去完成時。