一位“老程序员”的反思：C、Python、Java 不可兼得，专心学好一门编程语言就行！北京硫酸案，儿子被害凶手拒绝赔偿，母亲将整瓶硫酸泼向仇人女儿

全文：大多数开发人员在其生涯中，接触到的C词汇闻所未闻一种，但主要就掌控并运用的多数只有两门。那么在数量多样、适用应用领域各有不同的C词汇中，哪两门更适合你来学习呢？“老开发人员”Eleanor Berger 归纳了前些年他对各种C词汇的看法及其产业发展心路历程，接下去瞧瞧我们领略他心目中的最佳C词汇是什么。

书名镜像：https://devtails.xyz/@adam/switching-to-c-over-modern-programming-languages

声明：责任编辑为 CSDN 译者，需经许可，明令禁止转发。

最近，著名格斗游戏开发人员、id Software 创办人之一John Carmack在采访中表示，开发人员应该埋首努力学习两门C词汇。这倒让我感到有点吃惊。虽然我个人十分赞成这条建议，但在现如今的开发人员圈子，这种观点是有争论的。

我猜，我就是大家所说的“老开发人员”了。我的年纪非常大了，一生都在专门从事程式设计组织工作，而且从迈入社会之后就一直在专门从事此项专业组织工作。有时，我觉得自己是一名C词汇发烧友，目睹了许多C词汇的产业发展。往后，这是一段令人激动的发展史，我们会情不自禁地得出结论一个（错误的）推论：多掌控三种C词汇总没再者。C词汇的发展史产业发展十分精采，但现如今的产业发展形势相对比较豁达。

在责任编辑中我想简述一下曾经的发展史，归纳经验和教训，并看看究竟何种C词汇才是最好的技术标准词汇。

随着计算硬体和软件工程作为两门学科逐渐蓬勃发展，计算机程式设计（除了CPU本身的命令之外）也开始缓慢地产业发展。在最初的数十年里，C词汇主要就是学界的科学研究对象，还掳获了少部分科学研究人员。开发人员的选择很有限，主要就取决于应用领域。

业务程式设计采用COBOL，科学程式设计采用Fortran，还有一些其他词汇通常用于特定应用领域、科学研究H55N。

对于大多数开发人员来说，整个程式设计生涯或在很长一段时间里，只需埋首学习两门C词汇。虽然有人对C词汇的设计感兴趣，但彼时该应用领域还很稚嫩。尽管出现了一些很有趣的创新，但对于如何才能设计一种好的C词汇，人们还没有很好的理解。

随着计算机硬体数量的增加以及用途的日益多样化，C词汇的数量也开始增长，C词汇的选择变成了一个流行的话题。人们开始对C词汇进行分门别类。我们可以通过开发人员的种类以及他们渴望达到的专业水平，判断他们会选择何种词汇。个人计算机程式设计发烧友采用越来越流行的BASIC。这是一种很荒诞、很原始的C词汇，却被广泛采用并成为了一代开发人员（包括我自己）的引路人。Pascal引入了结构化程式设计，并产生了巨大的影响（Pascal与Turbo-Pascal 和 Delphi 建立了一个蓬勃产业发展的社区，但最终消失了）。

起源于UNIX的C成为了系统C词汇。C++成为了C的后继者，并借鉴了Smalltalk的面向对象程式设计，成为了专业应用程序和服务开发人员的词汇。最终 Visual Basic（与BASIC毫无关系）普及了“可视化程式设计”，满足了应用程序开发的需求（随着 Windows 的出现而迅速增长），并成为大众的首选。但人们普遍认为，VB开发人员是应用领域专家兼职程式设计组织工作，而C和C++才是“专业”的程式设计人员。

这个阶段，人们仍然没有很好地理解C词汇的设计，导致许多流行的C词汇很多方面的设计都不太理想。C词汇简单而强大，但很难熟练掌控，有可能出错的地方太多。C++的意图虽好，但最终的设计不佳，而且采用感不好。Visual Basic既有趣又简单，但有点儿戏，在当时的技术条件下，优雅与效率都不达标。Smalltalk 和 LISP 都是有趣而优雅的词汇，但由于捆绑到了专门的硬体和昂贵的工具，导致最后失势。

后来，互联网蓬勃发展。互联网对C词汇的影响究竟有多大也许未可知，但无疑这是一个重大因素。很久以前，C词汇是一个稀有之物，通常诞生于科学研究实验室和大型商业公司；但现如今似乎任何一个人都可以开发出自己的C词汇。曾有一段时间，PERL成为了流行的通用词汇，涵盖了从系统管理到 Web 程式设计的方方面面。后来，Python从科学科学研究词汇变成了简单易学的通用词汇，尽管最初产业发展缓慢，但最终席卷了整个世界。据传，Netscape 的 Brandan Eich仅用了几天时间就开发出了JavaScript（作为一种功能十分有限的浏览器扩展词汇）。这不仅证明Eich是一个天才，也证明那个时期人们对C词汇的设计有了很好的理解。

