【編者按】程式語言之於作業系統，意味著什麼？本文作者飛漫軟體創始人魏永明經過二十餘年的作業系統開發探索，明確提出程式語言是自主基礎軟體，尤其是作業系統的重要抓手。如果說作業系統是基礎軟體生態裡的皇冠，那程式語言就是王冠上的明珠。如果沒有自己的程式語言，那所謂的自主，就是海市蜃樓、空中樓閣。由此，他走上了開源程式語言的探索與實踐之路。

作者 | 魏永明 責編 | 唐小引

出品 | 《新程式設計師》編輯部

從低迷的 Linux 桌面系統說起

全世界範圍內的開源運動浩浩蕩蕩，滾滾向前。Linux 核心作為開源軟體中的傑出代表，在雲計算、伺服器端、 智慧手機端、嵌入式系統中的成功舉世公認。截止 2021 年底，Linux 在伺服器領域佔據了 96%的市場份額，在超級計算機領域幾乎佔領了全部市場，在雲計算基礎設施領域佔據了 90%的市場份額，在智慧手機領域也佔有 85%的市場份額。現今，在人們日常的工作和生活中，Linux 核心幾乎無處不在。但與此相反的，則是 Linux 桌面系統地位不斷下滑。據統計，長期以來，Linux 桌面系統的市場份額徘徊在 2%左右，而原來被微軟 Windows 壓得喘不過氣來的 macOS 系統，卻在近幾年取得了不小的進步，獲得了超過 10%的市場份額。

自 2000 年以來，全球有眾多公司如 Red Hat、SUSE 以及中國的若干企業一直在嘗試打造基於 Linux 核心、GNU 工具以及 X Window、GNOME 或 KDE 的桌面系統。但二十年來，我們並沒有得到一個可以媲美 Windows 或 macOS 的桌面系統，這其中的教訓值得深思。究其原因，大家都會指點一二。比如 Linux 桌面系統的模仿痕跡太重，技術上始終跟隨 Windows，也沒有自己的產品特色；缺乏 Office 這樣的關鍵應用軟體；各種發行版滿天飛，造成嚴重的碎片化問題，還導致應用之間的互相容性問題等。

為什麼二十年來，全世界有那麼多企業和社群前赴後繼、努力打造的 Linux 桌面系統，卻始終無法走向大眾市場，而僅僅侷限於少數狂熱的愛好者當中？

再以本人的親身經歷為例。筆者搞了二十多年嵌入式視窗和圖形系統——MiniGUI，最初模仿 Win32 提供 C 語言的應用程式設計介面。在本世紀最初的十多年間，MiniGUI 在機頂盒、功能手機、數碼相框等產品中得到了大量的應用。但自從 Google 開源釋出了 Android 作業系統之後，包括 MiniGUI 在內的很多嵌入式基礎軟體，都遇到了前所未有的危機，這其中也包括針對嵌入式系統的輸入法、字型、瀏覽器等多款軟體產品。為了應對這一危機，我們也曾做出過一些嘗試，比如提供類似 Visual Studio 一樣的介面設計器、類 iPhone 的 UI 特效、對 Java J2SE 應用框架的支援等。然而，這些嘗試和 Android 這種具有全新作業系統架構和應用框架的現代作業系統相比，實在不堪一擊。

這引得我不得不思考：嵌入式領域是本世紀初興起的產業，當時，我們在這個領域的基礎軟體水平和美國差不了多少，而且坐擁全球最大的消費類電子產品市場，但為什麼在其後十多年的發展競爭中，我們仍然落敗於美國？

程式語言是作業系統獲得突破的重要抓手

儘管我們可以將自身發展不力的原因歸咎於政府保護智慧財產權政策不完善等因素，但我們也不得不承認，在引領技術潮流方面，我們差的不是一星半點：我們的基礎軟體行業，和 Linux 桌面系統一樣，一直將自己定位為追隨者，始終沒有走出模仿的怪圈。要走出這個怪圈，我們首先要想清楚作業系統這類基礎軟體的第一使用者是誰，即我們首要服務於哪類使用者。

我的觀點是，類似作業系統這樣的基礎軟體，其首要使用者是開發者。一個基礎軟體，不論是作業系統還是資料庫，只有首先滿足了開發者的需求，服務甚至取悅開發者，才能建立起獲得進一步成功的基礎。重視開發者，優先為開發者服務，是基礎軟體的生存之道。其道理不言而喻：一款基礎軟體要獲得大規模的應用，就離不開開發者，而基礎軟體的作者本身，縱有七十二變，也不可能把全世界的應用需求都給滿足了。

