现在谈论 C++ 与 Java 的遗产是否有些为时过早？

最近 Bruce Eckel 关于 C++ 与 Java 遗产的博文引发了激烈的争论。在谈到了一些设计失误之后，他总结到：这两种语言对编程语言的发展都起到了非常重要的作用，同时也留下了宝贵的遗产。但此时来谈论这两种语言的遗产是否有些为时过早呢？

Eckel 曾是 C++ 标准委员会的成员，他回忆了当初 C++ 采取对 C 语言向后兼容的决定：

要想明白为何 C++ 那么难用、那么复杂及其设计中好的一面，你必须要清楚 C++ 的设计原则：与 C 语言兼容。Stroustrup 决定（看起来也是正确的）将众多的 C 程序员转向对象之路的过程透明化：可以不改变已有的 C 代码就能在 C++ 下编译通过。

C++ 吸引了大量的 C 开发者并使其转向了 C++，尽管在这方面取得了巨大的成功，但这种兼容的决策对语言的发展产生了严重的负面影响：

与 C 语言兼容会导致很大的局限性，但这也是 C++ 最强大的地方，同时也是最让人诟病之处。该决策促使了 C++ 的成功，同时也导致了其异常复杂。

他提到 C++ 中的操作符重载很难用：

他们（对 C++ 理解不深的那些家伙）认为程序员很难恰当地使用操作符重载，事实也基本如此，因为 C++ 既有栈存储，也有堆存储，你需要重载操作符以处理所有情况且要保证不会导致内存泄漏。确实有些难啊。

毫无疑问，这么说肯定会引起争论。Archilleas Margaritis 认为兼容 C 语言并没有什么问题：

我认为 C++ 并没有因为兼容 C 而导致糟糕的设计。ADA 也兼容于 C，但却是非常棒的语言，其设计来源于久经考验的工程学实践。 对于 C++ 来说，与 C 源码级的兼容才是问题的根源。C++ 保留了 C 的预处理系统来包含 C headers，这导致了别扭的失去了上下文关系的自由语法，而这么做的目的只是为了与 C 兼容，实在是得不偿失啊。

Michele Costabirle 认为从一开始就缺少标准的程序库是 C++ 的一个败笔：

我觉得 C++ 的一个严重问题就是缺少标准的程序库。 如果记得没错的话，Stroustroup 在“C++ 的设计与演化”一书中说到他应该写一个标准程序库来支持多继承，我等无福消受啊。

关于 C++ 有很多东西值得探讨，但确定的一点是：C++ 助力程序员在编程之梯上迈上了一个新台阶。

接下来 Eckel 又以同样的基调谈到了另一种编程语言：Java，他也揪出了 Java 的一些设计错误：

多年来，Java 团队一直对“操作符重载太复杂”这个论调深信不疑。这一点以及其它很多决定导致我们在开发中困难重重，鉴于此，我对 Gosling 及其率领的 Java 团队的很多决定都嗤之以鼻… 他们说：“为了效率必须引入原生数据类型”。而我认为正确的做法应该是坚持“万物皆对象”这一理念，同时在需要考虑效率问题时提供“后门”来进行低层次的操作（这也需要考虑使用 hotspot 技术来透明地提高效率，最后的结果也是这样——引入了该技术）。最后我们发现无法使用浮点处理器直接计算超函数（结果使用软件实现了）…

我曾批评过泛型那糟糕的设计，结果得到的回复也一样：“我们需要对 Java 之前的决定（非常差劲的决定）保持向后兼容”。最后随着越来越多的人掌握了泛型编程的技巧，他们才发现泛型确实很难用。

Bill Venners 所回忆的却与此不同：

我不知道你是怎么得到下面这个结论的：放弃操作符重载仅仅是因为它太复杂了。我记得在采访 Gosling 时曾问过他为何放弃操作符重载（我想该问题和答案还尚未公开过）。他的回答与其他场合下的说法也是如出一辙：Gosling 看到在其他语言中操作符重载被大量滥用（我不知道这是否专指 C++，但肯定包括 C++），这已经超过了它能带给我们的好处。就是这些，这是主观上的设计决策。

James Watson 对 Java 故意采取的那些限制表示支持：

Java 值得称道之处就在于容易模仿。用任何语言你都能编写出难以维护的代码，但 Java 则不然。它没有像其他语言那样提供那么多容易滥用的特性。 从个人角度来看，这很可怕。如果我不想使用某个特性，那不用就好了。Sun 提的那些建议与我何干？但如果你处在团队当中，每个人都有不同的想法，那情形就大不一样了。用有限的方法完成任务就很有意义了。

Noel Grandin 也来劲了，他甚至还提到了其他语言，这让争论达到了白热化的程度：

大多数其它的“热门”语言，像 Ruby、Scala 等都没有随大流，因为他们更偏重于编写代码，而不是阅读代码。 Java 完美的平衡了这一点——看起来 Java 很乏味且缺少“酷酷”的特性，但我们却能够轻松领会代码的意图。

最后，Eckel 谈到了 Java 遗产：

Java 将主流程序员带到了垃圾回收、虚拟机和一致的错误处理模型的世界中（特别是在你去掉 checked 异常时更是如此，这可以通过我在 Thinking in Java 第四版中提到的技术实现）。尽管它有很多缺陷，但却让我们提升了一个层次，将我们带到了更高层的语言中来。

最积极的因素就是为未来语言做好准备了：

C++ 曾经是最主要的语言，人们认为这会一直持续下去。很多人对 Java 也持有相同的观点，但实际上 Java 更容易被超越，原因在于 JVM。现在我们是可以创建一门新的语言并且其效率也可以达到 Java 的水平… 这种情况正在上演——既有高层的静态语言如 Scala，也有动态语言，包括新创建的和移植过来的，如 Groovy、JRuby 及 Jython…

无心插柳柳成荫，即便 Java 本身已经走到头且不会再发展了，那它也为后继者铺平了道路。未来所有的语言都会了解到：要么创建一种可被模仿的文化（就像 Python 和 Ruby 那样），要么给竞争者创造成长的空间。

在出现之际 Java 就引起了很多争论，尤其是在 C++ 与新的 Java 开发者之间的争论。从那以后，争吵声逐渐平息下来，我们也得以更清楚地看到自己所处的位置以及这两种语言的为我们所留下的遗产。或许现在谈论遗产问题有些为时过早？听起来好像他们已死或正在垂死挣扎（我们期盼你的意见）。

查看英文原文： Is It Premature to Talk About C++ and Java’s Legacy?