Python、Java、C#、Perl 創始人聚首暢談程式語言的未來

4 月初，在 Puget Sound Programming Python（簡稱 PuPPy）舉辦的第一屆年度慈善活動[1]中，四位傳奇的程式語言創始人聚集在一起就程式語言設計的過去和未來展開了熱烈的討論。此次活動旨在為面向所有人的電腦科學教育（Computer Science For All，美國前總統奧巴馬當年年初提出的新計劃，旨在美國教育體系中普及電腦科學）籌集資金。

與會的小組成員包括以下流行程式語言的創始人：

此次討論會由 Carol Willing 主持，目前她是 Jupyter 專案的指導委員會成員和開發人員。她還是首屆 Python 指導委員會成員，Python 軟體基金會研究員和前任主任。

程式語言設計的關鍵原則

小組成員提出的第一個問題是：“程式語言設計的原理是什麼？”

Guido van Rossum 認為：

程式語言的設計與 J·K·羅琳撰寫她的哈利波特系列叢書的方式非常相似。

他解釋說，J·K·羅琳是一個天才，她在第一本哈利波特書中提到的一些細節與第六和第七本書中重要的情節相呼應。

在解釋這與程式語言設計之間的關係時，他表示：“在程式語言設計中亦是如此，我們需要做到首尾呼應。”在設計程式語言時，首先我們會承諾某些細節，例如我們想要使用的關鍵字，我們想要遵循的編碼風格等等。但是，無論我們做了何種決定，都必須堅持到底，將來我們需要像 J·K·羅琳一樣，找到使用這些細節的新方式。

他補充說道：“一方面，在設計程式語言的工作中，最開始你要做出一系列的選擇，為你的故事發展埋下伏筆。另一方面，設計程式語言的藝術在於，你需要不斷回顧你的故事，並展開奇思妙想，以你始料未及的方式推進故事發展。”

當談論到 James Gosling 建立 Java 的過程，以及他所遵循的設計原則時，他只是淡淡地說：“Java 的出現並不像個人熱愛的專案那樣。其實我們只是想試著建立一個原型。”當時，James Gosling 和他的團隊開展了一個涉及嵌入式系統領域的專案。為此，他們與許多為嵌入式系統構建軟體的開發人員進行了交談，並瞭解了他們的工作流程。

該專案大約有十幾個人，Gosling 負責從程式語言的角度來儘量簡化專案。他補充說：“最初我們只想做比 C 更好的東西，但是後來就失去了控制，最終專案的其餘部分只是提供了素材。”唯一從該專案中倖存了下來的就是“Java”。基本上該程式語言就是為瞭解決身居資料中心之外的人的問題，這些人常常為網路、安全性和可靠性等問題困擾。

Larry Wall 覺得自己更像“語言學家”，而不是電腦科學家。他想創造一種更接近自然語言的程式語言。他舉了一個例子：“就好像我們不必讓每個人都走進大學校園才能決定他們各自的去向，我們可以觀察人們想去哪裡，然後設定通向這些地方的捷徑。”Perl 建立背後的一項基本原則是透過 API 提供一切功能。這種程式語言的標的不僅是建立一種優秀的文字處理語言，而且也想成為一種膠水語言。

Wall 進一步說，雖然在 90 年代 Perl 非常穩定，但也確實存在一些問題。因此，2000 年的時候，Perl 團隊決定打破一切，並提出了一套全新的設計原則。而且，他們還根據這些原則，重新設計出了 Perl 6。其中一些原則做出了正確的選擇——保守地使用括號，否則算上 Unicode 的括號也不夠用；無需蹩腳地重新發明面向物件等等。

他補充說，

“大量的重新設計就像是說，我們該用哪根柱子支撐一切？新的設計是面向物件的嗎？是在詞法作用域內重新設計，還是在更大的範圍內？每片資訊的正確的支柱是什麼？如果我們根本沒有支柱的話，該如何建立？”

Anders Hejlsberg 表示，他遵循了他所接觸過的所有程式語言的共同原則，即“做某件事情的方法只有一種。”他認為，如果開發人員有四種不同的方法，那麼最終很有可能會選擇錯誤的道路，而且要過很久才能在開發中意識到這個錯誤。根據 Hejlsberg 的說法，這就是為什麼開發人員總是會建立一種名為“簡單的複雜”的東西，也就是說拿到一些複雜的東西後，透過簡單的打包來掩蓋複雜性。

與 Guido van Rossum 的觀點相似，他進一步補充說，在設計一種程式語言的時候，無論你做出怎樣的決定，都必須堅持到底。在設計程式語言的時候，你需要謹慎地決定“不”將哪些東西引入到這種程式語言中。通常，人們會向你提出他們的建議，但你無法真正改變程式語言的本質。雖然你無法真正改變語言的基本性質，但是你可以進行擴充套件。基本上你有兩個選擇：要麼堅持語言的本質，要麼開發一個新的程式語言。