只有將開發者定義為基礎軟體，尤其是作業系統的第一使用者，我們的思路才可能有一個重要的轉變。

如果我們簡單回顧一下成功作業系統的發展，就可以得出這些作業系統一開始就不遺餘力地為服務開發者而努力。比如微軟，從 Windows 3。0 開始，就為降低 Windows 上的應用開發門檻在努力，這其中就包括 Visual C++、Visual Basic 以及後來的 Visual Studio、C#程式語言和。Net 應用框架。蘋果和谷歌圍繞各自作業系統所走的道路也類似。發展到今天，我們可以看到幾乎所有成功的作業系統都有自己專屬的一種程式語言以及圍繞其打造的獨特的應用框架。

作為反面案例，Linux 桌面系統上從未出現過任何專屬的程式語言、應用框架以及開發工具。在當前市場趨勢下，面對跨平臺和融合終端應用的開發需求，Linux 桌面系統更是乏善可陳。GNOME、KDE 兩大陣營，一個基於 C 語言，一個基於 C++ 語言，圍繞這兩個程式語言的應用框架，沿用的仍然是二十年前 Unix 工作站所使用的技術和框架。諷刺的是，Linux 桌面系統上使用最廣的開發工具，是微軟開發的 Visual Studio Code。

圖源：視覺中國

此前，我曾幾度闡述過程式語言對一個作業系統的重要性。簡而言之，程式語言之所以重要，是因為程式語言是確定一個系統長相的重要基因。就比如 C 語言，它適合開發貼近硬體的程式，而 C++，適合用於開發中間件。國外還有很多專注特定領域的程式語言，比如 Go 語言適合開發伺服器軟體，因為它天生為併發程式設計設計。程式語言可以確定一個系統的長相，也決定了這個系統的軟體棧，及其配套的開發工具，還可以成為解決一些頑疾的靈丹妙藥。因此，程式語言是自主基礎軟體，尤其是作業系統的重要抓手。如果沒有我們自己的程式語言，那所謂的自主作業系統，就是海市蜃樓、空中樓閣。

因此，如果我們要發展自主的作業系統，就必須走出模仿的怪圈，而若想成為技術上的引領者，就要嘗試為自己的作業系統設計一款全新的程式語言。沒有自主的程式語言以及圍繞其上的自主應用框架，對作業系統而言，就如同缺失了靈魂一樣，便無法勝任技術引領者的角色。

目前，在中國信創領域，中國政府正在推廣基於 Linux 的桌面系統以及嵌入式系統，在政府意志的推動之下，相關的技術積累和市場推廣正在穩步推進，曾經困擾業界多年的關鍵應用，如辦公套件、輸入法等，透過中國本土的商業軟體產品得到了有效解決。根據統計，單單中國政府的桌面系統，存量市場就超過了億套，每年的新增安裝量近五百萬套，如果再加上一些關鍵行業和要害部門（如能源、交通等），足以支撐全球 10% 的桌面系統市場份額。這將給基於 Linux 的桌面系統和嵌入式系統帶來前所未有的巨大市場機遇。然而，如果我們僅僅止步於跑馬圈地，而無視發展自主程式語言的重要性，到頭來也將竹籃打水一場空。

下一代作業系統需要什麼樣的程式語言？

隨著雲計算和物聯網技術的普及，現在的應用跟二十年前大不一樣了，最大的特點是需要聯網、跨平臺，而且可能要執行在不同型別的裝置上，我們暫且稱之為 “融合終端”應用。在滿足融合終端類應用需求這一方面，主流的作業系統廠商在做全新的嘗試，比如蘋果為 macOS、iOS、padOS、watchOS 開發 Swift 程式語言，谷歌的 Flutter 使用 Dart 程式語言，微軟也正在為 Universal App 做技術上的準備等等。

作業系統巨頭技術生態佈局（圖源：《新程式設計師》）

顯然，要在這場競爭中獲勝，需要我們設計新的、雲計算和物聯網友好的程式語言和開發工具。一方面，可用來滿足融合終端類應用的需求，另一方面還可用於提高應用的開發效率，同時，還可以成為作業系統生態的護城河。

