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

  • Ian Roughley
  • 韩锴

2008 年 2 月 23 日

话题:JavaRubyScalaPython语言 & 开发架构

“我是个 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 BiniStuart 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

JavaRubyScalaPython语言 & 开发架构