«前の日記(2006年11月08日) 最新 次の日記(2006年11月10日)» 編集

ema log


2006年11月09日 [長年日記]

_ [最近] 鳥取行

なんていうか、昨日昼まで寝ていた&夕方少し寝た影響で、寝付けなかったので、起きておくことにした。

そろそろ出発します。

_ [Programming][Ruby] プログラムとその図示

図による開発環境っておもしろいのが飛び出さないかなぁと言う話。

古来より、プログラムの構造を図示しようという試みはなされ続けているが、あまり、ドキュメンテーション以外で成功している例を見ない。抽象的なレイヤで図を書いてやる物が主流だ。

たとえば、フローチャートがあるが、現代では「ソースコードと何が違うんだ?」という至極もっともな指摘によりごく一部を除いて死滅したに近いといえる。

しかしだ。人間(少なくとも私は)文字列より、図の方が直感的に受け入れやすい。

SICP の「」に信号処理のモデルがあげられているが、このメタファは関数型言語の(LISP のといっても良いかもしれないが)影響を受けたプログラミング言語において、実際に使用可能な仕組みとして用意されている。

たとえば、Ruby であれば、method chain と呼ばれているが、map や gsub などで、for 文といったそれ自体に意味が含まれない形式的な記述ではなく、そこで行いたいことを書くことが可能だ*1

あまり良い例ではないが、簡単な例を挙げると Ruby の IO クラスは Enumerable を include しているので、map が利用でき、と書くと、hoge.txt の各行の先頭の文字を大文字にして、中身を出力するプログラムになる。何をしているかを、for ループなどと比較すると直感的に把握できるんじゃあないだろうか。これを図示すると↓のイメージになる*2

こういうスタイルと、お絵かき感覚のプログラミングって実は親和性が高くて、Squeak とかってその辺を踏まえてデザインされてるのかなぁとか思った。ちゃんと使ったことがないので想像ですww

yield なんかも、使うときは↑みたいなイメージを頭の中に抱いてる気がする。よくわからない何か(外部イテレータ)に移動するイメージ。CPU レベルでとらえていると言うよりは、こっちのレベルで考えてる気がする。「こっち」ってのがどこなのかは説明できないけれど、CPU レベルではない。実装レベルでの理解はあるんだけど、考える際にはもっと抽象レイヤで考えてる。とにかく、抽象と抽象で相性がよさそう。

少なくとも、for 文と図示の相性は最悪だったが、それはプログラミング言語側の表現能力の不足に依る物だったのではないだろうか。図によるプログラミングには、今後なんらかの余地が残っていそうな気がしてならない。Plagger とかマッシュアップとかってモロに信号処理的なモデルだよね。GraphEdit 的な開発環境があってもおもしろいんじゃないだろうか。それこそ、MindStorm みたいな。

重要なのは、「何が流れるか」というデータの部分で、それさえ見失わなければおもしろい物ができそうな気が飛び出しそうなんだけど、「これだ!」という良いアイデアは思いつかないなぁ。

欲しいのは、コードを使わないんじゃなくて、コードとの親和性が高そうなやつ。抽象レイヤを図で構成して、詳細をコードで書くの。これぞ、プログラムがドキュメント。ヒューーー(ナチュラルハイですごめんなさい)。

現実には、泥臭い処理がどうしてもあるから、ベースになる言語がよほど上手く作られてないと、うまくいかなさそう。

*1 たとえば、10回回るループが欲しい時に、開始条件と終了条件を決定しなければならないのはナンセンスで、10.times の方が本質を記述しているといえないだろうか。厳密には、for( int i=0; i<10; i++ ) は「結果として10回回る」のであって、「10回回る」ということを表してはいない。

*2  まぁ、あんまり、chain しすぎるとわかりにくくなるとは思う。その辺はその人の感性次第か。

本日のツッコミ(全2件) [ツッコミを入れる]
_ かずのり (2006年11月09日 00:10)

UMLをコード化するやつって無かったっけ?<br>MKTの研究やっけな?はて?

_ ema (2006年11月10日 12:16)

図がコードそのものじゃないとうれしくない気がするなぁ。結局、二つのものが管理対象になって同期でトラブりそうです。