截止 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 这样的关键应用软件；各种发行版满天飞，造成严重的碎片化问题，还导致严重的应用互兼容性问题等等。
显然，一个没有产品特色、技术特色，缺乏关键应用，还有一堆兼容性问题的系统，既不能吸引开发者，也不能吸引普通用户，的确很难和 Windows、macOS 竞争。但在笔者看来，上面所提到的原因其实只是表象，更深层次的原因在于，不论是社区还是企业，不管是国外的还是国内的，我们发展 Linux 桌面系统的思路存在严重的问题。
但迄今为止，没有任何一个 Linux 桌面系统为服务开发者而做过什么事情——各个 Linux 发行版的默认用户画像，便是爱折腾的黑客级开发者。而商业 Linux 桌面系统，更多的工作集中在整合各类开源软件、适配各种硬件、排除各种故障方面。试问，哪一个 Linux 桌面系统厂商尝试开发过更加现代的编程语言以及配套的开发工具，就如同微软为 Windows 系统开发 C#、TypeScript，苹果为 macOS 开发 Swift，谷歌为 Android 开发 Kotlin？
答案显然是没有。但凡有人在十年前开始做这件事情，也不至于到了今天 Linux 桌面系统的市场地位还如此之尴尬。二十年来，Linux 桌面系统没有发展出令人激动的技术和产品，尤其是面向普通开发者的编程语言甚至开发工具。因此，Linux 桌面吸引的开发者，仍然是笔者这样比较喜欢命令行工具的人，而这样的开发者大概也就 5% 不到，甚至更低。在当前市场趋势下，面对跨平台和融合终端应用的开发需求，Linux 桌面系统更是乏善可陈。GNOME、KDE 两大阵营，一个基于 C 语言，一个基于 C++ 语言，而 Windows 平台和 macOS 平台，却在积极推广基于更加现代的 C# 和 Swift 语言的应用开发框架、跨平台甚至是融合终端技术。
笔者在 2018 年发表的《三谈操作系统》一文中就曾阐述过编程语言对一个操作系统的重要性。简而言之，编程语言之所以重要，是因为编程语言是确定一个系统长相的重要基因。就比如 C 语言，它适合开发贴近硬件的程序，而 C++，适合用于开发中间件。国外还有很多专注特定领域的编程语言，比如 Go 语言适合开发服务器软件，因为它天生为并发编程设计。编程语言可以确定一个系统的长相，也决定了这个系统的软件栈，还决定了这个系统的配套开发工具，还可以成为解决一些顽疾的灵丹妙药。因此，编程语言是自主基础软件，尤其是操作系统的重要抓手。如果没有我们自己的编程语言，那所谓的自主操作系统，就是海市蜃楼、空中楼阁。
而眼前 Linux 桌面系统长期低迷的事实，更从反面证明了我的观点：没有自主的编程语言，对操作系统而言，就如同缺失了灵魂一样，其存在也如行尸走肉一般。
目前，Linux 桌面系统所使用的底层技术，比如窗口和图形系统、界面工具库等，已经趋于成熟，再设计一个新的窗口系统或者界面工具库的意义不大。就比如 Gtk，就算继续演进到 Gtk 5、Gtk 6，对应用开发者能有多大的帮助？大部分情况，带给开发者的其实是兼容性烦恼：那些因为照顾不同系统的 Gtk 版本而无处不在的条件编译。
而一旦我们为桌面应用以及未来的融合终端应用设计了自己的编程语言，尤其是让编程模式都发生巨大变化的语言，那我们就可以自顶向下去设计一个新的系统。这个系统甚至可以涵盖云端、客户端、嵌入式系统和物联网。而内核、工具链、窗口系统、界面构件库、包管理系统，所有这些底层的技术应该成为“汽车引擎盖”下面的东西，不需要天天拿出来给用户展示。对用户，或者开发者来讲，他们首要的需求是：“我能不能用更高的效率、更低的成本开发自己的应用软件，尤其是可以同时运行在多种设备上的。”
要实现这个目标，如果我们仍然在旧的思路上前进，围绕上面所说的那些引擎盖下的底层技术发力，不仅无法取得突破，还会浪费大量资源。笔者认为，只有通过一款全新设计的编程语言才可能获得突破，且此事宜早不宜迟。
另外，随着云计算和物联网技术的普及，现在的应用跟二十年前大不一样了，最大的特点是需要联网，需要跨平台。这需要通过设计新的、云计算和物联网友好的编程语言和开发工具来满足这些需求并提高应用的开发效率。另外，这几年随着物联网、人工智能、大数据、云计算、云原生、区块链等技术的兴起，开发者类型和数量在快速增长，其中非职业程序员变得越来越多。
那么什么样的编程语言是符合未来趋势的？对此，我不是先知，无法做出准确描述。但我知道，只有投身到其中，才有可能让自己的设想变成现实，才有可能书写历史。不过我们仍然可以从宏观上描述适应上述全新需求的编程语言可能的主要技术特征：
-
描述式语言，易读且容易理解，甚至可支持开发者使用母语编程。 -
具有更高抽象层次的编程语言；开发者可以使用更少的代码实现更多的工作，且无需过多关心技术细节。 -
提供跨平台可移植接口的编程语言；通过全新的接口设计来屏蔽底层操作系统或者平台的差异。 -
支持现代编程技术，如动态、协程、并发、闭包等。 -
良好的可扩展性和伸缩性，既可以用来开发脚本程序，也可以支持大型分布式应用的开发。 -
功能和性能的良好平衡。
HVML 便是在上述思想指导下的产物。
Hybrid Virtual Markup Language 的缩写，是由笔者提出并设计的一款通用、易学的编程语言。2022 年 7 月 31 日，我们开放了 HVML 相关的六大代码仓库，这标志着 HVML 1.0 的正式发布：-
HVML 解释器（PurC）：https://github.com/HVML/PurC
-
HVML 外部数据获取器（PurC Fetcher）：https://github.com/HVML/PurC-Fetcher
-
HVML 字符渲染器（PurC Midnight Commander）：https://github.com/HVML/PurC-Midnight-Commander
-
HVML 图形渲染器（xGUI Pro）：https://github.com/HVML/xGUI-Pro
-
DOM 布局库（DOM Ruler）：https://github.com/HVML/DOM-Ruler
-
扩展 WebKit 引擎（仅源代码包）
两年的时间，我们实现了从 0 到 1 的突破：
-
2020 年 5 月，笔者有了设计一款与众不同的编程语言的想法，后于 2020 年 7 月提出了 HVML 编程语言并公开了第一份规范草案。 -
2021 年 7 月，我们成立了一个攻坚团队并正式开始了 HVML 解释器（PurC）的开发。 -
2021 年 12 月 27 日，第一个 HVML 程序成功运行，标志着 HVML 的正式诞生。 -
2022 年 3 月 11 日，HVML 解释器完成和渲染器的对接，标志着 HVML 解释器和渲染器通讯协议 PURCMC 的诞生。 -
2022 年 5 月 30 日，我们完成了 HVML 图形渲染器 xGUI Pro 的初步版本。 -
2022 年 7 月 31 日，HVML 1.0 解释器 PurC、渲染器 xGUI Pro 趋于稳定，我们公开了 HVML 相关的所有源代码仓库（或软件包）。
在整整一年的开发过程中，笔者带领团队实现了所有的创新性设想以及绝大多数的功能。作为设计者，笔者将 HVML 定义为一种全新的编程语言：可编程标记语言（Programmable Markup Language）。我们为 HVML 赋予了全新的设计理念，使之基本满足上面所说的全新编程语言的技术特征：
-
HVML 使用标记来定义程序的结构和控制流，这大大提高了程序的可读性，同时大幅降低了学习难度。 -
HVML 使用具有动态功能的扩展 JSON 来定义数据，隐藏了底层系统，而且使其成为粘合不同系统组件的理想胶水。 -
HVML 引入了数据驱动的编程模型，这让开发人员更多地关注数据的生成和处理，而不是程序的控制流。 -
HVML 是动态的；开发人员不仅可以从远程数据源获取数据、模板和程序片段，还可以删除已有的变量。 -
HVML 使用独有的方式来支持协程、线程、闭包等等这些现代编程语言必备的特性。 -
HVML 非常灵活；开发人员可以使用 HVML 编写简单的脚本工具，也可以使用它来开发复杂的 GUI 应用程序，甚至可以用 HVML 开发服务器软件。 -
HVML 的运行飞快；HVML 解释器使用简单高效的栈式虚拟机，不使用任何垃圾收集器。 -
HVML 通过预定义变量重新定义了系统底层的模块和接口，从而屏蔽了不同操作系统或软件平台之间的差异。 -
相比常见的脚本语言，HVML 具有更高的抽象级别；使用 HVML，开发者可以用更少的代码完成更多的工作。
自开源发布以来，我们得到了诸多业界高手的赞誉。微博大V @tombkeeper 评价道：
就算对编程语言不感兴趣，但看看 HVML 的规范文档，也能汲取到不少营养。
中国开源软件的前辈和先锋，魏永明老师的又一力作 HVML，把解释器、虚拟机、布局和渲染器全都撸了一遍，在保证高性能的同时，还融合了数据驱动+描述式、协程、动态化等新趋势，HVML 是兼具实用和学习价值的精品！
个人认为 HVML 是中国基础软件新时代的新标志，将为人机界面、前后端开发、系统运维等行业带来深远的影响。不光是语言的应用方面，其自身以及配套系统如算法库也将带来大量的机会，使得所有程序员受益。
读者要想更多了解 HVML，可访问 HVML 的公开文档仓库，其中包含 HVML 语言规范文档、入门教程以及示例程序等：
https://github.com/HVML/hvml-docs
笔者搞了二十多年的图形系统（MiniGUI），但中间有几年我搞过移动互联网还有智能硬件，开发过很多网站和手机应用。后来物联网兴起，老美开始打压中国高科技产业，MiniGUI 的生意又回来了。但由奢入俭难啊，习惯了 Web 前端开发的便利性，就越来越难以接受使用 C、C++、Java 等语言来编写带有图形用户界面的应用程序——我发现使用 C、C++、Java 这类编程语言开发带 GUI 的应用，跟用牛刀杀鸡并无二致。就算有可视化的界面设计器帮助开发者，其开发效率也很难和网页前端技术相比。
因此，这几年我一直在思考一个问题：能否将 Web 前端技术带到浏览器之外？比如可以让 C/C++/Java 程序，甚至 Python 这类脚本语言也能轻松地使用 Web 前端技术来开发带 GUI 的应用。
为了将 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++、Rust 等接口的设计模式中解放了出来，转而使用 HVML 代码来处理。而 HVML 使用类似 HTML 的描述式语言来操控 GUI 元素，通过隐藏大量细节，降低了直接使用低级编程语言操控界面元素带来的程序复杂度。
在 HVML 应用框架中，有一个独立运行的图形用户界面渲染器。我们将这个渲染器设计为类似字符控制台的哑设备，这样，我们可以将 HVML 程序和应用的其他模块从控制界面元素展现行为的细节中解放出来。举个例子。我们在字符终端程序的开发中，可以使用一些转义控制指令来设置字符的颜色、是否闪烁等，而字符终端程序无需包含任何处理字符颜色以及闪烁的代码——因为这些细节字符控制台（可能是硬件，也可能是一个伪终端程序）帮我们默默处理了。HVML 的界面渲染器也遵循同样的设计思路，HVML 程序创建好一个按钮，至于这个按钮显示出来是什么样子的，用户如何跟它交互，这些统统无需 HVML 程序来操心——一切由渲染器在给定的描述式语言（如 HTML、CSS）的控制下运转。这带来另一个好处，由于在界面渲染器中不包含任何的应用运行逻辑代码和敏感的数据，从某种程度上讲，这带来了安全性的提高。
有了这样的应用框架设计，HVML 可以让几乎所有的编程语言，不论是 C/C++ 这类传统编程语言，还是 Python 这类脚本语言，都可以使用统一的模式来开发 GUI 应用。而在此之前，不同的编程语言有不同的 Toolkit 库，这些 Toolkit 库的能力不同，接口不同，渲染效果参差不齐。而 HVML 可以将这些交互类应用统一起来，甚至也包括那些传统的字符界面应用程序。
我们还可以将 HVML 程序运行在另外一台远程设备上（或云端），而渲染器运行在和用户交互的设备上，从而形成一个新的远程应用（或云应用）解决方案。
另外一个核心软件是配合 HVML 解释器运行的 GUI 渲染器。我们为桌面系统开发了一款基于 WebKit 的渲染器，称为 xGUI Pro，是一个跨平台的 HTML/XGML/CSS 渲染器，可运行在所有桌面操作系统以及合璧操作系统上。
如果要在资源受限的嵌入式系统中使用，还需要开发一个小型的 GUI 渲染器。为此，我们设计了一款新的 XGML 标记语言，专门用于嵌入式设备，对应的渲染器称为 xGUI Lite。目前正在开发中。
上述几款软件是用于运行时的，在开发阶段，还需要开发及调试工具，自动化测试工具等等。
当 HVML 用于云应用时，还需要一个云应用服务器软件。当 HVML 应用于各种领域时，还需要针对各行各业的扩展插件库、HTML/XGML 模板……
目前，HVML 已经进入到了开源协作的新阶段，开发团队和社区还有很多工作要做。首要目的，便是实现 HVML 规范 1.0 定义的所有特性和接口。这项工作将在今年内完成。另外，作为 HVML 技术栈的一部分，针对嵌入式系统 xGUI Lite 版本也已提上日程，将在年底发布。
目前 HVML 社区非常活跃，很多小伙伴帮助我们开发了各个 Linux 发行版的打包脚本，还有小伙伴制作了教学视频。作为社区领导者，我最希望的便是能够获得足够数量的赞助资金，用这些资金来激励 HVML 社区的小伙伴们，使得社区可以尽快进入到良性循环当中。另外，也希望有更多的基础软件企业加入到 HVML 的开发团队当中，助力 HVML 尽快走向成熟。
关于未来，如果 HVML 技术得到大量开发者的认同，我相信找到合适的商业模式，也只是时间的问题。另外，围绕 HVML 创立一个适当规模的基础软件企业，也不一定非要由我去做。假如有更加擅长企业经营的人围绕 HVML 开发了新的产品，找到了一套行之有效的商业模式，成功融资甚至上市，我本人也会非常高兴。我想，这是成熟生态的一部分。
当然，一个编程语言走向成熟并获得广泛应用将是一个漫长的过程。这需要构建一个强有力的开源协作社区，而成功的社区运营，又需要资金、人才等各方面的支持。这在国内尚无成功先例，更是一个需要长期实践的课题。
国产基础软件行业最缺乏的是突破和创新，不论是技术上的还是产品上的。但根子上缺的是思想、认知以及方法上的突破和创新。出现这种情况的原因也很简单，就是我们大量从业人员对基础软件的认知非常肤浅。就比如我们在介绍 HVML 的过程中，总有一些人在未了解其关键技术特色的情况下，就开始评头论足，拿自己肤浅的认知来评价甚至下结论，比如 “不就是 PHP 加 JSP 嘛”、“不像 QML，更像 XML”、“看不出做这玩意有啥意义”、“我认定这东西没前途”，甚至还有人恶意挑衅：“骗了多少科研经费？”
显然，说这些话的人既不是高手也不是善于思考的人，相反，这折射出我们国家普通软件工程师非常不自信的一面：面对全新的技术，受限于其肤浅的认知和狭隘的眼界，他们表现出来的不是虚心学习，汲取营养，而是焦虑、害怕和拒绝，甚而至于，做出最恶毒的揣测以展示自己的不凡。
苹果有个广告词：Think Different，有人把它翻译为“不同凡想”，其实掩盖了真实含义，我觉得直译为“想想不同”更加贴切。我们可以学习这个精神，在设计和实现中，多思考一些不同的方法出来，就可能实现突破。比如 HVML 是全球第一个可编程的标记语言，这是 HVML 最大的突破。再举个更加具体的例子，我们在开发 HVML 解释器的时候，需要一个 JSON 解析器。一般人的做法，抄一个开源的就差不多了。但我们的实现可以让 JSON 具有动态能力，而解析一个动态的 JSON 表达，需要构造一个抽象的构建模型。我们如此做了，也做到了。这就是“Think Different”的价值。