編程語言扮演的3個角色，它鏈接了機器、開發者以及團隊！

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

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

    若是咱們能夠解決下面的這3個問題，不只僅可讓開發者的體驗變得超棒，同時也確定會有實質性地回報。

 

可考覈性問題

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

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

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

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

 

可讀性問題

    時常咱們須要讀不少代碼才能找到咱們所須要找的東西。信息的密度很低。老是感受代碼的因果聯繫怎麼那麼「扭曲」。

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

    讓代碼可讀不只僅是把變量名取好就能夠作到的。編程語言若是不提供相似協程，AOP，函數重載這些機制，代碼風格是沒法寫成咱們但願的那樣的。

 

異構計算問題

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

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

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

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

 

願景

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

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

        ✿ 相關的邏輯被集中到一塊兒，不須要跳到不少地方就能知道究竟是怎麼回事

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

    到頭來，全部的一切都和代碼是給人來讀的有關。人能夠很輕鬆地從各類抽象層次去檢視代碼，推測它的正確性。代碼裏所寫的就應該是腦殼裏所想的。

 

無論你是轉行也好，初學也罷，進階也可——【值得關注點擊進入】的編程學習進階俱樂部

涉及到：C語言、C++、windows編程、網絡編程、QT界面開發、Linux編程、遊戲編程、黑客等等......

 

一個活躍、高格調、高層次的程序員編程學習殿堂；編程入門只是順帶，思惟的提升纔有價值！