在低资源编程语言中进行高级编码

原文 ↗ Hacker News 讨论 ↗

大型语言模型的进步正在使 AI 系统能够用更老旧或更小众的编程语言（如 COBOL、Fortran，甚至自定义或深奥的语法）编写和迁移代码，这让软件项目中的语言选择可能变得不再那么受限。评论者既强调了令人印象深刻的成果——例如 LLM 重新实现 SQLite 或帮助逆向工程遗留游戏平台——也指出了严峻担忧：不要将“氛围编码”的 AI 输出用于安全关键或金融基础设施，因为维护、验证和测试覆盖仍然至关重要。许多人认为，AI 更适合用于理解和现代化遗留系统，而不是直接完全取代它们，尤其是在资深人类维护者逐渐退出劳动力市场的情况下。

安全关键系统与“氛围编码”

  • 强烈反对将 LLM 生成的“氛围代码”用于银行、核能和航空电子系统。
  • 有人开玩笑说，这类系统最终可能“太重要了”，不能交给有缺陷的人类；也有人举出人类曾经避免灾难的反例。
  • 评论者指出，这些系统依赖形式化方法、证明以及经过长期验证的代码；LLM 也许有助于理解遗留代码，但不应编写核心安全逻辑。
  • 维护被视为真正的瓶颈；很多人会热情地用 Rust 从头写新东西，但愿意长期维护的人少得多。

语言选择正变得更加可替代

  • 许多人认为，在 LLM 和智能体的帮助下，语言选择可以像变量名一样短暂，这有点“科幻”。
  • 也有人认为，频繁重写说明规划不佳并增加风险；他们更偏好逐步演进、经过充分测试的代码。
  • 反方观点：如果有良好的规格说明和测试，实施语言只是实现细节；更容易的语言迁移可以减少技术债务。
  • 示例动机：先用 Python 做原型，再重写为 Rust；或者因为部署原因从 Smalltalk 迁移到 Go。

LLM 与低资源 / 小众语言

  • 多个报告显示，当在上下文中给出规则或技能时，前沿模型已经能很好地处理自定义或冷门语言。
  • 小众社区（例如围绕遗留多媒体技术的社区）正在使用 LLM 加速逆向工程和保存工作。
  • 有人惊讶于 COBOL 的表现落后，而 Lisp 及其他语言的表现相对较好；目前尚不清楚这是数据稀缺还是更深层的限制。
  • 人们对模型如何泛化到深奥或新近发明的语言很感兴趣。

从零实现 SQLite 与基准测试

  • OpenAI 内部将 SQLite 重新实现一遍，即使使用 PowerShell 或 PHP 等语言，也被认为令人印象深刻，但也有些戏剧化。
  • 一些人强调，实现一个兼容 SQLite 且带有强测试套件的版本是一个困难但可行的能力基准，而不是生产替代品。
  • 这被拿来与 LLM 生成 C 编译器的失败尝试作比较；人们争论 SQLite 和 C 编译器到底哪个更难。

汇编与新的低层语法

  • 讨论了新的、更高层的汇编语法（例如带有类似 C 的类型、结构化块），其可能更适合 LLM。
  • 有观点认为 LLM 已经很擅长原始助记符，因此收益可能更多体现在人类可读性，而不是 AI 需求。
  • 有人举出此前类似努力的例子，并对其广泛采用持怀疑态度，不过也有人认为，如果 LLM 工作流偏好这类目标，可能会迎来某种复兴。

关于遗留与小众语言的更广泛反思

  • 对大型机时代语言和资源约束的怀旧；人们感觉 AI 会把程序员从“打字员”转变为解决方案设计者。
  • 一些人对文章没有提到某些心爱的冷门语言（Haskell、Clojure、Forth）感到小小失望，不过许多人预计 LLM 也能相当好地处理它们。
  • 总体共识：对 LLM 来说，语言选择比对人类来说不那么重要，但安全、测试和长期维护仍然非常重要。