我一直在思考，如果人类越来越少写编程语言和工具，它们会发生什么。我最近写过代理在代码移植方面有多好，这让我更深入地思考了大型语言模型（LLM）和人类之间的限制。

大型语言模型面临的最大限制之一在于上下文长度。这是个棘手的问题，因为在当前的Transformer架构中，随着上下文窗口的延长，内存使用量会显著增加。而考虑到当前内存资源的紧缺状况，我认为世界并不存在内存过剩的问题。

因此，对于软件开发代理而言，编程语言的“令牌效率”可能产生显著影响，我好奇这是否会成为未来语言选择的考量因素。鉴于编码代理的大量上下文窗口将由代码构成，更高效的令牌语言应能支持更长的会话时长，并减少资源消耗。

我们见过 TOON（一种 JSON 编码以提高令牌效率），但编程语言呢？#fn1">[1]

方法论

我在做一些研究时发现了 RosettaCode 项目。它自称是一个 编程 chrestomathy 网站（顺便说一句，我很喜欢这个网站）。它有超过一千个编程“任务”，人们用各种语言编写。它在近 1000 种不同的编程语言中都有贡献。

我在 GitHub 上找到了数据集的镜像 ，于是拿出 Claude Code，让它用 Hugging Face 的 Xenova/gpt-4 分词器做对比——这是 OpenAI 的 GPT4 分词器的社区移植版。

然后我让 Claude Code 建议一些最流行的编程语言，大致符合我的经验，然后找出这些 19 种语言中都有解决方案的任务，然后通过分词器运行。 我没有包含 TypeScript，因为 Rosetta Code 数据集中任务非常少。

这个数据集和方法中存在许多潜在的限制和偏差！它旨在对某些编程任务中略有相似的解决方案进行有趣的观察，而非科学研究。

选举结果

更新： 很多人问过 APL。我又重新跑了一组同类编程任务——它以 110 个代币排名第四。事实证明，APL 著名的简洁对大型语言模型来说并不是优点：分词器对其符号集优化不佳，所有那些独特的字形（⍳、⍴、⌽等）最终都变成了多个令牌。

更新 2： 有位读者联系我，提到了 J 语——我以前从未听说过。它是一种类似 APL 的数组语言，但使用 ASCII 代替特殊符号。它以平均仅 70 个代币的优势占主导地位，几乎是 Clojure（109 个代币）的一半。数组语言在避免特殊符号集时可以极高地节省令牌。如果代币效率成为关键驱动力，这或许是语言发展的一个非常有趣的方式。

C（我比较过的最低 token 效率的语言）和 Clojure（最高效的语言）之间有 2.6 倍的显著差距。

毫不意外，动态语言的令牌效率要高得多（无需声明任何类型，节省了大量令牌）——不过 JavaScript 是分析中最冗长的动态语言。

但让我惊讶的是，像 Haskell 和 F#这样的函数式语言效率竟然非常低——几乎比最高效的动态语言差一点点。这无疑是因为它们非常高效的类型推断系统。我认为用类型语言做 LLM 有很多好处——尤其是它可以编译并快速反馈语法错误或方法幻觉。有了 LSP，这会更有帮助。

假设上下文窗口中有 80%是代码读取、编辑和差异，使用 Haskell 或 F#可能会导致开发时间明显长于使用 Go 或 C#。

让我觉得很有趣的是，我们正处于一个奇特的未来，计算量有千万亿次浮点，但代码“小”上下文窗口的冗长度实际上可能很重要。大型语言模型不断打破我对软件工程应有的认知模式。