為什麼會有這麼多程式語言?

【編者按】本文主要探討為什麼存在這麼多的程式語言,以及新的程式語言為什麼不斷地被創造出來。作者從計算機歷史博物館的一幅展示程式語言演化的巨圖入手,分析了不同的程式語言是如何受到前人的影響,以及如何針對特定的任務或工作負載而設計的。作者認為,控制是創造新程式語言的最大主題,因為不同的公司或組織可能有不同的目標或需求,而現有的程式語言可能難以滿足或改變。

原文連結:https://cacm.acm.org/blogs/blog-cacm/262424-why-are-there-so-many-programming-languages/fulltext

未經允許,禁止轉載!

作者 | Doug Meil 譯者 | 楓葉聊齋

責編 | 夏萌

在上世紀 90 年代,一位朋友問我為何存在那多的程式語言。他雖然對計算機有所了解,但並非專業開發者。他不解地問:「為何沒有出現一個卓越的程式語言?」 。我回答說,程式語言通常是針對特定的任務或工作負載而設計的,從這個意義上說,大多數語言在它們能夠實現什麼方面差別不大,而更多的是在於它們使什麼變得容易。最後一句話是我從別人那裡聽來的,我感覺很有道理,很貼切。其實這個問題我也沒想明白。

幾年前,我有幸參觀了加利福尼亞山景城的計算機歷史博物館。這個博物館收藏豐富,其中一幅程式語言演變圖讓人印象深刻。這幅圖非常讓人震撼,無論是用過任何語言寫過 「Hello World」 的人都會情不自禁地走過去觀看,找找自己鍾愛的語言,我也沒能例外。人們本能地用指尖追溯圖中的 “影響” 軌跡,深入了解這些語言的歷史發展和未來趨勢,具體內容取決於他們所關注語言的年代。

圖片來源:計算機歷史博物館

圖片來源:計算機歷史博物館

這張圖從遠處看,就像在講述一段故事。

圖片來源:計算機歷史博物館

圖片來源:計算機歷史博物館

圖表左側的標題寫道:

“這幅圖給我們展示了大概 150 種程式語言,它們只是無數程式語言中的一部分。這些語言中有通用型的,也有專用型的。新語言很少能夠完全擺脫舊語言的束縛,它們都受到了舊的語言的啟發或者借鑑,這些關係用箭頭標註出來了。”

這意味著,這張複雜的圖表只是程式語言演變的一小部分罷了。圖表上的時間線是 1954 年到 2000 年。而此圖開始製作時已經存在的程式語言,現在已經更多了。軟體界似乎總有新的程式語言出現。

往事如煙

我們現今在計算領域所視為理所當然的事物,回望計算機的初期時代,都顯得不可思議。早在那時,儲存、記憶體和處理能力都是昂貴且稀缺的資源。為了能在計算機實驗室使用計算機,人們需要克服種種困難,無論環境多麼艱苦。然而,在那個時代,相對來說,程式語言的名稱空間還是一片未開墾的土地,1950年代和1960年代初的程式語言可以直接以其功能進行命名,比如 FORTRAN(Formula Translator,公式翻譯器)、COBOL(Common Business Oriented Language,通用商業的通用語言)、BASIC(Beginner’s All-purpose Symbolic Instruction Code,初學者通用符號指令程式碼)、ALGOL(Algorithmic Language,演算法語言)以及 LISP(List Processor,列表處理器)。你可能沒聽過 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 年以來創造出的眾多程式語言的一部分。今天的技術環境中,似乎已經有適用於所有基礎語言特性組合的程式語言,包括:

  • 許可證:開源(各種類型的許可證)、商業

  • 平臺:作業系統、硬體支持

  • 語言正規化:過程式、函數式、物件導向等

  • 類型系統:動態、靜態等

  • 併發性:單執行緒、多執行緒

  • 記憶體管理:自動垃圾收集、手動管理

  • 執行方式:解釋執行、編譯到虛擬機器、本地編譯等

  • 其他語言特性:內建的資料類型和資料結構、資料庫和網路功能以及其他實用性能,構成了一份龐大的候選列表。

似乎這些程式語言已經足夠滿足在任何平臺上的任何低級、高級、函數式、過程式、對象、單執行緒、多執行緒、編譯或腳本需求。那麼,為什麼新的程式語言仍在不斷地被創造出來?在我看來,最大的原因是對控制權的追求

掌控與命運

在二十世紀九十年代中葉,微軟的主要開發語言是 Visual Basic 和 Visual C++,它們都起源於較早的計算機語言。Visual Basic 因其在構建 Windows 桌面應用的前端方面展示出的優秀能力而受到青睞,但在諸如資料結構和執行緒等高級語言特性方面卻顯得力不從心。而 Visual C++ 則呈現出另一種情況——開發者可以通過它實現幾乎所有的功能,但這也意味著他們必須面對 C++ 的高複雜性。

在那個時期,出現了一種位於兩者之間,折中的語言的機會,接著在 1996 年,Java 應運而生。作為一種全能的面嚮對象語言,Java 既沒有 C++ 的過度複雜,又提供了豐富的功能性,這一特點令人矚目。我至今記得在微軟的 Visual J++ 剛剛發佈的時候,我也曾嘗試過使用它。那時候,幾乎每個人都加入了這場 Java 的盛宴。

Java 的主要設計理念之一就是跨平臺性。不幸的是,這與當時微軟主張的只在自家平臺運行的策略產生了衝突,這也就引發了支持 Java 的 Sun Microsystems 公司與微軟之間從 1997 年開始的訴訟。雙方的關係趨於緊張,最終導致微軟在 2002 年推出了另一種看似與 Java 極為相似,但實則非 Java 的語言:C#。C# 成功地填補了 Visual Basic 和 Visual C++ 之間的空缺,並且是微軟可以完全掌控的一種語言,這與 Java 極為不同。