这一时期出现了许多其他的C词汇，其中最有名的是Java。这门词汇本身并没有特别之处，但它提供的JVM是一个通用的运行时环境，实现了“编写一次，到处运行”，也就是说该词汇十分通用，不受特定硬体、操作系统、或目标环境的限制。严格来讲，早期的JVM并没有什么值得炫耀的，但它开创了词汇运行时及部署选项日益成熟的时代。

自JVM以后，C词汇就开始朝着一个有趣的方向迅速产业发展。源自Self词汇（Smalltalk的后继者，虽然优秀但十分失败）的即时编译器（JIT）得到了更深入的科学研究，从而诞生了Java的HotSpot，而微软为了对抗Java推出了.NET CLR。.NET则更进一步，将 CLR（Common Language Runtime，公共词汇运行时）作为了多词汇的通用运行时，而不仅仅是C#。事后看来，这是一个分水岭：C词汇的选择变得无关紧要。这可能不是微软做出这个选择的主要就原因（当时他们仍在努力继续支持流行度十分高的Visual Basic，还有C#），再加上那段时间微软的封闭式许可，最终CLR未能成为最受欢迎的运行环境。但在千禧年之后的第一个十年中，C词汇的数量越来越多，而且无处不在。

另一方面，开发人员的数量也出现了爆炸式增长。随着软件的需求快速增长，以及工具和知识的普及，全世界数百万人都变成了开发人员。这些开发人员也是人类，他们渴望强烈的群体认同。就像普通人对体育运动团体有着强烈而非理性的看法一样，开发人员也开始在C词汇的选择问题上站队。许多开发人员迫不得已选择某种新兴、独特、特殊的程式设计语言。例如，有人声称函数式程式设计才是王道、Ruby比Python好、Scala将彻底改变数据科学、不选Clojure是你的损失……至此，C词汇从线性产业发展进入了混乱的达尔文优胜劣汰时期。

原以为，这个时期的人们会意识到某些C词汇过于疯狂，无法持续产业发展。然而，实际情况并非如此，相反，情况出现了意想不到的转变。在“云”计算时代，许多应用程序和服务的部署跨互联网上的大量分布式节点，采用何种C词汇似乎已无关紧要。开发人员都在开发互相交流的独立组件，又有什么必要纠结C词汇呢？组件之间并不需要知道彼此是用何种词汇编写的。如果开发人员喜欢用X词汇编写组件，那么就用这种词汇好了。谁在乎呀。

在不同机器上运行的组件也是如此，随着Docker的发布，容器得到了普及，无论是在一台机器上运行的应用程序，还是通过编排软件在机器集群上协作运行的软件，都可以采用相同的范例轻松管理。

现如今人们仍在开发新的C词汇，其中不乏前途无量且备受期待的词汇。有些是特定应用领域的（移动应用程序采用的Swift、Kotlin 和 Dart，以太坊智能合约采用的Solidity），而有些则比较通用，但每种词汇都得益于这数十年来积累的经验和教训（面向云程式设计的Go，面向系统程式设计的Rust，以及JavaScript的超集TypeScript，等等）。

与此同时，程式设计世界达到了一个新的成熟度，我们不再追逐每一种新趋势，采用每一种新词汇。我们都成长了。

毫无疑问，有些C词汇确实更为出色，而有些C词汇则更适合处理某些特定的用例。任何专门从事过程式设计一段时间的人都清楚，学习两门新词汇一点也不难。大多数开发人员只需一个下午，就可以轻松学习两门新词汇的基础知识，采用几天后就可以多或少地提高组织工作效率。新手开发人员可以从任何两门主流C词汇开始学习，并将学到的程式设计知识轻松地应用到其他词汇中。

然而，频繁变更C词汇并非好事，原因主要就有两个。首先，学习C词汇有点像学下棋。你可以快速学习规则，但这并不意味着你可以战胜经验丰富的玩家。你需要学习策略，而这需要时间和练习。这是一个由最佳实践、陷阱、优化技术，以及库、工具和社区组成的生态系统。其次，程式设计虽简单，却容易出错。即使拥有常见的程式设计经验和最好的工具，将想法转换为计算机代码也不是一件直觉行为。无论开发人员建立了怎样的直觉，也必须经历反复采用、即时反馈和纠错的循环。每次更换C词汇，你都需要付出代价。所以，根据我的经验，C词汇的选择很重要，但是一旦做出了选择，从长远来看，就应该坚持下去。

时至2022年，我们在选择C词汇时，需要考虑以下几点。

首先，最关键的考虑因素是词汇的适用范围。如果是特定的应用领域，必须采用一些特定于应用领域的词汇，则最具普遍适用性的词汇是首选。值得庆幸的是，自从Java提出“编写一次，到处运行”以来，运行时和部署便不再是问题，成本和合该任务。

场景，但在理想情况下，通用的主流词汇应该足以应对大多数场景。

