オブジェクト倶楽部のライトニングトークスで発表してきました。どういった経緯でこのアウェイなネタができあがったのか、ネタ晴らしをします。
最初はRubyKaigi用のネタだったんです。PythonでRubyのインタプリタでも作ってLTに出ようかな、というのが出発点。でもLTには落選したので(代わりに池澤さんが感動的なLTを披露して下さいました)、お蔵入りに。プログラムも２〜３回大きなリファクタリングをして放ってあります。これはPEP-263を逆手に取ったメタプログラミング手法。プログラムの先頭に以下のように書いておくと、専用のプリプロセッサを実行してPythonのコードに変換する、というものでした。
# -*- encoding: ruby -*-
なぜそんな事を開始したかというと、「RubyがDSLに向いた言語だって？Pythonだって負けないもん！」というのが動機だった気がする。やりながら漠然と思ったのは以下の実装方法による比較です。
- 内部DSL→パーサ作らなくていいから楽。処理系も不要
- プリプロセッサ→パーサは作る必要があるけど、変換しちゃえば実行は楽
- 正規表現→パーサも作るし、処理系も必要
それと同時に思ったのが「他のDSLと違って、PythonとRubyの変換ってできることがほとんど変わらないからやってもムダじゃないの？」ということです。ここで僕の中に「言語間の距離」というスケールができあがりました。このスケール上に上記の３つを並べてみると・・・なんかパターンっぽいね。内部DSLは実装方法ではないから、通常のプログラムと区別するポイントとして「遅延実行」というのを考えてみました。関数型言語の遅延実行とは別の意味です。念のため。
これで一通りできたけど、内部DSLの設定ファイル的な使い方を説明しきれてないので、「使い方(目的)」という項目を追加しました。この段階で一通りのフィジビリティは完了。後はマインドマップで整理しつつ試行錯誤したり、足りない情報を追加してスライドにまとめていきました。そうそう、「C言語はRuby/Pythonにとっては高速化のためのDSL」というのはPython温泉で何気なく言ったらウケが良かったので入れました。あとは、MDAとして僕が唯一成功例だと思っているMATLAB/simlinkも概念として入れてあります。電子回路や制御線図みたいな超多重並列演算(見た目上)を表すことってプログラムじゃできないもんね。
後は発表用に順番を考えたり、導入の「DSLって？」というスライドを入れたりして完成しました。ちなみに、最後の未来像のところは、MATLAB/simlinkのアプローチはマルチスレッドの開発のしやすさに関しては一石を投じるかもしれないと思ったので、パターンとは別に「未来のDSL」として話すべきかな、と思って入れました。後は、Pythonのpyparsingというパーサモジュールが素敵で「これのCookbookが欲しい」というのが動機。それを組み合わせるだけで俺言語ができれば素敵だなって。この前のオブラブでは関数型言語が流行るといっていたけど、好き好んで新しいモノを使うのって10年前からJavaとかRubyに触っているような人種だよね？それはそれですごい物ができそうだけど、大衆化するかというと疑問が残ります。
そういえば、オブラブスタッフのブログにトラックバックを打とうと思ったんですけど、objectclub.jpのイベントページからはリンクとか何にもないんですね。りょーさんに教えてもらってようやく。
