近期在 OpenAtom OpenHarmony（简称“OpenHarmony”）开发者圈中，几个演示视频引起了广泛关注，视频中的演示程序成功运行在了 PC 的浏览器、微信小程序和 OpenHarmony 的开发板这三个环境中。让人惊讶的是，这个项目的开发工具是通过部署在网页端类似 Scratch 的 Web 端 IDE 工具完成的！视频画面中程序运行稳定且流畅，具有相当高的完成度。带着好奇心，我们找到了视频的发布者杜天微，一位住在老北京胡同里的开源贡献者。
视频中演示的项目是通过 OpenBlock 编写的，目前已经开源。知道 OpenBlock 还是在开放原子开源基金会的交流群中，彼时了解到 OpenBlock 是开源项目 OpenHarmony 下的一个 SIG（Special Interest Group），SIG 的发起人很喜欢在微信群中与开发者深入探讨问题。记得有一次，在 OpenBlock SIG 的微信群中有人提及近期火热的“元宇宙”这一概念，杜天微与话题的参与者们进行了三个多小时的探讨。其他参与者因为时间太晚不得不休息了，杜天微仍然独自一人在阐述自己对这一新兴技术领域的观点，直至凌晨 4 点多仍意犹未尽……OpenBlock 希望通过将编程简化、将业务逻辑可视化的一门图形化编程语言，语言特性上有 Erlang 和 Smalltalk 的影子，语法层面借鉴了 Scratch，使用 Blockly 作为语言前端。像很多高级语言一样，OpenBlock 拥有独立的编译器、链接器和运行时（OpenBlockVM），提供了简单易用的 IDE 工具。
设计师、产品经理、运营人员、行政、财务、人力资源等非程序员角色可以通过简单易用的图形化编程提升工作效率；成熟的项目开发团队中的非程序员角色也可以通过 OpenBlock 语言支撑商业项目的开发。
从使用人群和语言定位来说，OpenBlock 并没有可以参考的成熟语言。OpenBlock 追求语言极强的易用性和商业项目的开发能力，定位为适用范围广泛的、面向非程序员群体的图形化脚本语言。在当前主流的语言中并无同时关注这两点的先例，Scratch 实现了面向非程序员群体，但对完整项目的开发缺乏基础支持，而能够支撑完整项目开发的主流编程语言需要较高的学习成本，无法面向非程序员群体。为了平衡易用性和商业项目开发能力，OpenBlock 在语言设计上做了必要取舍，也包含了关键性创新。这些特性饱含了 OpenBlock 团队这些年来的思考和探索。
与主流语言的“面向对象编程”不同，OpenBlock 是面向“状态机编程”。目前只有微软正在孵化的 P 语言采用了这种设计。“状态机”是 OpenBlock 语言中一个非常关键的概念。它的概念非常简单，遵从一个简单的运行规则：在当前状态的逻辑中决定是否要切换到其他状态。当“状态机”可切换的状态被限定，仅有有限的几个可切换状态时就是“有限状态机”。有限状态机普遍存在于我们现实生活中，譬如说门的状态仅限于开和关两种。
有别于主流的文本语言，OpenBlock 使用 Blockly 作为前端语言，图形化代码语句，并通过图像与使用者交互。比如 OpenBlock 可以把状态机的状态转换以图表的形式在 IDE 中展现出来，这在主流文本的语言里，通常是没有的。
OpenBlock 在设计上就考虑了可移植性，通过宿主语言来实现跨平台。在语言设计上，OpenBlock 最小化了系统库，保留了数据操作相关的系统库；使用小型指令集，指令数量预计限制在 100 个左右；使用宿主语言的运行时，可以利用任何可用的宿主语言的特性。这使得 OpenBlock 在跨平台部署时不需要繁复的开发。
在 OpenBlock 中，状态机之间不存在方法调用，只能通发送可跨运行时传输的消息来完成数据传递。因为没有方法调用，OpenBlock 可以在多线程、高并发的环境下运行。我们可以把 VM 当做 Actor，在服务器集群中创建成千上万个 VM 实例，每个 VM 里放业务紧密相关的状态机。所有的 VM 放在一个线程组里运行。只要保证每个 VM 不同时出现在多个线程中调用，就可以保证数据的线程安全，从而实现高并发。而从单线程到多线程的处理，只是在与框架集成的代码中提供支持就可以了。
在面相对象编程时，我们如何设计一个打坦克的游戏呢？最直观的想法是将坦克封装成一个高度聚合的类，在一个类里处理全部的坦克控制逻辑。当业务变得复杂，我们就会拆分出移动控制类、火炮系统、生命系统等组件，但是对外仍然暴露聚合的坦克接口。无论怎么拆分，这个聚合的接口都会与其他系统发生耦合。
OpenBlock 面相状态机编程从根本上打破了这个过程。首先我们并不认为坦克是一个整体，而是由一组分别运行的状态机组成，每个状态机对应一组独立运行的业务：生命行为、火炮行为、移动行为。各个行为是独立的状态机，可以在不同的状态进行切换，对外没有暴露任何实际 interface 代码。而是通过把这些状态机捆绑为一个坦克实体，共同接收坦克上发生的所有事件和收到的消息，分别处理实现自己的逻辑，完成业务上的整合。而不同的状态机之间，只有约定的消息，没有固定的接口，所以在代码层面是没有实际的耦合的，要替换组件非常的容易。
作为编程语言，我觉得想让它发展起来就要生态化运作，这不是一门简单是生意。语言不做生态就没人用，没人用就是死水一潭。要想搞活，就要开源，这也是几乎所有主流语言的统一做法。大公司都把编程语言开源，自己去做生态的生意，而小公司没有人力，没有财力，还想生存下去，没有理由不开源。
也许 20 年前，一个新生的编程语言可以依靠小体量的业务生存下去，但是今天，肯定不行。我将 OpenBlock 捐献给开放原子开源基金会，也是希望借助开放原子开源基金会的开源社区运营经验来提升项目影响力、扩大项目应用领域、获得更广泛的支持，让 OpenBlock 能够继续发展下去。目前 OpenBlock 的商业实践有哪些？目前是否获得了一定的商业成功？
商业上，目前 OpenBlock 实践并不多，主要是因为它的完成度还不是很高。
目前，跟北京大学有个 VR 编辑器的项目，是面向非技术学科的研究生做科普教育的。也有使用 OpenBlock 开发的商业 App，目前已经上线运营一年多了。最近，我们正在跟一家游戏公司合作开发商业游戏。
因为涉及到部分商业内容，就不过多透露了，目前这些项目对于一个早期的编程语言来说已经是很好的成绩了。
在这些领域中，OpenBlock 绝对不是用来解决技术问题的，它解决的是业务逻辑的问题。以 Unity 游戏研发为例，程序员通过 C# 写的代码在 IOS 上是不能更新的，所以引入一个 Lua，所有的游戏代码使用 Lua 来写，用 Lua 去调用 C# 的东西，这才把 C# 带入到 IOS，这些全是程序员在编写。OpenBlock 相较于 Lua 来说严格区分了技术和业务，原来是程序员写 Lua，现在换成策划在写 OpenBlock，程序底层的基础部分仍然使用 C# 来写。业务是业务，技术是技术，这样的明确分开后能够让技术人员专注于基于 C# 的具体业务实现，也能让策划人员更好地通过 OpenBlock 表达出明晰的业务逻辑。您认为 OpenBlock 未来会在哪个领域大放异彩？
未来，我希望 OpenBlock 能够实现全民编程。
就像抖音在视频领域里做的一样，把拍摄、剪辑、发布从专业级做到了全民级。我希望未来每个人都可以用 OpenBlock 解决自己面对的任何问题，比如批量处理庞大的 Excel 数据、处理大数量级的邮件、管理家里的物联网设备等；在幼儿编程领域使用 OpenBlock 制作可交互的幻灯片和小游戏；在商业领域能够支撑商业级的 APP 的开发等等。
OpenBlock 本身的可拓展性比较高，也是比较新的开源项目，未来走向何方具有不确定性，这些领域和场景只是基于 OpenBlock 现有的实践作出的构想。目前很多服务平台都提供了图形化开发的能力，通过鼠标拖拽就能够完成开发，OpenBlock 有什么优势呢？
这种低代码开发的东西其实特别多，它多是以业务模块来组合的，当遇到非标准型业务的时候，这类型的低代码开发就无能为力了。归根结底就是这类平台不具有创造力，而开发人员面对的大部分企业业务需求都具有自己的一些不能被低代码开发平台满足的特性。这种平台只能造杯子，顶多 DIY 一下杯身、杯盖、杯垫的样式，并不能创造出一个带加热和保温功能的杯子，加热和保温就是这类平台不具备、需要开发人员单独开发的功能。
而 OpenBlock 是你随手就可以做出一些贴合场景的东西来，不管你面对的场景是什么。虽然我做不了太多，但我什么都能做点，今天想开发一个微信小程序在移动端跑，明天想做一个网页在 PC 端跑，后天还想控制一下家里的家电在开发板上跑，这些事儿都能通过 OpenBlock 这一种语言来实现。未来 OpenBlock 开源项目还会做哪些事情？向哪个方向努力？
未来 OpenBlock 会不断完善功能，主要在向使用者表达方面做更多努力。
为了提高编程效率，也会支持文本编程的形式，但仍然以图形方式做反馈。最初接触到 OpenBlock 的开发者很难理解把 OpenBlock 定义为语言这件事，所有人都会觉得编程语言就是在那敲代码。有这种认知的人并不知道世界上有大量的小学生在用 Scratch 这种东西，它也是一种语言。虽然，Scratch 在成年人的眼里就是小孩玩具，但是它背后蕴含的教育原理是深刻的。它真的不能研发产品，它本身就是一个非常完美的产品，迄今为止，我没有看到任何在编程语言在科普项目领域能够超越它。在 OpenBlock 上引入文本编码形式并不是在迎合这种偏见，只是纯粹想提升深度使用者的编程效率。深化图形反馈是 OpenBlock 根上的东西，未来很长一段时间都会做持续优化。
另外，OpenBlock 会使用更多的语言实现运行时，首当其冲的就是 C 语言。按照 OpenBlock 的设计，将来会选择性的实现一些语言的运行时，并不会涵盖所有。最初 OpenBlock 的研发考虑了 VM 的实现问题，C# 和 JS 环境支持最全面，实现 VM 相对容易，且适用范围也很广，所以会优先适配这两个语言。考虑到 C/C++ 语言被广泛使用，接下来的重要工作是适配 C/C++ 语言，同时也可以进一步拓宽 OpenBlock 的应用范围。目前项目有多少人参与？急需哪方面的开发者参与共建？
目前项目已经有除我以外的开发者加入了，同时开发文档搭建这部分已经有在校的教师和大学生参与共建了。
OpenBlock 迫切需要一些 JS 和前端的开发者参与到项目共建中来，除此之外没有其他的要求。对一个新生的项目组来说，即使有开发者能够使用 OpenBlock 做一些小作品，能够参与文档共建都是不错的开始。
于我而言比较困难的就是我没有组织过社区的经验，开发者进入项目中来，我还不知道能不能组织好协作，这部分前期还需要开放原子开源基金会的帮助。
其实开源这块最大的挑战莫过于，用了开源产品，而不回馈开源社区，这种情况在全球都挺普遍的。
于开源开发者个人而言，既然做开源项目，也应该有所觉悟，如果接受不了企业用了某个开源产品，挣了很多钱，且并不打算通过任何形式回馈开源社区，干脆就不要做开源。开源和回馈，是品德，品德是用来律己的，不能苛求别人。
从生态大局考虑，应方方面面保证开源项目贡献者的合法权益，促进生态圈内的良性循环，以及加强开源文化的宣传和推广，让更多人了解开源，认可开源模式。
杜天微
简介：OpenBlock 核心贡献者；前上市集团技术总监；10 年大型游戏研发经验；15 年互联网研发经验，邮箱：duzc2@163.com
OpenBlock 代码仓：https://gitee.com/openblock/openblock
京公网安备 11010802041100号