本文最初發(fā)表于作者個人博客，經(jīng)原作者 Gabriel Gonzalez 授權(quán)，InfoQ 中文站翻譯并分享。

我花了不少時間思考這個問題：編程歷史的終結(jié)可能是什么樣子的。我所說的“歷史的終結(jié)”，就是編程范式不再有重大發(fā)展的時候。

對于編程的“命運(yùn)”我很關(guān)心，因為我更愿意參與那些讓我們接近終極編程模式的開源項目。從我的經(jīng)驗來看，這類工作壽命更長，影響更大，有助于推動整個編程領(lǐng)域的發(fā)展。

那么，對于編程而言，歷史的終結(jié)會是怎樣的呢？是不是：

• 已經(jīng)到來了？

一些人將編程視為已經(jīng)解決的問題，并將所有新的語言和范式視為舊語言或范式的翻版。在他們看來，剩下的工作就是慢慢地優(yōu)化事物，排除錯誤，或者解決非技術(shù)性的問題（比如人事管理或者資金），從而完善我們的工藝。

這一觀點我個人并不認(rèn)同，因為我相信，至少，函數(shù)式編程范式將逐漸取代面向?qū)ο蠛兔钍骄幊谭妒剑m然函數(shù)式編程未必就是終極編程范式）。

• 人工智能？

或許機(jī)器可以將我們的自然語言指令翻譯成代碼，從而減輕了我們準(zhǔn)確表達(dá)意圖的負(fù)擔(dān)。或許一些足夠智能的、人工智能驅(qū)動的 IDE 可以為我們自動地完成大多數(shù)程序。

同樣，我也不相信這一觀點，而且我認(rèn)為 Dijkstra 在他的文章《論“自然語言程序設(shè)計”的愚蠢性》（On the foolishness of 'natural language programming**'
）中很好地推翻了這一觀點。

老實說，我不能肯定什么是正確答案，但是我會給出我自己關(guān)于編程的歷史終結(jié)的猜測。

我的觀點是，編程的下一個邏輯步驟是分成兩個沒有重疊的編程領(lǐng)域：

• 運(yùn)行時構(gòu)建

• 數(shù)學(xué)編程語言

具體地說，我預(yù)期編程語言在本質(zhì)上將發(fā)展成為更具數(shù)學(xué)特性的語言，讓用戶編寫的程序像純粹的數(shù)學(xué)表達(dá)式一樣表達(dá)其意圖。

舉例來說，考慮下列布爾邏輯“和”運(yùn)算符和函數(shù)合成運(yùn)算符的數(shù)學(xué)規(guī)范：

這些數(shù)學(xué)規(guī)范也是可執(zhí)行的 Haskell 代碼（盡管使用了額外的括號來與主流函數(shù)語法相似）。Haskell 是編程語言的一個例子，它的代碼希望類似于純數(shù)學(xué)表達(dá)式和定義。

由于現(xiàn)實世界是混亂的，因此任何呈現(xiàn)這種理想化數(shù)學(xué)界面的語言都需要在幕后引入大量的復(fù)雜性，在這里，運(yùn)行時構(gòu)建可以用來掩蓋這些“丑陋”的細(xì)節(jié)。

換言之，我預(yù)言編程的歷史終結(jié)將是連接純數(shù)學(xué)表達(dá)式和現(xiàn)實世界的接口。

請允許我舉幾個例子，說明這種將用戶空間（userland）代碼數(shù)學(xué)化的趨勢已經(jīng)開始顯現(xiàn)：

• 內(nèi)存管理

手動內(nèi)存管理曾經(jīng)是大多數(shù)編程語言的“用戶空間”問題，但新語言的總體趨勢是自動內(nèi)存管理（Rust 除外）。以前，內(nèi)存管理是程序員必須關(guān)心的一個明顯的副作用，現(xiàn)在，把內(nèi)存管理下推到運(yùn)行時（通過垃圾收集或其他方式），使編程語言更加純粹，使它們更接近于理想化的數(shù)學(xué)表達(dá)式。