那麼什麼樣的程式語言是符合未來趨勢的？對此，目前階段很難準確描述。但我們可以嘗試從宏觀上描述適應上述全新需求的程式語言可能的主要技術特徵：

描述式語言，易讀且容易理解，甚至可支援開發者使用母語程式設計，從而讓非職業程式設計師也能編寫出滿足需求的程式。

具有更高抽象層次的程式語言，開發者可以使用更少的程式碼實現更多的工作，且無需過多關心技術細節。

提供抽象的跨平臺可移植介面。透過全新的介面設計來遮蔽底層作業系統或者平臺的差異，這是跨平臺的必然選擇。

支援現代程式設計技術，如動態特性，對協程、併發、閉包等的支援。

良好的可擴充套件性和伸縮性，既可以用來開發指令碼程式，也可以支援大型分散式應用的開發。

功能和效能的良好平衡，使之可用於嵌入式系統，甚至物聯網裝置端。

一旦我們為未來的融合終端應用設計了自己的程式語言，尤其是讓程式設計模式都發生巨大變化的語言，那就可以自頂向下去設計一個新的作業系統。這個作業系統甚至可以涵蓋雲端、客戶端、嵌入式系統和物聯網。而核心、工具鏈、視窗系統、介面構件庫、包管理系統，所有這些底層的技術將成為“汽車引擎蓋”下面的東西，一般的應用開發者無需關心這些技術。如此，便有了服務開發者的基礎。在此之上，我們利用或者圍繞新的程式語言開發 IDE（整合開發環境）、自動化測試和部署框架、關鍵應用軟體、應用商店、特定應用領域內的第三方執行時函式庫等等，而這一切，合起來便是作業系統的生態。

自主開源程式語言設計與開發之路

為了踐行上述所講的理論，我提出並開發了全新的程式語言 HVML（Hybrid Virtual Markup Language，中文名為呼嚕貓）。這是一款通用、易學的開源程式語言，從 2020 年 7 月提出並公開第一份規範草案，到 2021 年 7 月成立攻堅團隊著手 HVML 直譯器（PurC）的開發，2022 年 7 月 31 日，在 GitHub 上開放了 HVML 相關的六大原始碼倉庫（或原始碼包），這標誌著 HVML 1。0 正式釋出，這其間已經走過了兩年的時光。

而在過去整整一年的開發過程中，筆者帶領團隊實現了所有的設想以及絕大多數的功能。作為設計者，筆者將 HVML 定義為一種全新的程式語言：可程式設計標記語言（Programmable Markup Language）。併為 HVML 賦予了全新的設計理念，使之基本滿足前文所說的全新程式語言的技術特徵：

使用標記來定義程式的結構和控制流，大大提高了程式的可讀性，同時大幅降低了學習難度。

使用具有動態功能的擴充套件 JSON 來定義資料，隱藏了底層系統，而且使其成為粘合不同系統元件的理想膠水。

引入了資料驅動的程式設計模型，這讓開發人員更多地關注資料的生成和處理，而不是程式的控制流。

HVML 是動態的，開發人員不僅可以從遠端資料來源獲取資料、模板和程式片段，還能刪除已有的變數。

使用獨有的方式來支援協程、執行緒、閉包等現代程式語言必備的特性。

具有極強的靈活性，開發人員可使用 HVML 編寫簡單的指令碼工具，也可以使用它來開發複雜的 GUI 應用程式，甚至是開發伺服器軟體。

執行飛快，HVML 直譯器使用簡單高效的棧式虛擬機器，不使用任何垃圾收集器。

透過預定義變數重新定義了系統底層的模組和介面，從而遮蔽了不同作業系統或軟體平臺之間的差異。

相比常見的指令碼語言，HVML 具有更高的抽象級別；使用 HVML，開發者可以用更少的程式碼完成更多的工作。

初衷和設計思想

之所以決定設計和開發 HVML，除了以上的思考之外，還跟我的經歷有關。

在我所開發的 MiniGUI（開源 Linux 圖形使用者介面支援系統）生意受到 Android 衝擊之後，我帶領團隊轉戰移動網際網路以及智慧硬體，開發過很多網站和智慧手機應用。幾年前，隨著美國打壓中國高科技產業愈演愈烈，國家又開始重視基礎軟體的自主可控，MiniGUI 的生意又回來了，我們也幫著一些客戶開發了基於 MiniGUI 的解決方案。但由奢入儉難，習慣了網頁前端開發技術的便利性，作為開發者，我們自己都難以接受使用 C/C++這樣的程式語言來編寫帶有圖形使用者介面的應用程式——我發現使用 C/C++這類程式語言開發帶 GUI 的應用，跟用牛刀殺雞並無二致；就算有視覺化的介面設計器幫助開發者，其開發效率也很難和 Web 前端技術相比。

