為什么我們需要更好的編程語言？
我一直在告訴別人：“編程非常了不起。”在你有任何想法的時候，都可以編寫軟件，然后愿望就實現了。這很真實。與建立物理的東西不同，首先你需要建立整個工廠，而軟件的擴張相對非常容易。你可以找到所有已經編譯好的組件，而且是免費的，拿來就可以用。建立好一段代碼后，就可以重復使用無數次，而無需花錢。聽起來很厲害的樣子。
但有時候不是這樣的。編程帶給人的驚喜只是暫時的。在建立了很多代碼以后，在寫代碼的過程中你會不斷遇到讓人迷惑的錯誤。一旦你習慣了特定語言和框架的模式后，一旦你需要第二種天性去掌握所選語言中非自然的語法時，編程的偉大之處就不復存在了。
更別提我們有無數種不同的編程語言。每當開發人員面對特殊語言的語法而深感沮喪時，他們都會想“為什么我們不能創建一種新的語言改正這個問題呢?”有些人還真的這么做了，很幸運的是自然選擇已經淘汰了很多很差的語言(有時也有意外，比如至今PHP還存在)。一旦一門新的語言開始在一群開發者中流行起來，那么恭喜你 ，現在又出現了一個新的開發者社區，他們互相合作，努力讓這門特殊的語言發展壯大。
每一種新語言的誕生所帶來的創新，都能造福我們每一個人。但是有時也有不利的一面。有些人可能寫了一些非常有用的開源JavaScript庫，但是從事Python的開發者卻完全沒法用。他們不得不自己寫一個Python版本的函數庫，或者用JavaScript重寫所有代碼。再想想當前有多少種語言和框架。如果你不覺得這很荒謬的話，那只能說明或許你在軟件開發這一行太長時間，已經習以為常了。
語言都包含些什么?
各種編程語言都在以下三個方面上有著很大的不同：語法、語義和標準庫。
沒錯，我知道，我過于簡化它們了，但是聽我給你解釋。
1. 語法
如果不遵循語法，那么你會在編輯器中看到各種彎彎曲曲的紅線，而且你的代碼也無法通過編譯器或解釋器。
JavaScript使用大括號，布爾型使用小寫的true和false，用//表示行注釋。
- function doSomething() {
- a = true;
- if (a) {
- ... // Do something.
- }
- }
Python用縮進，布爾型用首字母大寫的True和False表示，用#表示行注釋。
- def doSomething():
- a = True
- if a:
- ... # Do something.
Haskell又有完全不同的語法：
- doSomething :: IO ()
- doSomething = do
- let a = True
- if a
- then ... -- Do something.
- else return ()
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，那么我們就可以解決這個問題。雖然在語義上，調用print(“Hello”)與Java調用System.out.println(“Hello”)不同，但是其實它們可以是同一個API。
我們有兩種方法可以解決這個問題。要么我們讓大家都不要再使用標準庫了，轉而使用我們的“API層”。或者我們可以讓計算機自動推斷你使用的代碼。我并不看好“說服大家改變他們的方式”，所以我會選擇后一種方法。
我們不用為編程語言的標準庫中的每個函數都提供API。一般我們只可能用到標準庫中的幾個函數。我們可以自動將這些代碼從一種語言轉換到另一種語言。然后，我們只需要每個開發都用這些API替換具體的標準庫的調用。不用擔心，計算機依然需要你，至少現在需要。
第三步：把所有東西都做成API
現在我們有了干凈的代碼模塊定義的純粹的語義，并將與標準庫的交互抽象成了API。
下一步做什么?創建API。
現今的代碼庫有多個文件構成，彼此之間通過“import語句”互相引用。這對于我們來說很便利，但是這也意味著我們需要在腦海中勾畫代碼庫的結構。任何一個地方發生小的變化，都可能在不經意期間給別的地方帶來破壞性的影響，尤其是如果我們沒有做好自動測試的話。而且，代碼庫會不斷增長，而編譯的時間會逐漸加長。
也許有更好的方法解決這個問題。比如模塊化就是個好辦法。
我之前寫過關于模塊化的文章(點擊這里查看：https://medium.com/@fwouts/the-zenc-master-plan-c693bf3b265e)，基本上來說：每段獨立的代碼都應該抽象成API。我稱之為模塊。你無需在意一個具體的模塊使用什么語言編寫的。在寫模塊的時候，你不用導入這些文件。實際上，這時文件已不復存在。你可以直接使用API，它們會自動加載這些功能。
模塊有什么好處?
- 可以鼓勵大家考慮設計：首先你需要設計API
- 可以降低認知的開銷：你僅需要“填空”
- 簡化測試：你只需測試API，并可以模擬所有的依賴性
- 世界會變得更加美好：沒有了語言之間的壁壘，沒有了巨大的代碼庫;程序員更加快樂，客戶更加快樂
第四步：盡情享受
我不確定第三步之后會發生什么，但是我覺得所有人都會很滿意。
