程序为何总出错？Stephen Wolfram 的 Bug 理论
Towards a Theory of Bugs: The Ruliology of the Unexpected
Bug 在软件世界中无处不在，且往往出人意料。Stephen Wolfram 提出，利用 ruliology 和计算不可约性原理，我们可以从基础层面理解 Bug 的本质。即便是结构简单的程序，如 Turing machines，也可能因计算复杂性而产生不可预测的错误。文章探讨了计算有效性与 Bug 倾向之间的权衡，以及自动化系统（包括 AI）在检测这些深层 Bug 时面临的根本挑战。
当程序做了我们不想要的事情时，我们就会把那些事情称为 Bug。
HN 评论区
46- gjm11
Wolfram 关于“bug”的讨论，大部分并不是在谈下面这种情况：
你想要一个能完成 X 的程序。于是你思考一个能完成 X 的程序应该长什么样，然后写了一个你认为能产生结果 X 的程序，但也许你犯了一些错误。
而是在谈另一种在我看来完全不同的情况：
你想要一个能完成 X 的程序。于是你写了一堆随机的小程序，过一会儿发现其中一个在小样本上看起来像是在做 X。你就用了它，但也许实际上它并不总是有效。
这里的关键区别在于：第一种情况中，你试图通过理解程序在做什么来避免 bug；而第二种情况中，你试图通过观察程序的输出来避免 bug。
（也许一些极端的测试驱动开发实践者会倾向于后者。也许某些 AI 驱动的编程 uncomfortably close 地接近了它。但这通常不是人们编写和调试软件的方式。）
Wolfram 试图为这种观点辩护，他说：
“从根本上说，确保程序永远按你意愿运行的唯一方法，是理解它能做的一切。但这其中隐含着一个悖论：如果你真的能理解程序能做的一切，那基本上意味着该程序在做某种计算上可简化的事情，而你可能最终根本不需要运行程序的所有步骤就能得到结果 […]”
- tomstuart
Stephen Wolfram 工作方式中令人沮丧的一点是，因为他从未真正定义过任何东西，所以很难分清哪些是真正有趣的实证科学，哪些只是在瞎折腾的数据可视化。
在这里，在他开始之前，我们凭什么认为图灵机实现 f(n)=n+1 中的 bug 在任何意义上都能代表正常计算中的 bug？他似乎是在生成随机状态机，然后评估它们，挑选出那些近乎正确但又不完全正确的 f(n)=n+1 实现。这像是一个正常的“诚实”的软件 bug 吗？它像你在评估软件供应链风险时可能会寻找的那种蓄意破坏吗？它像你在 fuzzing 时可能会看到的那种漏洞吗？就我所能看到的，没有任何理由认为它像上述任何一种。
- seanhunter
我是不是搞错了？Google 安全工程副总裁说“我们 simply must eliminate every software vulnerability on Earth”（在 AI Agents 发现它们之前），这句话不仅野心勃勃得令人咋舌，而且从一开始就注定要失败？
https://youtu.be/B_7RpP90rUk (at 3:00)