最后，我们选择的C词汇应该优于大多数其他词汇。即使在2022年，仍有一些糟糕的C词汇，难以学习和采用，很容易让开发人员陷入困境。

鉴于上面的陈述，我认为实际上我们并没有太多选择。下面，瞧瞧我们来看看这些最佳C词汇。

C词汇界的JavaScript就像人类交流时采用的英语一样。它是最流行、最通用的C词汇，适用于许多不同的场景（浏览器/前端、系统/后端、作为扩展词汇嵌入到许多环境中）。JavaScript的运行时（V8 / Node / Deno）十分高效，拥有许多出色的工具和庞大的社区。

TypeScript是JavaScript的超集，引入了强类型和标准工具，正在迅速产业发展成为JS程式设计的默认选择。

Rust拥有C/C++的所有功能，更易于采用，而且也没有太多陷阱。Rust的社区和生态系统十分强大且在不断产业发展，工具也很好用。如果你需要的功能Rust都提供了，那它绝对是不二之选。以前只能采用C或C++的场合，现如今也可以选择Rust。此外，Rust还在建立自己的WebAssembly通用词汇（WebAssembly可以说是终极版的“编写一次，到处运行”的运行时）。

我采用Python已经超过20年了，可惜时至2022年，Python依然算不上真正的通用C词汇。原因之一是，Python仍然十分低效，很多注重性能的场合都无法采用Python。还有一个原因是，它未能进入主流的面向用户环境，比如网络浏览器或手机。尽管如此，Python仍不失为一种出色的C词汇，而且在数据工程/数据科学/机器学习中占据了重要位置，所以如果你专门从事这些应用领域的组织工作，那么Python绝对是两门值得了解和热爱的词汇。就目前的情况来看，Python很可能会作为数据科学的通用词汇继续产业发展下去，但可能无法突破这个应用领域。

Go是一种十分适合“云”程式设计的词汇。Go词汇优雅、易于学习和采用，拥有出色的社区、生态系统和工具。它被广泛应用于云原生应用领域的核心产品，因此它会长期发展下去。不幸的是，Go并没有普遍的适用性，基本无法用于互联网服务器之外的环境。此外，由于Go设计上的选择，它在C/C++世界中表现不佳。Go固然好，但如果必须做出选择，凡是Go能实现的功能Rust都可以实现，随着时间的推移，Go有可能会被主流系统C词汇取代。

C#及其生态系统十分出色，你可以用它实现很多功能。Java的各个方面都比不上C#，所以我不理解为什么有人会喜欢它，但Java确实很流行。C#的应用很广泛，不仅是一种系统和“商业”词汇，现在更是延伸到了移动应用程序和浏览器。强大的运行时，伟大的生态系统。但是，除非你需要C#的一些量身定制的运行时和工具的功能，否则在短期内C#很难与JavaScript和Rust竞争。

根据林迪效应，C和C++在未来数十年内将继续流行下去。如果你已是这两种词汇的专家，肯定不愁找组织工作。如果有这方面的需求，则花时间学习二者也是不错的选择。否则，选择Rust更合适。

这三种词汇在特定应用领域占有一席之地。如果需要移动UI程式设计，则这些是不错的选择。但JavaScript的适用性更普遍，而且也同样适用于移动开发，因此我们更应该选择JavaScript。

LISP很特别，即使日常组织工作没有这种需求，也应该学习一下。Racket 是最先进的、十分复杂的词汇（实际上它是一种词汇构建工具包）。据传，Clojure的功能很强大，因为它的目标是JVM，可以采用 Java 库。但我不清楚这个卖点有多大作用。

函数式词汇很重要。在某些情况下，它们是更优的选择。Haskell是函数式程式设计的代表。F#具有更好的普遍适用性，因为它的运行平台是CLR，并且可以采用 .NET 库。Scala不是纯粹的函数式，但十分通用，并且在 JVM 上运行。

Julia十分适合数学应用领域。R和MATLAB都有各自擅长的特定场合。不过，在Python主导的数据工程应用领域，这些C词汇恐怕很难幸存下来。

如果你专门从事shell程式设计，那么PowerShell是迄今为止最好的选择。它适用于所有操作系统，所以我们没有理由采用任何其他 shell。PowerShell也算是一种通用C词汇，但实际上在非系统管理之外，没有人采用它。

这些词汇也曾有过辉煌的岁月，主要就是作为网络“后端”词汇。无论你如何看待这些词汇，现如今都不应该再在它们身上白花力气。它们都在走向灭亡。

VB 改变了世界，但现如今却被淘汰出局了，无论是作为通用词汇还是作为对其他程序的扩展。在遥远的过去可以用VB实现的功能，现如今都可以用其他现代词汇更出色地实现。

我喜欢程式设计词汇，而且永远对新词汇充满了好奇。但是，就目前而言，TypeScript是我心目中的C位，而在需要强大的功能和低级访问权限的情况下，Rust居第二。我相信，2022年几乎所有开发人员都与我有类似的看法。