2006/01/28
- Matzにっき:「オブジェクト指向神話」神話, 「オブジェクト指向」改め「抽象データ指向」
- 404 Blog Not Found:オブジェクト指向は構造化の「次」か?
プログラミングパラダイム及び言語の進化ってのは、 複雑すぎでそのままでは人間の頭に入りきらない問題をいかにして 頭に入りきる大きさに収めるかという試みに他ならない。構造化も抽象化も カプセル化も、そのための道具だ。
オブジェクト指向の出自は現実の世界のモデル化にあったはずだが、 ある時、それが「簡易抽象データ型＋簡易名前空間＋簡易クロージャ」として 使えることに誰かが気づいた (誰が最初に気づいたかは知らないけれど 広めたのはStroustrupだろう)。これらの概念はそれぞれが、 モジュラリティの高いプログラミングに使える道具であり、 問題の複雑さを整理するのに役立った。で、後者の方が広まってしまった。
オブジェクト指向がわかりにくいとされる理由の一端は、 このような経緯にあるのだろう。 小飼さんが「『オブジェクト指向』は『構造化』の進化系ではなく、 元来直交して扱える概念」という時、それは出自に遡ってとらえている。 一方、プログラミングパラダイムの方から見ると、構造化の後でたまたま 「使える」概念として出てきたのがオブジェクト指向だったわけで、 Matzさんの「実際には、オブジェクト指向プログラミングは、 構造化プログラミングの『次』と 認識されるべきものだと思う」というのは そっちの立場なんだと思う。
後者が広まったのはC++のせいもあるが、旧来のプログラミングに 慣れていた人々が現実のモデル化というのを具体的にイメージするには、 Smalltalkのような環境が無いと難しかった、ということもあるのではなかろうか。 私自身は、アセンブラでちょっと面倒なプログラムを書いてて スパゲティになってしまった時に、伝え聞いていた「データと手続きを 一緒にして、オブジェクト間のメッセージパッシングでプログラムを記述する」 という手法を試してみたらびっくりするほどすっきり書けて、 ああこれが巷でいうオブジェクト指向というやつなのかと納得した 覚えがある。つまり方法論から入ったわけだ。C++どころかCもろくすっぽ 知らなかった頃だ。もしCを使い込んでいてC++に触れて、 構造体の延長として抽象型もどき、名前空間もどき、クロージャもどきを 手に入れればこりゃ便利だと思っただろう。
上で「簡易」とか「もどき」とか言っているのは、初期のC++が提示した それらは結局本来の概念の代用、もしくは一次近似に過ぎなかったからだ。 それ自体は悪いことではない。 それも一種のモデル化(それも、結構使えるモデル化)だから。 ただ、言語の限界を押し広げるように使ってゆくといつか近似はほつれてきて、 不満が出てくる傾向はある。テンプレートを導入したり名前空間を別に入れたり、 あるいは無名クラスやデリゲートやらと言っているのは、 ほつれを何とかしようとして近似の度合を二次、三次と上げているようなものである。
Tag: Programming
2006/01/26
CVS管理してるもの以外のデータは以前は適宜CD-ROMに焼いてバックアップと していたのだが、1枚に入りきらなくなって面倒になってきた。 こういう大事な仕事が面倒だとプロクラするようになって後で悲劇が起きる ことになっている。 付ける場所が無くて転がってたEIDEのディスクがあったのでHDDエンクロージャを 買ってきてバックアップディスクにすることにした。 USB2のだともう安いねえ。デザインで選ぶようなものになってるんだなあ。
バックアップそのものはrsync --link-destで。Gauche:gdumpfs?もあるけど、 まあ出来合いのコマンドがあるならそっちがいいかと思って。 でもいちいちコマンドラインをタイプするのも面倒なので 結局wrapperを書いてしまった。
Tag: Programming
2006/01/23
センター試験のリスニングのトラブルのニュースを読んでいて思ったんだが、 新しい機械を50万台近く配って、一回限りの試験をやらせようっていう発想が 何というか、日本人的だなあと思う。「ちゃんと動いて当然」という頭 があって、付けたしのようにトラブルへの対応手順を考えたんじゃなかろうか。 こっちじゃそういう発想は出てこない。うまくいきっこないから。
人間が相手の場合、失敗に大きなペナルティを課すことで「ちゃんとやる」 圧力をかなりの程度まで増やすことができ、実際に日本社会の多くの部分が そのようにして動いているのだが、機械の故障率ってのは人間ほど柔軟じゃない。 メーカーにプレッシャーをかけて多少調整することは出来たとしても、 結局はコストとのトレードオフになる。入試センターは当初 「故障はゼロと思っていた」と言ってたそうだが、 本気で故障率を10^-6以下にしたつもりだったんだろか。
エラー処理が醜くなる時っていうのはだいたい設計をしくじっている。 トラブルが一定率で起きることを織り込んでいれば、 トラブル時の再テストや再試験などにあまり複雑な手順を設定できないはずだ。 例えば「一度しか聞けない」という制限をはずせばずいぶんすっきりすると 思うのだが。装置に頭出しをつけなくちゃならないけれど、機器トラブルは すぐに交換すれば済むし、操作ミスのリカバーも容易になる。 それによって故障率のマージンが広く取れるならコスト的には どっこいどっこいになるかもしれない。
何度も聞けていいのか、に関しては、そもそもリスニングで何を 試験したいのかってことになる。ネイティブのスピードで読まれた英語を 一発で聞き取れる受験生なんてほんのごく一部だろうから、問題はかなり ゆっくり読み上げられていたのだろうと想像する。 だが、今後受験生が英語を使ってゆく場面で、(1)相手がゆっくりと 一度だけ喋ってくれる (2)相手は普通に喋るが、聞き返したら何度でも 言い直してくれる、のどちらに遭遇することが多いだろう。
自分の経験からすると、リスニングの能力はリニアに向上するのではなく、 不連続な段階がある。その一番重要なものは、「どの単語が聞き取れな かったかが自分でわかる」という段階だ。それをクリアすると実用上 あまり不自由することがなくなる。 で、複数回聞くことによって救われるのはその段階に達している受験生 だけなので (それ以下だと何回聞いてもわからない)、複数回聞けるように することの影響ってあんまり無いんじゃなかろうか。
Tag: 生活
2006/01/17
昨年、short filmで一緒にやった役者さんが亡くなっていたことをついさっき知った。 Entertainer Ray Bumatai, 52, succumbs to brain cancer。 撮影が6月半ばだったから、撮影のほとんど直後に脳腫瘍が再発していたのだ。
一緒に仕事をしているだけで勉強になった。もっと経験を積んでから また共演できたらいいと思っていた。 チャンスというのはいつでも一回限りなのだ。舞台でも、人生でも。
2006/01/10
関数型言語でfor文が無いのは、という話がどこかでもりあがってるのを見た。 それについては「再帰が基本で、forはsyntax sugar」でいいと思うのだけれど、 もうひとつ、for文みたいなイディオムは、ファーストクラスクロージャと 組み合わさると、変な落とし穴を作ることがある。
ナイーブな実装を考える。
(define-syntax for
(syntax-rules ()
((for (var init) test update body ...)
(let ((var init))
(let loop ()
(when test
body ...
update
(loop)))))))
gosh> (for (i 0) (< i 5) (set! i (+ i 1))
(print i))
0
1
2
3
4
#<undef>
一見うまく動く。しかし、for文のbodyでクロージャが作られ、それが for文のエクステントを越えて生き延びると、困ったことが起きる。
gosh> (define p '())
p
gosh> (for (i 0) (< i 5) (set! i (+ i 1))
(push! p (lambda () i)))
#<undef>
gosh> p
(#<closure #f> #<closure #f> #<closure #f> #<closure #f> #<closure #f>)
gosh> (map (cut <>) p)
(5 5 5 5 5)
処理の本体をクロージャにして抽象化するのはSchemerなら息を吸うように やってることだが、ループ変数を破壊的に変更してしまうとそれが 等価な変換ではなくなってしまうのだ。 些細なことに思えるかもしれないが、こういうところにトラップがあると まるで息を吸うのに不自由する感じがある。
Schemeのdo構文は再帰のsyntax sugarなのでこの問題はない。forも ループ変数を破壊的変更でなく再帰関数の引数にして持ち回ればこの問題は 起きないのだが、手続き型言語のfor文は(C++の「イテレータ」イディオムを 含めて)破壊的変更を暗黙のうちに仮定しているかのようだ。
なおCommon Lispのloopマクロやdotimesマクロはループ変数を 破壊的変更しくさるのだが、これはきっと破壊的変更の悪をプログラマに 教えんとするSteeleの親心に違いない。そうに違いないのだ。 過去に学ばないプログラマは何度も何度も何度も何度もクローズした はずの変数がいつのまにか書き換わってることに悩んで何時間も デバッグに費すのだ。おかげで昨日も締切前の貴重な時間を無駄にした。くそぅ。
Tags: Programming, Lisp, Scheme
