フレームワークのお仕事
僕の友人であるひさいち君がMaltsというフレームワークを作っていて、僕もそれに感化されていろいろフレームワークを考えているのですが、彼がhttp://blog.moe-project.com/2011/12/04/%E3%82%A6%E3%82%A7%E3%83%96%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E4%B8%8A%E3%81%A7%E5%BF%85%E8%A6%81%E3%81%AA%E8%A8%AD%E8%A8%88%E3%81%A8/という興味深い記事を書いていたので、これにもちょっと流されてなんか書こうと思います。
Maltsは確かWebアプリケーションの基底部分とその上に乗っかるMVCなどのプログラミングスタイル？を分離して実装していると聞いているので、その考え方で僕が今作っている信号処理フレームワーク、GitHub - mackee/utakata: Lightweight framework for singal processingを解説してみたいと思います。
Webアプリケーションと信号処理アプリケーションの違い
Webアプリケーション
- 設計が画面ドリブンなイメージ。それから必要な機能を導いていく感じ
- MVCという関心の分離がされ、普及したスタイルがある
- 今、アプリケーションといえばWeb、というぐらいに主流の世界
信号処理アプリケーション
- Webアプリケーションから見れば信号処理アプリケーションはModelにあたる。ライブラリぐらいに見てもいいかもしれない
- 歴史が長いためアルゴリズムがたくさんある。それらを組み合わせるだけで新たな信号処理アプリケーションが作れる
- 何ドリブンかといえば、出力信号ドリブン、つまり欲しい情報にあわせて処理を組み合わせていく設計
信号処理フレームワークに「スタイル」の考え方を適用する
utakataは今v0.1を実装していますが、このバージョンで用意されているスタイルは「一発入力・一発出力」スタイルとも言うべきもののみです。これは、信号処理にかける数列を全領域にわたってUtakataDispatcherに一気に食わせてどーこーするというものです。かける処理はDispatcherに予め信号ソースと共にリストで列挙したものを渡します。これにより、信号処理にありがちな直列的な処理を簡単に指示することができます。
まだ実装を始めていないutakata v0.2では「ストリームリスナ」という概念を導入します。信号処理は流れてくるストリームをリアルタイムで処理・出力することが一番需要がある使われ方ではないかと僕は思うからです。ストリームリスナはストリームオブジェクトを食わせることで信号処理を行いますが、逐次的に結果が出てくるので、入ってきたものを右から左へ流すというスタイルを上手く記述できるのではないかと考えています。
以上のようにutakataではスタイルというべきものを現時点で2つ実装する予定です。前者の一発スタイルではとにかく全領域にわたっての何らかのデータが欲しいという場合にわかりやすくできるのではないかと思います。スケールなどは下位のライブラリへ投げてこちら側ではそれを抽象的にラップしますので、面倒な事は考えません。デメリットは、先頭データの結果が出てくるまでに時間がかかるということでしょうか。最後のデータが欲しい場合には、同じアルゴリズムで実装した場合、時間差はあまりかからないと思います。スケール機構などのオーバーヘッドを考えたら前者の方が早いこともあると思います。
というわけでMaltsのように生産性があがる方で書いてくださいと言うよりは、欲しいデータの種類によってスタイルを使い分けてくださいという感じです。
フレームワークとライブラリの境目
フレームワークとは何でしょうか？
- よく使うありがちな処理をセンスよくまとめてくれる
- 何から書けばいいか分からないときに教えてくれる標識のようなもの。その標識の通りに進んでいけば効率的に開発できるよっと
- コーディングスタイルの強制による生産性の向上
一方ライブラリとは何でしょうか？
こうしてみると結構近いですよね。そもそもフレームワークにライブラリが内包されているものがありますし、逆も然り。ただ、フレームワークは書き方、ベストプラクティスを執拗に勧めてくることにあると僕は思います。例えばNumPyなんかのライブラリだと手続きで書こうがオブジェクトで書こうがライブラリはなーんにも咎めませんが、MVCなフレームワークはモデルやビューの概念をわかっていないと当然使えませんし、その中の便利機能もベストプラクティスに最適化されています。PHPのフレームワークで言うとZendFrameworkはフレームワークと名乗っておきながらかなりライブラリに近いです。MVC的な機能も持っていますが、そいつを呼ばない限りライブラリとしてZendFrameworkを使えるという、良く言えば柔軟、悪く言えば優柔不断に陥りやすいやつだと僕は思っています。
utakataはライブラリ？ フレームワーク？
この問いに答えるのなら、ライブラリを内包したフレームワーク、もしくはライブラリを書くためのフレームワークと言えます。極端な言い方をすれば、プログラマがする仕事の9割は「utakataで使えるライブラリ」を書くこと、が思想です。
utakataで行われる処理のほとんどはライブラリ内部で行いますが、ライブラリ自体は前後に同じ種族？のライブラリが来れば、それらを選ばずに処理するという特性があります。入れ替えても動きます。結果は異なってきますが。
何がやりたいのかといえば、ライブラリを共有することで最終的にプログラマがやるのは既存のライブラリを列挙するだけ、みたいなことにしたいんです。
そうしたらラクでしょ？ 虫のいい話かもしれませんが。
ほとんどutakataの脳内構想の宣伝になってしまいましたがこんな感じです。
