Charles Nutter 访谈：Duby 与 Surinx

Charles Oliver Nutter 因其在 JRuby 方面的工作而闻名，但他自己也创造了两种语言： Duby 和 Surinx 。InfoQ 采访了 Charles，来了解为什么他要创造 Duby 和 Surinx，以及两种语言的未来。

Charles，你刚发布了 Duby 0.0.1 。为什么要创造 Duby，它会如何发展？

Duby 始于一个小项目，我渴望能用 Java 之外的东西来实现 JRuby。当时，我希望 Duby 能支持像 C、.NET 这样的后端。目前只实现了 JVM 的支持，最近几个月来这块进展的很快。 我是这样来定义 Duby 的：它是一种结合了 Ruby 语法、一个可插拔编译器和类型系统的语言。我相信一种语言要真正代替 Java，它必须有和 Java 完全一样的执行结果；必须要支持所有当前 Java 的特性，还要能轻松适应新特性；除了 JDK 自带的东西，它不能有任何外部运行时依赖。这些条件源自我自己的需要。我想要一种语言，能在生成自立的 Java .class 文件时代替 javac。我想要一种语言，没有像如今的 Java 这么大的语义鸿沟。我想要一种语言，能工作在任何 Java 工作的地方，从最小的嵌入式设备到最大的企业级系统。如果一种语言不能像 Duby 一样支持这些特性，那么它将永远无法完全代替 Java。

Duby 有两种可能的未来，我希望看到其中的一种或者两种都能实现。其一，Duby 成为广泛使用的、通用的 Java、javac 代替品。我觉得它的可能性正慢慢地变大，因为现在 Duby 已经支持很多的 Java 特性，每周都有更多的特性加入其中。其二，某人设计一种语言，和 Duby 一样简洁优雅，并且满足我的三个必要条件。如果这语言够漂亮，我也就没理由再继续 Duby 的工作了…… 这还能让我省点时间来做别的事呢 :)

下面的这个 Swing 的 Hello World 是个很好的 Duby 范例：

 
import javax.swing.JFrame
import javax.swing.JButton
import java.awt.event.ActionListener
 
frame = JFrame.new "Welcome to Duby"
frame.setSize 300, 300
frame.setVisible true
 
button = JButton.new "Press me"
frame.add button
frame.show
 
class AL; implements ActionListener
 def initialize; end
 def actionPerformed(event)
   JButton(event.getSource).setText "Duby Rocks!"
 end
end
 
button.addActionListener AL.new

你前面说到开始 Duby 是为了用它来实现 JRuby，现在进展的怎么样了？

这的确是最初的动机，也确实是一个很有吸引力的副目标。但我逐渐发现 Duby 最终可以成为 Java 的竞争者，甚至是在它的早期，现在这种简单形式下，其中就有不少有趣的东西。Duby 还需要更多的特性来说明它能成为 JRuby 的实现语言：我们需要类似 IDE 和 Ant 任务这样的工具支持；需要有足够的动力来进行一次重写（或者实现一个 Java 到 Duby 的转换器），因为横向重写需要很多资源，却无法为 JRuby 带来性能或兼容性的提升。比较可行的做法可能是用 Duby 来实现新代码和扩展，提供范例帮助 Ruby 爱好者们也来这么做。 值得一提的是要感谢来自 Google 的 Ryan Brown（他最近为 Duby 做了很多贡献），我们有了能输出.java 源文件的编译器模式。如果再有一个.java 到.duby 的转换器，我们就能有第一个可以彻底双向转换的 JVM 语言了。这是一个很令人激动的想法。

除了 Duby，你还创造了 Surinx，一种和 Duby 同源的动态语言。 Stackoverflow 上有人说到“Surinx 就是 Groovy 应该有的那个样子”。是什么原因促使你写 Surinx 的？

Groovy、JRuby、Jython 和其他动态语言都受到两个问题的困扰。我们必须工作在没有 invokedynamic 的 JVM 上，因此必须做很多额外的事情来保证动态派发能正常工作。我们还要处理一些在 JVM 上很难实现的特性（好比 JRuby 和 Jython 中的），或者是早期版本中那些计划的很好却注定要走恶运的特性（比如 Groovy 中的一些东西）。Surinx 代表了和过去彻底划清界限，只使用 JVM 的类型和派发机制（类似 invokedynamic）。事实上，Surinx 很像动态版本的 Duby，可以认为它是一种“最简单的、可行的”JVM 动态语言。 需要注意一点，虽然 Surinx 是动态类型语言，但它不提供其他动态类型语言提供的一些功能，例如开放类、method_missing 或者元编程能力。原因很简单：Java 的类型系统不支持这些东西，Surinx 也不会引入新的类型系统。然而，其中一部分内容最终可以通过编译器插件和转换或者新的 JVM 特性（类似热交换）来实现。所以说，没人知道未来会带给我们什么。

至于 Surinx 的未来，比 Duby 的要简单些：两者会合二为一。因为是我写的 Surinx 和 Duby，我明确地知道它们实际上是同一种语言，只是用了不同的派发机制和类型声明要求。既然 Duby 可以方便地将不明类型或动态类型的表达式看做是需要动态调用的，那么没理由不把 Surinx 吸收为 Duby 的特性之一。

Chrales 还为 invokedynamic 写了篇很棒的介绍。

Duby 托管在 GitHub 和 Kenai 上。

你是怎么认为的，Duby 能成为 Java 的接班人吗？

查看英文原文： Duby and Surinx, an Interview With Charles Nutter