Bill Burke 谈动态语言的现状与神话

“我是个 Java 的狂徒么？”——这是个好问题。Bill Burke 在他的博客文章“动态语言的现状与神话”中回答了这个问题：

也许是吧，但是我并不这么认为。…我也不相信 Java 是一切的终结。语言需要优雅的、类型安全的闭包功能，这样才能利用 Annotation 实现 DSL。它需要一种标准的、非代码生成的方式为 Annation 添加新行为。它需要一种结构化的句法来简化初始化。AOP 支持可能也很好，或者至少 JVM 的支持可以让实现类似于 AOP 的特性更容易些。在 JVM 和 Java EE、Seam、Hibernate、Spring 和 JBoss AS 等产品的 API 中，更好的 Zero-turnaround 开发特性会为开发任务带来极大的帮助。

他继续说道：

如果有一种新语言支持下面的这些特性，我倒是愿意放弃 Java，但是这种语言必须满足：

• 类型安全，静态类型
• 能够找到一个可与现代 Java IDE 相匹敌的 IDE
• 存在丰富的 API 和库，可以很容易地构建应用程序
• 存在一个生机勃勃的商业生态系统
• 存在一个活跃的开源社区

尽管当前的动态语言具备了上述的部分条件，但却没有哪个可以包含一切。所以目前为止 Java 仍然是我的选择，而我也仍然是一个 Java 的追随者。

文章还中肯扼要地探究了动态语言的一些现实与神话。动态语言的现实状况包括：

• 某某动态语言无法在某些基准测试中超越 Java
• Ruby VM 不支持内核级线程
• Ruby、Python 这些动态语言不是类型安全 / 静态类型的
• 缺少了类型安全，语言在大型团队中很难具有良好的伸缩性
• 缺少了类型安全，就无法在现代的 IDE 中进行可靠的重构

动态语言的神话包括： - 软件工程师在工作中一定要用最好的语言

• 代码行数越大，意味着错误越多，因此动态语言比静态语言好
• 我使用某某动态语言的生产率高，是因为它的语法更清晰、更优雅、更强大

你可以在 Bill 的博客上读到每一项的更多细节，不过就其中大部分内容的争论已经由来已久了。最有趣的反倒是回复中的内容。关于动态语言，John Wilson 发表了非常精辟的看法：

动态语言不是万能药，但是要想解决某些问题，它们的确是非常适合的工具。 Java 曾经对于非专业的程序员也是很友好的，但是它现在已经渐渐地偏离了这个方向（嘿，泛型，我就是在说你！）。在这种状态下，给 Java 添加任何特性 都不能让它变得更易用。IDE 能够帮助专业程序员极大地提高生产力，但是需要程序员花很大力气去学习 Idea、Eclipse 和 Netbeans，这样做 需要极大的时间和精力的投入。

我们建立了越来越多的障碍，使得编写 JVM 逐渐变得困难。如果持续下去，JVM 就会死掉。如果开发 JVM 只剩下唯一的方式：去雇用昂贵的超级专家，那么一切就结束了。

如果专家们有了什么绝妙的想法，可以在几天之内迅速地开发了一个 Jython、JRuby 或者 Groovy 实现，假如这个实现不工作，他们其实并没有什么损失。但是如果这个实现可以工作，它会面临很多问题：速度慢、无法扩展、难以维护（注意，这些问题只有在应用程序成功后才会遇到）。然后你可以通过增加资源来修复这个问题（Twitter 的开发者们似乎还没有指出过这些问题）。但是，如果完成实现所需的资源并不容易得到满足，那么能够从理论走到现实的想法就会大量地减少。

在另一篇回复中，Hypothetical Labs 将Java 的遗产看作是与Bill 列出的各个特性相关的问题： > 问题在于Java 社区如何对待语言的变化。所有的变化都要做到向后兼容。由于担心会在某些地方破坏了一些应用程序，人们是不会轻易改变任何语言特性的。理 论上，我可以让自己写于上世纪九十年代的代码运行在最新的JVM 上。这有些疯狂。[不！这是Java！-Leonidas] 糟糕的代码（cruft）受制于语言的发展变化，并堆积这些变化，直到语言的某些特性不得不被去除。看看泛型的产生过程以及正在制定中的闭包规范，就可以 知道现实中的单一设计决策对这种语言的发展究竟意味着什么…最后的结果是，语言和核心社区很担心变化。

Enrique Utrilla 在一篇回复中提到，支持了 Neal Ford 提出的关于多语言开发者的观点，以及 Ola Bini 和 Stuart Halloway 的语言层解决方法的观点：

恕我直言，这个问题最终归结为三个关键概念间的平衡：生产力、维护的简单性和运行时效率。 也许我错了，但是动态在生产力方面上胜过了 Java，就像 Java 打败 c，c 打败汇编语言一样。你可以很快地完成某些事情，这很棒，比如，建立原型和证明概念的正确性。

在维护的简单性这点上，Java 和类似的语言（包括.NET，Scala 和其他任何你喜欢的非动态的、高层的语言）胜过了动态语言。重构对于现代 IDE 来 说已经司空见惯了，而且大多能在编译时发现错误。然而动态语言只能在运行时才能检查到错误，最糟糕的是，仅仅是有时。

我最亲睐的方案是博取众家之长，提供一个多种语言之间的良好整合。用 Java 编写各个关键算法，然后用最合适的语言将它们粘合到一起。相对于纯动态语言的 实现，这样做在整体上提升了系统性能。这种方法对于 Groovy 尤其有用，它同时具备了与 Java 的相似性和与 Java 无缝集成的能力。（我承认我并没有 用 Groovy 写过很多程序，但它已经成为我第二钟爱的语言了）。这还是各个因素之间的平衡。

我认为作为开发者，我们都应该被问到这个问题“我们的社区在哪里？”当开发者在不同的语言和平台之间游走时，会遇到比新手写得好一些代码以及“骨灰 级专家”写的简明扼要的代码么？这些代码都需要重写，以便于软件的维护。语言应该变得足够简单么？这样我们依赖于 IDE，并且非专业的程序员也可以做一些 事情，而我们，专业的程序员，就可以关注和扩展新的特性和非功能性需求，比如可伸缩性。我们应该保证向后可维护性么？还是在语言和库设计者没有考虑到的时 候，动态语言的灵活性允许我们添加向后兼容性？由于以前的开发者都纷纷转入到大量新生的动态语言和 JVM 平台语言社区上来，Java 原本生机勃勃的开源社 区会日渐衰落么？

不过，Bill 最后说道：> 我在博客中表达的真实意图不是要去抨击 Ruby 和其他动态语言，而是要去抨击所有含糊其辞的说法。

就这一点来说，希望无论对于动态语言还是 Java，都应该是这样的。查看原文链接： Bill Burke on Dynamic Languages: Rationalizations and Myths