Eclipse Xtext 2.0は、賞を取ったドメイン固有言語を開発するためのフレームワークの新バージョンだ。本日、Eclipseの年次リリース、Eclipse 3.7 - コードネームIndigoの一部としてリリースされた。
Xtext 2.0には、数多くのバグ修正とパフォーマンスの大幅改善のほかに、次のようなものが含まれている。
- リファクタリングフレームワークとリッチなホバー情報サポート
- 新しい式言語。どんなDSLにも組込め、ユーザは自分の言語内で簡単に計算論理を書けるようになる。
- 静的型付けテンプレート言語Xtend。コードジェネレータの開発と管理を簡単にする。Eclipseのツールと密に統合されている。
InfoQでは、Xtextの作者でリードアーキテクトであるSven Efftinge氏に話を聞いた。
InfoQ: Xtextの背景にあるビジョンは？
Sven: Xtextはまさにプログラミング言語を実装するためのオープンなフレームワークです。言語実装には、パーサー、シンボルテーブル、コンパイラなど、広く知られた実績のある方法および手段を使っています。Xtextの背景にあるビジョンは、EclipseのJavaツールのようなものを、わずかな労力でどんな言語にも提供することです。
InfoQ: Xtext 2.0の新機能のうち、開発者が必要とした、もしくは、一番欲しがっていた機能は何ですか？ またそれはなぜですか？
Sven: このリリースでは、フレームワーク全体の品質とパフォーマンスの向上にかなり力を入れました。ほかにも、さまざまな改善に取り組み、編集体験を大きく改善しています。Javaを含む複数の言語にわたって機能するリネームリファクタリングもサポートします。また、ホバー情報サポートを使い易くしたことは、多くの人に気に入ってもらえるでしょう。
実際にXtextを全く新しいレベルに引き上げるのは、組込み式言語ライブラリです。Xtextを使って構造化言語を定義するのは、これまでも簡単でした。しかし残念ながら、ソフトウェアシステムには構造化情報だけでなく、時として振舞いや計算論理といったものを定義する必要があります。構造化言語を定義するのは簡単ですが、本格的な式言語サポートを実装するのは、極めて複雑で多大な労力を要します。そのため、これまでは生成したコードを何とか拡張して、振舞いを追加することが行なわれてきました。これは機能しますが、理想からはほど遠いものです。Xtext 2.0を使えば、式を定義した完全な文法を再利用できるだけでなく、コンパイラや型システム、インタープリタ、それからもちろん、素晴しいEclipseとの統合といった必要なインフラをすべて再利用し、拡張することができます。それから最後に、振舞いの記述は、それが属するところ、すなわちDSLスクリプトに置くことができます。
Xtext 2.0には静的型付けテンプレート言語Xtendも搭載されます。これは特に、コードジェネレータを書くのに適しています。これは実際、新しい式ライブラリをベースにしており、コードジェネレータを実装するのに優れた言語であるとともに、Xtextを使ってどんな言語が作れるかを示す、非常に高度なサンプルでもあります。
InfoQ: Xtextを導入している人はたくさんいますか？ 彼らはXtextを使って何をしているのですか？ XtextのようなDSLフレームワークのスウィートスポットは何なのでしょうか？
Sven: 編物アルゴリズムのための言語や実行可能な楽譜など、クレイジーなものをいろいろと見てきました。SigasiのVHDLデザイナーのような複雑な言語の製品もあれば、Xtextを使ったオープンソースプロジェクトも多数あります。アプリケーションの種類によって、それぞれDSLのスウィートスポットがあります。たとえばWebアプリケーションについて見てみると、ドメインモデルは明らかにDSLで定義するとうまくいきます。Rails、Grails、SpringRoo、Play! frameworkといったものはみな、とても苦労して既存の言語をカスタマイズし、エンティティなどを簡潔に定義できるようにしています。Xtextを使えば、既存の言語に無理をさせる必要はありません。ドメインモデルを構成するものを定義し、これらの概念を利用するアプリケーションプラットフォームに変換するコードジェネレータを書くだけです。これは直感的で、妥協もなく、しかも、本当にすばらしいEclipseツールが手に入ります。
もうひとつ非常に興味深いアプリケーションはデータ駆動のモバイルアプリケーションです。クロスプラットフォームのモバイルアプリケーション開発に対する取り組みには、さまざまなアプローチがあります。オープンソースのフレームワークAPPlauseは、Xtextを使って定義したDSLを搭載しています。これを使うと、モバイルアプリケーションを簡単に定義して、iOSやAndroidといった異なるモバイルプラットフォームへ展開することができます。
InfoQ: 式言語を使うことで、GPPL/3GL（汎用言語/第三世代言語）とDSLの世界をブリッジしていますね。この5年、10年で、それぞれの進化をどう考えていますか？
Sven: 最近、Scalaの父であるMartin Odersky氏は、Scalaをもっと並列プログラミング向きにするため、5年の欧州研究助成金を獲得したと発表しました。彼らの提案を見てみると、アプリケーション特有のコードを生成するために、Scala式をDSLに組込めるようにするというアプローチをとることがわかります。これは並列化を考慮したものです。Odersky氏はSE-Radioにおける非常に興味深いインタビューの中で、このことについて語っています。彼はそこで、大規模な並列化には汎用のアプローチではうまくいかないだろう、特定ドメイン向けのDSLを定義するのが進むべき道だ、と述べています。彼らは並列化のセマンティックスを言語のドメイン固有の概念にカプセル化できるようにします。このように、Scalaもまた、Xtextが新しい式ライブラリですでに実現した方向へと進化するようです。
InfoQ: Xtextや今度のXtendのような新しいフレームワークの登場や、ソフトウェアアーキテクチャがさらに複雑に「多言語化」してきたため、コードジェネレーションが一部で人気を取り戻してきたようですね。これは単なる流行でしょうか？ それとも、複雑なソフトウェアアーキテクチャをDSLやコードジェネレーションの手助けによって抽象化するという、もっと大きな流れだと考えていますか？
コードジェネレーションとDSLはもうかなり長い間、主流のテクニックになっています。Ruby on RailsやSpringRooのようなフレームワークはかなりコードジェネレーションに基づいていますし、XMLスキーマやDTDといったものはみな、ドメイン固有言語を極めて不恰好なシンタックスで定義したものです。XtextとXtendは、こうしたテクニックをもっとうまくサポートできるようにしたツールです。すぐれた抽象化を作り出す方法や手段はほかにもありますが、私にとって非常に重要なことは、DSLとコードジェネレーションがすべての問題を解決するわけではないことをみんなが理解してくれることです。ほかのテクニックと同様、利点もあれば欠点もあります。開発者として、あなたは間違いなく、XtextやXtendのようなものを自分の道具箱に揃えておくべきです。しかし、それ以上に重要なことは、それらを適用すべきとき、すべきでないときを正しく理解することです。
InfoQ: 相補的だったり、重複があったり、お互いに競合するようなDSLが増えてきたとき、プロジェクト内で異なるDSLを使えるよう開発者を支援するような機能はありますか？
DSLの大きな利点はハイレベルな抽象化です。しかし抽象化すればするほど、その抽象化を別のシナリオで再利用しにくくなります。したがって、通常はある1つのプロジェクトのニーズに合わせた、シンプルな言語を定義するべきです。なぜなら、そこで使われない概念を入れる必要がなくなるからです。言語はできるだけ特化するのが望ましいです。Xtextでは、特にそうした言語を驚くほど難なく定義し、展開できるよう設計されています。
補助的に、Xtextは複数の言語をお互いに統合できるようゼロから設計されています。JavaなどXtextで作られた言語でなくてもです。ツールが複数の言語間をシームレスに動いてくれるので、別の言語だと感じることはないでしょう。
どうもありがとう！