English version (Thanks to Elecfreaks for the translation!)

提示

  • 2024.04.22 添加了无线编程比较项

前言

我用过大多数图形化硬件编程平台，可能比这个领域的大多数产品经理用过的产品要多。

这不是什么值得夸耀的事情，它不过意味着我浪费比别人更多的时间在五花八门的编程平台上，意味着我迟迟没有遇到真正的好产品。

我们之所以打造自己的系统，是因为不想把时间用来学习别人的糟糕想法 – Alan Kay

不幸的是，通常而言，这就是计算机教育的含义。学习者花费许多时间，学到的只是系统设计者的糟糕想法。

教育者花费许多努力，所做的，只是部分抵消了糟糕的系统所起的负面影响 – Alan Kay

幸运的是， John Maloney 为这个领域带来了曙光，结束了我在不同平台之间颠沛流离的生活。

图形化编程

在有巨人肩膀可以站立的世界，短视却依然是一个问题 – Alan Kay

图形化编程，几乎彻底征服了儿童编程这个领域，以至于当我们谈论儿童编程时，基本是在谈论图形化编程。

这个领域有真正伟大的人物: Seymour Papert、 Cynthia Solomon、Alan Kay、Mitchel Resnick、Natalie Rusk、John Maloney…

有真正出色的著作: 《Mindstorms》、《终身幼儿园》、《A Computer for Children of All Ages》…

也有真正出色的项目: Etoys、Scratch、Snap!、GP blocks、MicroBlocks …

至于主流领域的产品平均水平为何如此之低，确实是个谜…

这个领域的先驱们有着清晰的认知论和愿景，这个领域的出色见解远不止 “拼搭积木能够减少语法错误”。 但很可惜，这些 powerful ideas 大多未被今天的教育者和系统设计者所理解。人们甚至满足于 Blockly 这样退化的东西。Live programming 是 Scratch 力量源泉之一，这需要强大虚拟机(VM)的支持，仅仅将积木翻译到代码远远起不到增进理解的作用。关于这个话题，我在CodeLab 纪事做了更细致的讨论。

图形化硬件编程领域，需要真正强大的虚拟机(以及与之协同的图形 IDE)来支撑建构主义风格的教学。但目前这个领域很少意识到虚拟机的作用，只停留在对积木的关注上。

图形化硬件编程

We make, not just to have, but to know. – Alan Kay

确切的说，我们需要进行物理计算（physical computing）。我们需要采集物理世界的信息并对物理世界施加影响。 – 给老杨的礼物 🎁

硬件编程的乐趣在于，我们可以让想法，经由代码和运行它的硬件材料，作用在现实世界之上。这样一来，我们的思想，便有了物理的身体。

《理想国》里说:「言语是一种比蜡还容易随意捏造的材料」, 它如此灵活，能够用来与朋友逗乐，用来表达你的思想，用来创造诗歌与小说；编程就像言语，它同样可以用来表达你的想法，用来与朋友逗乐，以及，用来表达和创造。它让你与世间的万物沟通，你可以用它指挥一台飞行器，制作一个体感游戏。或者在朋友生日那天，在 Ta 进门的一刻，将手中的魔杖一挥，在空中划一个字母 L 的轨迹，瞬间，点亮房间里五彩的灯光。 在 CodeLab，你将轻松做出这样的魔杖，并对周围的世界施以魔法。如果你愿意，可以将 CodeLab 看作霍格沃茨(Hogwarts)。 – 关于 CodeLab

今天当教育领域讨论STEM/STEAM/创客(Maker)/物理计算时，或多或少都与硬件编程有关。

在图形化硬件编程领域，出色的项目极少，上一个值得被批评的项目是微软的 MakeCode，此外的大多数系统连清晰的设计理念都没有，只是 A 抄 B，B 抄 C，通常连同糟糕的想法一起抄，东拼西凑，不值一驳。迄今为止，真正做到出色的项目只有 MicroBlocks。

