読書会メモ第4回及び第5回

【第４回】第1章第3節(p31〜p37)
【第５回】第1章第3節(p37〜p40)

●メモ

クロージャとデザインパターン

第一章の山場である「高階手続き」に入る。まず関数を引数や返り値として扱う方法(クロージャ)を知り、それによりどのようにプログラムの抽象化を図れるのかを学んでゆく。javaの世界にしかいなかった自分にとって、この「関数とそれに付帯する環境(スコープ)」を束ねて扱うという概念は新鮮だ。これにより、動詞の多態性を表現することが可能になる。
このアイデアをオブジェクト指向言語に持ち込んだのがデザインパターンだったのだろう。データ(オブジェクト)から離れて関数を扱うことができないオブジェクト指向言語では、動的に処理の多態性を表現することは難しい。関数(動詞)を名詞化し組み合わせることで、それを実現しようとするのが（特にComposition系の）デザインパターンなのだろう。
自分などはクラス化できるならそれでいいじゃんと思ってしまうのだが、クロージャに慣れてくると、それを持たない言語がう鬱陶しくて仕方がなくなるという話はよく聞く。そう感じられる程度にはLispを使いこなせるようになりたい。

いずれにせよ、処理の本質を抽出して、抽象化することができるのだという話。

抽象化と漏れの法則

流れで少し話が飛ぶが、「プログラミングとは抽象化である」ということの意味が最近ようやく少し肌身で感じられるようになってきた。『Joel on Software』の中に、「漏れのある抽象化の法則｣という非常に印象的な記事があったことを思い出し、もう一回読んでみた。

TCPは、下層にある信頼性のないネットワークに対する完全な抽象化を提供しようとしているが、しかし、ときどきネットワークは抽象化から漏れ出て、あなたは、抽象化があなたを守ってくれない何物かの存在を感じ取る。そうしてこれは、私が「漏れのある抽象化の法則」と名付けた法則の一例になっている。

自明ではない抽象化はすべて、程度の差こそあれ、漏れがある。

（中略）

10年前、私たちは、将来は新しいプログラミングパラダイムによってプログラミングが簡単になっているだろうと想像していた。確かに、何年にもわたって私たちが築き上げてきた抽象化は、GUIプログラミングやネットワークプログラミングのような、10年、15年前には扱う必要がなかった、ソフトウェア開発の新しいレベルの複雑さを取り扱うことを可能にしてくれた。そして、現代的なオブジェクト指向のフォームベースの言語のような素晴しいツールは、たくさんの仕事を驚くほど早く成し遂げられるようにしてくれる。しかし、ある日突然、抽象化が漏れているところで問題を解明する必要が生じ、それには2週間もかかるのだ。そして、あなたがプログラマを雇うとき、仕事のほとんどがVBプログラミングであっても、VB プログラマを雇ったのでは十分ではない。VBの抽象化が漏れているところに出会うたび、彼らはタールにはまりこんで動けなくなってしまうからだ。

(『Joel on Software』p.219〜p.223)

プログラミングツールや言語の抽象化が進み便利になると同時に、その漏れも積み重なっていく。抽象化は完全にはなされない前提に立てば、プログラマが知識としてカバーすべき領域は大きくなっていく。
この記事はプログラマに必要とされる知識領域という文脈で書かれているが、「抽象化と漏れの法則」は当然もっと一般化することができる（そもそも人類の文明が発達し、分業が進み、産業が起こり、現代に至る過程そのものが、抽象化の過程といってもいい）。

ええと、何がいいたいのか。

・Joelは大きくなっていく漏れの山を嘆いているが、結局抽象化の度合いとは相対的な判断に基づくものなのであって、いつの時代にも、どの分野においても、その類いの嘆きはなくならないのだろう。

・自分の仕事について、機能の仕様策定から実装への落とし込みまでの全過程において、力の及ぶ限り(ここが逃げ)美しくかつ実効的な抽象化を目指したい。あと、様々な現実を前にしたときに、如何に漏らすかというのも面白いポイントだと思う。

クロージャから人生へ

結局、「人生色々あるけど自分がやるべきことをやる他に選択肢はない」というところにこのエントリーは着地しました。おそまつ。