Windows PowerShellは面白い

PowerShellの真の威力は、すべてのオペレーションが.NET Frameworkのオブジェクトに基づいている点にある(すでにお気づきのようにPowerShellではパイプの中を流れるデータは単なるテキストではないのだ)。

コードネームMonadは、シェルコマンド(Cmdlet)をMonadスタイルで作っている点にあるのか。パイプはたぶんHaskellでいうところの(>>=)で組み合わせたコマンドだろう。そのほかのコンビネータはなにがあるんだろうか。以下は簡易ドキュメントらしい:

なる、functionはCmdlet aを作るもの、filterはa -> Cmdlet bを作るものか。filterの例って本当に関数型言語っぽいし。


MacはシェルにObject指向プログラミングを組み込んだけど、VistaはシェルにOOに関数型の汎用コマンド演算体系(Monad)を組み込んだ感じだ。


これで任意のコマンドから利用できるデータソースたりうるWinFSがないのは正直もったいないと思った。これは、個別にコマンドを実装すらいいって話なのだろうけど、そうなるとfilterとデータ型は相互作用的に広がりることは起こらないだろう。結局、いままでのアプリと同じく、テキストやwell-known XMLといった共通フォーマットでない限りは、データとその処理は一体で一緒に普及させるしかなくなる。


たしかに、WinFSがあったところで、ローカルデータでしかないというのが、現状としては費用対効果面では問題になるだろう。ただ、Webリソース(そのキャッシュ)をWinFS構造に取り込むのは、(GFSのように)そんなに難しくないと思うのだが、どうなのだろうか(パフォーマンス上の問題か?、それともOOデータというのがネックになるのだろうか?。


さいごに夢というか、Cmdletシェルの可能性を少し考えてみる。たとえば、cscコンパイラだが、現状はアセンブリファイルを吐くだけだ。これがCmdletになれば、クラス構文木のストリームを返すもの(csc -parse)、バイトコード化するもの(csc -compile)、アセンブリにパックするもの(csc -link)、として実現できる。

ここにAspect指向を追加するような構文木を受け取って、構文木を返すCmdletを作ることができるようになる。ほかにもコード処理をするコードも作れ、それをパイプでつなぐことができる。たとえば、バイトコード化はCLRではなく、JVM classファイルフォーマットにしてしまうCmdletとか。

現状はこういう機能は、システムにビルトインされていて、せいぜいライブラリ的にシステムを作るときに作者が組み込むかでしかない。Cmdletになれば、ユーザー側で選べるようになり、作者にとってもトータルシステムを構成することが省かれ、より特有の機能だけに洗練できるかもしれなくなる。

現状はまだそんなにフィルタ化できるものはないけれど、フィルタ化するといいというものは実はかなりあったりする。とくにWebリソース(YouTube2chRSSはてブ、などなど)やOffice文書はそんなの多いわけだし。いまは、まあPlaggerを使えばいいのかもしれない。それよりもミクロレベルから、それと同じようなことがやりやすくなる可能性があるということだ。

あとGUIと合わないということもない。GUIのメニューは実質的にコマンド発行でしかないのだから。要はいかにフィルタ抽象できるかを解決できれば、むしろカスタマイズシステムとしてCmdletを起動するGUIを作ることが簡単になる。とくにWPFと組み合わせたらおもしろいだろう。