事實上，Rust 是證明這一規(guī)則的例外，因為人們普遍認(rèn)為 Rust 更適合于構(gòu)建運(yùn)行時，而非用于意圖的高級規(guī)范。

• 函數(shù)式編程（尤其是純函數(shù)式編程）

函數(shù)式編程是向更傾向于數(shù)學(xué)化的編程方向邁進(jìn)的一個重要步驟：

• 以表達(dá)式代替語句；

• 以純函數(shù)代替副作用；

• 以代數(shù)數(shù)據(jù)類型代替非對象；

• 以遞歸代替循環(huán)。

關(guān)于這一點，我在《為什么我更喜歡函數(shù)式編程》（Why I prefer functional programming）一文中詳細(xì)討論過。

但是，函數(shù)式編程并非自由的勝利。有效地支持高階函數(shù)和閉包并非易事（特別是對于編譯語言來說），這就是為什么那些較不復(fù)雜的語言實現(xiàn)通常更傾向于命令式而非函數(shù)式。

• 評估順序（特別是懶惰）

對于 Haskell 的評估模型，我一直認(rèn)為“懶惰評估”并不適合推廣其優(yōu)點。但我更傾向于認(rèn)為，Haskell 擁有“自動評估管理”（注：這一解釋與實際情況相差不大，因為 Haskell 標(biāo)準(zhǔn)只規(guī)定了一個非嚴(yán)格的評估策略。GHC 是懶惰的，但是 Haskell 這一預(yù)言標(biāo)準(zhǔn)并沒有要求懶惰實現(xiàn)。詳情請參閱《懶惰與不嚴(yán)格》（Lazy vs. non-strict?）。換句話說，程序員將表達(dá)式指定為依賴于計算的圖，而運(yùn)行時則找出最有效的順序來減少圖。

這里還有一個例子，我們把過去用戶空間問題（評估順序）推進(jìn)到了運(yùn)行時。忽略評估順序可以讓我們用更數(shù)學(xué)的方法來指定事物，因為評估順序在數(shù)學(xué)上同樣是不相關(guān)的。

在研究上述趨勢時，出現(xiàn)了一種常見的模式：

• 下面是把用戶空間問題推送到運(yùn)行時問題：

• 使程序更接近純數(shù)學(xué)表達(dá)式，并且：

• 顯著地增加了運(yùn)行時的復(fù)雜性。

你可能會想：在不遠(yuǎn)的將來，還有哪些用戶空間問題可能會被推送到運(yùn)行時問題上呢？我能想到的例子如下：

• 包管理

這次是如此的接近未來，以至于它已經(jīng)發(fā)生了（見：Nix 和 Dhall）。這兩種語言都為獲取代碼提供了內(nèi)置支持，而沒有使用獨(dú)立的包管理工具來處理帶外包。這一語言級別的支持允許程序嵌入外部代碼，就好像它是一個純粹的子表達(dá)式，更接近于數(shù)學(xué)化的理想。

• 錯誤處理

這個問題需要更多的解釋：我認(rèn)為，類型系統(tǒng)是一個邏輯結(jié)論，它把錯誤處理推入“運(yùn)行時”（實際上是推到了類型檢查器而非運(yùn)行時）。在 Dhall 語言中，這種想法得到了充分的體現(xiàn)：Dhall 不能用來引發(fā)或捕捉錯誤的用戶空間支持，因為所有的錯誤都是類型錯誤。（注：這有點過于簡化，因為 Dhall 支持 Optional 值，你可以使用 unions 在 Dhall 中模擬錯誤，但是它們不常以這種方式出現(xiàn)，而且通常 Dhall 代碼使用類型檢查器捕獲錯誤。Dhall 是一種完全函數(shù)式編程語言，它做了很多工作來防止運(yùn)行時出錯，例如，禁止比較文本是否相等。另外，該語言在技術(shù)上依賴于類型，并且支持在類型檢查時測試任意代碼，以便靜態(tài)地捕捉錯誤。）

依賴類型 和 完全 函數(shù)式編程語言的發(fā)展使我們與把錯誤處理推到運(yùn)行時的目標(biāo)更加接近。

