バナナとプログラミング（メカAG）

今回はメカAGさんのブログからご寄稿いただきました。

バナナとプログラミング（メカAG）

プログラムが自然言語よりも理解しにくい理由の一つに、自然言語は概要→詳細という形式を持っているのに対して、プログラムはあくまで処理手順の列挙に終始している点ではなかろうか。

たとえばバナナはオヤツに入るか？という問題。「遠足のしおり」みたいなのがあって、オヤツについてもあれこれ書かれている。いつ食べるかとか量とか。その後でオヤツに含まれるもの、含まれないものなどの注意事項が並ぶ。

プログラミングの場合どうか？まずバナナがオヤツか否かのif文が冒頭にあり、オヤツでなければエラー処理や例外処理が記述される。その後にオヤツの食べる処理とかが続くわけだ。

でも人間にとって分かりやすいのは、最初にざっくりとした概要。細かな判定や例外処理やエラー処理は枝葉末節であり、とりあえず全体を理解した後でいい。

　　　*　　　*　　　*

アスペクト指向プログラミングが、これに近いのかもしれない。手順ではなく条件を記述する。たとえばこの変数にゼロが代入されたら、この処理が実行される、と。「いつ」ではなく、条件を記述。つまり原理的にはその変数への代入処理が実行されるたびに、この条件がチェックされる。最適化とかで省けるチェックはあるだろうけど。このケースは絶対にゼロにならない、と。

これを普通のプログラミング言語で馬鹿正直に書いたら、代入のたびにif文が並ぶすごく見にくいコードになってしまうだろう。

　　　*　　　*　　　*

人間の思考というのは、順序ではない。「ある1人の男が山道を歩いていた」「その男は年はまだ若く」「背中には荷物を背負っている」「その荷物は重そうで男の肩にキリキリと食い込んで」と。

これをシーケンシャルに記述したら「肩にキリキリと食い込むほど重そうな荷物を背中に背負っている1人の若い男が山道を歩いていた」となる。なんか読みにくいし、なかなか重要な部分がでてこない。こういう文章をずっと読んでると「で、結局本題はなんなの?」となる(笑)。

　　　*　　　*　　　*

とはいえ、最初に全体的な概要を説明し、次に細部を語る形式だと、重複部分が多くなり冗長でもある。上記なら「男」が何回も出てくる。バナナの話にしても、もっと複雑になれば、どんどん煩雑になっていく。

「○○は～である。ただし××の場合は～で、さらに△△の場合は～」と、だんだん条件を指し示す範囲がわかりにくくなってくる。誤解の余地を少なくするには、ますます表現が冗長になる。

よく説明書とかで、この注意事項はこっちのケースにも当てはまるのか?と悩んだりする。当てはまるか否かを推測しなければならないし、その結果が一意に確定できないかもしれない。

人間は普通はそれらを「常識」で処理しているわけだ。しかし不慣れな問題領域では、常識のストックが足りないので、判断がつきかねるケースが出てくる。

　　　*　　　*　　　*

以前、よく出来た小説は、ストーリーがフラクタル構造になっているのではないかと述べた。自己相似。物語の最初の方で語られたテーマが、スケールを変え、細部も若干変わって繰り返し語られる。主人公が自分の近所の乱暴者を懲らしめる話からスタートして、だんだん敵が国や世界や宇宙規模にスケールアップしていくような(笑)。

なぜ退屈しないかといえば、基本は同じだが細部はその都度変わるから。単純な善悪ではなく、悪人の意外な心優しい側面が語られたり、弱者を助けて良いことをしたと思っていたら、そいつがとんでもない食わせ物だったり(笑)。

この場合、数多くの重複部分を持っているにもかかわらず、煩雑さはあまり感じない。もし最初から「正義とは？」を冗長性なく語るとしたら、たぶんその説明は耐え難いほど複雑なものになるだろう。

弱者のフリをした悪者、一見悪者に見える心優しい人間、それを見分ける細かな注意事項が続いた後、ようやく近所の乱暴者をやっつける最初のエピソードが始まる。こんな小説誰も読まないだろう(笑)。

でもプログラムってこんな感じだよね。

　　　*　　　*　　　*

プログラマはあくまで概要→詳細の順序で記述し、それをコンパイラとかが推論や最適化を駆使して、適切な処理手順に変換する…そういうプログラミング手法が求められるようになってきたのではなかろうか。

コンパイラは「文法エラーです」ではなく、「このケースとこのケースは論理矛盾を起こしていて、処理を一意に決定できません」というエラーを出す。

まあ、バグを見つけるのも大変そうだけど(苦笑)。

執筆： この記事はメカAGさんのブログからご寄稿いただきました。

寄稿いただいた記事は2014年09月24日時点のものです。