与 C 语言长别离

这几天来，我在思考那些正在挑战 C 语言的系统编程语言领袖地位的新潮语言，尤其是 Go 和 Rust。思考的过程中，我意识到了一个让我震惊的事实 —— 我有着 35 年的 C 语言经验。每周我都要写很多 C 代码，但是我已经记不清楚上一次我 创建一个新的 C 语言项目 是在什么时候了。

timg

如果你完全不认为这种情况令人震惊，那你很可能不是一个系统程序员。我知道有很多程序员使用更高级的语言工作。但是我把大部分时间都花在了深入打磨像 NTPsec、 GPSD 以及 giflib 这些东西上。熟练使用 C 语言在这几十年里一直就是我的专长。但是，现在我不仅是不再使用 C 语言写新的项目，甚至我都记不清我是什么时候开始这样做的了，而且……回头想想，我觉得这都不是本世纪发生的事情。

这个对于我来说是件大事，因为如果你问我，我的五个最核心软件开发技能是什么，“C 语言专家” 一定是你最有可能听到的之一。这也激起了我的思考。C 语言的未来会怎样 ？C 语言是否正像当年的 COBOL 语言一样，在辉煌之后，走向落幕？

我恰好是在 C 语言迅猛发展，并把汇编语言以及其它许多编译型语言挤出主流存在的前几年开始编程的。那场过渡大约是在 1982 到 1985 年之间。在那之前，有很多编译型语言争相吸引程序员的注意力，那些语言中还没有明确的领导者；但是在那之后，小众的语言就直接毫无声息的退出了舞台。主流的语言（FORTRAN、Pascal、COBOL）则要么只限于老代码，要么就是固守单一领域，再就是在 C 语言的边缘领域顶着愈来愈大的压力苟延残喘。

而在那以后，这种情形持续了近 30 年。尽管在应用程序开发上出现了新的动向： Java、 Perl、 Python， 以及许许多多不是很成功的竞争者。起初我很少关注这些语言，这很大一部分是因为在它们的运行时的开销对于当时的实际硬件来说太大。因此，这就使得 C 的成功无可撼动；为了使用和对接大量已有的 C 语言代码，你得使用 C 语言写新代码（一部分脚本语言尝试过打破这种壁垒，但是只有 Python 有可能取得成功）。

回想起来，我在 1997 年使用脚本语言写应用时本应该注意到这些语言的更重要的意义的。当时我写的是一个名为 SunSITE 的帮助图书管理员做源码分发的辅助软件，当时使用的是 Perl 语言。

这个应用完全是用来处理文本输入的，而且只需要能够应对人类的反应速度即可（大概 0.1 秒），因此使用 C 或者别的没有动态内存分配以及字符串类型的语言来写就会显得很傻。但是在当时，我仅仅是把其视为一个试验，而完全没有想到我几乎再也不会在一个新项目的第一个文件里敲下 int main(int argc, char **argv) 这样的 C 语言代码了。

我说“几乎”，主要是因为 1999 年的 SNG。 我想那是我最后一个用 C 从头开始写的项目了。

在那之后我写的所有的 C 代码都是在为那些上世纪已经存在的老项目添砖加瓦，或者是在维护诸如 GPSD 以及 NTPsec 一类的项目。

当年我本不应该使用 C 语言写 SNG 的。因为在那个年代，摩尔定律的快速迭代使得硬件愈加便宜，使得像 Perl 这样的语言的执行效率也不再是问题。仅仅三年以后，我可能就会毫不犹豫地使用 Python 而不是 C 语言来写 SNG。

在 1997 年我学习了 Python， 这对我来说是一道分水岭。这个语言很美妙 —— 就像我早年使用的 Lisp 一样，而且 Python 还有很酷的库！甚至还完全遵循了 POSIX！还有一个蛮好用的对象系统！Python 没有把 C 语言挤出我的工具箱，但是我很快就习惯了在只要能用 Python 时就写 Python ，而只在必须使用 C 语言时写 C。

（在此之后，我开始在我的访谈中指出我所谓的 “Perl 的教训” ，也就是任何一个没能实现和 C 语言语义等价的遵循 POSIX 的语言都注定要失败。在计算机科学的发展史上，很多学术语言的骨骸俯拾皆是，原因是这些语言的设计者没有意识到这个重要的问题。）

显然，对我来说，Python 的主要优势之一就是它很简单，当我写 Python 时，我不再需要担心内存管理问题或者会导致核心转储的程序崩溃 —— 对于 C 程序员来说，处理这些问题烦的要命。而不那么明显的优势恰好在我更改语言时显现，我在 90 年代末写应用程序和非核心系统服务的代码时，为了平衡成本与风险都会倾向于选择具有自动内存管理但是开销更大的语言，以抵消之前提到的 C 语言的缺陷。而在仅仅几年之前（甚至是 1990 年），那些语言的开销还是大到无法承受的；那时硬件产业的发展还在早期阶段，没有给摩尔定律足够的时间来发挥威力。

尽量地在 C 语言和 Python 之间选择 C —— 只要是能的话我就会从 C 语言转移到 Python 。这是一种降低工程复杂程度的有效策略。我将这种策略应用在了 GPSD 中，而针对 NTPsec , 我对这个策略的采用则更加系统化。这就是我们能把 NTP 的代码库大小削减四分之一的原因。

但是今天我不是来讲 Python 的。尽管我觉得它在竞争中脱颖而出，Python 也未必真的是在 2000 年之前彻底结束我在新项目上使用 C 语言的原因，因为在当时任何一个新的学院派的动态语言都可以让我不再选择使用 C 语言。也有可能是在某段时间里在我写了很多 Java 之后，我才慢慢远离了 C 语言。

我写这个回忆录是因为我觉得我并非特例，在世纪之交，同样的发展和转变也改变了不少 C 语言老手的编码习惯。像我一样，他们在当时也并没有意识到这种转变正在发生。

©著作权归作者所有：来自51CTO博客作者无鳍的鱼的原创作品，如需转载，请注明出处，否则将追究法律责任