早在1990年代，我的一位朋友曾問我為什麼有如此之多的編程語言。「為什麼沒有一種大家都會用、公認最好的編程語言？」他精通計算機，但不是開發人員，至少不是全職開發人員。我回答說，編程語言通常是為某些任務或工作負載而設計的，從這個意義上說，大多數語言在它們使什麼成為可能方面的差異較小，而在它們使什麼變得容易方面差異很大。最後一句是我記得別人說過的一句話。這聽起來很聰明也很恰當，但事實是我真的不知道為什麼會有這麼多編程語言。這個問題一直縈繞在我的腦海中。
幾年前，我有機會參觀了位於加利福尼亞州山景城的計算機歷史博物館。那是一個了不起的地方，在眾多展品中，有一幅覆蓋整面牆壁的、關於編程語言演變的圖表。這張圖是如此之大，以至於任何曾經在任何東西中寫過「Hello World」的人都有一種將鼻子貼在牆上並逐段搜索以嘗試找到他們最喜歡的語言的衝動。我當然也做了。
過去的好日子
在今天，有很多東西被認為是理所當然的。在早期，則一切都是昂貴且有限的：存儲、內存和處理能力。人們不得不逆風走上坡路，然後通宵熬夜來獲得計算機時間。在那段時間更輕鬆的事是，編程語言的命名空間是空白的，而1950年代和1960年代可以精確地為其所做的事情命名：FORTRAN(公式翻譯器)、COBOL(通用面向業務的語言))、BASIC(初學者通用符號指令代碼)、ALGOL(算法語言)、LISP(列表處理器)。大多數人可能沒有聽說過 SNOBOL(String Oriented and Symbolic Language,1962)，但是不需要費勁猜就可以確定它存在的目的。
如果在那段時間更充分地理解了面向對象的編程概念，那麼我們可能會使用「OBJOL」之類的東西進行編碼——一種明確命名的面向對象語言，至少從那個時代的命名模式來看是這樣。
PL/I(1964)的大膽之處值得一提和欽佩，它的目標是成為「一種好的編程語言」。這個名字說明了一切：編程語言1。應該不需要2、3或4。雖然 PL/I成為計算機編程的高地人的計劃沒有像設計者預期的那樣實施，但他們提出了一個關鍵線索：為什麼有這麼多語言？早在1960年代初，人們就已經想到了這個問題。
此時此刻
Scala(2003)、Go(2009)、Rust(2010)、Kotlin(2011)和 Swift(2014)只是2000年後創建的語言的幾個例子。還有更多。在當今的技術環境中，似乎這些基本語言……滿足任何平台上的所有低級、高級、功能、過程、對象、單線程、多線程、編譯或腳本需求。鑑於此，為什麼仍在創建新語言？我看到的最大主題是控制。
90年代是 Visual Basic和 Visual C++的時代，它們都源自計算機歷史博物館語言圖上的舊節點。 Visual Basic流行於為 Windows桌面平台構建前端應用程式，但缺乏許多高級語言功能(例如，數據結構、線程)。 Visual C++處於光譜的另一端——開發人員幾乎可以做任何事情，但問題是 C++很複雜。可以這麼說，存在一個「中間語言」的機會。然後 Java在1996年爆發。Java是一種功能齊全的面向對象語言，沒有 C++的鋒利邊緣，這一事實令人信服，我至今記得在 Microsoft的 Visual J++剛問世時，每個人都加入了 Java派對。
Java的主要設計重點之一是平台可移植性。不幸的是，至少就非微軟平台而言，這並不是微軟的目標之一，這使得 Sun Microsystems(當時 Java背後的公司)和微軟陷入了衝突，導致1997年開始的訴訟。這種關係最終導致微軟發佈了另一種名為 C#(2002)的語言，它看起來很像 Java，但實際上並非如此。 C#填補了 Microsoft開發堆棧中的「中間」位置，並且與 Java不同，Microsoft可以控制它。
這並不是唯一的Java訴訟。甲骨文於2010年起訴谷歌在 Android移動平台中使用 Java，因為甲骨文在收購 Sun Microsystems後成為 Java語言的所有者。這是一場長達十年的法律鬥爭，最終於2021年打到美國最高法院。
總體設計控制
維護和發展現有系統具有挑戰性。軟件增長的悖論是，系統的廣泛採用會導致更多的使用，這可能會導致更大的成功，然後是更大的採用。但隨着採用和使用的增加，它可能導致系統變得更難改變，尤其是在大方面，因為這樣的改變有破壞向後兼容性的風險。管理不是不可能，只是很難。
管理編程語言的增長可以說是最困難的案例之一。編程語言用戶是開發人員，優秀的開發人員不僅有生產力，而且有一種創造性地使用語言特性的方式，並非所有這些特性都是作者所希望的。如果需要找到邊緣情況，開發人員就會找到它們，尤其是在大規模上。
Go(2009)是一個有趣的例子，說明想要做的越來越多。其創建的一個驅動因素是需要能夠在 Google的容器化雲環境中高效且可預測地部署的東西。另一個驅動因素是對一種強大的語言的渴望，特別是在網絡和並發方面，但在語言特性方面不太強大，因為作者顯然也是出於對 C++複雜性的「共同厭惡」。假設，谷歌可以通過為谷歌已經在使用的現有語言構建一個新的編譯器和運行引擎來回應第一個驅動因素。雖然這不是一項簡單的任務，但谷歌有很多聰明人，所以這是有可能的。但是要改變開發人員正在做的事情——以及做的方式——需要改變編程語言的語法和功能，而這些類型的改變很難——特別是當開發人員被告知某些事情不再被允許或必須被允許時。有時，為手頭的用例創建新的東西會更容易，然後重新開始。再次開始。最終另一個節點被添加到計算機歷史博物館的牆壁大小的計算機語言圖表中。
在2003，go的前身，google搞出了名為Go！的語言，這表明語言命名空間變得越來越小。儘管容易混淆，為什麼Google仍使用了該名稱？我不知道。