昨日『Ashigelコンパイラの勉強会』に参加してきました。
スライド：Inside of Asakusa DSL
Togetter：#ashigel Ashigelコンパイラの勉強会
自分が書いてきたメモはほとんどスライドの写しなので、今回は感想だけ書きます。（というか全部理解できたとは言いがたいので、感想しか書けないというか(苦笑)）
まず「DSL」という言葉について。
自分は最近Scalaを勉強していてScalaの本でよく「DSLの例」を見かけていた。Scala上に新しい構文っぽいものを作り上げ、それを使って目的の記述を行う形式。
なので漠然とAsakusa DSLもそんな感じかと思っていたんだけど、全然違った＾＾；
Asakusa DSLは大きく三層に分かれていて、大きな粒度から順にBatch DSL・Flow DSL・Operator DSL。
まだ公開されておらず初めて見る記述だけに、最初に簡単な実例があると分かりやすかったんじゃないかと思う。まぁ、自分は実際にコーディングしてみないと理解できない人間だからかもしれないが＾＾；（HadoopもScalaもそうだった）
という訳で、実際の実装を見たわけではないので、以下、「こんな仕組みなんだろう」という想像に基づいて書く。
で、Operator DSLは「演算子」と呼ばれていたけれども、自分の感覚では、これは「関数」だなー。（CascadingのFunctionに相当すると思われる）
たぶんどんなパターンの演算を行いたいか（1クラスを受け取って1クラスを出力する、あるいは複数クラスを受け取って…とかのパターン）に応じてテンプレートが用意されていて、そのテンプレート（クラス）を継承したクラスをプログラマーが作り、メソッドをオーバーライドして処理を記述してゆく。具体的にどんなクラスを入出力としているのかは、アノテーションで指定する（Ashigelコンパイラはこのアノテーションを読み取って、OperatorFactoryを生成する）。
（スライドのp.24）
その処理が演算（関数）で、演算を記述しているものだから演算子。…あぁ、演算子でいいのか(爆)
自分は「演算子」と聞くと「+」とか「==」とかのもっと細かいものを思い浮かべちゃうけど、まぁ上位粒度であるFlow DSLから見れば粒度の細かい「演算子」という事なんだろう。
Operator DSLはJavaプログラマーが記述し、実際のHadoop実行時にMap・Reduceから呼ばれる。これ重要。
アノテーションで情報を指定してコンパイラーで処理するのはSlim3とかでもやってる常套手段なので、特に違和感は無い。（これをDSLと呼ぶのかどうか？とは思わなくもないけど＾＾；）
次いでFlow DSL。
「演算子」を組み合わせる層。ある演算子の出力を別の演算子に渡す、という順序を記述する。
（スライドのp.25・95～96）
この記述方法が曲者。
あくまで「前後関係の記述」を「Javaのメソッド呼び出し」を利用して表記しているだけ。
だから、Javaソースとして書くけれども、実際に実行される事は無いんだと思う（コンパイル時点で解釈されるだけ？）。ここがOperator DSLとは全く異なる。
たぶん、Operator DSLでUpdateHogeというクラスを作ったら、OperatorFactoryクラスにupdateHoge()というメソッド（UpdateHogeを返す）が作られるんだと思う。
そのUpdateHoge演算子の出力をoutフィールドで表し、次の演算子クラスのメソッドの引数として渡す“ように記述する”ことによって、演算子の実行順序を表す。
だからこの場所でのUpdateHogeクラスの変数には、「Javaを利用して書いているから、何らかの変数が必要」という以上の意味が無いんだろう。
（Javaの文法に沿っていないとコンパイルエラーになる。Ashgelコンパイラはapt（スライドp.94）を利用してJavaソースとして解析するから、記述内容はJavaの文法に則っている必要がある）
（※ここら辺、具体的にはやはり違うようです。コメント欄参照）
うーん、分かりにくいｗ 黒魔術だと言われる訳だ(笑)
演算子が「語彙」であるというのも最初は分からなかったけど。演算子クラスはその業務で使うロジックだから、「在庫を更新する」とか「金額を計算する」とかの名前になると思う。
実際には在庫とか金額がもっと業務寄りの名前になるはずで、担当者はその単語（語彙）を使って会話しているだろう。逆に言えば、業務で使う用語が演算子クラスに現れる。だから「語彙」。
「語彙としてプログラムする」（スライドp.100）っていうのは、Factoryで使えるメソッドが、定義された語彙（演算子）のみで、それを使ってプログラムする、という意味だろうか。
ちなみに、Flow DSLでは演算子から演算子へ順次処理していくので、その記述から「在庫を更新してから金額を計算する」とかの文章が作れそうな気がする。
うはー、色々考えられているなぁ。
それにしても、フローはやはりGUIで描きたくなるよね(笑) 会場からも質問があったし自分もそう思ったしスライドp.100にも100万回言われたって書いてあるし(爆)
GUIツール上だけで全てを操作しようとすると不便だけど、ベタテキスト（XMLでもいいけど）と相互に切り替えられれば便利だと思う。
（自分が今の仕事で使っているStrutsのFormクラスを生成するGUIツールは不便。大規模なコピーや名称置換はテキストベースの方がやりやすい）
とりあえず、Cascadingのフロー図出力機能のようなものなら比較的簡単に作れるんじゃない？
まぁOSSなので、誰かがやってくれるだろう(笑)
DSLの最後がBatch DSL。（スライドのp.27・108）
これもafterとかのメソッド呼び出しの形式で、処理順序を記述する。
Cascadingならコンストラクターにパイプを渡してたけど、これはAsakusa DSLの方が分かりやすい（書きやすい）かも。
（というか、このレベルのものは無理してJavaで書かなくても…と思わなくも無い(苦笑)が、かと言ってXMLに書くんじゃ、かつて来た道を逆戻り…。あれ、Oozieはそういうものだったかも？）
Asakusa DSL全般を通して、Javaを利用しているというのが面白い。
というのは、間違ったクラスを使おうとするとJavaコンパイラーがエラーを出してくれるので、IDE上でそのまま開発できることになる。
つまり自作コンパイラーを作る上で、そういった面は自作しなくてもよいことになる。
なお、@asami224さんが作っているAsakusa Scala DSLはまた違った形らしいので、楽しみ＾＾
その他。
やはりMapReduceは複数データの結合（join）が一番の鬼門というか肝だなー。
CascadingだとCoGroup、Asakusa Frameworkだと直和型（スライドp.42・83）かな。
実行計画の作成（スライドp.61）とか最適化（p.117～）の考え方も面白かった。ほんと色々な事をやっている。
なぜそれが有効なのかはHadoopに詳しくないと分からないが、逆に言うとHadoopを使う上での注意点にもなってくる。
（ちなみに、スライドp.74の「分断」は何で有効なんだろう？？）
Ashigelコンパイラのコンパイル時間の例で、多めでも2分くらいというのは、速いな。
自分が今の仕事でやってるのは、最低15分はかかるし。（くたばれEJB）
あとは、生産性か。100倍というのは言葉の綾だけど、今Asakusa Frameworkを使っている現場では手書きのMapReduceではとても出来なかったというのはその通りなんだろうな～。
（Asakusa Frameworkを使って1～4人でやっている、素のHadoopなら40人は必要なんじゃないかとのこと）
まだ未完成でこれからという面も多いようだけど、このスピードで開発・公開したという所がポイントなんだろう。（2010年9月から開発開始って、半年経ってない！）
最後に。
@ashigeruさん、ずっと立ったまましゃべり続けて（休憩中も質問に答えていて休めてない＾＾；）お疲れ様でした。ありがとうございました！
（4部構成で今日中に全部終わるか、って話も冒頭にあったけど、終わって良かった(笑)）
