💡返回博客
背景
2018 年左右，西瓜创客上线了第一版本的 A 系列编程课程，作为在 Scratch 的后续转入代码编程 Python 的课程。 A1 设计的核心思路是让学习的难度提升不要太陡峭，加上 Python 更适合处理算法和数据，Scratch 更适合处理表现。 于是西瓜创客开发吧用 Python 写算法，并且函数会被显示为 Scratch 中的积木（Block）供给 Scratch 的程序使用（那时还是 Scratch 2）。
在 Python + Scratch 的功能支持下，我们开发了一系列有趣的课程。 例如可以在 Python 中请求 互联网上的 API，把结果返回到 Scratch 中辅助创作。 可以查询天气、可以控制舞台中的角色，可以发短信到手机等等等等（后续 2019 年升级到了在 Scratch 3 中，并且增加支持了通过 Python 控制 Scratch 的角色）。
西瓜创客的整个发展思路是以教学为主，因此，我们并没有把这些功能给非 A 系列学员开放。因为教学的目标是学，因此我们也没有对 Python in Scratch 做更深入的持续投入。
共创世界成立后，我们的目标从简单的教学扩展到了做更好的工具，通过降低创作门槛和提高创作的，释放每个创造者的创造力。于是我们推出了 Gandi IDE: an in-browser collaborative IDE and game engine for scratchers. 在咕咕了一年多后，Python in Gandi 终于要回来了。
规划
为什么要引入 Python 到图形化编程
引入 Python 到 Scratch 中并非我们炫耀一下技术。它有很强的实用意义。 从他们各自的优缺点上讲：
Scratch 的优缺点
Scratch 这类图形化编程工具最大优点是直观、操作直觉、容易学习和使用。在对新手学习编程的创作者而言更不容被劝退。
缺点也是明显的，为了容易上手， Scratch 牺牲了高天花板的可能性。例如（包含但不限于）：
- 渲染器的 draw call 没有和用户写的逻辑代码分开，糟糕的代码容易把 FPS 卡得低；
- 没有 assets 管理机制，大工程需要所有素材加载就绪后才能运行，大量素材加载也造成内存压力；
- 代码是在运行时查找，代码运行效率低，尤其是在大量循环、递归和数据处理方面的操作；
- 受限于 JS runtime 的单线程，算法计算时，处理交互的代码会被卡死；
Python 的优缺点
Python 作为被广泛使用的代码编程语言，相比 C 语言要直观简单很多。它的优点主要是：
- 比 C 易用，对初学者相对友好；
- 数据类型/结构完整，远远比 Scratch 中的数据类型完善；
- 丰富的库和框架，Python 拥有大量的第三方库和框架，尤其是在人工智能领域的算法可以直接使用；
- 大型社区支持，Python 拥有庞大的开源社区，因此有很多资源、文档和支持可供开发者使用，这对于解决问题和持续学习非常有帮助；
相对应，Python 也不是万能的，它的主要缺点是：
- 运行速度也没编译型语言快（但是比 Scratch 要快太多了），几乎所有语言都会遇到性能和易用性上的 trade off；
- GIL 限制：Python 中的全局解释器锁（GIL）可以防止多个线程同时执行 Python 代码，这可能会限制 Python 的多线程性能；
- 对 UI 和图形显示的支持弱，即便有 PyGame 库，和 Scratch 比起来也太弱了；
结论
回到问题，我们为什么要把 Python 引入到 Scratch 中。 本质是要突破 Scratch 的限制，让创作变得更简单。 让 Scratch 发挥表现层的优势，让 Python 发挥算法层的优势。
目标
通过发挥 Python 和 Scratch 的各自优势，让复杂算法可以在 Python 中轻松实现，以达成 Gandi IDE 的核心目标：降低开发难度 👶 ，提高作品天花板 🤹♀️ 。
在这个核心的目标下， 我们可能会做和不会做的事（注：在前提条件改变后，会重新考虑）：
会做
- 👶 通过动态积木，让 Python 中的方法转化成为 Scratch 中的 Block
- 👶 集成 Python 中现有的库，降低重复劳动
- 👶 AI 代码辅助，生成代码和辅助 debug 功能以降低开发难度
- 🤹♀️ Serverside Script，直接在服务器的虚拟机上运行，直接操作社区里的用户相关数据或进行服务端数据运算（例如多人游戏中的分数判定，用户数据在服务端处理等等）
- 🤹♀️ WASM 化 + 多容器，提高数据处理能力
- 🤹♀️ Scratch VM 中的数据直控，降低多次转换下的低效问题
不会做
- 在 Server 端做简单的计算并通过网络请求返回给客户端（服务器计算资源不值得用到基础的计算上，并且终端上做简单计算更高效无延迟。 除非这个计算需要特别的服务端支持，例如 GPU 支撑下的 Matrix 计算，神经网络计算）
- 直接用 Python 重写 Scratch 中的语句（不是 Python 的优势，只是换一个语言来控制 VM 和 Render 出了教学意义外，没有什么用）
- 直接用 Python 控制 VM 中的渲染部分，例如移动角色等操作（逻辑代码和渲染代码放在一个 loop 中已经是 Scratch 的缺陷了，如果两个 VM 同时控制一个 Render 会让程序运行更混乱）
阶段
Python in Gandi 计划有两个部分，三个阶段（会根据具体情况调整）。 这两个部分对应到目标：提高天花板和降低使用难度。
在提高天花板方面对应的三个阶段：
- 算法加速：支持在浏览器中原生运行 Python 程序，并且根据 Python 中的函数生成动态积木用于 Scratch 中使用，并且通过使用 WASM 等技术解决 Python 的执行性能问题；
- 数据控制：跟随 VM 的改造，支持整个工程数据操作（不用再执行低效的反复转义操作）；
- 混合计算：支持服务器脚本 + 终端边缘计算 。
在降低使用难度方面对应的三个阶段：
- AI 编程辅助：支持算法的自动生成和代码解释功能以帮助编程学习；
- AI 高级辅助：根据上下文，自动推测和生成算法；
- 描述即编程：仅通过描述，即可自动生成代码并部署。
目前第一个版本的 Python in Gandi 均处于第一阶段。
展望
我们之所以会重新上线 Python in Gandi，核心原因还是为了降低创作的难度，提高创作的效果。上线的第一阶段能极大地改善对计算和数据有强烈处理需求的项目运行效率。 例如，音游中的谱师可以直接把数据定义到 Python 中，对数据进行操作，或者动态导入 JSON 或者 CSV 文件作为数据源。而过去实现同样的效果需要进行大量的字符串操作、编解码和列表导入导出操作，十分的低效和不方便。又如，在 RPG 和大地图类的游戏，有大量的算法执行效率上的要求。这类程序和游戏在第一阶段上线后就能得到很大改善。
在性能方面，后续当 Render 层渲染和逻辑层分开后，Python in Gandi 和 Scratch 中 “运行时不刷新屏幕” 功能将会有更大的提升。卡帧的问题才得以彻底解决。我们计划这些改造的基础部分会放在 2023 年完成。
在低门槛方面，首次上线会支持 3 种 AI 代码辅助，还是以人为主，机器为辅。后续根据我们训练的模型更加完善，会支持 Scratch 中的代码辅助（代码生成、解释和 Debug）并且过渡到以 AI 生成为主，人引导和描述为辅的全智能时代。
拓展阅读
Python in Gandi 技术实现
<iframe
width="100%"
height="800px"
scrolling="no"
src="https://www.ccw.site/embed?id=blog/posts/python-in-scratch-and-gandi&type=comment"
title="Python in Scratch/Gandi 综述"
frameBorder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
allowFullScreen
></iframe>