ソフトウェアをその仕様から合成できるかということについて、ルール検索とプログラムの半自動合成を読んで考えてみたんだが。いや多分出来るんだろうけど、それってどれぐらいの手間がかかるんだろうね?
例えば (3 8 7 1 0) => (0 1 3 7 8) というルールが与えられたらそれは十中八九ソートなのだろうけど、それがわかった所で実は何一つとして問題は解決していないのだよね。ソートと一口に言っても当然その種類は膨大で、問題領域にあわせたアルゴリズムを選択する必要が当然の事だがある (余談。 Java の標準ライブラリでは要素数が極度に少ないときはインサートソートに切替えるクイックソートが使われている) 。で、実の所アルゴリズムはネタが割れてしまえば実装なんざそこらに転がっていてものによってはライブラリ化されていて、あとはそのアルゴリズム同士をどう組み合わせるかって問題になるわけだ。それってどこまで機械が面倒見てくれるの?
暴言承知で書かせてもらうと、この手の研究にはプログラミング言語としての UML と同じ匂いがする。俺のいた大学で UML からプログラム生成ということをやってる人が居たが (俺はその人の講義が大嫌いだった) 、それって結局外っ面のインターフェースだけ書いて実装がないじゃんとか、どういうインターフェースになるのかなんて組み始めて初めてわかることが多いんだけどとか、まあそういう文句を瞬時に思い付いてしまったんだよな (俺は UML はスケッチあるいは既に出来たプログラムの補足資料としては認めているが、コードを書く前に UML を書くというのは殆ど狂気の世界に思える。第一オブジェクト指向でしか役に立たん概念を覚える気には全くなれない) 。
そもそも実際のソフトウェアってのは呆れ返る程に手続きだらけの場合が多いわけで (今の仕事もそうだし、俺が趣味で作ってるものもそう) 、それってどこまで形式化できるのかなあ。例えば Web サーバのアクセスログから「ユニークアクセス」と「リンク元一覧」を抜き出すって処理を考えた場合、それは多分
整形プログラム ログファイル = 整形済みデータ
整形済みデータ = ユニークアクセス + リンク元一覧
ユニークアクセス = 空白区切りデータの第 1 フィールドの重複なしリストの総数
リンク元一覧 = 空白区切りデータの第 11 フィールドの重複なしリストという仕様の階層になると思うのだが (専門外なので的外れな事を書いているのかも。まあいいや) 、こんな事書いてる暇があったらシェルスクリプトを一発書き下して終わりにしてしまう。でもこれ、何か仕様とコードで抽象化の度合がさして変わってない気がするんだよなあ。
ちなみに俺は論理型にしろ何にしろ、結局の所ソフトウェアをどの視点から見ているのかっていうことの違いに過ぎず、実はさして抽象化の度合は (平均値を取れば) 変わってないんじゃないかと睨んでる。つまりはどれもケースバイケースで使うものであって、銀の弾丸のようなパラダイムはきっと存在しない。詰まらない結論かもしれないが、一つの視点で全てを賄おうとするのはユートピアではなくてディストピアなので仕方がない (もしもそのパラダイムで太刀打ちできない問題が表れたときにどうしようもないから) 。
定期が切れたから申し込みにいかなきゃと思っていたら、なんだよこの雨は。やってられねえ。
何で俺ってよくわかんねー輸入もののトルティア用サルサとか買っちゃうのかなあ。まあおいしいから別に良いんだけど。
洗い物をするのを忘れていたが、まあ明日の朝やれば良いや。寝る。