如果 EndBASIC 中没有 BASIC 会怎样？—— Julio Merino 著

# 如果 EndBASIC 中没有 BASIC 会怎样？ 来源：https://blogsystem5.substack.com/p/no-basic-in-endbasic 自从我开始构建 EndBASIC (https://www.endbasic.dev/) 以来，已经过去了六年时间：这是一个具有复古外观的 BASIC 解释器，可在 Web、桌面和嵌入式硬件上运行——并且允许编写跨平台应用程序，利用图形、云文件共享系统，甚至通过 GPIO 访问本地硬件。 但尽管听起来很酷，旅程也很令人兴奋，但关于项目的未来，总有一件事让我困扰：谁愿意花时间在一种被废弃的语言上构建新东西？即使是 Visual Basic，这个经过多年演变并获得“严肃语言特性”的真正平台，也已不再流行，据我所知，微软目前将其置于“维护模式” (https://learn.microsoft.com/en-us/dotnet/visual-basic/getting-started/strategy)。 所以我一直在思考……*“如果 EndBASIC 中没有 BASIC 会怎样？”* 换句话说，我如何利用在这个项目下创建的许多组件来构建人们实际上*想要*使用的东西，无论是用于复古风格的开发还是其他用途？ [](https://substackcdn.com/image/fetch/$s_!fqQl!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe7ae6401-0227-4c79-98ba-b8c0b352845f_1084x994.jpeg) 事实上，整个项目中 BASIC 的部分——即语言解析器和编译器——是最不有趣的。是的，我写了一个 BASIC 解释器，但我方言今天提供的功能数量……非常有限，而且构建这些功能并不是最激动人心的事情。例如：记录和文件是非常需要的功能，但添加它们并不会让项目变得比现在更酷或更有用。 所以：让我们看看 EndBASIC 背后的构建块（BBs），以便想象这些组件如何重组形成不同的东西。 在 EndBASIC 的根源处有一个“纯”语言核心，具有相对简单的、尚未优化的编译器和伴随的虚拟机，可以通过原生 Rust 绑定进行扩展，并可以嵌入到 Rust 程序中。利用这个核心语言来实现命令式 DSL 甚至动态配置文件是微不足道的。 但这里的“纯”是什么意思呢？简单来说，作为一个独立 crate 实现的核心语言，具有最少的依赖项，其中绝对没有函数或命令定义。这个 VM 执行的程序默认没有任何副作用，也不能逃逸 VM：它们只能计算值，可能基于主机注入的全局变量。 这个核心 crate 的消费者，如 EndBASIC 的标准库，负责实现使语言有用的所有函数和命令——但这些都被有意地排除在核心之外。即使是您期望 BASIC 方言提供的基本原语，如 `PRINT` 或 `INPUT`，也**不**是核心语言的一部分。这在编译器实现中带来了一些困难 (https://www.endbasic.dev/2023/01/endbasic-parsing-difficulties.html)，但这是一个明确的设计选择，以保持核心的简洁。 在 EndBASIC 的图形绘制命令之下，有一组 Rust 原语来与可能具有图形功能的控制台交互。 目前，这个控制台在各种环境中运行，包括： - 通过 `crossterm` 库在基于文本的 Windows 和类 Unix 终端上。 - 用于在 Windows 和类 Unix 系统（当然包括 macOS 和 Linux）上支持本机桌面图形的 SDL 库。 - 针对 Web 浏览器的 HTML5 canvas。 - 针对“启动到 EndBASIC”环境的 NetBSD wscons 帧缓冲区。 - ST7735s LCD（但更一般地说，基于 SPI 的 LCD）。 对于所有图形后端，这些 Rust 原语为常见形状提供一致的基本光栅化算法，并支持不同的位图字体。 在 EndBASIC 的文件操作背后，有一个 Rust 库，实现了基于虚拟驱动器的文件系统，并针对这些驱动器有多个实现。目前，驱动器可以由以下内容支持： - 内存，如 RAM 盘。 - 硬编码到二进制文件中的一组只读文件。 - 主机文件系统中的一个目录。 - 浏览器的本地存储。 - 云服务。 云服务的驱动器由 EndBASIC 服务支持，该服务提供简单的 REST API 用于文件访问和修改。存储在此驱动器中的文件可以是用户私有的，但也可以与特定用户共享或设为公开。 为 EndBOX (https://www.endbasic.dev/endbox.html) 提供动力的，是一个精简到最小组件集的 NetBSD 基础系统，能够在设备上电后几秒钟内启动到图形应用程序。 系统镜像的设计使得可以轻松地从 Windows 和 macOS 主机访问配置文件和用户数据，从而可以在不需要访问内部 NetBSD 操作系统的情况下调整系统和执行备份。换句话说：NetBSD 只是一个对用户不可见的实现细节。 该平台配有一套自定义的强大构建脚本集合，协调从头编译 NetBSD 以及交叉编译使用前面描述的控制台框架的 Rust 应用程序。然后这些脚本负责将交叉编译的二进制文件打包到镜像中，并在启动过程的早期启动它。您可以将其视为 buildroot (https://buildroot.org/) 的简单版本，但基于 NetBSD 并明确针对为嵌入式设备创建应用程序专用镜像。 更重要的是：为了支持在启动过程早期启动的应用程序的需求，并确保应用程序以最少的权限运行，平台提供了一种 RPC 机制和一个特权守护进程，可用于为特定操作（如重启机器）提升权限。还有一个守护进程可选地从部署的设备收集完全匿名的遥测数据（如版本号、主机架构和正在使用的图形设备）。 在阅读上述四个构建块时，我怀疑脑海中可能会出现一些关于如何在不保留 BASIC 方言的情况下使用这些组件的想法。 以下是我的一些想法，关于这个项目如何演变： - **继续构建 BASIC 语言。** 是的，当然这是一个可能性！EndBASIC 本身是一个有趣的项目，向其添加更多功能并继续构建这个复古环境是一个无尽的快乐来源。即使我后来质疑其意义…… - **用真正的语言替换 BASIC。** 正如我前面所说，进一步开发 BASIC 方言并不太有趣，特别是因为 BASIC 充满了使其难以解析的瑕疵。那么，如果您获得了 EndBASIC 目前提供的完全相同的复古、跨平台体验，但基于人们*喜欢*在这些天使用的真正语言呢？Lua 是一个强有力的竞争者……但 LISP 或 Scheme 也可以。我对后两者了解不多，但知道 LISP 机器 (https://en.wikipedia.org/wiki/Lisp_machine) 曾经存在……它们可能非常合适。 - **专注于核心。** 我有点喜欢拥有一个纯编译器和虚拟机的想法，它可以扩展形成 DSL，全部用 Rust 编写。那么专门在此基础上构建可能是另一条可能的路径？问题是世界上已经存在太多语言，以至于你无法想象，所以 pursuing 这感觉从一开始就是死胡同，我甚至不确定它意味着什么。 - **基于 BSD 的 buildroot 替代品。** buildroot 有效，但它基于 Linux，并带来您会从 Linux 期望的问题：您本质上是在组装由不同的人构建且几乎没有沟通的离散组件集合。将它们组合在一起给您“某物”，但它并不连贯。然而，EndBASIC 背后的平台对嵌入式磁盘镜像应该如何具有意见化的设计，并提供基本服务来强制执行安全原则、保护隐私并保持高性能。那么，如果您可以编写一个 Rust 本机程序，利用我的控制台和文件系统抽象原语，并将其轻松部署到嵌入式设备上作为“完整的操作系统”呢？ - **某种人工智能的东西。** 不可否认，人工智能将长期存在，所以我也在想它可能与 EndBASIC 有什么关系。AI 编码代理非常适合原型设计，而 EndBASIC 是一个很好的平台，可以用很少的代码展示引人注目的结果。那么，也许 EndBASIC 可以成为编码代理的良好目标，以便您可以 vibe code 嵌入式项目？ 我在去年某时写了这篇文章，因为灵感耗尽：发布 EndBOX 是一项繁重的工作，一旦发布，我必须休息一下。老实说，收到如此少的兴趣有点令人失望。到圣诞节时，我重新拿起草稿，几乎要发布它。但是…… 在一月份，我开始全面重新实现 EndBASIC 的核心语言，因为现在不重要原因。这意味着“下一步”已经决定，至少在接下来的几个月内：正如我在上周的 EndBASIC 0.12 发布公告 (https://www.endbasic.dev/2026/05/endbasic-0.12.html) 中提到的，这次重写即将登陆。一旦完成，我想花一些时间构建我一直希望拥有但多年来从未实现的一些功能。特别是，我想提供一些额外的图形操作原语（主要是用于精灵），我想最终添加声音支持。 但所有其他想法仍然在桌面上，我很好奇：它们中是否有任何引起您的好奇？ #### 关于此帖子的讨论 ### 准备好更多了吗？