ルール検索とプログラムの半自動合成
(via 青木日記/T (2006-05-19))
世間的にはどうなのかよく知りませんが，ここらへんはけっこう ET パラダイムでは普通に研究されているところだと思います．
まぁ，テストってのは不完全な仕様記述に過ぎないので，理論的に完全なものは原理的に不可能なのかもしれませんが，泥くさいぶん，より現実的ですよね．
例えば，特定の引数の組み合せを満たすルールをデータベースから取って来て，半自動的にプログラムを合成する研究なんかが考えられます (私は関わってないのでよく知りませんが)．
具体例としては，
なーんか数リストを突っこむと， (1 2 3)
それが 2 倍になってかえってくる (2 4 6)
ようなルール *rulename
って，ライブラリ DB 内に無い ? と．
つまり，制約条件 (*rulename (1 2 3) (2 4 6)) あるいは，(*rulename (2 4 6) (1 2 3)) を満たす (引数の順番は任意) ルール名を組み合せ探索すると言う，単純なメタ計算 (論理プログラミング風に言えば，2 階アトムの探索問題) に，問題は還元されます．
もう１つ例．(a b c) と (1 2 3) と (a b c 1 2 3) という関係を満たすルール名は ? → (append (a b c) (1 2 3) (a b c 1 2 3)) みたいな感じ (本当に，単にテストケースのみから探索．プログラムの宣言的意味などは考慮してない．でも，けっこう実用的に見えませんか ?)．
# ここらへんは，アトムの置き換えで全ての計算が進んで行く，極めて宣言的な言語ならではですよね．手続き型や関数型では，こうはいかないと思います．もともと，プログラム合成や部分計算などの技法は，論理プログラミングの土壌で育まれたというのも納得です．だって，本当に見たままなんですもん．意味論が．
まー，もちろんここで示したのはものすごくナイーブな方法で，停止性とか効率とかいろいろな問題はありますが．原理的には，そんなに不可能なことではないと思います．
今のプログラミングの現状が，人間が一々膨大な API ドキュメントを当たり，それっぽい機能がまとめれたモジュールの中から，それっぽい関数なりメソッドなりを引っ張って来て，ドキュメント読んだり，自然言語であいまいに書かれていて謎なところは，一々ちゃんと思い通りに動くか確かめたりと，ものすごく原始的なレベルですからね．
ここらへんの探索が，ちょっとインテリジェントになるだけでも，かなりインパクトは強いような気がします (理論的にちゃんとやるのは難しくても，とりあえず，現実的なケースではそれなりに動くようなものは実用化できそう，という意味)．
パッケージを絞りこんだりすれば，けっこう実用的なのでは．DB にルールがどんどんたまっていくにしたがって，いろいろと面白いことができそうな気がします．google みたいに，例えアルゴリズムは単純でも，スケールの力ってのはもの凄いですからね．
ここらへんは，うまく軌道に乗れば，一気に世界を変える可能性に満ちた，夢のある研究領域だと思います (もちろん，簡単なことでは無いですが)．
■ 一人でまったく新しいプログラミング言語を考えるスレ
ウィトゲンシュタインの『哲学的探求』読んでるときに考えついたんだけどね、テストを書いとくとそれを満たすプログラムを生成してくれる言語ってどうよ。つまり、テストを書くためだけのプログラミング言語。そんなのできたら全世界の SE とコンサルが泣いて喜ぶね！
……そんなの実装できるわけねー。ていうか全世界の SE の皆皆様がやってることはこの言語の処理系に近いような気がする。
世間的にはどうなのかよく知りませんが，ここらへんはけっこう ET パラダイムでは普通に研究されているところだと思います．
まぁ，テストってのは不完全な仕様記述に過ぎないので，理論的に完全なものは原理的に不可能なのかもしれませんが，泥くさいぶん，より現実的ですよね．
例えば，特定の引数の組み合せを満たすルールをデータベースから取って来て，半自動的にプログラムを合成する研究なんかが考えられます (私は関わってないのでよく知りませんが)．
具体例としては，
なーんか数リストを突っこむと， (1 2 3)
それが 2 倍になってかえってくる (2 4 6)
ようなルール *rulename
って，ライブラリ DB 内に無い ? と．
つまり，制約条件 (*rulename (1 2 3) (2 4 6)) あるいは，(*rulename (2 4 6) (1 2 3)) を満たす (引数の順番は任意) ルール名を組み合せ探索すると言う，単純なメタ計算 (論理プログラミング風に言えば，2 階アトムの探索問題) に，問題は還元されます．
もう１つ例．(a b c) と (1 2 3) と (a b c 1 2 3) という関係を満たすルール名は ? → (append (a b c) (1 2 3) (a b c 1 2 3)) みたいな感じ (本当に，単にテストケースのみから探索．プログラムの宣言的意味などは考慮してない．でも，けっこう実用的に見えませんか ?)．
# ここらへんは，アトムの置き換えで全ての計算が進んで行く，極めて宣言的な言語ならではですよね．手続き型や関数型では，こうはいかないと思います．もともと，プログラム合成や部分計算などの技法は，論理プログラミングの土壌で育まれたというのも納得です．だって，本当に見たままなんですもん．意味論が．
まー，もちろんここで示したのはものすごくナイーブな方法で，停止性とか効率とかいろいろな問題はありますが．原理的には，そんなに不可能なことではないと思います．
今のプログラミングの現状が，人間が一々膨大な API ドキュメントを当たり，それっぽい機能がまとめれたモジュールの中から，それっぽい関数なりメソッドなりを引っ張って来て，ドキュメント読んだり，自然言語であいまいに書かれていて謎なところは，一々ちゃんと思い通りに動くか確かめたりと，ものすごく原始的なレベルですからね．
ここらへんの探索が，ちょっとインテリジェントになるだけでも，かなりインパクトは強いような気がします (理論的にちゃんとやるのは難しくても，とりあえず，現実的なケースではそれなりに動くようなものは実用化できそう，という意味)．
パッケージを絞りこんだりすれば，けっこう実用的なのでは．DB にルールがどんどんたまっていくにしたがって，いろいろと面白いことができそうな気がします．google みたいに，例えアルゴリズムは単純でも，スケールの力ってのはもの凄いですからね．
ここらへんは，うまく軌道に乗れば，一気に世界を変える可能性に満ちた，夢のある研究領域だと思います (もちろん，簡単なことでは無いですが)．