• 日志

事實上，我感到驚訝的是，尚未完成對大量日志記錄的語言支持（或者，也許發(fā)生了，但是我沒有注意到）。在語言中，這似乎是一件可以實現(xiàn)的很普通的事情，特別是在性能不敏感的應(yīng)用領(lǐng)域中。

很多語言已經(jīng)支持分析了，如果用戶愿意為日志花費(fèi)性能預(yù)算，那么將分析支持轉(zhuǎn)變?yōu)槿罩局С挚雌饋聿⒉皇且粋€什么大的飛躍。

日志是典型的副作用之一，它是一種“丑陋”的細(xì)節(jié)，“破壞”了本來是純粹的、數(shù)學(xué)的代碼。

• 服務(wù)

面向服務(wù)的架構(gòu)是另一種傾向，它會阻礙純無副作用代碼的編寫。

我并不清楚面向服務(wù)的語言運(yùn)行時是什么樣子，但是我認(rèn)為，目前的“無服務(wù)器”解決方案并不是我心中所想的那樣。諸如 AWS Lambda 之類的東西還是太低級了，無法提升本質(zhì)上是數(shù)學(xué)化的代碼。舉例來說，如果編程過程中有任何部分需要使用獨(dú)立的工具來部署或管理無服務(wù)器的代碼，那么這與編寫純數(shù)學(xué)表達(dá)式大相徑庭。必須有與“無服務(wù)器代碼的 Nix 或 Dhall”類似的東西。

你可以批評我的預(yù)言，說它是不可證偽的。看起來我可以將編程中的新進(jìn)展解釋為屬于運(yùn)行時構(gòu)建或數(shù)學(xué)表達(dá)式范疇。

正因為如此，我想強(qiáng)調(diào)預(yù)言中的一個關(guān)鍵支柱：運(yùn)行時和數(shù)學(xué)表達(dá)式的劃分會隨著時間而變得更明顯。它是預(yù)言的實際內(nèi)容，我們可以從語言中推斷出一些證據(jù)。

當(dāng)前，許多主流編程范式和工程組織混淆了這兩種職責(zé)，因此，你最終會發(fā)現(xiàn)，人們編寫的軟件項目是操作邏輯（運(yùn)行時問題）和“業(yè)務(wù)邏輯”（數(shù)學(xué)意圖）的混合體。

在我的預(yù)言中，工程領(lǐng)域?qū)碛芯幊陶Z言理論或編程語言工程經(jīng)驗的人產(chǎn)生強(qiáng)烈的需求。這些人將負(fù)責(zé)構(gòu)建專用語言和運(yùn)行時，將盡可能多的操作問題抽象出來，以支持各自企業(yè)的純數(shù)學(xué)領(lǐng)域特定語言。這些語言將會被另一組人所使用，其目的是將人們的意圖轉(zhuǎn)化為數(shù)學(xué)表達(dá)式。

這個預(yù)言的一個結(jié)果就是，在不遠(yuǎn)的將來，你會看到編程語言的“寒武紀(jì)大爆發(fā)”。當(dāng)語言工程師把更多的操作問題推到運(yùn)行時中時，當(dāng)然，他們需要根據(jù)特定的目標(biāo)或組織需求對運(yùn)行時進(jìn)行定制，而非嘗試編寫一種通用語言。換言之，隨著每種新語言適應(yīng)其各自的利基市場，在語言運(yùn)行時（和類型檢查器）中會出現(xiàn)明顯的碎片化現(xiàn)象。

雖然存在一些運(yùn)行時碎片，但你在用戶空間代碼中看到與此相反的趨勢：用這些不同的語言編寫的程序?qū)㈤_始更接近于彼此，因為他們本質(zhì)上變得更數(shù)學(xué)化了。數(shù)學(xué)表達(dá)式在某種意義上將成為用戶空間代碼的可移植“通用語言”，尤其是當(dāng)非數(shù)學(xué)問題被推到相應(yīng)語言的運(yùn)行時。

這種預(yù)言更容易被證偽。

原文鏈接：