從低迷的 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 社區非?；钴S，很多小伙伴幫助我們開發了各個 Linux 發行版的打包腳本，還有小伙伴制作了教學視頻。作為社區領導者，我目前最希望的便是能夠獲得足夠數量的贊助資金，用這些資金來激勵 HVML 社區的小伙伴們，使得社區可以盡快進入到良性循環當中。另外，也希望有更多的基礎軟件企業加入到 HVML 的開發當中，助力 HVML 盡快走向成熟。

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

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