本文将讨论 MicroBlocks 相较于其他平台出色的地方。在此我只关注那些能够增强用户的系统特性，具体而言我关注以下的特性:

  • 可理解性
  • 开放性
  • 低门槛、高天花板、宽围墙
  • 对建构主义教学风格的支持

其中我把可理解性放在第一位, 可理解性帮助我们更好地思考和创造。成为 Maker 的重要意义之一是: 借助创造的过程来理解世界:

To know the world one must construct it. –Pavese

We make, not just to have, but to know. – Alan Kay

The challenge is not building it but understanding it – Bret Victor 《Seeing Spaces》

如果一个系统要为创造精神服务，它必须能被个体完全理解。 – Smalltalk 背后的设计原则

欢迎批评

十分欢迎读者的批评。

本文的目标是提供一份类似 “评测和选择指南” 的材料，希望能够为较真的用户选择编程平台提供基于理性的依据。也希望这份材料能经受住资深用户、教育者、硬件工程师和黑客们的批评。

这篇文章很可能存在事实性错误，错误的产生可能有以下原因:

  • 我对评测的平台不够熟悉，对功能特性有所遗漏
  • 由于各个平台都在不断更新，有许多改进正在发生(诸如我之前指出“根据积木翻译的 Python 协程代码会误导初学者”，Makeblock 就做了很出色的改进)。

如果我的评测有任何事实性的错误，或者某些平台已经做出了相关改进，欢迎读者邮件指正: wuwenjie718@gmail.com，来信的论述若是充分，我将更改本文，使其更接近事实。这份列表目前只是 v1.0 版本，它将持续更新。

如果你希望有更多的图形化硬件编程平台纳入比较，也欢迎告知我。

ps: 我自知对 MicroBlocks 有很强的情感偏好(尽管我认为这种喜好是基于理性的), 在写作本文的时候，我试图克制这种情感倾向，希望它不会引起我对其他平台的偏见(若希望这篇文章有说服力，尽量保持中立是必要的)。举个例子, 我在我的电脑上(MacOS 12.3.1 M1)试着连接 micro:bit 运行 hello world, 在 Mind+ 和 Kittenbot 平台都没有成功，但我没有因此在相关评测项目上立刻给它们低分。因为这有可能是我的电脑系统太小众(大多数人用 Windows)，以至于没有被重视，导致测试不够充分。我到这些平台的用户社区看了用户的反馈，发现它们不大会遇到我的问题。我也让我的朋友在 windows 下测试，他们反馈都不错，最后在上手简易程度上我依然给了 Mind+ 和 Kittenbot 高分。

比较平台

本文选择了一些我自己使用过、且有一定影响力的图形化硬件编程平台(至少以此为卖点之一)。

图形化硬件编程平台的比较

比较的平台比较多，请左右滑动表格。

