【CSDN 編者按】機器編程的可行性增大促使這一想法加快落入實地，事情的發展開始令人期待。英特爾為未來跨架構編程時代所設計的機器編程將會怎樣影響程式設計師的世界？軟體能否實現編寫軟體？
作者 | 鄭麗媛 責編 | 張文
頭圖 | CSDN 下載自東方 IC
近年來，隨著計算機領域的快速發展，逐漸形成了一股對立的趨勢：計算機資源愈發異構化，因而需要更多硬體領域的專家級程式設計師 VS軟體開發人員更青睞抽象高效的程式語言，導致硬體性能得不到充分發揮。
這樣的趨勢下，如果有一款工具可以讓計算機自己編程豈不是解決了這個矛盾？基於這種思考，英特爾提出了「機器編程」這個概念，旨在通過自動化工具提升開發效率。
機器編程是什麼？
在 2018 年英特爾研究院和麻省理工學院聯合發布的《機器編程的三大支柱》論文中，「機器編程」一詞首次出現在人們的視野。它融合了機器學習、形式化方法、程式語言、編譯器、計算機系統等多個領域。通俗地說，機器編程就是通過機器學習和自動化方法，設計出可以自己編寫軟體的軟體，即教系統自己編程。
除了上文所說，機器編程可以補充跨架構專業編程人員的缺口之外，它還能解決軟體開發和維護上的一大痛點問題： Bug 。機器編程的核心原則是：人類向機器表達他（她）的意圖，機器去自動創建完成該意圖所需的所有軟體。英特爾將機器自動創建軟體的部分稱為創造和適應，由此得出機器編程的三大支柱：意圖(Intention)、創造(Iinvention)和適應(Adaptation)。
英特爾首席科學家、英特爾研究院機器編程研究主任及創始人 Justin Gottschlich 表示：儘管目前軟體顯著提高了人們的工作效率，但在全球 78 億人中，只有 2700 萬人會編寫代碼，佔比不到 1%。因而，機器編程的未來願景是降低編程的門檻，讓每個人都能創建軟體，將這 1% 變成 100%。
英特爾推出機器編程研究系統 ControlFlag
抱著這份美好的願景，英特爾開始踏上了機器編程這段旅程的第一步。Justin 認為，要想讓機器編程真正能夠幫助到開發人員，那麼有兩點必不可少：
提高編碼員和非編碼員的工作效率；確保機器編程系統生成的是高質量、快速、安全的代碼。基於這兩點，發展機器編程關鍵的第一步是：改進軟體調試（Debug）。
所謂 Debug ，就是識別、分析和糾正軟體缺陷，讓軟體變得更加強大且可靠的過程。2017 年劍橋大學開展的一項調查顯示：美國程式設計師平均花費 50% 的時間在 Debug 上，這嚴重影響了工作效率。此外，Debug 本質上也意味著軟體的質量不合格。
再進一步研究發現，Debug 幾乎都是由於程式設計師向機器傳達意圖不正確導致的。而機器編程所追求的讓人機交流準確無誤，正好就可以糾正這一點。假設機器可以完美地捕捉到人的意圖，那麼 Debug 基本上就消失了。英特爾的實驗也得到了意外收穫：利用機器編程，程式設計師的工作效率提高了 2 倍，軟體的質量也得到了提升。
這個結果意味著機器編程的願景並非空想。上周五英特爾推出了可自主檢測代碼中錯誤的機器編程研究系統 ControlFlag ，雖然系統還處於早期階段，但在初步測試中，ControlFlag 就展現了非凡的魔力。它利用超過 10 億行未標記的產品級別代碼進行了訓練並學習了新的缺陷，這使得自我監督系統有望成為強大的生產力工具。
ControlFlag檢測 Bug 的功能正是通過機器編程實現的。具體來說，ControlFlag 通過被稱為異常檢測（anomaly detection）的功能進行運轉：通過學習經過驗證的例子來檢測正常的編程模式，來發現代碼中可能造成 Bug 的異常。值得一提的是，不論開發者使用的是何種程式語言，ControlFlag 都可以通過學習檢測到其中的異常。
此外，ControlFlag 也證明了它的強大。在分析 cURL （一個開源的命令行工具，被程式設計師廣泛地用於實現網際網路下載）時，ControlFlag 發現了一個之前從未被發現的異常，也就是說，ControlFlag 發現了被開發者審核過並且廣泛使用的產品級別代碼中隱藏的 Bug。因此，英特爾也開始評估在內部使用ControlFlag，以在軟體和固件產品化中尋找 Bug。
機器編程會導致失業？
然而，強大會不會意味著取代？功能如此優越的機器編程在未來是否會讓部分程式設計師失業？這種擔憂並不難理解，畢竟如果機器編程可以實現自動化構建程序，那原來做這件事的人該怎麼辦？
Justin 其實經常被問到這個問題，但 Justin 始終認為，機器編程如果成功，那未來只會創造數千萬甚至數億個就業機會，而非取代專業程式設計師使其失業。
他的理由很簡單，有兩個方面：
當今存在的大多數機器編程系統都需要大量的數據。數據通常是以代碼的形式存在，而代碼則是由專業程式設計師所編寫。因此，一旦自動化編程完全實現，那麼對高技能程式設計師的需求將會增加，因為專業程式設計師寫的代碼越多，那麼通過大量學習，所構建的機器編程系統就越先進；降低編程行業門檻。機器編程如果完全實現，那麼用戶就可以向機器表達他或她想要的系統從而進行自動化編程。只要有批判性思考的能力，並將軟體創造的步驟和想法邏輯合理化，那麼所有人都能編程的願景就不會遙遠。因此， Justin 一直堅持一個觀念：自動化不僅不會取代任何現有的程式設計師，反而會為全新類型的程式設計師創造非常大的平臺，讓他們可以毫無顧忌地發揮想像力。或許這些程式設計師的編程技能會稍遜色，但強大的創造性會彌補這個不足，只要有能力表達他們的想法，那麼機器和系統會幫他們把這些想法綜合起來做出軟體。
機器編程正處在拐點
Justin 曾經說過：機器編程正處於拐點，但拐點並非一夜之間到來。機器編程進入拐點，大致是因為三個基本進步的實現。
算法的進步。在確定性算法和隨機算法方面都得到了進步，這些形式化方法和機器學習算法為建立機器編程系統提供了大量的機會。目前很多可以實現的事情在 10 年前都做不到。算力的進步。如果無法以易於處理的形式去執行，那麼就算能夠執行算法，但卻需要 10 年、20 年才能完成。隨著過去 10 年英特爾在算力方面的進步，特別是異構計算方面，讓英特爾有了解鎖機器編程的第二塊鑰匙，成為了關鍵的轉折點。數據。大多數系統往往需要大量的數據，目前數據量正好非常豐富。以GitHub 為例，2020 年其代碼庫超過了 2 億。這是一個巨大的代碼量，因為任何一個代碼庫都可能包含多個源文件。而這些源文件，每一個都可能包含數百或數千行代碼。因此這個數字變得非常大，增長非常快。因此，就拐點而言，這三件事合在一起，才讓今天成為可能。
至於這是如何發生的，Justin 認為其驅動力是英特爾看見了未來即將進入異構系統的時代。異構系統編程人員的缺失，讓英特爾意識到需要某種機制，讓程式設計師或非程式設計師不僅能訪問異構硬體，還能充分利用可用資源。同時這也是英特爾機器編程的基本驅動力之一。
機器編程已經起步，如果完全實現，那全民編程的時代將不再遙遠，你準備好了嗎？