「适应Lisp来解决问题，而不是让你的问题适应Lisp。」这句话在Lisp圈子里流传了至少二十年，听起来像某种编程禅语。但真有人拿它去跟C语言拼性能的时候，事情就变得微妙了。
上个月，Twitter上爆发了一场关于「地道代码」（idiomatic code）的争论。@Ngnghm（圈内知名的Lisp程序员）和@korulang（新语言Koru的官方账号）围绕一个具体问题来回拉扯：Lisp能不能在不写成一坨反人类代码的前提下，跟C语言正面刚性能？
Koru方面抛出了一个具体数字：他们的n-body基准测试比C快14%，比Lisp快106%。这个数字像一块石头砸进水里。
「地道」到底是什么意思
争论的核心概念是「地道」。在编程语境里，它大概等于「流利程序员会写的代码」加上「贴合该语言怪癖的写法」。地道C语言用短变量名、简单循环、不安全的算术运算；地道Lisp则倾向于列表操作、递归思维、运行时灵活性。
问题是，当你说「地道」的时候，你其实在说两套完全不同的东西。对C程序员，地道意味着贴近硬件、牺牲安全换速度；对Lisp程序员，地道意味着抽象层级高、代码即数据、运行时能改自己。这两套「地道」在性能赛道上天生不对等。
Koru的测试设计很有意思：他们要求所有实现都是「朴素版」—— competent programmer would write，不搞花活，不开-ffast-math，不手调汇编。这种约束试图把比较拉回到「语言本身表达能力」的层面，而不是「程序员能多拼」的层面。
但「朴素」这个词本身就是个黑洞。
Koru的博主后来承认，部分代码和博文是用大语言模型生成的。这个细节被轻轻带过，却暴露了一个更深层的问题：当我们谈论「地道」时，我们到底在谈论人类程序员的直觉，还是某种可被算法复制的统计模式？
14%背后的架构迷雾
Koru的14%优势有个前提条件被刻意模糊化了：测试跑在什么架构上？什么操作系统？编译器版本？这些变量在系统编程领域能轻易吞掉20%的性能差异。
博主自己也埋了个伏笔——他们展示了如何用「非地道」的C代码追上Koru的速度。换句话说，C语言的地道性是可以被牺牲的，而牺牲之后，天花板反而更高。这让「地道」作为比较基准的正当性变得可疑。
Lisp社区对此的回应分成两派。一派坚持认为，真正的Lisp程序员会先用宏系统把问题领域抽象掉，再写解决方案，性能是次要的优雅；另一派则开始翻旧账，指出Common Lisp的现代编译器（SBCL、CCL）其实能生成相当不错的机器码，只是没人愿意写那种「为了速度看起来像C」的Lisp。
这场争论最讽刺的地方在于：Koru语言本身的设计目标，恰恰是让「地道」和「性能」不再互斥。他们的kernel机制试图在高级抽象和底层控制之间找平衡点——这本来是Lisp六十年前就宣称要做的事情。
当「地道」成为挡箭牌
回顾整个事件，「地道」这个词被双方当成了修辞武器。Koru用它来证明自己的设计更优——看，我们的地道代码比你们的地道代码快；Lisp阵营则用它来划清界限——你们的地道不是我们的地道，这种比较本身就不地道。
这种僵局在编程语言论战中反复出现。Go语言刚出来时，有人批评它的错误处理太啰嗦，Go程序员回应「这是地道Go风格」；Rust的学习曲线被吐槽时，社区也会搬出「地道Rust思维」来辩护。「地道」成了一种免疫机制，把批评翻译成「你还没入门」。
但Koru的测试至少做了一件事：它把「地道」从抽象美德拉到了可测量的战场。14%和106%这两个数字，不管背后有多少未控制的变量，都迫使Lisp社区面对一个具体问题：如果性能真的重要，你愿意把代码写成什么样？
一位参与讨论的Lisp程序员在Thread末尾丢了一句：「我花了十年学会用Lisp的方式思考，现在有人告诉我这种方式天生慢一倍。我不确定该生气还是该好奇。」
如果「地道」真的是语言身份的核心，那么为了速度背叛它，还算不算同一种语言？如果Koru的kernel机制真的能同时取悦抽象派和性能派，Lisp的宏系统是不是该重新证明自己的不可替代性？
热门跟贴