bruceeckel译者注：

本文翻译自Bruce Eckel（《Thinking in C++》& 《Thinking in Java》作者）的博文，该博文于2009年03月14日发表于：

http://www.artima.com/weblogs/viewpost.jsp?thread=252441

本文的发表引起了互联网上热烈的讨论，关于讨论大家可以到这里围观。

下面是原文。原名《The Positive Legacy of C++ and Java》

摘要：

在最近的讨论中，有些人断定C++并不是一个设计完美的语言。在我在C++标准委员那8年里，我目睹所有关于C++的决议的诞生。我希望本文有助于帮读者理解C++和JAVA的设计选择，从而可以让大家更全面的来看待他们。

有人说，我很少再使用C++。当我使用C++时，我只是为了测试一下陈旧的代码，或者写一个和性能密切相关的程序，通常这个程序非常小，并且通过其他的语言来调用。(我喜欢的做法是，用Python快速开发一个程序，用profile辅助程序对其进行性能优化，如果需要的话，通过Python的ctypes调用C++写的程序来改善性能)。

因为我曾经是C++标准委员会的一员，我目睹了这些决议的产生。这些C++决议都是在经过超级深思熟虑的考虑之后在做出，他们远比大多数Java的决议更为谨慎小心。

然而，就像有些人准确地指出那样，C++是复杂而难于使用的，并且充满了各种个样容易让人忘记的古怪的规则。当我在写书的时候，我只能从规范中找到这些规则的说明，而不是自己能记住这些规则。

为了让人们理解C++这门语言如何即难用、复杂，同时还要有良好的设计，你必须记住一条C++中最主要的设计原则——兼容C语言。这是Stroupstru最正确的决定，这样做将会出现一条让大量的C程序员通向C++程序的捷径：这条捷径允许C程序员不需要做任何修改就可以在C++下编译程序。然而，这也成为了C++语言巨大的约束，它给C++带来了强大的力量，同时也给C++带来了无尽的痛楚。正是因为这个约束导致了C++如此的成功，并且也如此的复杂。

这些C++古怪的条约使那些没有完全了解C++的Java的设计者们犯了傻。例如，他们认为程序员能用好操作符重载将会是非常困难的一件事。但是操作符重载在C++中却是必须的，因为在C++中有栈分配，同时又有堆上的分配，你只有通过重载好操作符来处理好不同类型的内存分配，并保证不会产生内存泄漏，的确是难！但对Java来说，因为Java只有单一的一种内存分配机制（译者注：Java基本上是采用堆分配）和垃圾回收机制，这样操作符重载在Java中就变得多余（正如C#的操作符重载，和更早之前的Python操作重载，但是Python出现的要比Java早）。但是多年以来，来自Java的团队就一致认为“操作符重载太过复杂”。这一决议或其他的一些Java决议，明显说明了很多Java的设计者在做出决议的时候没有做足自己的工作，这也是为什么我有了一个藐视由Gosling和他的Java团队所做决议的名声。

同样还有太多太多的例子，基本类型“因为性能原因被引入”。真正的原因是为了坚持“所有都是对象”，并且同时为底层具有效率要求的程序提供一个后门（同时这也使得一些热点技术执行起来更有效率）。噢，但是事实是，你没有办法直接使用浮点处理器来进行超越函数的计算（译者注：Transcendental Functions ，一种微积分的函数），而只能使用软件来计算，但原本这类函数就可以使用浮点计算处理器来计算的。我尽我所能将类似这样的问题罗列出来，但是我听到的结果却总是那些无用的回答“这就是Java的方式”。

当我写下泛型是个如何糟糕的设计时，我得到了同样的回应，“我们必须兼容之前的（糟糕的）Java的决议”。最后越来越多的人们获得了足够关于泛型是多难用的经验——的确，C++的泛型更强大，一致性更好（尤其现在当编译器的错误信息越来越清晰后，泛型也比以前更好使用），因为Java泛型设计很差，很难，所以人们又开始回到认真对待具现化而不是泛型，当然，这对语言是有帮助的，因为具现化这个东西并不会消弱太多的语言设计，也不会因为这些自我限制而导致语言缺陷。

那个Java的问题列表在这些沉闷的回应面前只能显得单调乏味。那么，是不是这样就意味着Java是失败的语言设计呢？绝对不是，Java将主流程序员带入到了一个垃圾收集器、虚拟机、一致的错误处理模型的世界(如果你不使用异常处理，这类异常可能是非常有用的异常，正如我在《Think in Java 》4ed中演示的那样)。伴随着它设计上种种缺陷，Java把我们带领到了一个更高的层次，在这个层次上我们正在准备着迎接更为高级别的语言。

另一个观点，人们一直认为C++是语言中的先驱，许多人也认为Java是语言的先驱。但是因为虚拟机，Java使得自己更容易被别的语言替代。现在任何人都有可能快速创建一门新的语言，并且和Java具有一样的效率；而以前，要得到一个正确的，有效率的编译器花去了开发一门新语言的大部分时间。

现在，我们正在见证这一切的发生——不管是更高级的静态语言，例如Scala，或者说是动态语言（译者注：Dynamic Language，如Python或Ruby），不管是新的还是移植的，例如Groovy ，JRuby和Jython。这就是未来的趋势，并且其过度将会非常的平滑，因为你可以在已有的Java代码中使用这些新语言，如果有需要，你甚至可以重写Java中产生有性能瓶颈的地方。

正如C++会消亡一样，Java自生有可能消亡，或着被用于特殊环境之下（或仅仅是为了支持以前遗留的代码，因为Java并不像C++那样会被用于硬件编程）。但是Java 真正的亮点，也是意料之外的收获，就是如果当Java已经到了自身没法在进化的地步时，Java已经为其替代者创建一条平滑之路。所有未来的语言都将从这里学到：要么为自己创建一种可以不断重构(进化)(正如Python和Ruby做的那样)的文化，要么就让其竞争者发展壮大。