2012年7月17日火曜日

「Monadicプログラミング」の狙い

クラウド温泉3.0@小樽のセッション「Monadicプログラミング・マニアックス」で使用するスライドのネタ検討その1です。

セッションはMonadicプログラミングがテーマですが、そもそもMonadicプログラミングをすると何がよいのか、ということをまず明らかにしておかないといけません。

ひとつは、プログラミングが簡潔になる、部品の再利用性が上がる、といった日々のプログラミングの効率に関するメリットです。これは、使ってみると日々実感するわけですが、使っていない人にはあまり響かない切り口と思います。

そういう意味では、ボクも当初それほど興味はなく、簡潔⇒コードゴルフ的なコードになってしまうというデメリットもあるので、積極的に採用しなくてもよいのではないかと思っていました。旧世代のプログラマとしては、永続データ構造をベースとした富豪プログラミングに対する違和感もあります。

ボクがScalaを始めた動機はDSL(Domain Specific Language)で、内部DSLのホスト言語としてScalaは非常に有効であることが確認できました。これをオブジェクト指向言語+αで使えば十分と考えていたわけです。

並行プログラミング

ところが、以下のスライドを見て考えが変わりました。

これはScalazでの並行関数型プログラミングを説明したものですが、特にComposing concurrent functionsのあたりをみて、並行プログラミングはこちらの方向に進むのではないかと感じました。つまり、モナドの基盤の上に並行プログラミングの部品を構築しているプログラミング・モデルです。

このプログラミング・モデルの上で並行プログラミングを行うためには、Monadicプログラミングが必須になります。

Scalazを本格的に調べ始めたのは、これがきっかけです。

データフロー

そしてもう一つ、Monadicプログラミングの適用分野としているのがデータフローです。

OFAD

個人的に最も興味のあるテーマは、モデリング+プログラミングを融合した技術領域です。本ブログの名前の「Modegramming」の由来にもなっています。

モデリングについては、ビジネス・モデリングの下半分から分析、設計までの一気通貫をプログラミングと連続性を持たせた形でどう実現するのかが興味の対象です。

OOAD/OOP時代のボクなりの結論は本にまとめることができました。

今興味を持っているのは、実装技術と実行環境がそれぞれ関数型言語(正確にはオブジェクト+関数)とクラウド・プラットフォームに進化していく中で、モデリング技術がどの方向に進化していくことになるのか、という点です。

基本な考察は「Object-Functional Analysis and Designふたたび」などで行なっていますが、データフローがひとつの鍵になるかなと考えています。

DSL

データフローは、以前からg3(g3 (クラウド温泉@小樽))を軸にDSL化を模索していて、いくつか検討や試作を行なっています。

当初はUNIXのパイプライン的なメカニズムをベースにデータフローを記述することを考えていたのですが、最近はMonadicなアプローチが面白そうと考えるようになってきました。

ひとつは、Monadicプログラミングは一種のパイプライン・プログラミングということが分かってきたことです。パイプラインのメカニズムをフレームワークで用意するより、Monadicな基盤の上に構成した方がより汎用性が高まります。

もう一つは、Monoidの適用です。データフローの処理をストリームの畳込みと考えると、データフローのプロセスをMonoidとして抽象化する方向性も有効そうです。データ処理の詳細を記述するためのDSLという観点では、Monoidの枠組みは便利に使えそうという感触もあります。

以上の点から、Monadicプログラミングをデータフロー記述のベースとして期待しているわけです。

スライド

Monadicプログラミングの具体的な適用分野として、並行プログラミングとデータフローが有力な候補ということを説明しました。どちらもクラウドコンピューティングで重要な技術となりそうなので、そいういう意味ではMonadicプログラミングはクラウドコンピューティングにつながっている技術ということになります。

スライドには以下の3項目を書いて、このあたりの話をしていく感じになるかもしれません。

  • ロジック記述
  • 並行プログラミング
  • データフロー

クラウド温泉的にもよい流れですね。

0 件のコメント:

コメントを投稿