[color=red]原文地址[/color]:[url]http://blog.csdn.net/beckel/archive/2008/05/27/2488305.aspx[/url]
Java: Evolutionary Dead End
January 3, 2008
我在比利时安特卫普举办的Javapolis大会上刚做完一个主题演讲。现在是周五早上，前一天Josh Bloch作了发言，谈到了在closures(闭包)建议方面的争论。现在他就坐在我的对面吃早餐，我们更进一步谈论了这个话题。
当初我开始抱怨的时候，理由就很简单：Java作为一种语言过于繁杂（noisy）了。读代码要比写代码费劲得多，凭这一点就直接增加了软件开发的实际成本。计算机的时钟周期是一类非常稀缺的资源，凡是毫无效益地耗光这些资源的东西—即使是表面看无伤大雅的一句多余的System.out.println()—都会剥夺可能有重要用途的循环周期，并降低编程语言的效率（[url=http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html]Steve Yegge在最近的文章中谈到了这个问题[/url]）。
Josh在演讲中提到向Java generics添加最后一个通配符可能会极大增加语言复杂性。Neal Gafter则建议应该具体化generics。而这两个人最开始都是Java generics的绝对支持者，他们对于我的批评文章的反应就说明了这一点。现在似乎出现了变化，我注意到一些人开始提出“generics确实很不错，但是…”（虽然最近Tim Bray称这些人是个[url=http://www.tbray.org/ongoing/When/200x/2007/12/16/On-Closures]祸害[/url]）。
我们对于复杂度唯一能够掌控的是抽象：隐藏无关紧要的部分（“分而治之”就是一种变化）。Java的自身矛盾性就在于它忽略了复杂性问题的一个关键方面，就是代码的可读性没有被看作为一个重要问题。似乎如果是IDE为你写的代码，那么这些代码即使是再复杂（本来不必这么复杂）也没关系。
Josh进一步阐述了他关于复杂性的观点。他说，这并不是某一孤立的特性才具有的复杂性，因为这经常是直观可见的。这是一个将一个新特性以各种可能的方式与语言其它特性结合而形成的合成复杂性。当你将一个特性硬塞进已有的语言而不是从头开始认真仔细地进行设计时，你就不可能控制这种特性是如何与其他已有特性相融合的了。合成复杂性可以导致令人吃惊的问题，特别是在增加了特性后且做什么都于事无补的时候。吃早餐时Josh说这种复杂性会为Java困惑者们提供丰富的参考依据，令他们兴趣盎然，可是对于整个社区来说却没有一丁点好处。
[b][size=medium][color=blue]稳定性 VS 特性嗜好者[/color][/size][/b]
我从与Josh共进早餐中领悟到的是我是一名特性嗜好者（feature junkie）。特性是这样一类好玩的游戏：一旦你掌握了它们，它们就可以以令人着迷的方式来运用。所以我总是在思考在新特性方面语言的演化问题。你也许会发现你也是一名特性嗜好者。
所以，当Java Generics一类的特性被糟糕地（我认为）加入到语言中时，我感到十分沮丧，我认为在增加特性时他们没有做该做的事。
但在我看来，该做的事绝不是一点不增加新特性。而是如果你不能正确处理，那么该语言可能就会不再成长并变得更相对稳定些，直到放弃对每一种已有语言特性的追求。
勿需证明，C最好的特性之一就是很多年以来它没有作任何改变。C++也十分稳固。所以这么说来让Java稳定下来也不见得是坏事。
这并不是说类似generics和closures的特性就“不好”。完全相反，当将它们精心设计到一种语言中时，它们可以十分清晰且功能强大。然而回想当初，Java是有这样的机会的。Bill Joy在语言最初版本之前[url=http://www.artima.com/weblogs/viewpost.jsp?thread=173229]强烈要求加入closures和generics[/url]等内容，但没人理睬。
很多年以来人们一直容忍着，然后突然间generics就必须要硬塞进语言之中。这显然和当年C#出现generics的情形极为相似。后者也是要在Java5中制造出几个其他特性。似乎增加这些特性的紧迫性不是来自于要使用Java解决现实问题，而是Sun在试图保持与微软的C#进行竞争的感觉。这或许并非是空穴来风，因为Java必须首先要以粗犷方式破茧而出的原因，是其认为存在一个必须要赢取的市场窗口。一个依仗市场推进力设计出来的程序设计语言最终要以白忙活一场而步入终结。
[b][size=medium][color=blue]兼容性的圣杯[/color][/size][/b]
一种选择是正确地加入新特性并破坏向后兼容性。作为一个特性嗜好者我会选择这样做，因为它不会将降低语言的完整性。而该方法一直以来未被采纳是因为向后兼容性总是语言的利器之一。我注意到Python在早期版本中战战兢兢地小范围破坏了向后兼容性。这个变化实际上没有引发任何反对声音。结果是Python正计划扩大向后不兼容的范围。Ruby也在考虑去掉一些Perl特性以简化语言。那些不想拥抱这些变化的人不会进步，他们实际也是出于保守而不愿进步。很多公司出于这个原因仍旧一直使用Java1.1。他们也将不会受这场争论的影响，因为无论如何他们都没打算接受这些变化。
我们如果由于向后不兼容而无法正确地加入新特性，当语言的变化到来时我们就无法施展拳脚了。我们处在的位置和C++一样。C++常常在设计方面饱受批评。而我作为标准委员会的成员的这八年里，经历了在每一个语言特性上的争论。这些特性并非是反复善变，而是谨小慎微和深思熟虑过的。导致语言最终变得复杂和困难的正是要保持对C的向后兼容性。一旦你打算与任何一样事物都保持向后兼容性，你就必须准备好因增加特性而破坏语言。如果Java不想破坏向后兼容性，那么它就不可避免要接受新特性所具有的毫无收益的复杂性以及无法完整实现等特点。我在《Thinking in Java（第四版）》中谈到过这个问题，Java Generics只是对真正generics的一个苍白的模仿，而对于closures更有价值的建议之一（我想它该叫做“CPA”，但在Javapolis大会的演讲中没听到过该词—也许有人会告诉我正确叫法）是对真正closures的不完整实现。但实际上有个完整实现会更好些，因为它会使代码更清晰、更简单易懂。
基础级新特性应该在新的语言中有所体现，其作为语言整个体系的一部分来精雕细琢地进行设计，而不是事后才想起来添加进去。在我看来，Java当前最好的退出策略（exit strategy）是[url=http://www.scala-lang.org/]Scala[/url]。我甚至听到了一些顶尖的程序员说在这个问题上他们并不在乎Java发生了什么事，因为他们正打算转向[url=http://www.scala-lang.org/]Scala[/url]。
如果Java要完整地存在下去，它就必须像C一样：成为一匹能靠得住的“驮马”。实际上，将来任何语言上的变化都必须能够使语言和其使用方法变得简单和清晰（比如修复classpath问题），并且充实丰富（比如说）那些被打入冷宫的不完整的库（像JMF）。
然而，类似closures这样重要且基础级的语言特性虽然在理论上极其吸引人，但一旦将其强行加进在抽象清晰性上重视向后兼容的语言中时，就会在实践过程中付出巨大的成本。因此在这个问题上我们必须变得异常保守。
（我们会在即将到来的JavaPosse摘要中讨论这个以及其他Java方面的重要问题：[url]http://www.mindviewinc.com/Conferences/JavaPosseRoundup[/url]）
Java: Evolutionary Dead End
January 3, 2008
我在比利时安特卫普举办的Javapolis大会上刚做完一个主题演讲。现在是周五早上，前一天Josh Bloch作了发言，谈到了在closures(闭包)建议方面的争论。现在他就坐在我的对面吃早餐，我们更进一步谈论了这个话题。
当初我开始抱怨的时候，理由就很简单：Java作为一种语言过于繁杂（noisy）了。读代码要比写代码费劲得多，凭这一点就直接增加了软件开发的实际成本。计算机的时钟周期是一类非常稀缺的资源，凡是毫无效益地耗光这些资源的东西—即使是表面看无伤大雅的一句多余的System.out.println()—都会剥夺可能有重要用途的循环周期，并降低编程语言的效率（[url=http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html]Steve Yegge在最近的文章中谈到了这个问题[/url]）。
Josh在演讲中提到向Java generics添加最后一个通配符可能会极大增加语言复杂性。Neal Gafter则建议应该具体化generics。而这两个人最开始都是Java generics的绝对支持者，他们对于我的批评文章的反应就说明了这一点。现在似乎出现了变化，我注意到一些人开始提出“generics确实很不错，但是…”（虽然最近Tim Bray称这些人是个[url=http://www.tbray.org/ongoing/When/200x/2007/12/16/On-Closures]祸害[/url]）。
我们对于复杂度唯一能够掌控的是抽象：隐藏无关紧要的部分（“分而治之”就是一种变化）。Java的自身矛盾性就在于它忽略了复杂性问题的一个关键方面，就是代码的可读性没有被看作为一个重要问题。似乎如果是IDE为你写的代码，那么这些代码即使是再复杂（本来不必这么复杂）也没关系。
Josh进一步阐述了他关于复杂性的观点。他说，这并不是某一孤立的特性才具有的复杂性，因为这经常是直观可见的。这是一个将一个新特性以各种可能的方式与语言其它特性结合而形成的合成复杂性。当你将一个特性硬塞进已有的语言而不是从头开始认真仔细地进行设计时，你就不可能控制这种特性是如何与其他已有特性相融合的了。合成复杂性可以导致令人吃惊的问题，特别是在增加了特性后且做什么都于事无补的时候。吃早餐时Josh说这种复杂性会为Java困惑者们提供丰富的参考依据，令他们兴趣盎然，可是对于整个社区来说却没有一丁点好处。
[b][size=medium][color=blue]稳定性 VS 特性嗜好者[/color][/size][/b]
我从与Josh共进早餐中领悟到的是我是一名特性嗜好者（feature junkie）。特性是这样一类好玩的游戏：一旦你掌握了它们，它们就可以以令人着迷的方式来运用。所以我总是在思考在新特性方面语言的演化问题。你也许会发现你也是一名特性嗜好者。
所以，当Java Generics一类的特性被糟糕地（我认为）加入到语言中时，我感到十分沮丧，我认为在增加特性时他们没有做该做的事。
但在我看来，该做的事绝不是一点不增加新特性。而是如果你不能正确处理，那么该语言可能就会不再成长并变得更相对稳定些，直到放弃对每一种已有语言特性的追求。
勿需证明，C最好的特性之一就是很多年以来它没有作任何改变。C++也十分稳固。所以这么说来让Java稳定下来也不见得是坏事。
这并不是说类似generics和closures的特性就“不好”。完全相反，当将它们精心设计到一种语言中时，它们可以十分清晰且功能强大。然而回想当初，Java是有这样的机会的。Bill Joy在语言最初版本之前[url=http://www.artima.com/weblogs/viewpost.jsp?thread=173229]强烈要求加入closures和generics[/url]等内容，但没人理睬。
很多年以来人们一直容忍着，然后突然间generics就必须要硬塞进语言之中。这显然和当年C#出现generics的情形极为相似。后者也是要在Java5中制造出几个其他特性。似乎增加这些特性的紧迫性不是来自于要使用Java解决现实问题，而是Sun在试图保持与微软的C#进行竞争的感觉。这或许并非是空穴来风，因为Java必须首先要以粗犷方式破茧而出的原因，是其认为存在一个必须要赢取的市场窗口。一个依仗市场推进力设计出来的程序设计语言最终要以白忙活一场而步入终结。
[b][size=medium][color=blue]兼容性的圣杯[/color][/size][/b]
一种选择是正确地加入新特性并破坏向后兼容性。作为一个特性嗜好者我会选择这样做，因为它不会将降低语言的完整性。而该方法一直以来未被采纳是因为向后兼容性总是语言的利器之一。我注意到Python在早期版本中战战兢兢地小范围破坏了向后兼容性。这个变化实际上没有引发任何反对声音。结果是Python正计划扩大向后不兼容的范围。Ruby也在考虑去掉一些Perl特性以简化语言。那些不想拥抱这些变化的人不会进步，他们实际也是出于保守而不愿进步。很多公司出于这个原因仍旧一直使用Java1.1。他们也将不会受这场争论的影响，因为无论如何他们都没打算接受这些变化。
我们如果由于向后不兼容而无法正确地加入新特性，当语言的变化到来时我们就无法施展拳脚了。我们处在的位置和C++一样。C++常常在设计方面饱受批评。而我作为标准委员会的成员的这八年里，经历了在每一个语言特性上的争论。这些特性并非是反复善变，而是谨小慎微和深思熟虑过的。导致语言最终变得复杂和困难的正是要保持对C的向后兼容性。一旦你打算与任何一样事物都保持向后兼容性，你就必须准备好因增加特性而破坏语言。如果Java不想破坏向后兼容性，那么它就不可避免要接受新特性所具有的毫无收益的复杂性以及无法完整实现等特点。我在《Thinking in Java（第四版）》中谈到过这个问题，Java Generics只是对真正generics的一个苍白的模仿，而对于closures更有价值的建议之一（我想它该叫做“CPA”，但在Javapolis大会的演讲中没听到过该词—也许有人会告诉我正确叫法）是对真正closures的不完整实现。但实际上有个完整实现会更好些，因为它会使代码更清晰、更简单易懂。
基础级新特性应该在新的语言中有所体现，其作为语言整个体系的一部分来精雕细琢地进行设计，而不是事后才想起来添加进去。在我看来，Java当前最好的退出策略（exit strategy）是[url=http://www.scala-lang.org/]Scala[/url]。我甚至听到了一些顶尖的程序员说在这个问题上他们并不在乎Java发生了什么事，因为他们正打算转向[url=http://www.scala-lang.org/]Scala[/url]。
如果Java要完整地存在下去，它就必须像C一样：成为一匹能靠得住的“驮马”。实际上，将来任何语言上的变化都必须能够使语言和其使用方法变得简单和清晰（比如修复classpath问题），并且充实丰富（比如说）那些被打入冷宫的不完整的库（像JMF）。
然而，类似closures这样重要且基础级的语言特性虽然在理论上极其吸引人，但一旦将其强行加进在抽象清晰性上重视向后兼容的语言中时，就会在实践过程中付出巨大的成本。因此在这个问题上我们必须变得异常保守。
（我们会在即将到来的JavaPosse摘要中讨论这个以及其他Java方面的重要问题：[url]http://www.mindviewinc.com/Conferences/JavaPosseRoundup[/url]）
扫一扫
5875
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