慧编程(Makeblock) Maker(编程猫) KittenBot MakeCode MicroBlocks Mind+ Mixly Scratch(MIT)
可理解性 同时支持灌入式与交互式 ❌ ❌ ❌ ❌ ✔ ❌ ❌ ❌
交互式编程
Live programming		 🌟🌟🌟(仅在线模式) 🌟🌟 🌟🌟🌟(仅舞台模式) 🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟(仅实时模式) 🌟 🌟🌟🌟
实时 debug 🌟🌟🌟 🌟🌟 🌟🌟🌟 🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟 🌟🌟🌟
复杂积木的可理解性
(引擎盖下)		 🌟🌟🌟 🌟🌟 🌟🌟 🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟 🌟🌟 🌟🌟
数据可视化 ❌ ❌ ❌ ✔ ✔ ❌ ❌ ❌
从板子回传积木到编程环境 ❌ ❌ ❌ ❌ ✔ ❌ ❌ ❌
在运行时理解系统状态 ❌ ❌ ❌ ❌ ✔ ❌ ❌ ❌
在用户环境中理解系统底层 ❌ ❌ ❌ ❌ ✔ (开启高级模式) ❌ ❌ ❌
低门槛 开箱可用性 🌟🌟🌟(支持网页，依赖插件) 🌟🌟(支持网页，依赖插件 300+MB) 🌟🌟🌟(支持网页，依赖插件) 🌟🌟🌟🌟🌟(纯网页) 🌟🌟🌟🌟🌟(纯网页) 🌟🌟🌟(支持网页，依赖插件) 🌟🌟🌟🌟🌟(支持网页) 🌟🌟🌟(支持网页，依赖插件)
跨平台 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟(不支持 Linux, 需要社区插件)
上手简易程度 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟
高天花板 积木丰富度 🌟🌟🌟 🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟
可扩展性 🌟🌟🌟 🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟
多任务能力 🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟
支持离线运行 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ❌
离线模式支持广播(消息) ✔ ❌ ❌ ❌ ✔ ❌ ❌ ❌
全功能的无线编程模式 ❌ ❌ ❌ ❌ ✔ ❌ ❌ ❌
宽围墙 支持板子的数量 🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟
支持的传感器/执行器数量 🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟 🌟🌟
用户引入新硬件的自由度 🌟🌟🌟 🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟🌟🌟🌟 🌟🌟🌟 🌟🌟🌟🌟 🌟🌟
支持 “一次编程 多板运行” ❌ ❌ ❌ ❌ ✔ ❌ ❌ ❌

注: 在下个版本(v2.0) 中，我会详细解释每个比较项的含义。

结语

你无法用提出问题的思维解决问题。 – 爱因斯坦

当前的图形化硬件编程领域，与我几年前写作 两种硬件编程风格的比较 时相比，并没有什么大的进步，整个领域都想让平台支持灌入式和交互式编程，虽然大家称呼这两种能力的方式各有不同(在线/离线,实时模式/上传模式,舞台模式/代码模式…)。但目前只有 John Maloney 的 MicroBlocks 做到了让两者无缝融合，进而让平台更好地支持 Maker 们探索和创造。获得这种大家梦寐以求的特性的方法，并不是沿着"将翻译积木成代码"的老路前进，也不是让积木简单地调用代码。“你无法用提出问题的思维解决问题”。正确的做法，是需要一个强大的虚拟机。这当然极其不易，如果你看过 John Maloney 的经历，会发现，他在这个方向上已经思考和探索了数十年。

我想引用 Hacker News 上的一位用户对 MicroBlocks 的评价，在专业工程师中很有代表性:

Excellent summary. The “oh wow this feels different” aspect of MicroBlocks comes after you try it. It makes programming microcontrollers as interactive and hands-on as building electrical circuits from discrete components. Your changes are immediate. And the live data graphing from sensors feels like a graphic voltmeter or oscilloscope. For physical computing it’s simply the best learning tool I’ve ever encountered (note I’m an EE major, not CS). All those “real” programming languages now fall short in my view. I’m hooked. – kgiori

FAQ

我过去有 Scratch 经验，想让虚拟世界的角色与现实世界互动，有什么建议吗？

Microbit More是我看到过与 Scratch 结合得最好的硬件扩展，比 MIT Media Lab 设计的扩展要出色许多，也远胜其他公司的扩展。

作者是 Alan Kay 的一个学生，也是 Smalltalk 用户, 所以他能很好地理解 Scratch 的设计理念(Scratch 最初是在 Smalltalk 里设计的)，进而设计出与之协调一致的插件，完全追随 Scratch 的哲学。目前 CodeLab 部署的 Scratch 已经将其集成进去了，大家可以免费使用，Microbit More 的开箱可用性很好，很适合新手。

MicroBlocks 不能翻译出代码吗？这是不是它不如其他系统的一个证据？

渴望将积木翻译成代码，只是 “积木是代码的薄薄包装，代码是本质，积木是表层” 这一糟糕设计理念的诉求。我已经在 CodeLab 纪事 做了讨论。

