多宿主语言、跨平台平部署的开源图形化脚本语言-OpenBlock 原创 精华

近期在OpenAtom OpenHarmony（简称“OpenHarmony”）开发者圈中，几个演示视频引起了广泛关注，视频中的演示程序成功运行在了PC的浏览器、微信小程序和OpenHarmony的开发板这三个环境中。让人惊讶的是，这个项目的开发工具是通过部署在网页端类似Scratch的Web端IDE工具完成的！视频画面中程序运行稳定且流畅，具有相当高的完成度。带着好奇心，我们找到了视频的发布者杜天微，一位住在老北京胡同里的开源贡献者。

视频中演示的项目是通过OpenBlock编写的，目前已经开源。知道OpenBlock还是在开放原子开源基金会的交流群中，彼时了解到OpenBlock是开源项目OpenHarmony下的一个SIG（Special Interest Group），SIG的发起人很喜欢在微信群中与开发者深入探讨问题。记得有一次，在OpenBlock SIG的微信群中有人提及近期火热的“元宇宙”这一概念，杜天微与话题的参与者们进行了三个多小时的探讨。其他参与者因为时间太晚不得不休息了，杜天微仍然独自一人在阐述自己对这一新兴技术领域的观点，直至凌晨4点多仍意犹未尽……

什么是OpenBlock？

OpenBlock希望通过将编程简化、将业务逻辑可视化的一门图形化编程语言，语言特性上有Erlang和 Smalltalk 的影子，语法层面借鉴了Scratch，使用Blockly作为语言前端。像很多高级语言一样，OpenBlock拥有独立的编译器、链接器和运行时（OpenBlockVM），提供了简单易用的IDE工具。

设计师、产品经理、运营人员、行政、财务、人力资源等非程序员角色可以通过简单易用的图形化编程提升工作效率；成熟的项目开发团队中的非程序员角色也可以通过OpenBlock语言支撑商业项目的开发。

从使用人群和语言定位来说，OpenBlock并没有可以参考的成熟语言。OpenBlock追求语言极强的易用性和商业项目的开发能力，定位为适用范围广泛的、面向非程序员群体的图形化脚本语言。在当前主流的语言中并无同时关注这两点的先例，Scratch实现了面向非程序员群体，但对完整项目的开发缺乏基础支持，而能够支撑完整项目开发的主流编程语言需要较高的学习成本，无法面向非程序员群体。

OpenBlock有哪些技术特性？

为了平衡易用性和商业项目开发能力，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做一些小作品，能够参与文档共建都是不错的开始。

于我而言比较困难的就是我没有组织过社区的经验，开发者进入项目中来，我还不知道能不能组织好协作，这部分前期还需要开放原子开源基金会的帮助。

您认为国内的开源环境会受到哪些挑战？

其实开源这块最大的挑战莫过于，用了开源产品，而不回馈开源社区，这种情况在全球都挺普遍的。

于开源开发者个人而言，既然做开源项目，也应该有所觉悟，如果接受不了企业用了某个开源产品，挣了很多钱，且并不打算通过任何形式回馈开源社区，干脆就不要做开源。开源和回馈，是品德，品德是用来律己的，不能苛求别人。

从生态大局考虑，应方方面面来保证开源项目贡献者的合法权益，促进生态圈内的良性循环，以及加强开源文化的宣传和推广，让更多人了解开源，认可开源模式。

受访人简介：

杜天微

邮箱：duzc2@163.com

OpenBlock代码仓：https://gitee.com/openblock/openblock

简介：

OpenBlock核心贡献者；前上市集团技术总监；10年大型游戏研发经验；15年互联网研发经验