当所有人都在讨论如何用自然语言让 Agent 接管编程时，Smalltalk 阵营的老兵交出了一套反方向的答卷。2026年9月，在保加利亚普罗夫迪夫举办的 ESUG 2026 大会上，Pharo 核心开发者 Esteban Lorenzano 登台发表了时长 30 分钟的演说，正式公开并开源了新一代 IDE 项目 Pharo Pulsar，并随即拿下本届 ESUG 创新奖一等奖。
这件事耐人寻味的地方不在于拿奖，而在于它的立意。整个行业正在疯狂把开发者推离编辑器，让用户退化为只负责点赞和验收的审查员；Pulsar 却打出 以编码为中心 的旗号，试图把开发者死死锚定在代码与活体系统的底层。
需要先澄清一个检索干扰：这里的 Pulsar 运行在 Pharo 活体镜像之上，与那个由 Atom 分支衍生而来的通用文本编辑器没有任何代码渊源。
穿透镜像的桌面栈
Smalltalk 体系从诞生起就具备独特的活体镜像与反射机制，系统本身就是一个随时可以修改的活物。但数十年来，这种自成一体的闭环也让它背上了沉重的历史包袱：自带的图形渲染与现代操作系统格格不入，高分屏适配怪异，多窗口管理脱节。
Pulsar 没有走传统 Web 化的路子，也没有沿袭老旧的形态，而是选择彻底倒向现代 Linux 原生桌面生态。其底层基于 Spec 框架，直接挂载了 GTK 4、libadwaita、libpanel、librsvg 与 VTE 原生终端。
这套组合拳的意图非常直接：它不仅要保留 Smalltalk 随时中断、检查对象、修改运行中方法的原生反射能力，还要获得现代桌面级的高性能分栏、原生渲染曲线以及顺滑的终端集成。在 Pulsar 的构想里，程序员不需要跳出镜像去查日志，也不需要依赖浏览器看文档，编辑器必须提供最高密度的代码操纵界面。
越是机器代写泛滥的节点，穿透系统黑盒的掌控力越是稀缺特权。
在 Lorenzano 的逻辑中，生成式模型越是能够轻而易举地产出成百上千行代码，开发者就越需要拥有毫秒级导航、检查与重构活体系统的硬实力。工具如果只负责隔靴搔痒地显示对话气泡，最终只会让工程滑向无法维护的泥潭。
激进底座换来的工程代价
然而，把一套高度动态的运行时与庞大的 C 语言桌面库深度绑死，必然要付出极其沉重的工程代价。从官方仓库的实际状态来看，Pulsar 目前依然是一件充满毛刺的实验品。
截至 2026年10月14日，该项目的官方仓库记录着 0 release 与 0 tag，完全依赖 Nightly 版本分发，其目标运行时被划定在尚在演进中的 Pharo 14。
更为棘手的是底层兼容性与跨平台难题：
- Linux 端为了抚平依赖地狱，必须借助 Flatpak 隔离打包，macOS 虽提供专用安装脚本，但在多窗口状态下存在隐患；
- 原生 Windows 版本受制于外部函数接口架构，目前完全无法运行，官方只给出了通过 WSL 曲线救国的方案；
- 官方严厉警告禁止采用标准的 ZeroConf VM，原因是其自带的动态链接库会与系统级 GTK 组件产生致命的符号冲突。
这些底层妥协迅速在日常使用中暴露出来。在公开的缺陷追踪中，Issue #113 记录了明暗主题切换直接引发整个镜像崩溃的惨剧；Issue #110 显示 macOS 用户一旦打开第二个项目，全局鼠标事件就会彻底失效；Issue #121 则表明简单的 Git 分支切换操作也会抛出 doesNotUnderstand 异常。
- 风险.Pulsar 目前绝非开箱即用的生产力工具，过深的 C 库绑定使得它在跨平台修复上面临极高的维护壁垒。
三岔路口处的控制权之争
面对软件规模膨胀，Smalltalk 社区内部实际分裂出了三条截然不同的技术路线。
第一条是坚守内生的 Calypso，稳健但缺乏现代桌面质感；第二条是以 Glamorous Toolkit 为代表的探索，主张把一切转化为文档与领域特化视图，模糊代码与数据的边界；而 Pulsar 代表了第三种激进反扑：放弃花哨的超文本幻想，退回最硬核的工匠模式，利用 GTK 4 的现代控制力打造纯粹的专业工作台。
在这套哲学里，生成式命令行工具绝不能当掌舵者，只能扮演呼之即来的侧边插件。开发者必须掌握每一行载入内存的逻辑，随时准备用反射工具拆解它。这种近乎偏执的控制欲，恰恰是对当下过度依赖大语言模型写代码所带来的失控感的一场正面阻击。
- 建议.资深动态语言开发者可借助 Flatpak 环境提前体验其架构思想，但生产环境升级仍须等待 Pharo 14 周期内 FFI 稳定性的最终收敛。
这场实验能否成功，完全取决于 Lorenzano 和社区能否在后续版本中驯服底层动态链接库的冲突，并填平 Windows 原生支持的鸿沟。无论结局如何，Pulsar 的出现都砸出了一个清晰的信号：技术进化的终点，绝不只有把权力移交给黑盒这一种选择。