【藍因子教育】編程語言扮演3個角色，連接機器、開發者及團隊！

一門編程語言同時扮演了3個不同的角色：它連接了機器，它連接了開發者，它連接了團隊。

然而在這些角色上，現有的編程語言都有嚴重的問題。

如果我們可以解決下面的這3個問題，不僅僅可以讓開發者的體驗變得超棒，同時也肯定會有實質性地回報。

可考覈性問題

軟件開發的最大危機是缺乏可考覈性。

理想的情況是，總有一個團隊對整體負責，然後他們把職責分派給下一層的多個團隊。就像結構化編程所許諾地那樣分工方式。

然而在這個到處都是微服務的世界裡，職責以碎片化地方式從一個團隊傳遞給許多其他的團隊，導致業務方的負責人疲於給多個技術團隊重複溝通。更爲重要的是，這導致了沒有人可以對最終業務收益負責。

爲什麼這個問題和編程語言相關？因爲我們所寫的每個function，每個class都是關於如何分拆問題的。語言不僅僅描述了邏輯，它還塑造了我們的世界觀，如何把大問題拆解爲小問題，又如何把小的解決方案拼裝回大的解決方案。

可讀性問題

時常我們需要讀很多代碼才能找到我們所需要找的東西。信息的密度很低。總是感覺代碼的因果聯繫怎麼那麼“扭曲”。

同時代碼重用也不可避免地犧牲了可讀性，因爲你要跳過那些和你的特定使用場景無關的通用邏輯。非功能性需求同時又和本來已經很複雜的功能性邏輯糾纏到一起。比如大段大段的錯誤處理就是導致代碼很不好讀的常見原因之一。

讓代碼可讀不僅僅是把變量名取好就可以做到的。編程語言如果不提供類似協程，AOP，函數重載這些機制，代碼風格是無法寫成我們希望的那樣的。

異構計算問題

主流語言對於並行和分佈式計算的支持是以編譯器hint和庫的形式來實現的，其世界觀基本停留在PDP-11只有一個線性執行的CPU的年代。

今天在一臺機器上有多種執行引擎（SIMD, GPU）已經司空見慣了，在一個軟件內同時使用他們中的多個也越來越普遍。

而且內存模型也不僅僅是一個大的heap，對於不同的執行設備，可能有多級的heap。

編程語言應該對實際的執行設備提供更接近真實的抽象，而不是把我們的思維和表達限制在過時的計算模型上。

願景

理想的編程語言應該具有下面這些特性：

✿ 職責應該從最頂層到最底層逐級分解，總會有那麼一個團隊可以對全局負責

✿ 相關的邏輯被集中到一起，不需要跳到很多地方就能知道到底是怎麼回事

✿ 語言應該能夠描述現代的計算環境，包括SIMD/GPU/微服務等多種計算模型

到頭來，所有的一切都和代碼是給人來讀的有關。人可以很輕鬆地從各種抽象層次去檢視代碼，推測它的正確性。代碼裡所寫的就應該是腦袋裡所想的。