有了這樣的認知，我開始思考為正在開發中的 HybridOS（合璧作業系統）設計一款專門的程式語言。最初，我們的目標是讓熟悉 C/C++或其他程式語言的開發人員可以透過 HVML 使用 Web 前端技術（如 HTML/SVG/ MathML 和 CSS）輕鬆開發 GUI 應用程式，而不是在 Web 瀏覽器或 Node。js 中使用 JavaScript 程式語言做繞轉。最後，我們不光實現了這一目標，而且還將 HVML 實現為一種通用的程式語言。

為了將 Web 前端技術引入到通用的 GUI 應用的開發中， 開源社群也做了大量的探索性工作，比如 Electron 開源專案，就嘗試用 Chromium+Node。js 來搞定一切。但這個專案存在一些問題，究其原因，跟 Web 前端技術本身的侷限性有關：所有的一切都離不開瀏覽器，尤其是 JavaScript 程式語言。

後來，我們在開源的瀏覽器引擎 WebKit 中，嘗試引入了一些具有動態能力的標籤，可以用來實現迴圈迭代、分支控制等功能。有了這個基礎，我提出了一個大膽設想：何不乾脆設計一種全新的標記語言？於是，就有了 HVML。

簡單來講，HVML 嘗試用一種新的思路來解決前面的那個問題：

第一，將 Web 前端技術（主要是 DOM、CSS 等）引入到其他程式語言中，而不是用 JavaScript 替代其他程式語言。

第二，採用類似 HTML 的描述式語言來操控 Web 頁面中的元素、屬性和樣式，而非 JavaScript。

在設計 HVML 的過程中，我有意使用了資料驅動的概念，使得 HVML 可以非常方便地和其他程式語言以及各種網路連線協議，如資料匯流排、訊息協議等結合在一起。這樣，開發者熟悉哪種程式語言，就使用這種程式語言來開發應用的非 GUI 部分，而所有操控 GUI 的功能，交給 HVML 來完成，它們之間，透過模組間流轉的資料來驅動，而 HVML 提供了對資料流轉過程的抽象處理能力。

這樣，圍繞 HVML 形成的應用框架，和傳統的 GUI 應用框架以及 Web 前端技術都有顯著的不同。傳統的 GUI 應用，程式碼設計模式無外乎直接呼叫 C/C++或其他程式語言提供的介面，在一個事件迴圈中完成建立介面元素、響應使用者互動的工作。Web 前端技術和傳統 GUI 應用的最大區別在於描述式的 HTML 和 CSS 語言，但程式的框架在本質上是一樣的——事件迴圈，而且必須使用 JavaScript 語言。

但 HVML 提供了一個完全不一樣的應用框架。在完整的基於 HVML 的應用框架中，包含一個獨立執行的圖形使用者介面渲染引擎，開發者透過編寫 HVML 程式來操控渲染引擎，而 HVML 程式在 HVML 直譯器中執行，並可以和其他已有的程式語言的執行時環境結合在一起，接收由其他程式語言程式生成的資料，並按照 HVML 程式的指令，將其轉換為圖形使用者介面的描述資訊或者變更資訊。透過這樣的設計，我們將所有涉及到圖形使用者介面的應用程式分開成兩個鬆散的模組：

第一，一個和 GUI 無關的資料處理模組，開發者可以使用任何其熟悉的程式語言和開發工具開發這個模組。比如，涉及到人工智慧處理時，開發者選擇 C++；在 C++程式碼中，除了裝載 HVML 程式之外，開發者無需考慮任何和介面渲染及互動相關的東西，比如建立一個按鈕或者點選一個選單後完成某項操作等的這類工作，開發者只需要在 C++ 程式碼中準備好渲染介面所需要的資料即可。

第二，一個或者多個使用 HVML 語言編寫的程式（HVML 程式），用來完成對使用者介面的操控。HVML 程式根據資料處理模組提供的資料生成使用者介面的描 述資訊，並根據使用者的互動或者從資料處理模組中獲得的計算結果來更新使用者介面，或者根據使用者的互動驅動資料處理模組完成某些工作。

