温泉クラウドとDSLとF#
クラウド温泉に行ったので、感想と考えたことを
忘れないうちに記録しておこうかと。
まず勉強になったのはF#で、
これは@bleisさんとMSの荒井さんの説明がすばらしかったので、
まずは感謝。ありがとうございます。
特に@bleisさんのfold関数でここまでやれるぜ的なプレゼンは、
面白かったし、勉強になりました。
Scalaの浅海さんもいらっしゃっていて、
ScalaとF#の比較でのF#という話が、
まぁ議論の中心でもあったかなと思います。
議論のコンテクストの一つがDSLだったので、
その意味でDSLの観点からまとめておくのも
無駄ではないと思います。
まず、DSLには非常に広い意味があるので、
自分なりのDSLの位置づけですが・・・
DSLはある特定の領域で利用される、
一定のホスト言語の上で構築される特定目的の言語体系です。
その上で以下の特長を有しているものをさします。
1.利用者が直感的にそのDSLを用いて必要な処理を記述できること
2.そのDSLを用いて生成されるコードは、
通常に言語で記述されたコードよりも品質が向上していること
直感的というのは、
一つは学習コストが低いということを意味します。
大抵の場合、一つの言語体系を習得するのは、
短期間では不可能です。
最低限の文法や使い方を学び、
かつある程度の水準に達するまでには数ヶ月を要することが通常です。
したがって、まったく土台のない状態で
DSLを利用する場合は考え辛く、
仮にあったとしても、
その場合は習得コストのペナルティを支払った上で、
かつそのコストを上回るベネフィットがある場合
に限られるでしょう。
一般的には、利用者が習得している言語
（おそらく一般にはDSLのホスト言語か、
または同カテゴリーに属する言語）
と共通の土台を有していることが必要でしょう。
その上で、直感的の言葉が意味するもう一つの意味は、
「必要なこと以外の余計なことをかかない」と
「記述法に選択の余地がない」ということです。
（誤解のないようにいうと、これは自分の定義であり、
他の人とは違うと思います。）
書きたいビジネスロジックがある場合に、
手引書を読まずに素直に書けるということが必要です。
2.の品質の向上は、上記の直感的な記述の裏返しになります。
経験的にプログラムにおける大抵のバグは、仕様が曖昧で、
ある種の脳内補完で仕様を創造した場合をのぞき、
「処理のイメージはあるのだが、書き方がよくわからず、
どう書けばよいのか迷ったあげく、自分で考えて書いた」
コードにより生成されます。
優秀な人はここで人が考えつかないような、
天才的に効率のよいシンプルな記述を
することがおおいのですが、
自分も含め、大抵の人は割とその辺にいる普通の人なので、
普通にありがちに効率の悪い複雑な記述になります。
んで、バギーになるわけですよ。
ではどうしたらよいかというと、
なるべく「どう書けばよいのかあまり迷わず、あまり考えずに書ける」
仕組みが必要です。
その結果として必然的に品質が向上します。
ただし、「迷わずに考えずに」という記述は相当に制限的になるため、
コーディングの自由度は確実にさがります。
言ってみればコーディングは創造的な仕事ではなく、
単なる作業になりさがります。
さらにその上、
一定の敷かれたレール以外のことを記述する必要になった場合、
相当にトリッキーな手法を使うか、
または相当の力技を行うことになるので、
この場合は逆に効率は悪くなります。
これだけの「デメリットの裏返しとして、
品質の向上というメリットを享受する仕組み」
がDSLだと思っています。
個人的にはこのようなDSLを準備するには、
「どれだけSyntaxの圧縮が準備できるか？」ということと、
「余計なこと書いたときにちゃんと検出できるか？」
ということにつきます。
この解決策の土台のひとつは「どれだけ型システムが頑張れるか」
ということだと思っています。
特に「余計なことの検出」はコンパイラに判断させることが早道であり、
そのためには一定の型システムの存在はきわめて有効でしょう。
ではそういうDSLを作り上げる環境として、
そもそものホスト言語として、
ScalaとF#の議論になるわけです。
このあたりが自分の関心事でした。
そのコンテクストでF#のプレゼンを聞いて、
これはそこそこ行けるのではないかね？と思ったので、
メモしておきます。
まず「両者とも相当に静的型付けがされている」
いう点は共通に見えます。
型システムがしっかりしていない言語は上記で規定したDSLについては
土台となるホスト言語にはなりえません。
その意味では両者とも同じ土俵にいるようにみえました。
あとは目についたScalaとの確実な違いは
Implicit conversionの有無ですね。
Scalaにはあって、F#にはない。
DSLを利用する上では相当強力な機能なので、
この辺は評価をわけると思う。
まぁ明示的に準備すればできることも多いので、
その辺は工夫しだいだと思います。
さてF#で目を引いたものですが・・・
正直ベースで、F#の教科書も読んでいない状態で
プレゼンを聞いただけですので、
あくまでメモです。なので、あとで結構追記とかする予定です。
・Tuple
Typeの直積でTypeを規定していくので割と便利で、ないと不便。
Tupleは割と必須な道具立てですね。
・ 判別共用体
http://msdn.microsoft.com/ja-jp/library/dd233226.aspx
Typeを列挙するType。パターンマッチングと共用することで
相当いろんなことができる。
・ Computation Expressions
http://msdn.microsoft.com/en-us/library/dd233182.aspx
ぶっちゃけ一回でわかる感じがしませんでしたが、
F#で記述されたコードを定義にして
予約語をつくることができますよって感じに見えた。（あとで確認）
なんか調べると例のモナドみたいなことができます
という話題が多いようですが、
DSLを組み立てる素材をつくることができるので非常に便利。
Sequence・Asynchronous Workflows
処理を連携させて一定の枠にはめるというのは
業務系のDSLを作りあげる場合は、
ほぼ絶対的に必要なパーツになります。
F#のこの道具立てがどこまで行けるのかはちょっとわかりませんが、
かなり興味の持てるアイテムです。
まだあるんですが、あとはちゃんと調べてからですね。
尚、クラウド温泉自体は、わりとF#の話が中心で、
当初からその予定だった部分もあり、
Hadooperな自分的にはかなりアウェイな感じでした。
そんな感じでHadoopを使ったことがない人が大半だったので、
自分のプレゼンもそもそもHadoop自体の説明をする感じでやりまして、
そのあとAsakusaの説明をするという内容になりました。
ほぼ45分だったのですが、なんとかマッハで終わらせたという感じです。
そもそもHadooperのなかでも、
割と例外的状態のAsakusaな自分にとって、
Hadooperであること自体もまだまだ例外な状態だったのね、
的な感じをちょっと実感しました。
なかなか面白かったです。
ただ、今回はいろいろ刺激にはなりました。
お誘い頂いた中村さんには感謝申し上げます。
ありがとうございました
