IT 行业发展至今日，编程语言数不胜数，每种编程语言都有自己的用户。为了证明自己使用的语言比其他的语言好，用户们经常在网上争论不休。其中，最常拿来比较的就是编程语言的运行速度，然而通过速度来比较编程语言的好坏，这种做法就正确吗？

事实上，由于测试代码过于简单，很多速度测试都不够客观。在实际应用中，我们常常需要编写大量重复度低的业务逻辑；但在速度测试中，为了保证公平性，测试人员往往会用同一段代码测试每种语言，并且为了减少工作量，他们不会使用复杂代码，而是选择重复度高的代码（比如计算斐波那契数列）。同时，测试者为了让代码运行时间更长、测试结果更明显，还常常在速度测试中使用大数据 —— 可这也会导致数据无法放入 CPU 的 L1 缓存（大部分 CPU 的 L1 缓存仅有几十 KB）。要知道，L1 缓存的运行速度远高于 L2 和 L3 缓存，如此一来，这类测试结果便完全无法反映真实应用场景。

另外，前一段时间 GitHub 上有一个热度很高的编程语言速度排行榜，它使用的测试代码是计算莱文斯坦距离（Levenshtein Distance，一种衡量两个字符串差异的字符串度量标准，指通过插入、删除或替换单个字符，将一个字符串转换成另一个所需的最少操作次数），结果显示第一名 Fortran “吊打” 了第二名 C 语言。尽管这个结果看似很有说服力，但有技术专家发现，该测试中用于 Fortran 的代码被额外添加了优化逻辑，导致测试条件并不公平。

编程语言的速度排行榜，其实就像手机跑分 —— 跑分高低并不能代表它是否适合某个用户。就好比喜欢拍照的人会更关注手机的摄像头配置，经常出门的人会更看重手机的续航能力；对于开发者而言，编程语言的复杂度、语法规则的友好度，往往对选择更具决定性作用。这也是为什么 JavaScript 和 Python 即便运行速度不算快，也常常成为开发首选。

说到底，这个世界上没有哪种编程语言是 “六边形战士”，更不存在绝对 “最好” 的编程语言 —— 选择的核心，永远是 “适配场景”。