如有需要，MicroBlocks 当然可以翻译成代码(而且它确实以文本形式存储，你可以用文本编辑器查看保存项目的文本代码)，高级用户如有需要，系统甚至可以向用户显示积木所对应的虚拟机指令和字节码 (实时编译)，但 John Maloney 刻意隐藏了引擎盖下的实现细节，这对用户进行创造和理解系统帮助不大，要求用户在不同的心理模型中切换，通常会分散注意力，极大增加学习难度，尤其对于初学者而言。CodeLab 纪事 里也有相关讨论。

如果你的系统无法在图形层面进行深入的编程，需要用户理解代码才能进行更深度的工作。那只说明该系统图形化能力太弱，这是一个设计缺陷，而不是支持 “将积木翻译成代码” 的理由。

在 MicroBlocks 中，积木与其文本表示(代码)是一体的两面，由于出色的整体设计，这两者已经做到了高度一致，以至于用户只使用积木就几乎能完成所有文本代码能做的事情，包括编写扩展插件！

MicroBlocks 可能是 Etoys(Alan Kay 领导的项目) 之后，图形化编程系统走得最远的例子。

你自己会如何给这些平台综合打分?

我自己心中的排序是:

MicroBlocks >> MakeCode > Makeblock >>> …

MicroBlocks 一骑绝尘并不令人惊讶，John Maloney 几乎是这个方向的开创者，而且在这个领域探索了数十年。微软团队有丰富的编译器经验，在既有的技术框架里几乎做到了极致。令我震惊的是 Makeblock(慧编程)，他们几年来克服了非常多的难题，而且解决方案非常出色，为增强可理解性做出了很大努力(多任务、广播消息)。但很遗憾的是，MakeCode 和 Makeblock 出发点并不是 Powerful Idea: 把积木看作底层系统(MicroPython/C++)的薄薄外衣。这是个弱小的想法(由 Blockly 引入)，在这个想法之上再怎么努力优化，取得的进展都是十分有限的。

唯有构建强大的虚拟机(和 IDE)才能追上 John 取得的颠覆性进步。

Point of View Is Worth 80 IQ Points – Alan Kay

如果我想设计类似 MicroBlocks 这样的系统，要怎么做?

对于有志于设计类似 MicroBlocks 这类系统的架构师(我自己曾经便是，在看到巨大差距后，我就加入了 MicroBlocks，与 John 共事)，以下是一些建议。

由于计算的特质之一是它总是可以模拟其他可计算的东西。所以的确有可能基于 MicroPython+Blockly 构建出类似 MicroBlocks 的系统(兼得灌入式和交互式的能力)，由于 MicroPython 已经包含了一个健壮的虚拟机(VM)，也许可以作为起点。接下来要考虑的是编程界面(IDE, 积木是其中一部分)如何与虚拟机交互，如何启动和停止程序？如何跟踪程序的运行状态，以便显示图形反馈(例如用发光边框显示正在运行的积木)？如何处理并行任务？如何通过点击运行单块积木？如何打断正在运行的程序？如何从硬件里取得程序？如何取得硬件的运行时信息？如何从错误中恢复？…

(消息)通信是关键。这是一个相当不容易独自一人想明白的领域，甚至连 John Maloney 也不是独自想明白的，John 从 Smalltalk/Squeak 里获得了架构的大部分内容(Smalltalk 一直是 Live programming 灵感的源头之一，另一个是 Lisp )，MicroBlocks 便是站在巨人(Smalltalk)肩膀上才看得更远。

如果你想越过 Smalltalk，直接从 MicroBlocks 的架构里学习，The MicroBlocks Virtual Machine 、 The MicroBlocks IDE 可能是你需要的资料，但缺乏对 Smalltalk 的理解，可能会导致难以看到这些设计背后的理念，进而导致理解上的困难。

参考