副作用礼賛

こんにちは、nil.htmlでひどい目にあった@tomoodaです。 今日は副作用についてまたまたオレオレ説を妄想してみます。

プログラミングの世界で副作用というと、多くの人は「破壊代入」「ファイルＩＯ」「画面描画」「UIイベント」みたいなものを想像するでしょう。 そういえば破壊代入については以前もワケワカラン事を垂れ流した記憶があります。ツ

どうしてこれらを副作用と呼ぶのでしょうか？主作用というか効能みたいなのは何なんでしょうか？ それは、「計算」ですね。 「計算」ですから、何らかの答えを得るために計算するわけですが、その答えを得ることが計算機の動作の主作用であり効能だ、という考えかたです。 この考え方は計算機科学あるいはソフトウェア工学の中で広く深く浸透しています。 でもねえ、それ、ホントかね？と思うのですよ。

計算機は文字通り計算する機械なわけですが、今ではちょっと名前的にミスマッチだと思います。 例えば自動販売機もコンピュータで制御されています。 もちろん、投入金額の計算とか、オツリの計算はちゃんとやってもらいたいですが、自動販売機の「主作用」は計算じゃないですよね。 オレにとって自動販売機の主作用は、オレにドクターペッパーを供給する、ということですよ。 できればダイエットドクターペッパーのほうがいいですが、普通のドクターペッパーでも勘弁してあげます。 ドクターペッパーをオレに供給した上でのカネ勘定だと思うわけです。

もうちょっと一般的に言えば、メディアないしはサービス装置としての計算機の主作用は、人に何かを見せたり、人から何か入力を受けつけたり、モノを動かしたり、そういう計算機科学がこれまで「副作用」と呼んできたものじゃないでしょうか。 人とのインタラクション、他の装置とのインタラクション、それこそが今の計算機にとっての主作用だとオレは思うのです。 足し算したり、掛け算したり、ループしたり、条件分岐したり、そういうのはインタラクションを実現するための手段であり、何ならやらなくて済むならやらないほうがいいのです。 だって、少ない足し算で同じインタラクションを実現できるのなら、少ない足し算のほうがいいに決まってますよ。

そう、オレから見れば、いわゆる計算機科学で扱う「計算」というものこそ、副作用なんです。

もちろん、計算なしには実現できないインタラクションこそが計算機の活躍する場だから、計算を全て排除とか言うつもりはありません。 計算は必要です。でも、少なければ少ないほどいい。 誤解を恐れずに言えば、今の計算機の使われ方では多くの場合、計算は必要悪なんじゃないかとすら思います。

そういうわけで、インタラクションの実現としてのプログラミングでは、計算を最小限に押さえてプログラムは「副作用」を表現する言語というのもあっていいと思います。 もちろん、「副作用」が絡まり合うととっても悲しいコードになってしまいます。 だから「副作用」をより合理的に効果的に記述することが必要なんだと思います。

副作用という点では、オブジェクト指向というのは利用者の認識と副作用を一致させるためのパラダイムだ、とも言えるような気がします。 以前、オブジェクト指向というのは、計算機の利用者が認識した対象に対してメッセージングすることだということを書きました。 「このメガネ」に対して「レンズはビビッドピンクがいいな」とメッセージを投げた時、眉毛がピンクになるのではなく、ちゃんとレンズがビビッドピンクになってほしいのです。 そして、ツルまでいっしょにピンクになったら、ツルもピンクになることが事前にわかったり、仕方ない時は事後でもいいからちゃんと利用者が認識できるようになったほしいのです。 つまりは、オブジェクト指向では、利用者が認識している対象を知ることも大事だし、何がどうなったのか対象を利用者に認識させることも大事なんじゃないかなー、と思うわけです。

だからといってオレの著者近影写真をフォトショで遊ばないでくださいね。ツ