2008/08/27
『ミスト』のラスト
こちらと こちらで 批判されてる映画評論家がいて、 好奇心でその人の映画評 をいくつか読んでみた。私もまるきり勘違いすることがよくあるので人の批判はできない んだが、『ミスト』評 (リンク先ネタバレ注意)でラストを「救済」としているのが気になった。 というのは、『蝿の王』を知らないとあのラストは救済に見えるかも、と思うからだ。 (あと、あのラストを「衝撃狙いの悪趣味な演出」みたいに言っている評も見たけど、 それもバックグラウンドを知らないせいだと思う)。 もちろん観客それぞれの背景によって解釈は色々あっていいんだけれど、 あれを救済で済ませてしまうのはあまりに勿体ないと思うので書いておこう。 できるだけ見た人にしかわからないように書くつもりだけど、 どうしたってラストに触れるので『ミスト』未見の人は注意。
『蝿の王』はもう古典なのでストーリー出しちゃっていいかな。 出しちゃうよ。ネタバレ嫌な人はここでストップ。 少年達を載せた飛行機が無人島に不時着し、大人がいない状況で 少年達のコミュニティが理性と秩序から次第に本能と混沌へと変貌してゆく様子を描く。 で、まあ最後には大人がやってきて少年達は助かる。
助かるのだけれど、助けにやって来たのは軍隊だ。 『蝿の王』小説中でわずかに触れられるが、外の世界では戦争をしている。 このラストの意味についてはGolding自身の言葉が的確だろう。 Stephen Kingは『Hearts in Atlantis』の中で『蝿の王』を出したときに この言葉を紹介している。
The boys are rescued by the crew of a battle-cruiser, and that is very well for them, but who will rescue the crew?
『蝿の王』の見事さは、「特殊な環境下での集団の変貌」を圧倒的な説得力を もって描いたのちに、「ローカルに見れば救出」「けれどグローバルに見れば、 救出者達もまた、同じ状態の集団の中にいる (そして読者もそうかもしれない)」 という一種のどんでん返しを、ひとつの瞬間でやってみせるところだ。
で、『ミスト』である。
父親の叫びに応えて霧の向こうから現れたのがアレだったことの意味は何か。
子供が怖れた "Monster" とは何だったのか。
果たして人々は救済されたのか。
果たして我々は救済されるのか。
2008/08/25
デバッガ
アプリケーションの開発時にはデバッガーを使うのはあたりまえだろう。 そのデバッガーを使えなくて何がプログラマだ、くらいの事は思うのだけど、 世のプログラミング言語の入門書にデバッグの仕方もましてやデバッガーの使い方も載っていない。
この手の言い草はよく聞くけれど、私はデバッガはほとんど使わない。使ってもせいぜい、どうしても他に資料のないコアダンプを解析しなきゃいけない時だけで、普段はまるっきり使わない。そこにソースがあるなら、怪しい箇所を推理しつつprintfをつっこむ。なぜなら、私はプログラムを書く時に一番大切なものは、そういったツールを使う能力ではなくて、
思考力
であると思うからだ。それと共に、本当にクリティカルなバグには、デバッガは無力だからでもある。
ハンドアセンブルが長かったので、CP/Mが動くようになってDDTという デバッガを最初に使った時は感動したものだ。ハンドアセンブルではprintfデバッグ は簡単ではない。コードを挿入するとアドレスがずれてジャンプオフセットの計算を やりなおさないとならない。インストラクションの頭をRST命令で潰すのが定石だが 戻し忘れると面倒なことになる。それを自動でやってくれて、対話的にレジスタの 内容が見られて、ステップ実行まで出来るというのは衝撃だった。 そのあとコアダンプを見るのにadbを覚えて、gdbを使うようになったのはだいぶ 後だなあ。一時期はgdb+Emacsで何でもやってた。
でも今ではデバッガは滅多に使わなくなった。使うときもソースレベルで ブレークポイント設定しまくってさらにステップ実行…というのはほとんどやらない。 インタラクティブな逆アセンブラ/メモリダンパとしての使い方が多いかなあ。 GC絡みの怪しい挙動の解析とか、最適化のかかったコードの振る舞いを追ったりとか、要するに ビットに直接触る必要がある場合限定。 通常のデバッグはprintfスタブを使い、もう少し込み入った問題であれば その問題限定の検証ツールを組み込んだりしている。
ソフトウェアって多くの層の積み重ねで、 gdbみたいなスタイルのデバッガがぴたっとサポートできるのは そのうちの特定の層だけなんだよね。 仕事の主要部分がその層に集中していればデバッガは強力な武器になるけれど、 そうでないとあまり役に立たない。で、昔はよく使ってたのに何で使わなくなったのか なあ、と考えてみたのだけれど、 ソースレベルデバッガは出発点としているモデル：「メモリ、レジスタ、 CPUの状態変化とソースとを関連付けて追っかける」っていうのが崩れてきているって 背景があるんじゃないかなあと。
- ランタイムの多層化。例えばVM上で走るコードのロジックのバグの場合、 gdbで実行を追ってもVMの同じところをぐるぐる回ってるだけでほとんど何も分からない。 watchpointや条件付きbreakpointも、粒度がソースレベルのロジックと 大きく異なっていて使いにくい。
- コンパイルタイムの多層化。 メモリ読み書きのリオーダリングで、ソースの字面どおりに状態が遷移することは もはや当てに出来なくなっている。高水準言語における「関数」や「データ構造」は 抽象的な存在で、そのまま一連のインストラクション列やメモリの連続した領域へと マップされることはどんどん減っている。
- 単一の状態遷移モデルの限界。 並列に走ってるスレッドがあれば、ソースの字面で見えている状態遷移とは 関係ないところで状態が変わっちゃう。
- あと、コードを実行する主体がもはやCPUとは限らない(GPU等)、とかね。
ソフトウェアの一番下が状態機械である以上、その層を覗くツールとしての 現在のスタイルのデバッガの有用性は今後も残るだろうけど、 より一般的なツールとしての「デバッガ」に求められる異なるモデルっていうのが 必要になってるんじゃなかろうか。状態遷移よりは静的・動的な検証というものが 主役になるような気がする。言語の方にもそれに結びついた仕様が入って行くだろうし。 というか大きな企業はこのくらい既に考えてるだろうから最近流行りの「えんたーぷらいず」 言語の開発環境にはそういう支援が入ってたりしないんだろうか。
Visual Studioで作業してる若い人なんかを見ていると、実行環境からすぐにデバッガに 入ってがしがし編集してすぐ再実行して…ってサイクルを回してて、それはそれで 悪くないんだけれど、何て言うのかな、 「手元のデバッガが面倒を見られる層に無意識的に作業リソースを集中させてしまう」 というおそれがあるようにも思う。無意識に「デバッガで見られる状態機械の レイヤを越えた抽象化を避ける」というか。杞憂ならいいんだけど。
(追記2008/08/27 01:56:39 PDT: ちなみに、もちろんロートルLisperは 「実行環境からすぐにデバッガに入ってがしがし編集してすぐ再実行」なんだけどさ。 20年前から。でももっと良いやり方があるんじゃないかなあ、と思うのだ。)
Tag: Programming
2008/08/20
らむ太とteapot
らむ太はなぜかUtah teapotがお気に入りで、画面にteapotが写ると大騒ぎする。 あんまり騒ぐのでかみさんがセコンドハンドショップで普通のティーポットを買って与えたら 喜んで遊んでいる。
CGアニメーションの特集番組でテクスチャマッピングか何かの説明で teapotが映り、ぐるっと一回りするシーンを見たらむ太は、 自分のティーポットを床に置くとそれを見ながら周囲を一周して 「おんなじ、おんなじ」と騒いでいた。 確かに、world coordinateでtransformするのと カメラ位置を(逆行列で)transformするので得られる映像は同じである。
らむ太語録
- あわゆ (洗う)
- たわいま (ただいま)
Tag: 生活
2008/08/12
rfc4180の曖昧性
CSV形式はRFC:4180でフォーマルに定められているのだが…
- recordはCRLFで終わる、ただし最後のレコードの後ろのCRLFは省略可
- recordはひとつ以上のfieldをCOMMAで区切ったもの
これって、ファイル末尾がCRLFで終わっている場合、
- それがrecord終端のCRLFなのか、
- その後ろにひとつの空のfieldを持つrecordがあって、その後ろのCRLFが省略されているのか、
わからないよなあ。
一応「各レコードのフィールド数は同じでなければならない」って規定があるから それまでに2つ以上のフィールドが出てきてれば(2)の可能性は排除できるけど。
まあ慣例的にはCRLFの後ろにEOFが来てればCRLFが終端だとするだろうけれど、 それを形式的に(EBNFとかPEGで)かつ簡潔に記述するのって結構面倒なような。
と、PEGのテスト用のCSVパーザをいじってて思った。
Tag: Programming
2008/07/31
病院の一日
一昨日昼前くらいに、らむ太の目の中にごみが入っているのをかみさんが見つけた。 白目の部分に0.5mmくらいの黒いものがくっついている。 eye washを買ってきて流そうとしてみたのだが、全く移動する気配がない。 そのうちeye washを嫌がってらむ太も散々泣いたんだが、それでも動かない。 見た感じ、真っ黒で表面はなめらか、周囲もスムースな円形の何かだ。 放っておくとそんなに気にするふうでもないのだけれど、 感染などすると心配なので午後からかかりつけのpediatricianに連れて行った。 ところがドクターもそれが何だかわからない。 (視線をじっと固定できずにきょろきょろするもんだからじっくり見られないってのもある。) 結局Kapiolani Hospitalの眼科を紹介してもらう。
で、昨日午前にまず眼科。瞳孔を開く薬を入れてまず眼の中を検査し、 何かが深く刺さっているのではないことを確認。Kapiolani Hospitalは産科と小児科が メインなので、さすがに子供の扱いには慣れている。 それでも、いざスワブで取り除こうとするとらむ太は散々暴れた。 目薬で表面麻酔を入れてるんだけど、やっぱり怖いらしい。 押さえつけてどうにかスワブで拭ってもらうが全然取れない。
結局、全身麻酔をかけて取り除くことになった。
全身麻酔となると色々おおごとになる。 かみさんはこのへんの知識があって、 麻酔前に食事が出来ないことを見越して朝食を抜いていたのが奏功。 午後には処置を受けられることになる。 食事のことを思い出させないようにひたすららむ太の気を惹いているうち、 本人も疲れたのだろう (緊張してハイテンションになっていたのもあるだろうが) 麻酔をかける直前に眠ってしまった。 それでも、静脈注入だったので針が入る時には起きて少し暴れたが 程なく大人しくなり、眼医者がピンセットで取り除いた。 回復室で眼を覚ますまで待って、結局丸一日潰れたが 無事に済んで何よりだ。
結局モノは何だったのかというと、虫であった。 顕微鏡を実家に置いてきてしまったので詳しくは見られないが、 何かの甲虫類っぽい。そいつがしがみついていた模様。
Tag: 生活