Java 的廣泛影響力實際上證明了它的重要性,這遠遠超過了與單一訴訟的關係。2010 年,Oracle 以 Google 在 Android 移動平臺上使用 Java 為由,對 Google 提起訴訟,這是因為 Oracle 在收購了 Sun Microsystems 後成為了 Java 語言的所有者。這場法律糾紛持續了十年,最終在 2021 年進入了美國最高法院的審理程序。

全面設計控制

系統維護與發展常常頗具挑戰性,我在 BLOG@CACM 的多篇帖子中討論過這個話題,例如《Log4j 和無感的高風險任務:管理軟體元件升級》和《快速系統轉換的藝術》。軟體增長的悖論在於,系統接受度的增長會帶來使用量的提升,從而可能帶來更大的成功,並進一步吸引更多的使用者。然而,隨著系統的採用和使用增加,可能會變得越來越難以進行改變,特別是大規模的改變,因為這可能會破壞向後兼容性。雖然這種情況並非無解,但的確非常困難。

管理程式語言的發展可能是最難的挑戰之一。開發者是程式語言的使用者,他們不僅生產力高,而且經常會以創新的方式使用語言特性,其中有些使用方式甚至可能超出了語言的初始設計預期。如果存在特定的邊緣情況,尤其在大規模應用場景下的開發者,終將會找出並利用這些情況。

Go 語言(2009 年發佈)是一個典型的例子,其設計目標旨在做出權衡:足夠強大,但又不過於複雜。Go 語言的誕生部分源於 Google 對一種能在其容器化雲環境中高效、可預測部署的語言的需求。另外一個原因是希望有一種語言能夠在網路和併發性方面有強大的能力,但在語言特性方面不要太繁雜,因為設計者們顯然對 C++ 的複雜性感到反感。

Google 或許可以通過為它自身已經在使用的語言構建新的編譯器和運行時引擎來滿足第一個需求。儘管這並非易事,但 Google 有足夠的人才資源來實現這一目標。然而,改變開發者正在做的事情以及他們的開發方式需要對程式語言的語法和功能進行調整,而這種改變往往相當困難,尤其是當開發者被告知某些事情不再被允許或必須以不同方式進行時。

有時候,只要有足夠的資源(如 Google),針對手頭的用例創建新的東西,然後從零開始可能會更加容易。於是,計算機歷史博物館的計算機語言牆面圖又增加了一個節點。

Go 語言的名稱實際上與 2003 年的一個完全不相關但更強調語法的語言 Go! (帶感嘆號)有所衝突,這反映出語言名稱空間的差異化正變得越來越難。儘管存在這種衝突,Google 為何仍選擇這個名稱?這個問題我不得而知,你可以自行探索。

致謝

在此我要向計算機歷史博物館的 Dag Spicer 表達深深的感謝,他通過郵件向我提供了計算機程式語言發展圖的 PDF 檔案。十分感謝!

參考資源

計算機歷史博物館 – 連結:https://computerhistory.org/

程式語言發展史 – 連結:https://en.wikipedia.org/wiki/Timeline_of_programming_languages

PL/I – 連結:https://en.wikipedia.org/wiki/PL/I

《挑戰者》(電影)- “只能有一部” – 連結:https://en.wikipedia.org/wiki/Highlander_(film)

程式語言正規化對比 – 連結:https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages

Sun/Microsoft Java 訴訟:

  • 2002年的報道:連結:https://www.cnet.com/tech/tech-industry/sun-microsoft-settle-java-suit/

  • 2009年的報道:連結:https://www.cnet.com/tech/tech-industry/sun-settles-with-microsoft-announces-layoffs/

Visual J++ – 連結:https://en.wikipedia.org/wiki/Visual_J%2B%2B

Oracle/Google Java 訴訟 – 連結:https://www.bbc.com/news/technology-56639088

Go! (2003) – 連結:https://en.wikipedia.org/wiki/Go!_(programming_language)

Go (2009) – 連結:https://en.wikipedia.org/wiki/Go_(programming_language)

BLOG@CACM 文章精選:

  • Log4j 和無感的高風險任務:管理軟體元件升級(連結:https://cacm.acm.org/blogs/blog-cacm/257897-log4j-and-the-thankless-high-risk-task-of-managing-software-component-upgrades/fulltext)

  • 快速系統轉換的藝術(連結:https://cacm.acm.org/blogs/blog-cacm/252981-the-art-of-speedy-systems-conversions/fulltext)

你是否曾被程式語言的選擇困擾過?在你的開發經歷中,你是否發現了某個程式語言在特定任務上的優勢?讓我們一起在評論區分享你的見解吧!

相關文章

用一個小時編寫一個小程序

用一個小時編寫一個小程序

【CSDN 編者按】要想快速編寫程序,必須要認真考慮技能、工具選擇、攤銷和回報。 原文連結:https://buttondown.email...

Kubernetes 真的很難嗎?

Kubernetes 真的很難嗎?

【CSDN 編者按】Kubernetes 提供了許多開箱即用的好東西,可以推進業務的發展。但這是否意味著,所有服務都要放到 Kubernet...

震驚!C 語言字串處理有很多坑?

震驚!C 語言字串處理有很多坑?

【CSDN 編者按】毋庸置疑,在使用 C 字串時必須小心,否則你就會因為各種的未定義行為而感到頭疼。 原文連結:https://www.de...

MySQL如何支撐每秒百萬QPS?

MySQL如何支撐每秒百萬QPS?

【編者按】本文主要介紹 PlanetScale 是如何通過 MySQL 的水平分片支撐每秒一百萬個查詢(QPS)的。 原文連結:https:...