程式語言的型別系統

在談論到 Python 決定型別的方法時，Guido van Rossum 分享了 Python 首次推出時的一個故事。起初，int 不是一個類，實際上它是一個轉換函式。後來，Guido 意識到這是一個錯誤。“我們有很多這樣的功能，我們意識到我們犯了一個錯誤，我們向用戶提供了與內建物件型別不同的類。”

於是，Python 團隊決定重新構建 Python 的整個型別，併進行了大量的清理。因此，他們將函式 int 更改為類 int 的指定符。現在，呼叫這個類意味著構造該類的實體。

James Gosling 表示一直以來他都很註重效能，而提高效能的一個因素是型別系統。在構建最佳化編譯器和提前檢查正確性等方面，型別系統非常實用。擁有型別系統也有助於為小型裝置構建系統的情況。他說：“為了能在有限的空間內工作，你必須瞭解裝置提供的每一種可能性，而且你知道得越早，就越有可能出色地完成工作。”

Anders Hejlsberg 將型別系統視為一種工具。開發人員喜歡他們的 IDE，他們習慣於使用陳述句的自動補齊、重構和程式碼導航等。這些功能是透過程式碼的語意知識而實現的，而這種語意知識正是由型別系統的編譯器提供的。Hejlsberg 認為，新增型別可以大大提高開發人員的生產力，雖然這與我們的直覺相反。

他補充說：“我們以為動態語言更容易掌握，因為你擺脫了型別的束縛。然而，事實證明，如果你以非侵入的方式新增型別，同時努力做好型別推斷等，那麼就可以提高效率。”

談到 Perl 中的型別系統時，Wall 表示 Perl 5 和 Perl 6 有不同型別的系統。在 Perl 5 中，所有型別都會被視為字串，即便是數字或浮點型別。該團隊希望在重新設計 Perl 6 的時候依然保留這個功能，然而他們意識到：“如果新使用者對可互換性感到困惑，那還好；但如果連計算機都感到困惑，那就不妙了。”

於是，在 Perl 6 中，Wall 和他的團隊希望將其打造成更好的面向物件以及更好的函式式程式語言。為了實現這一標的，他們需要一個非常合理的型別系統，併在底層建立一個非常合理的元物件模型。此外，你還需要非常重視“一切都是物件，一切都是閉環”的口號。

影響程式語言維護性的因素有哪些？

Guido van Rossum 認為，如果想加強程式語言的維護性，那麼就需要在靈活性和規範性之間取得恰當的平衡，這一點非常重要。雖然對於小型程式來說，動態型別更好用，但大型程式則需要採用嚴格的方法。而且，最好能夠透過程式語言本身實現規則，不要給使用者留下太多自由發揮的空間。出於這個原因，Guido 打算在 Python 中新增類似 TypeScript 的技術。他補充說：

“實際上，TypeScript 非常實用，因此我們也想在 Python 中新增類似的概念。當然我們的新增方式會略有不同，因為我們的語言環境不同。”

除了型別系統以外，事實證明重構引擎也非常有用。有了重構引擎後，就可以一次執行數百萬行程式碼的大規模重構了。通常，人們不會重新命名方法，因為你很難認真看完一段程式碼，然後正確地給每一個變數重新命名。如果你有一個重構引擎，那麼只需點下幾個按鈕，輸入新名稱，然後 30 秒內就可以完成重構。

Anders Hejlsberg 表示，TypeScript 專案源自一些龐大的 JavaScript 程式碼庫。隨著這些程式碼庫變得越來越大，維護工作變得異常艱難。後來基本上這些程式碼庫變成了“只寫的程式碼”。他補充說，因此我們需要理解程式碼的語意，而這個過程也降低了重構工作的難度。他表示：“這種語意的理解需要一個型別系統，而且在你開始新增型別系統時，你還可以新增程式碼的檔案。”Wall 也支援“良好的詞法作用域有助於重構”的觀點。

程式語言設計的未來

在談論到程式語言設計的未來時，James Gosling 分享了程式設計中一個未充分探索的領域——編寫使用 GPU 的程式碼。他強調說，目前我們的程式語言都無法直接利用 GPU，我們應該加大這個領域的發展。

Anders Hejlsberg 表示，程式語言不會像硬體或所有其他技術那樣快速地變化。就發展速度而論，程式語言更像是數學和人腦。他說：“我們仍然在使用 50 年前發明的語言進行程式設計，所有的函式式程式設計原理都是 50 多年前的研究成果。”

但是，他也相信，如今的程式語言趨於多正規化，不會嚴格區分面向物件程式設計或函式式程式設計等類別。

“語言正在走向多正規化。我覺得我們不應該再說我只喜歡面向物件的程式設計、指令式程式設計或函式式程式語言。”

如今，更重要的是我們需要瞭解最新的研究、新思維和新正規化，並優雅地將這些新思想融入到我們的程式設計風格中。