Kefir C 编译器公开开发停止

# Kefir C 编译器公共开发终止 来源：https://kefir.protopopov.lv/posts/announce2.html ### 致相关人士： 今天我宣布 Kefir C 编译器的公共开发终止，并将项目转入私有模式，为期不定。 #### 发生了什么？ 首先，我本人对此变化感到遗憾，但认为这对于项目的可持续性是必要的。 从现在起，在未来不确定的时间内，Kefir 编译器项目的新主要开发成果将不再公开发布。项目的工作将继续以私有方式进行。 新的开发模式涵盖了项目中所有实质性的新变化，但 bug 修复和琐碎的次要改进除外，以及任何我认为特别需要发布的内容。目前已发布的工作成果将保持可用。因此，这一变化**不应阻止**任何人向现有的公开代码库报告 bug。任何报告的问题都将尽可能公开处理。 #### 当前未发布的代码会怎样？ 当前已发布的开发分支中有一定数量的代码。这些更改并不琐碎，但在我看来不值得单独发布。在接下来的几天里，我计划稳定这些变更集，并将其作为未发布的慢速`master`分支保留。任何潜在的 bug 修复都将发布在那里。 #### “私有”是什么意思？ 意思是我将所有新代码留给自己，供我自己的享受、娱乐和乐趣。我不打算出售任何东西，不分发二进制文件等。如果有人特别*实质性地*感兴趣，我可能会以非常有限的方式分享，但这并不是我的意图。 #### 为什么？ ##### 太长不看版 总结以下长篇论述，我希望为自己保留项目的乐趣精神，同时使其在整体上保持可持续和健康。我也不希望我未来的工作被商业目的无偿利用。将其私有化解决了这两个问题。鉴于公众兴趣冷淡且缺乏合法化的途径，这一决定的明显缺点似乎非常有限。 我将阐述一些想法如下。可以跳过。**点击阅读长篇论述** ##### 范围与开发资源 从一开始，我纯粹出于对编译的兴趣而投入该项目，而 C 语言在这方面提供了丰富的环境。任何其他动机最多只是次要的，并且是事后补充的。因此，源代码的发布一直只是拥有它的副作用。一开始我根本没有更好的事情可做。我在业余时间、自费进行该项目。 然而，到目前为止，编译器已经超出了我在所有重要维度上合理维持开发的能力：每次更改都需要考虑整个测试套件的正确性、与其他功能的集成、优化管道和性能考量、编译器效率以及其他问题（例如调试信息管理）。大量的开发时间用于规划更改和调试后的连锁反应，严重减缓了有趣的实验。要维持合理的开发速度，我需要要么降低质量标准并放弃上述某些考量，要么投入更多时间和开发资源。我不愿意做前者，也无法在满足他处首要义务的同时健康地做到后者。 坦率地说，我无法在保持乐趣的同时维持现状。将项目转入私有模式让我在心理上将其重新定位为纯粹有趣的尝试，无需进一步严肃考虑。 ##### 理性计算 该项目存在的理由从一开始就是高度主观和非理性的。尽管如此，我也在核算这个时间黑洞的成本，尤其是最近当范围与开发资源不匹配变得更加尖锐时。坦率地说，即使对于一个从未追求实质成功的项目，“投资回报率”也是极低的。至此，我得出结论，我需要认真考虑这一点。 具体来说，我所说的“ROI”涵盖了更广泛的内容，包括（而且实际上主要是）非财务方面。看到真实的反馈、互动、积极的参与总是令人鼓舞和激励。我*深深感谢*每一位花时间探索该项目、使用它、报告 bug、打包它或以任何其他方式参与其中的人。然而，我目前观察到的相关活动水平，理性地说，无法让我将工作从一个有趣的爱好转变为某种利他性的公益社区服务。目前的现状是完全合理且可预期的，我并未自欺欺人地认为这项工作有多重要或影响多大，但这一点在我的“ROI”计算中也很重要。 在过去几个月里，我曾尝试做一些安排来使这项工作合法化，并使我能够以有益的方式（再次强调，是更广泛意义上的有益，不一定单指财务）继续开发编译器。不幸的是，我的尝试都徒劳无功，没有带来任何结果。自去年秋天以来，我也尝试稍微增加一些关于这项工作的公开活动，包括录制一个讲座 (https://www.youtube.com/watch?v=MFdRccQ1y6M) 和写一些公告。公开程度被我自己的项目（非）重要性观、我的尊严和优先事项有意限制。遗憾的是，这段经历并非中立，我因此遭遇了一些不愉快的互动。 ##### 软件开发的大趋势 最近，随着人工智能的进步，软件开发作为一个学科发生了重大变化。这个项目到目前为止基本上不受新编码实践的影响，主要是因为我自己动手实现想法给我带来乐趣，并且我相信通过艰难方式克服挑战是我从中获得的主要价值。 然而，这种转变让我重新评估了开源代码发布。在此之前，我对自由和开源软件持积极态度，并将其视为像 kefir 这类工作的默认模式。我不需要为自己发布任何东西提供理由。但现在，我越来越觉得自己无偿工作的主要受益者是那些抓取互联网来训练大语言模型的公司。目前该领域公认的现状违背了我以 GNU GPLv3 许可该工作的初衷。对我来说，发布不再是“零假设”，而是需要明确的理由，而我无法提供。 #### 这是心血来潮的决定吗？ 不是，在私下讨论中，我已经提出了这个想法将近一年。然而，尽管有上述考量，仍有一些我希望能发布出去的东西。自去年 12 月以来，我曾多次打破自己设定的宣布期限。在最近几个月里，我也在等待上述安排尝试的结果。 #### 这是最终决定吗？ 不一定。我可能会改变主意，可能会感到厌倦，也可能会出现我尚未考虑的新因素。这是基于我对当前情况看法的新现状。任何改变都将被宣布。 #### 我有话要说…… 如果你认为我的推理不完整，或者我遗漏了一些重要信息，欢迎联系我。如果你有任何可能改变这个算计的东西，我很乐意倾听。如果你认为还有其他重要的事情要说，同样。如果你有 bug 要报告，欢迎你这样做。如果你想戏弄或嘲讽我，你也可以这么做，毕竟这也是一种认可。 话虽如此，本公告**不是**为了吸引注意。我只是在宣布这个变化，正如我在 README 中承诺的那样。 #### 还有什么吗？ 像之前的公告一样，该项目完全献给 Sloka 和 Kauguri。 然而，这还不是全部。下面我还有更多不必要的想法和一些预先回答的问题，如果有人感兴趣的话。 **点击阅读更多长篇论述** ##### 你为什么要写所有这些？ 我需要理清关于这个决定的思路，将它们以可发布的形式写下来是实现这一目标的最佳方式。我不期望有人特别在意，这首先是为我自己而写的。 ##### 你应该筹集捐款/推广项目/更公开等等！ 该项目已经占用了大量时间。从事此类活动，我需要放弃任何剩余的开发时间，去做我不喜欢的事情，而前景又不明朗。这要求太高了，而且很可能也不会提供稳定的前进道路。此外，在我看来，该项目*不值得*如此喧闹和纠缠。我有一定的尊严需要维护。 ##### 你应该使用 AI，效率提高 X 倍！ 如前所述，大部分开发时间实际上用于思考解决方案、它们与当前代码库的集成、影响以及架构和设计。然后调试后续问题。真正编写代码的时间占比很小，在大多数情况下如此。在这个项目中，我确实使用 AI 进行高层次的概念设计讨论，但喜欢自己编写最终的代码。此外，对我的生产力更大的提升是将与典型 AI 智能体订阅相当的资金用于改进 CI 基础设施，因为实时验证更改是我面临的整体上最严重的瓶颈。 ##### 该项目缺少 Y，所以无法成功！ 确实，许多技术上还缺少东西。限制是我可以花在设计、验证和调试上的时间和资源。制作半成品实现是可能的，但不可行（这也适用于上面关于 AI 使用的说明）。 ##### 该项目过度工程化了，是你自己的错！ 过度工程化的担忧我自己也提到过。然而，这种过度工程化实际上是一种由于开发资源限制而未能完全实现的架构。下面，我将引用我在 2026 年 4 月某天发送的一封邮件中的一段话。这是对我愿景的非常简要的解释，在其他情况下可能会需要更多阐述。 > 不一定。过度工程化不是一个绝对的判断，而是相对于当前能力的判断。如果我将 kefir 的能力视为其当前状态，是的，它过度工程化了。然而，我之所以采用“当前能力”，只是因为我到达了一个点，即在当前架构内进一步发展能力所花费的成本超过了我能合理化的范围。当前的架构支持向许多不同方向发展，但在这样做时也带来了某些显著的成本。如果我有资金并且可以全职工作，当前的架构将完全合适。举个例子，我将以 IR 模块为例。它被设想并实现为完全平台无关的栈机器抽象，隔离编译器前端，并且它确实如此工作——它提供了完整的字节码集、类型语言、数据布局语言、内联汇编集成，以及一组基于此访问平台特定信息的 API。原则上，它可以发展为一个完全独立稳定的字节码格式，类似于 JVM 字节码或 webassembly。我本可以开发一个解释器和多个类似于 HotSpot 架构的后端编译器。然而，我承受不起这样的绕路，所以我选择了最直接的路线：在其上放置一个 C 前端，在其下优化编译器后端。类似地，优化编译器本身也以非常特定的方式构建：栈 IR -> 优化器 IR -> 目标特定虚拟三地址码 -> 目标特定 IR -> 物理三地址码 -> 代码发射到汇编。当然，现在看起来似乎多余，但如果考虑到更大的愿景，这未必如此。优化器 IR 在很大程度上是平台无关的，因此它可以渐进式地应用，然后被再次解释、序列化为字节码，或者廉价地降低到虚拟三地址码（例如，无需选择 DAG 等功能）。虚拟三地址码本身也不是偶然的设计。在某些不那么优化的模式下，它可以立即以很少的额外成本去虚拟化为物理形式。其次，它再次可能提供类似于 AsmJit 的独立输入语言/接口，因此人们可以从他们的应用程序生成虚拟 x86-64 代码，让后端为其处理一些优化，并以不同方式发射。甚至有人可以尝试解释或 JIT 编译虚拟三地址码，例如用于某种类似 valgrind 的动态分析。目标 IR 本身被设计为优化链的最终组件，以 SSA 形式提供机器资源的忠实表示，我相信比 LLVM 的 MachineIR 更忠实，并且它使我能够通过将这些复杂性卸载到目标 IR 通道中，来避免指令选择的复杂性（如 SelectionDAG）。最后，物理三地址码本身也不是偶然的。目前它仅用于生成不同的汇编语法，但没有什么能阻止直接从它生成可执行代码，例如用于 JIT 目的或直接绕过汇编器。原则上人们可以在其上构建一个汇编器工具。所以你看，整个管道被设计成一个可插拔的框架，在整个堆栈上具有许多潜在用例。我对过度工程化的不满不是说我本可以用更少的工作达成当前状态，而是说我无法在保持健康和合理的同时实现我更大的愿景。 #### 结语 我想再次感谢所有以任何形式参与该项目的人。我也感谢那些费心阅读此公告（全文或部分）的人。我甚至感谢那些激怒或烦扰过我的人，因为这给了我一些教训。 祝大家度过一个**愉快的**夏天！你知道**接下来**该做什么（你当然知道）。