怎樣解決編程語言之間的差異性問題？

關鍵時刻，第一時間送達！

毫無疑問，不同的編程語言間存在著很多差異性。那麼對於這種差異性開發者應如何解決？本文就來一探究竟。

以下為譯文：

我一直在告訴別人：「編程非常了不起。」在你有任何想法的時候，都可以編寫軟體，然後願望就實現了。這很真實。與建立物理的東西不同，首先你需要建立整個工廠，而軟體的擴張相對非常容易。你可以找到所有已經編譯好的組件，而且是免費的，拿來就可以用。建立好一段代碼後，就可以重複使用無數次，而無需花錢。聽起來很厲害的樣子。

但有時候不是這樣的。編程帶給人的驚喜只是暫時的。在建立了很多代碼以後，在寫代碼的過程中你會不斷遇到讓人迷惑的錯誤。一旦你習慣了特定語言和框架的模式後，一旦你需要第二種天性去掌握所選語言中非自然的語法時，編程的偉大之處就不復存在了。

更別提我們有無數種不同的編程語言。每當開發人員面對特殊語言的語法而深感沮喪時，他們都會想「為什麼我們不能創建一種新的語言改正這個問題呢？」有些人還真的這麼做了，很幸運的是自然選擇已經淘汰了很多很差的語言（有時也有意外，比如至今PHP還存在）。一旦一門新的語言開始在一群開發者中流行起來，那麼恭喜你 ，現在又出現了一個新的開發者社區，他們互相合作，努力讓這門特殊的語言發展壯大。

每一種新語言的誕生所帶來的創新，都能造福我們每一個人。但是有時也有不利的一面。有些人可能寫了一些非常有用的開源JavaScript庫，但是從事Python的開發者卻完全沒法用。他們不得不自己寫一個Python版本的函數庫，或者用JavaScript重寫所有代碼。再想想當前有多少種語言和框架。如果你不覺得這很荒謬的話，那隻能說明或許你在軟體開發這一行太長時間，已經習以為常了。

語言都包含些什麼？

各種編程語言都在以下三個方面上有著很大的不同：語法、語義和標準庫。

沒錯，我知道，我過於簡化它們了，但是聽我給你解釋。

1. 語法

如果不遵循語法，那麼你會在編輯器中看到各種彎彎曲曲的紅線，而且你的代碼也無法通過編譯器或解釋器。

JavaScript使用大括弧，布爾型使用小寫的true和false，用//表示行注釋。

Python用縮進，布爾型用首字母大寫的True和False表示，用#表示行注釋。

Haskell又有完全不同的語法：

2.語義

所有編程語言都有大多數相同的特徵：變數賦值、數字相加、字元串操作、調用函數、等等。

然而，每種語言都有特殊的思想，以特定的方式運行。可以將它們劃分成不同的模式（命令式、面向對象、函數式），但是即便是兩個相同模式的編程語言在細節上也是完全不同的。

在「聲明類」，「調用函數」，或「定義參數的類型」時，你定義了程序的語義。有些語言遵循這樣一套規則，而其他的遵循別的規則。比如：C++中聲明的類可以延伸到多個類。當你使用「+」將數字和字元串加到一起的時候，根據語言的語義會得出不同的結果。一些編程語言會因為類型不匹配而導致編譯失敗，但是有些編程語言會自動將數字轉換成十進位的字元串。

語法與語義的關係就相當於用單詞（語法）來表達想法（語義）。你可以通過語言的語法來表達語義。

3.標準庫

最後，每種語言都有各自的軟體包，我們稱之為「標準庫」。

在Python中，你可以調用如下函數：

print()：在控制台輸出信息

len()：返回數組的長度

以及各種實用的模塊，例如：json，threading，等等

在JavaScript中，你可以使用console.log()代替print()，可以訪問Object、Array等類。

標準庫是一門語言中重要的組成部分。它可以為語言帶來活力，沒有標準庫，你無法簡單地做出任何東西。

很諷刺的是，並沒有「標準的標準庫」。每個標準庫基本上都不同於其他庫：一些庫只提供最低限度的方法，而有些庫則提供非常廣泛的函數，所以開發人員基本上不需要依賴任何第三方庫。

基本的想法

以上我們介紹了一門語言的構成，接下來我有一個基本的想法：我們是否可以找到一種方法清晰地分割語法、語義和標準庫呢？我們又如何實現這一想法呢？

第一步：只有程序員關心語法

我想解決的第一個問題就是語法。編譯器和解釋器擁有更加有效的方式表現代碼，我們稱之為抽象語法樹。我們用代碼描述的內容最終可以用如下抽象語法樹表示：