透過這樣的設計，HVML 應用框架將操控介面元素的程式碼從原先呼叫 C、C++ 等介面的設計模式中解放了出來，轉而使用 HVML 程式碼來處理。而 HVML 使用類似 HTML 的描述式語言來操控 GUI 元素，透過隱藏大量細節，降低了直接使用低階程式語言操控介面元素帶來的程式複雜度。

在 HVML 應用框架中，有一個獨立執行的圖形使用者介面渲染器。我們將這個渲染器設計為類似字元控制檯的啞裝置，這樣，可以將 HVML 程式和應用的其他模組從控制介面元素展現行為的細節中解放出來。舉個例子，我們在字元終端程式的開發中，可以使用一些轉義控制指令來設定字元的顏色、是否閃爍等，而字元終端程式無需包含任何處理字元顏色以及閃爍的程式碼——因為這些細節字元控制檯（可能是硬體，也可能是一個偽終端程式）幫我們默默處理了。HVML 的介面渲染器也遵循同樣的設計思路，HVML 程式建立好一個按鈕，至於這個按鈕顯示出來是什麼樣子的，使用者如何跟它互動，這些統統無需 HVML 程式來操心——一切由渲染器在給定的描述式語言（如 HTML、CSS）的控制下運轉。這帶來另一個好處，由於在介面渲染器中不包含任何的應用執行邏輯程式碼和敏感的資料，從某種程度上講，提高了安全性。

有了這樣的應用框架設計，HVML 可以讓幾乎所有的程式語言，不論是 C/C++這類傳統程式語言，還是 Python 這類指令碼語言，都可以使用統一的模式來開發 GUI 應用。而在此之前，不同的程式語言有不同的 Toolkit 庫，這些 Toolkit 庫的能力不同，介面不同，渲染效果參差不齊。而 HVML 可以將這些互動類應用的統一起來，甚至也包括那些傳統的字元介面應用程式。我們還可以將 HVML 程式執行在另外一臺遠端裝置上（或雲端），而渲染器執行在和使用者互動的裝置上，從而形成一個新的遠端應用（或雲應用）解決方案。

儘管 HVML 最初是為了解決 GUI 應用的開發而設計，但隨著開發的深入，我們引入了一個全新的棧式虛擬機器作為 HVML 程式的假象執行機器。有了棧式虛擬機器這一堅實的理論基礎，我們為 HVML 賦予了通用計算的能力。也就說，HVML 不僅僅可以作為互動式應用的膠水語言，還可以當做通用的指令碼語言使用。同時，由於我們為 HVML 提供了協程、併發執行等的現代程式設計機制，因此，HVML 還可以用於高併發的伺服器軟體的開發。

任重道遠，開源協作是正道

完成了最初的設計與開發後，HVML 已經進入到了開源協作的新階段，開發團隊和社群還有很多工作要做。首要目的，便是實現 HVML 規範 1。0 定義的所有特性和介面。這項工作將在 2022 年內完成。另外，作為 HVML 技術棧的一部分，針對嵌入式系統的渲染器也已提上日程，將在年底隨合璧作業系統的新版本一併釋出。

當然，一個程式語言走向成熟並獲得廣泛應用將是一個漫長的過程。這需要構建一個強有力的開源協作社群，而成功的社群運營，又需要資金、人才等各方面的支援。這在國內尚無成功先例，更是一個需要長期實踐的課題。

目前 HVML 社群非常活躍，很多小夥伴幫助我們開發了各個 Linux 發行版的打包指令碼，還有小夥伴製作了教學影片。作為社群領導者，我目前最希望的便是能夠獲得足夠數量的贊助資金，用這些資金來激勵 HVML 社群的小夥伴們，使得社群可以儘快進入到良性迴圈當中。另外，也希望有更多的基礎軟體企業加入到 HVML 的開發當中，助力 HVML 儘快走向成熟。

關於未來，如果 HVML 技術得到大量開發者的認同，我相信找到合適的商業模式，也只是時間的問題。另外，圍繞 HVML 創立一個適當規模的基礎軟體企業，也不一定非要由我去做。假如有更加擅長企業經營的人圍繞 HVML 開發了新的產品，找到了一套行之有效的商業模式，成功融資甚至上市，我本人也會非常高興。我想，這是成熟生態的一部分。

未來無需假設，投身其中，讓自己的設想變成現實，才有可能書寫歷史。

—