Charles Oliver Nutter 氏は JRuby の開発で有名だが，自身でも２つの言語を作り出している。それが Duby と Surinx だ。InfoQ では Charles 氏にインタビューを行い，Duby と Surinx を開発した理由とその将来像について話を聞いた。
つい先日 Duby 0.0.1 がリリースされましたが，Duby の開発を始めたきっかけと目標について教えてください。
Duby の最初はトイプロジェクト(toy project)でした。私自身 Java 以外に JRuby を実装できるものを欲しかった，というのがそれを始めた動機です。当初は C や .NET のような他言語のバックエンドとなるものにしたい，という考えもありました。現在は JVM のサポートに限定して作業を進めていますが，ここ数ヶ月の間に急速に進歩しています。
私は Duby を Ruby の文法，差し替え可能なコンパイラ，型システムを持った言語である，と定義しています。プログラム言語が本当に Java の代わりになるために必要な特性が３つあります。Java と同等のパフォーマンスを備えること，現在の Java の機能をすべてサポートし，将来の機能拡張にも容易に対応可能であること，JDK で提供されるもの以外の外部ランタイム依存を持たないこと，この３つ。これらの基準は私自身が必要としているものです。私が望んでいるのは javac の代替として，依存性のない Java クラスファイルを単独で生成可能なプログラム言語なのです。今日の Java が抱えている以上のセマンティックギャップを持たないプログラム言語なのです。そして，最小の組み込みデバイスから最大のエンタープライズシステムに至るまで，Java が動作するすべての場所で動作するプログラム言語なのです。これらの機能をサポートできない言語では Java を完全に置き換えることは不可能であり，Duby はそれを達成しています。
Duby には２つの将来像があります。そのどちらか，あるいは両方とも実現できれば，と願っています。ひとつめは Duby が Java と Javac の後継として，広範かつ汎用的に利用されるものになること。すでに Java の機能の大部分はサポートできていますし，週ごとに追加されていますから，これは実現に近づいていると言っていいでしょう。もうひとつの将来像は，Duby に比肩するようなクリーンでエレガントな言語を誰かがデザインしてくれて，私の３つの要求を満たしてくれる，というものです。その言語が十分に美しければ Duby の作業を続ける理由もなくなって ... 私も他のことをする余裕ができるかも知れません :)
Duby のプログラム例としては，以下の Swing Hello World デモ が適当だろう。
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
You said that Duby was started to implement JRuby in it, how is that coming along?
JRuby を実装するために Duby の開発を始めた，というお話がありましたが，そちらについてはどうなのでしょうか？
もともとの動機は確かにそうでした。目標のひとつとして興味はあるのですが，現在では Java が占める位置への後継者になり得るものとして Duby を考え始めています。現在はまだ初期段階の単純なものですが，それでも興味深い部分がたくさんあります。JRuby を Duby 上に実装するためには，いくつかの機能を追加しなければなりません。IDE や ant タスクなどのツールのサポートも必要になりますし，プログラムの書き直しを承知させるに足るだけの説得力も必要でしょう (さもなくば，Java から Duby への変換ツールを用意する必要があります)。書き直しは多大なリソースを要する一方で，JRuby のパフォーマンスや互換性が向上することはないのですから。それよりも Duby を使った新しいコードやエクステンションの実装例を Ruby ユーザに公開して，同じ作業をするための参考にしてもらった方がよいのかも知れません。
.java ソースファイルを出力できるコンパイラモードの実現に関しては，Google の Ryan Brown 氏に大変感謝しています (氏には最近 Duby に関して数多くの貢献をして頂きました)。この上 .java から .duby へのコンバータがあれば， Java 以外では初めての，完全にラウンドトリップ可能な JVM 言語が手に入ることにもなるのです。考えるだけでわくわくします。
Duby と並行して，その動的言語版である Surinx の開発も行っていますね。"Surinx は Groovy のあるべき姿だ" と Stackoverflow に書かれたこともありました。Surinx の開発を始めた理由をお聞かせください。
Groovy，JRuby，Jython といった動的言語を悩ませている問題が２つあります。invokedynamic を実装していない JVM 上でも動的ディスパッチが機能するように，小細工やオーバーヘッドを数多く施さなければならない，というのがひとつ。２つめは，JVM 上に実装するのが困難なプラットフォーム外(off-platform)機能 (JRuby や Jython に見られるような) や，見込み外れとなった初期の機能 (Groovy にいくつかあります) も扱わなければならない，という点です。Surinx はそのような過去とは完全に決別しています。Surinx は JVM の型と (invokedynamic のような) JVM の ディスパッチ機構だけを使用して動作するのです。Surinx は正真正銘の動的言語版 Duby ですが，同時に "可能な限りシンプルな" JVM 用の動的言語である，とも言えるでしょう。
Surinx は動的タイプ言語でありながら，他の言語のようなオープンクラスや method_missing 機構，メタプログラミング機能などを提供していない点についても説明が必要でしょう。理由は簡単で，Java の型システムがそのようなものをサポートしていないからです。Surinx では新たな型システムを取り入れるようなことはしていません。ただし将来的にはコンパイラのプラグインやコード変換，あるいは hotswapping のような JVM の機能追加によって実現される機能もあるでしょう。ですから，先のことは分かりません。
Surinx の将来について話すのは Duby の場合よりずっと簡単です。この２つは統一されます。両方の言語を開発する立場から言えば，Surinx と Duby はディスパッチ機構と型宣言条件こそ違っていますが，本質的に同じ言語であることは明らかです。Duby でも動的起動に必要な "型のない式" や "動的な型の式" を容易に扱えるのですから，Surinx を Duby の機能として吸収できない理由はありません。
Charles 氏は invokedynamic に関する優れた紹介資料も書いている。
Duby は GitHub と Kenai で公開されている。
Duby は Java の後継者のひとつになり得るだろうか，読者の考えはどうだろう？