圖：歐幾里得演算法的抽象語法樹

如果仔細觀察，你會發現上述語法樹可能來自多個語言。是Python？是JavaScript？還是C++？這都無所謂：所有這些語言都擁有同一個語法樹。

當然，現實的例子會更加複雜。這就是為什麼我們用文本寫代碼的原因：更加緊湊，更加易於書寫，還有更加易於閱讀（有人可能有不同的看法）。從編程誕生的第一天，我們採用的就是這種方法，很少有人對此質疑。

對於一個更加現實的例子來說，抽象語法樹會描述所選語言的語義（例如：類的定義）。但是擁有類似語義的語言之間還是可以共享同一個抽象語法樹，並可以擴展到一定範圍。這非常實用，因為你可以自動轉化部分代碼。

所以，我們可以把語法想像成抽象語法樹之上的人類思維。代碼可能並不會以文本的形式存儲在任何地方，僅在文本編輯器內。如果你想在特殊的語言上使用不同的語法，也完全可以。這不會影響到別人。

我其實有點驚訝怎麼沒有一種工具可以將代碼從一種語言轉換成另一種語言，這完全可行啊。我猜肯定有人試過，但是放棄了，因為如果不將整個標準庫轉換過去的話是沒有實用性的。很明顯，我也在做這方面的嘗試。

第二步. 將標準庫抽象成API

API是一個非常高明的概念。每個軟體都可以通過API與其他軟體溝通。移動端的應用可以通過API與伺服器交流。伺服器可以通過API與資料庫交流。每個人都可以通過API與他人對話。這是一件很酷的事情。

為什麼我要在這裡討論API？因為這正是我們所需要的。API是語言的媒介。它們是一套語義，可以描述一個特殊代碼模塊對外提供的功能。無論是函數庫，HTTP伺服器，或是別的。

聲明API的方式多種多樣。可以是NPM上的JavaScript模塊，並在README文件內提供API文檔。也可以是代碼中明確聲明的API，比如TypeScript模塊。也有可能並沒有API的聲明，也沒有清晰的文檔。

但是重要的是：API聲明了代碼模塊的」對外介面「，你可以用其他語言重寫模塊內部的代碼，但API不會發生改變。這就是API的魅力所在。雖然編程語言一團糟，但是API很酷。

我們有兩種方法可以解決這個問題。要麼我們讓大家都不要再使用標準庫了，轉而使用我們的「API層」。或者我們可以讓計算機自動推斷你使用的代碼。我並不看好「說服大家改變他們的方式」，所以我會選擇後一種方法。

我們不用為編程語言的標準庫中的每個函數都提供API。一般我們只可能用到標準庫中的幾個函數。我們可以自動將這些代碼從一種語言轉換到另一種語言。然後，我們只需要每個開發都用這些API替換具體的標準庫的調用。不用擔心，計算機依然需要你，至少現在需要。

第三步：把所有東西都做成API

現在我們有了乾淨的代碼模塊定義的純粹的語義，並將與標準庫的交互抽象成了API。

下一步做什麼？創建API。

現今的代碼庫有多個文件構成，彼此之間通過「import語句」互相引用。這對於我們來說很便利，但是這也意味著我們需要在腦海中勾畫代碼庫的結構。任何一個地方發生小的變化，都可能在不經意期間給別的地方帶來破壞性的影響，尤其是如果我們沒有做好自動測試的話。而且，代碼庫會不斷增長，而編譯的時間會逐漸加長。

也許有更好的方法解決這個問題。比如模塊化就是個好辦法。

我之前寫過關於模塊化的文章（點擊這裡查看：https://medium.com/@fwouts/the-zenc-master-plan-c693bf3b265e），基本上來說：每段獨立的代碼都應該抽象成API。我稱之為模塊。你無需在意一個具體的模塊使用什麼語言編寫的。在寫模塊的時候，你不用導入這些文件。實際上，這時文件已不復存在。你可以直接使用API，它們會自動載入這些功能。

模塊有什麼好處？

可以鼓勵大家考慮設計：首先你需要設計API

可以降低認知的開銷：你僅需要「填空」

簡化測試：你只需測試API，並可以模擬所有的依賴性

世界會變得更加美好：沒有了語言之間的壁壘，沒有了巨大的代碼庫；程序員更加快樂，客戶更加快樂

第四步：盡情享受

我不確定第三步之後會發生什麼，但是我覺得所有人都會很滿意。

聲明：本文獲作者Fran?ois Wouts 翻譯授權。

原文：https://medium.com/@fwouts/the-fucked-up-world-of-programming-a8edb64fcfa

譯者：彎月，責編：言則

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！