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

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

對(duì)于編程的“命運(yùn)”我很關(guān)心，因?yàn)槲腋敢鈪⑴c那些讓我們接近終極編程模式的開源項(xiàng)目。從我的經(jīng)驗(yàn)來看，這類工作壽命更長(zhǎng)，影響更大，有助于推動(dòng)整個(gè)編程領(lǐng)域的發(fā)展。

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

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

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

這一觀點(diǎn)我個(gè)人并不認(rèn)同，因?yàn)槲蚁嘈牛辽?，函?shù)式編程范式將逐漸取代面向?qū)ο蠛兔钍骄幊谭妒剑m然函數(shù)式編程未必就是終極編程范式）。

• 人工智能？

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

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

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

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

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

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

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

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

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

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

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

請(qǐng)?jiān)试S我舉幾個(gè)例子，說明這種將用戶空間（userland）代碼數(shù)學(xué)化的趨勢(shì)已經(jīng)開始顯現(xiàn)：

• 內(nèi)存管理

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

事實(shí)上，Rust 是證明這一規(guī)則的例外，因?yàn)槿藗兤毡檎J(rèn)為 Rust 更適合于構(gòu)建運(yùn)行時(shí)，而非用于意圖的高級(jí)規(guī)范。

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

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

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

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

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

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

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

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

• 評(píng)估順序（特別是懶惰）

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

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

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

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

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

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

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

• 包管理

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

• 錯(cuò)誤處理

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

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

• 日志

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

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

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

• 服務(wù)

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

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

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

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

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

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

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

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

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

原文鏈接：