这篇被广泛引用的帖子（反正我一直看到有人引用它）表明，动态语言和/或以更简洁的方式表示事物的语言在令牌效率上更高。似乎被引用的频率足够高，以至于LLM搜索结果一致。例如，当我搜索“动态与静态语言令牌成本”（不带引号）时，谷歌的AI总结开头指出，动态类型语言的LLM令牌成本通常低于传统的静态类型语言，因为省略显式类型声明使代码更加简洁。谷歌的AI引用了同一篇帖子，指出一些简洁的动态语言在令牌成本上可能是静态语言（如Rust、Go、C++等）的1/2到1/3。作者表示，我比较的语言中，C（令牌效率最差的语言）与Clojure（效率最高的语言）之间的差距达到了2.6倍。随后，他们还尝试了J，称其平均仅需70个令牌，几乎是Clojure（109个令牌）的一半。数组语言在避免奇异符号集时可以极其高效。如果令牌效率最终成为一个关键驱动因素，这可能是语言进化的一个非常有趣的方式。我找到了另一个动态与静态语言令牌比较的帖子，支持相同的结论。如果你想将其视为基准测试、评估和实验设计系列练习的第8部分，可以点击链接并思考评估问题，然后再阅读更多内容。在未进行我们自己的评估的情况下，第一个实验的问题之一是这些问题都很简单，从上面的引用中我们可以看到；一个在J中用70个令牌解决的的问题和在Clojure中用109个令牌解决的，根本不算什么问题（作者使用了Rosetta代码）。正如我们在查看原始模式与我们自己的评估时看到的那样，你可以从琐碎问题中获得非常不同的结果，在这些问题中，大部分工作都集中在输出一个答案上，而不必要的真实工作；原始模式所声称的巨大收益，在你开始关注那些需要超过几个令牌的问题时会消失。一般来说，对琐碎任务的表现并不具普遍性。第二个链接中的问题更微妙，因此我们将在附录中推迟大部分讨论，但它们包含一些问题，例如某个测试执行了错误的路径（该路径并不存在），导致该测试失败。后来的一个代理将不存在的路径符号链接到它自己的可执行文件，这在这种情况下有效，但也导致所有后续测试都运行该代理的可执行文件，而不是正确的可执行文件。作者试图得出结论，Rust出现了一些失败，这只意味着评级在Go代理将所有评分符号链接到Go可执行文件之前就已经进行了。我们不应仅依赖这些评估，我们可以尝试运行一些自己的评估。正如我们在这些评估以及我们在之前评估讨论中看到的那样，制作一个评估，其内容与评估创建者所认为的内容不一致是非常容易的。毫无疑问，这些评估也不例外，可能存在缺陷（见下文附录获取更多细节）。为了培养我的直觉，我喜欢在查看结果之前先进行预注册的猜测。一些我与朋友预注册的内容是：高度信心（95%）：整体动态与静态语言的论点不会成立，理由如上所述：这感觉类似于原始评估，结果在问题变大时充其量会被稀释。低信心（60%）：在超高努力下，静态语言会比动态语言稍微好一些。对于超高努力，非常微弱的信心认为，测试将更快地将反馈传递给模型，并将对正确性或效率产生某种好处，但这在各种原因下似乎也合理，例如，我注意到Codex在调用Rust编译器时，常常会产生完全相同的错误，然后必须修复它；也许这种情况会掩盖假设的更快反馈周期等情况。高度信心（98%）：像J这样的“奇怪”语言的优势不会成立，和整体静态与动态语言的论点相同，另外补充的是，AI实验室将在鲜为人知的语言上有很少（甚至可能没有）合成数据RL环境的努力。对于第一次评估，我尝试给代理提供zstd RFC（加errata），并告诉他们实现一个完整的zstd解码器（代理在没有互联网访问的容器中受限）。测试没有提供给代理。对于表面面积如此大的zstd，期望测试覆盖每种可能的情况并不合理。例如，即使zstd是一个经过充分测试的软件，我曾经在zstd中发现过一个数据损坏错误。测试套件并不打算覆盖每种情况。