Shiro:log:2008後半

Shiro:log:2008後半

最新: Shiro
前: Shiro:log:2008前半


(2008/12/28 15:21:33 PST 技芸とサイエンス)

もともと文芸の能力と科学の能力とは相反するものではないし、 独立したもののように錯覚してしまうこと自体が「理系文系」思考の最大の罪だと思うのだけれど:

ITエンジニアにコンピュータ・サイエンスは必須か - Zopeジャンキー日記

ここで、「コンピュータ・サイエンスをきちんと学んでいないとダメだ」といった趣旨の意見があった。これこそ、「ITは「理系」なのか?」で私が主題にしたかったポイントであり、まさにこのような考えかたに対して、私はちょっと違う気がする、ということが言いたかったのだ。

コンピュータ・サイエンスの知識は、もちろんあったほうがいい。しかし、ないとダメということもないと思う。

その理由は、プログラミングや設計の能力は、コンピュータ・サイエンス的な「科学の能力」というよりも、むしろ文章を書くような言語運用力、つまり「文芸の能力」に似ていると思うからだ。

[...]

コンピュータ・サイエンスは、コンピュータやプログラムを可能にする仕組みの知識であって、「プログラミングのスキル」というものは、それとは違うものだと思う。

それは理詰めでは到達できない、一種の「アート」であって、論理的な思考力以上に「美的感覚」を要求される、職人芸だと思う。

「理詰めで到達できないアートである」「論理的な思考力以上に美的感覚が要求される」 からといって「理論(コンピュータサイエンス)が無いとダメということはない」とは言えない。 上記前提から言えるのは、「理論だけではダメである」ということだ。

エリック・レイモンドの「コンピュータ・サイエンスの教育で誰かをプロのプログラマーに しようとするのは、ブラシや絵の具について学ばせてプロの画家にするのと同じくらい難しい」 という言葉は「コンピュータ・サイエンスの教育」 についてであることに注意。そしてノーヴィッグはレイモンドの言葉を 「でも、学校を楽しめないのなら、(熱意があれば)仕事をやる過程で同じような 体験を得ることはできる。いずれの場合にせよ、本による学習だけでは十分ではない。」 と言った後で引用している。「ちゃんとした教育をうけてないとダメとは言えない」と 言ってるだけであって、理論の知識そのものが不要かどうかには触れていないし、 ノーヴィッグの言葉はむしろ経験を通した理論の獲得をimplyしているのではないか。

確かにセンスは大きな役割を果たすのだけれど、センスだけで有益な仕事が出来るように なる例は非常に限られているだろう。歴史的に見ても飛び抜けたセンスを自分が持っていると 思うなら、理論は無視しても良いかもしれない。だがそうでない大多数の人にとって、 体系的な理論は自分のセンスを何万倍にも増幅してくれる強力な道具になる。

ITは「理系」なのか? - Zopeジャンキー日記

ITに求められるのは、とにかくたくさんの知識・道具の使い方を理屈抜きでアタマに叩き込んで、必要なときにそれを取り出せる、というような能力だ。イメージ的には、理系の研究者というよりも、はるかに「情報の土建業」に近い。

[...]

そして、「たくさんの知識・道具の使い方を理屈抜きでアタマに叩き込んで、必要なときにそれを取り出せる」という能力は、まさに「語学」の能力だ。語学では、文法などでは多少の論理性はあるものの、ほとんどは単語・イディオム・慣用表現を理屈抜きにアタマに叩き込む、つまり「覚える」「慣れる」というのが学習の中心だ。

「理系の研究者」に対してのイメージが間違っているような気がするけれど、 「たくさんの知識・道具の使い方を理屈抜きでアタマに叩き込んで」というのは 研究者だろうが現場の開発者だろうが必要とされる前提だ。 その後に、「それらの知識を理屈で体系化して『身につける』」という段階が来て、 その上に立った時にやっと「センス」が活きてくる。

サイエンスは知識を体系化する道具のひとつととらえることもできる。 学部4年生になって卒論を始めた頃、読まなければならない論文の量に 絶望的になったものだ。しかも読めば読むだけ、参照されてる文献をたどるから 読まなければならない論文が増えて行く。 けれども、その分野がコンピュータサイエンスの太い枝のどこに位置するのか、 そしてその分野内で枝がどのように張っているのか、が見えてきたら、 詳細にアルゴリズムまで調べるべきもの、歴史的な意味として「こんなのがあった」と 知っておけば良いもの、直接は関係しなさそうだけどもしかすると応用できるかもしれないもの、 などの見分けがつくようになり、ずいぶん楽になった。

プログラミングをアートに近いものととらえ、より良いものを作りたいと思うなら、 より良い道具を求めるのは自然なことではないか。 コンピュータサイエンスはプログラミングに関する古今東西の道具が整理されて納められた 道具箱 なのだ。道具が無い時にそれを言い訳に前に進まない、というのは間違っているが、 道具がすぐ隣にあるのに「道具よりもセンスが大事」と言って使ってみようとも しないのもまた間違っているのではないか。

理論を学ぶことによって自由な発想ができなくなってしまうのではないか、 と懸念する人もいる。「素人の方が既存の概念に縛られない発想ができる」ってやつだ。 そういうこともたまにはある。宝くじを当てるのに理論は必要ない。 何かを作ることをただ趣味でやりたいだけなら、ひたすらスロットマシンの レバーを引くように続けるのも良いだろう。退屈はしないし、時々小さな当たりがあるし、 ジャックポットの可能性だってゼロではない。 だが趣味ではなく、仕事として、あるいは人生のひとつの目標として 何かを作りたいと思うときに、その成功の可能性をスロットマシンに賭けたいかい?

道具だけ揃えて悦に入っている人も中にはいるのかもしれない。 そういう連中から「お前はこんなに立派な道具を持っていないからダメだ」と言われたら、 「道具なんか関係ねぇ」と反発したくなるのもわかる。 けれどもあなたが、自分のやっていることをアートだと位置付けるならば、 彼らの言うことなど無視して、自分が作りたいものを作るのに役に立つかどうかだけを考えて 判断すべきなのだ。問題なのは彼らではない。あなた自身でさえない。 結果として得られる作品だけが問題なのだから。

It is the tale, not he who tells it. ---Stephen King

(2008/12/27 10:10:36 PST オアフ大停電)

冬のハワイにしては暑い日だった昨日。 夕暮れに芝居の稽古に向かう途中、空が稲妻でぴかぴか。 劇場で衣装合わせの最中に何度かライトが瞬いて、やばそうだなと思っていたら 19時くらいにとうとう停電。 しばらく皆して回復を待ってたけど無理っぽいので解散。

ラジオはKHPR、KIPOは沈黙していたがKINEが生きてた。 オアフ島は西部の一地域を除いて全島停電。雷がどっかに落ちた拍子に グリッドが不安定になって連鎖的にシャットダウンしたらしい。 一部のラジオ局や主要ホテル、大きめのスーパーマーケット等はコジェネを動かしているけど 基本的に真っ暗。信号もついてないから車で家に帰るのは結構緊張した。 夜空の星が綺麗だった。

家ではらむ太が怖がったらしく、近くのホテルに避難していたかみさんとらむ太を 迎えにゆく。キャンプ用のガスランプを着けようとしたら、ランタンの袋が破れてた。 何も出来ないので早々に寝ることにするが、らむ太が怖がるので寝るまでずっと 歌を歌うはめに (昔は暗闇を怖がらなかったのだけどねえ。知恵がついてきたのか)。

結局朝6時頃に回復した。前回の大停電(2006年10月)は回復に14時間かかったから それよりは速かったけど、前回は日中だったからあんまり不自由は感じなかったのだな。 夜に停電すると寝るしかない。

(2008/12/23 03:39:22 PST 怖いもの)

sumiiさんの日記より:

長男がなぜかロボットを怖がる。ついこの間もディズニーストアに展示されていたWALL-○を見て硬直。(...) しまいにはイタズラや悪いことをしたときに「良い子にしないとWA○L-E買ってくるよ?」と言ったら「良い子にする!」と態度が一変する始末。

ロボットは大好きで前から「おおきくなったらろぼっとになる」と言っているらむ太だが、 怖がるものは別にある。 天狗の面と、 NHKでやってるバケルノ小学校の 「オキク先生」だ。夜なかなか寝ないで遊んでいる時に「オキク先生が来るよ」というと 慌てて布団に潜り込む。

だがどうやららむ太は「自分が怖いものは他人も怖がる」と思っているらしい。 「おかたづけしなさい」などと言うと 天狗のまねをして「てんぐしゃーん」とか おばけのふりをして「おきくせんせー」とか言って親を脅しにかかる。自分も泣きながら。 肉を切らせて骨を断つ戦略か。親には通用せんがな。ふははは。(だが「しめきり」は怖い)

(2008/12/20 05:28:20 PST 理論と現場)

ハワイ大学で受けた「Acting for the Camera」のクラスは、 自分にとってはじめての「フォーマルな演技理論」の経験だった。 これまでもいくつかのアクティングクラスで、 リラクセーションや感覚記憶、感情記憶などについては触れられていたし、 objective、motivationなどの概念をシーンワーク時につまみ食い的に紹介されたことはあった。 一方で演技論に関する本をいくつか読んで頭ではなんとなく 理論めいたものを知ってはいた。しかし、具体的に スクリプトから出発して撮影可能なレベルのシーンを作るまでの過程を 通じてどのように理論が使われるか、そしてそれらの理論が相互に どのように関連しているか、を示してくれたのはこのクラスが初めてだった。

演技というのは個人のセンスだとかアーティスティックなひらめきで 成り立っていて理論とはそぐわないように思われている節がある。 演技の理論などというとまるで「この手順に従えば演技が出来ます」という 公式みたいで嘘くさい。そういうのを学んでも紋切り型の演技しか 出来ないんじゃないかという気さえするかもしれない。

実際に学んでみて思ったのは、演技の理論と実践の関係は 計算機科学の理論と現場のプログラミングとの関係に似ているということだ。

プログラミング言語の文法とライブラリの知識を一通り身につけて、 現場で出会うパターンについて経験を積んで行けば、 職業としてやって行けるくらいにプログラムは書けるようになるだろう。 一方、計算機科学の教科書を見ると ギリシャ文字やら妙な記号やらがいっぱい出てきて、 現場のプログラミングとはかけはなれているように感じられる。 そんな小難しいことを知ってプログラミングに役に立つのだろうか。

実際には、抽象的な理論は、現場で出会う問題の根底にある「構造」を 見抜くのに役に立つ。 理論を知らず経験だけに頼るのは、目隠しをして旅をするようなものだ。 今までと似たようなパターンの問題に対しては、 勘に頼ってなんとなく進んでみても、いずれ目的地に着けることが多いだろう。 けれどそれでどうにも進めなくなった時は途方に暮れるしかないし、 全く見たこともないような問題に対してはそもそも何をどうしたら良いのかわからなくなる。 理論を身につけてその応用方法を知っていれば、 全体を見通して系統立てた攻略法を組み立てたり、 近道がありそうなところを嗅ぎ出すのに役立てることができる。

もちろん理論を知らないでもずば抜けた直感力で何とかしちゃう人はいる。 また、理論を身につけていても必ず道が見つかるとは限らない。 ただ、理論を身につけていた方が勘だけよりも成功率が上がるのは確かだ。

演技の理論にも似たところがある。 センスと経験だけでもそれなりに演技は出来る。 けれどそれは実は半分運頼みみたいなものだ。 理論は「この公式を当てはめれば演技が完成する」というようなものではないけれど、 自分なりの完成形を作って行くという過程の道筋を見極めるのに 大いに役に立つ。その道筋をたどる努力は飛ばすことはできないけれども。

(スタニスラフスキーシステムやメソッドがしばしば同じような演技しか もたらさないかのように批判されることがあるが、理論を公式のように 考えてしまうとそうなるのではなかろうか。)

クラスで学んだ具体的な理論については後でShiro:ActingForTheCameraにまとめる。

(2008/12/08 02:34:23 PST)

Hawaii Public Radioのひとつ、 KIPO (FM 89.3)の番組 "Aloha shorts" の公開録音をしてきた。 "Aloha shorts" はローカルの作家による短篇小説や詩を朗読する番組。 今回の私の担当は詩なので1分半くらいしか出番がないけど。 放送は1/27/2009 18:30-19:00。 多分オアフじゃないと受信できないと思う (本放送のKHPRはマウイ(KKUA)、ハワイ島ヒロ(KANO)でもやってるんだけど)。

Readingは初めてだったのだけれど、思ったよりもずっとおもしろかった。 3週分をまとめて収録するのだけれど、Dave Lancasterによるコメディ短篇 "Benny's Bachelor Cuisine" (2/3/2009放送) のReadingは一人芝居と言っても良い くらいの熱演で観客も笑いが止まらなかったし、 ベテランのローカル俳優Dan SekiとKaren Yamamotoによる短篇 "Communion" (2/10/2009放送) のReadingは声だけなのに 芝居の一幕ものをみているようだった。 ただ読むだけでも意外に奥が深い。

(2008/12/02 16:20:38 PST)

らむ太語録。

昼寝せずに遊んでいたせいで夕方はやいうちに眠ってしまい、夜中の2時に目を 覚まして遊び始めた。

お父さんは寝たくなくて仕事してるわけじゃないんだよ、息子よ。

(2008/11/30 11:08:13 PST ループ検出(2))

おお、昨日の話題をいけがみさんより丁寧な解説が。 確かに「木の循環」は変ですね。有向グラフにサイクルがあるかどうかの判定という ことですね。

O(m+n)の全走査アルゴリズムだけど、隣接グラフか行列を走査するにつれ マークしてく必要はやっぱりあるのですよね。

TAOCPの4巻で カバーされるんだろうか。このへんは。

(追記2008/11/30 19:13:09 PST):

Korte-Vegen の教科書によれば、topological sorting は TAOCP(Knuth, D.E. "The Art of Computer Programming; Vol.1; Fundamental Algorithms, Addison-Wesley, Reading 1968 (3rd ed. 1997) に言及されているとのことです。

ああ、topological sortingについては確かに1巻にありました。 Gaucheのutil.toposortモジュールはそのままTAOCPのやつを実装していたような。 うは、それでまさに循環が検出された時には "graph has circular dependency" ってエラーを出すようにしてる。 これそのまんまで良かったんだ。 入力形式が違っても同型になる問題に気づくってことは大事なのですなあ。

(2008/11/29 16:48:46 PST ループ検出)

リンクつきリストにループ部分があるかどうかを確かめる - ときどきの雑記帳

最後の "Best solution" にあげられてる「うさぎと亀」は あらゆるLisp/Scheme処理系で使われていると思う。list?は 循環リストについても停止しないとならないため。 (CLのlistpは最初のペアしか見ないのでちょっと違うが、 lengthなどは循環リストを検出しないとだめ)。

難しいのはcar方向にも循環する場合、つまり木の場合で、 これはvisitした全ノードを何らかの方法で区別する (マークをつける、 ハッシュテーブルに記録する、みつけたものから移動してゆく、など) しかないと思うのだけれど、もっと効率の良い方法はあるのだろうか。

循環がある場合も停止する必要はあるけれど、必ずしもタイトに循環を検出しなくても良い、 という用途はあって、その場合は適当なところまで循環を気にせずに処理を進めて 怪しくなったら循環検出モードに切り替える、という手はある。 Adams&Dybvigのr6rs equal?実装とか。

(追記2008/11/30 01:47:30 PST): 木の循環検知、こんな感じだとどうでしょうか?

木の場合も結局、「何とか優先」で順番に辿るわけなんで、うさぎを作っちゃうという考え方です。

なるほど。考え方としてははたと膝を打った。ただ全ノード記録に比べて良いかどうかは疑問。

空間計算量については、全てのノードについて非末尾再帰が入るからO(D) (D=非循環部分の木の深さ)。 ランダムな木だとだいたいO(D) = O(logN) とみなせるかなあ。 で、リストに対する亀とうさぎ (空間計算量O(1)) にはかなわないけど、 全ノードを記録する (空間計算量O(N) (N=ノード数)) に比べればかなり良い。

ところが、このアルゴリズムは全ノードについて探索が2分岐するから 時間計算量はO(2^N)になる。全ノードを記録する場合はO(N)。 Nの上限がわりと小さい値であって、空間計算量をケチりたい場合くらいにしか使えなさそう。 (訂正:O(2^N)にはならない。上記リンク先の追記参照。)

(追記2008/11/30 02:58:44 PST): miuraさんの解にヒントを得た。 時間計算量が爆発するのはうさぎが増えまくるからで、 あくまで一匹を追いかけるようにすればよい。つまり木の全ノードの列挙を シリアライズしてその列について亀とうさぎを適用すればいいわけだ。 ちょっとsamefringe problemに似てる。遅延ストリームを使ってみるが、 samefringeと同じように、コルーチンとか継続渡しでも書けるはず。

(use util.stream)

(define (acyclic-tree? t)
  (define (traverse tree)
    (stream-delay
     (if (pair? tree)
       (stream-append (stream tree) (traverse (car tree)) (traverse (cdr tree)))
       (stream tree))))

  (let1 str (traverse t)
    (or (stream-null? str)
        (let loop ((tortoise str)
                   (hare     (stream-cdr str)))
          (cond [(stream-null? hare) #t]
                [(stream-null? (stream-cdr hare)) #t]
                [(eq? (stream-car tortoise) (stream-car hare)) #f]
                [else (loop (stream-cdr tortoise)
                            (stream-cddr hare))])))))

どうかな?

あ、だめだ。

gosh> (acyclic-tree? '((a . #1=(c . d)) #1#))
#f

そうか、部分共有があるとeq?なノードに出会ってしまうんだ。 だから元の木構造の情報を失ってしまうと間違える。 ということは各ノードへの元の木構造のパスをストリームの各要素とする? むー、結局余分な空間を食いそうだが…

やっぱだめだ。パスの等価性判定のところで循環を考慮した比較が必要になるので 堂々めぐりだ。

まてよ、全ノードマークっていうのも勘違いしてたかも。全トラバースしてハッシュテーブルに 登録してゆく方法だと上のように部分共有があるケースを循環と間違える。 マークするのは各パス内だけ (現在いるノードからルートまでが見える状態) にしとかないと。 そうすると、ハッシュテーブルは使いづらい。リストを使うとして時間O(N・D)、 空間O(D)か?

(2008/11/27 01:42:49 PST 「御社が第一志望です」)

Exploding Offer Season - Joel on Software

You ace the interview, of course. They make you an offer.

“That sounds great,” you say.

“So, when can you let us know?”

“Well,” you tell them, “I have another interview coming up in January. So I’ll let you know right after that.”

“Oh,” they say. “That might be a problem. We really have to know by December 31st. Can you let us know by December 31st?”

Tada! The magnificent “exploding offer.”

新卒就職者に対するJoelのアドバイス。企業のリクルータはオファーを出した後、 あなたを他の企業に取られないようにするために、他社の面接の結果が分かる前に 返事をさせようとする。そんな「時限付き内定」をもらった時にどうすべきか。

Joelの言っていることは至極まっとうなことなんだけれど、おもしろいと思ったのは、 きっと日本の「新卒就職活動」ではこういうアドバイスはまずなされないだろうなってところ。

Joelのアドバイスは原文を読んでもらうのが一番だけど、ざっと要約すると

私はこのような態度は企業にとっても学生にとっても極めて健全だと思うが、 どうも日本の新卒就職活動の現場では、 そもそも就活が「当事者間の契約交渉である」という意識自体薄いという気がしている。 いわゆる新卒就活をやったことがないので単なる気のせいかもしれない。 けれど、例えば「面接で『第一志望か』と聞かれたらもちろんはいと答える」みたいな アドバイスをたくさん目にすると、気のせいではないと思われるのだ。

何でも米国風にするのが良いと言うつもりは全く無いが、 日本のこの就活における奇妙な空気は、「これが日本の文化だから」と 守るようなものではないと思う。 就職あるいは採用活動を大事にとらえるならなおさら、 その場で不誠実になることを称揚するアドバイスが蔓延するのは害にしかならないだろう。

(なお、「誠実になる」というのは何も「御社はすべり止めです」と答えるのが良いという ことじゃない。あなたにその会社に入る気があるということは、少なくともある程度の期間に わたって会社にあなたの人生の多くを預けても良いと既に思っているってことだから、 素直にそう答えればいい。「第一志望」「第二志望」「すべり止め」という考え方自体が おかしいのだ。就職活動は受験ではない。 一定のルールのもとでゲームをして順位を決めるものではなく、 どうすればお互いにメリットを得られるかという落としどころを探す社会的な活動なんだから。)

(2008/11/26 02:15:29 PST)

Acting classの先生のことば:

Often, a mark of an inexperienced actor is a tendency of giving suggestions to other fellow actors. So, if you absolutely need to offer a suggestion or a criticism to your fellow, do that with most respect and humility. Never, ever assume you know more.

(2008/11/24 18:01:19 PST) はまり中

こういうのもなー。つくづく時間の無駄だとは思うけど、たまに手を動かしとかないと 勘が鈍りそうだしなー。

(2008/11/11 03:20:14 PST) Into the Wild

信念のために命を落とした6人 - GIGAZINEでの Christopher McCandless ("Into the Wild" に描かれた若者) の紹介のされかたがひどい。 彼の行動を非難する人は多く、ネタ元の記事もはっきりと 非難する文脈でかかれていて、それはそれで無理もないことだと思うのだけれど、 GIGAZINEの紹介のしかたではただのバカにしか見えないではないか。 そのせいかどうか、こんなブクマコメまでついてるし:

最後の例については男子高校生でも実行しない本当に馬鹿げた行為だと思うのだが、 なんでそういうのをわざわざ映画化なんぞして名誉みたいに取り扱うのかなあ。 死に場所にアラスカを選んだってだけじゃねえか

あの映画が作られた文脈を理解するには、原作の "Into the Wild" を読まなければならない。

原作はChrisの足跡を丹念に追うことで、事件当時の報道の「無知な若者の無謀な冒険」 というイメージとは異なり、実はChrisはそれなりの準備をしていて 経験も積んでいたことが明らかにされている (既に彼は一年以上、 米国中西部やメキシコでサバイバル生活をしていた)。 餓死したのも、食料が見つからなかったからではなく、 食用となる植物と外見が良く似た毒性を持つ植物 (摂取すると吸収が 阻害され、いくら食料を摂っても栄養として取り込めないという症状が出る) を誤って 食べてしまったからではないか、ということだ。映画ではこのへんもさらっと流して あったのでわかりづらいけど。

ただ、原作はChrisを擁護するために書かれたのではない。そもそも原作作者の Jon Krakauerは、一貫して「人間は、理性的に考えればばかげている行動を、すさまじい熱意と執念を持って取ることがある。それはなぜか。」というテーマを 追っているノンフィクションライターだ。"Into Thin Air" ではチョモランマに挑む人々を、 "Under the Banner of the Heaven" では宗教原理主義者を追いかけた。 「なぜか」の答えは出ない。そもそも答えが出るような問いではない。 それでも、読者はJon Krakauerの掘り出した客観的事実およびその過程での 彼の主観的なjourneyを追体験することで、考える材料を手に入れることができる。

"Into the Wild" もその流れの中にある。なぜ、Chrisは社会的価値 (学歴、財産、etc) や家族とのつながりを捨てたのか。 なぜ、Chrisはオーソドックスな冒険家としての修行を積むことなく 荒野に身を投じたのか。単なる家出だとか放浪ではなく、「冒険」である。

"Into the Wild" がベストセラーになったのは、多くの人の心の中に、 自分の身ひとつで自然と対峙して生きてみたい、だとか、 約束された安全と引き換えに自分の中の荒ぶる自然を諦めてしまっているのではないか、 とかいう思いがあるからではないかと思う。少なくとも私はそうだ。 私はそういう火種を、自転車にテントを積んだ小旅行でごまかして鎮めてきたのだが、 なぜ心の中にそういう火種が燃えているのか、その疑問が Chrisの行動への「なぜ」と重なるのだ。

その「なぜ」がショーン・ペンを駆り立てて映画を作らせたのだろう。 Chrisの行動を讃えるためではない。ショーン・ペンもまた、自分の中に燃える 理性を越えた情熱を理解しようとしたのだ。

映画ではストーリーをつくるために、その「なぜ」に一見わかりやすい説明が 与えられてしまっているのが残念だ。原作の流れを汲むなら、 観客が心の中に大きな問いを抱えて映画館を後にするような作品になるべき だったのだろう。が、それでは映画にならなかったのかもしれない。

"..., but attempting to climb Everest is an intrinsically irrational act---a triumph of desire over sensibility. Any person who would seriously consider it is almost by definition beyond the sway of reasoned argument." --Jon Krakauer, Into Thin Air.

(2008/11/07 10:41:44 PST Don't take it personally)

真っ赤な論文原稿が指導教員から帰って来たら? - 発声練習

これは論文を書いている学生だけでなく、表現する者すべてにとって切に必要なことだなあ。

去年とったUniv. of Hawaiiの"Acting for the Camera" のクラスを今年も取っている のだけれど、このクラスは厳しい。演技を実際に撮影してそれを見ながら 先生がツボをついた批評をしてくれる。映像が目の前にあるので 自分としても直面するしかない。毎回ぼこぼこにされる感じだ。 (ただ、今回2回目なんで少し余裕をもって参加できているんだけど、そうすると 先生は常に、それぞれの参加者の現在のレベルに対して1ステップ上を基準に した批評をしていることが見えてきたのだが。)

で、先生がしつこく念を押すのが、"Don't take it personally." ということ。 批評の対象となっているのはあくまでその場に出された「作品」であって つくった本人の人格に対するものではない。 「役者の場合はこの違いを認識することがとりわけ重要だ」と先生は言う。 批評の対象となっている映像には役者自身が映っているわけで。画面の 中の自分を指して「ここがまずい」と言われた時にそれをpersonallyに 取らないようにする、というのは確かに少々難しい。

私自身がどうやってるか内省するに、どうも自分は「表現した時点の自分」 と「現在それを批評している自分」とを切り離すことで対応しているような 感じがする。表現した時点で、「外に出された表現」も「その時の自分」も 固定される。一度出してしまったものは取り返しがつかないし、 それを出してしまった自分というものも「なかったこと」にはできない。 その時の自分はそういうものだったのだ、というふうに諦めるしかない。 その上で、「その時の自分」から何を変えたらより良い表現ができるのか、を考える。

以前、就職ネタに触れた時に、自己分析なんてやってる暇があったら 表現しろ、みたいなことを書いたことがあるけれど、そういうことだ。 自分ってどんな人間かを知るには、今の自分を固定して標本にして、 それを眺めてみる必要がある。ところが自分の中でぐるぐる考えている 限り、今の自分と次の瞬間の自分と…が連続的に溶け合って、なかなか 固定することができない。標本にするためには、今の自分と次の瞬間の 自分を断絶させる必要がある。それには、今の自分に出来て次の瞬間の 自分には出来ないことをすれば良い。 「表現し、それを他人に目撃してもらう」のはその手段だ。 他人に目撃されてしまったら、取り返しがつかない。 その取り返しのつかなさが鍵なのだ。

追記2008/11/07 18:46:11 PST:
作品と人格 - 黎明日記

カネもらってちょちょっとやった仕事なら、人格と創作物は切り離される。しかし、心血注いで作った物の場合、そうではない。 [...中略...] このような場合に「人格と創作物は切り離される」と冷徹に言い放つことは難しい。

心情的にはそうだし、たぶんどんなに切り離したつもりでもどうしても切れないつながりが 底にあるはずなんだけれども。

だからこそ、敢えて「切り離す」と自分から決めることが重要なのではないかと思うのだ。 そうでなければ、自分の作品に甘えてしまう危険がある。死ぬまでに一作だけ世に出す つもりならそれでも良いのだけれど、次の作品へと進むには前作で出来なかったことに 直面しないとならないわけで。

たぶん、手放すことが出来るのは、野に放っても根本的なつながりは切れないという ことを信じられるからだと思う。自分がつくったものには、不可避的に自分の痕跡が 刻まれているはずで、それは作品がどう利用されようとも、届く人には届くはずだと いう確信。これが持てない時に、作者は自分の作品をコントロールしたくなってしまうのでは なかろうか。

追記2008/11/08 12:42:03 PST
http://twitter.com/kinaba/status/996240551

自分でフルボッコにできない作品は表現として外には出さない、としてるなあ自分の場合。まあチキンです。長めのブログ記事を書くでも裏で5個は突っ込み記事草稿を書いてから出すとかしてた。

出す前に自分で鍛えとくのは前提としても、自分から見える部分というのは どうしても限られるので、出してみたら思わぬ反応を喰らうということはよくありますな。 (自分と違う見方をしてもらわなければ出す意味が無いとも言える)。 Paul Grahamはエッセイの下書きを必ず信頼できる友人数人に読んでもらって 手直ししてるけど、良い方法だと思う。

あと、ライブで出すものについては「完成形」を持って行くということができない んだよね。練習でいくら納得行くものが出来たとしても、本番で完全にそれを 再現できるとは限らないし、観客の反応まで考えるとむしろ本番では練習の時とは 変えていかないとならない場合もあるし。そこで問われるのは作品そのものだけでなく 作品を載せる土台としてのその時点での自分自身でもある (文章だってそうなんだけど、 ライブの場合の方が明確)。オーディションの後はいつもずしんとくる。 ここで「切り離し」が出来ないと精神的にきつい。

でも人生はライブな決断の連続だ。いつ試されても反応できるように準備しておくことしかできない。

(2008/11/04 00:40:27 PST)

らむ太の遊び

らむ太は「かくれんぼ」を「もーいーかい」/「まーだだよ|もーいーよ」を言い合う遊びだと 思っているようだ。

父親は「しめきり」と言うと慌てるものだと思っているようなのでやつが飽きるまで付き合う。

(2008/10/11 18:06:10 PDT)

らむ太語録

うまく言えない言葉にはいくつかの規則があるっぽい。

ただ、「ダイハード」が何度言っても「だいやはー」になるのはわからない。 その「や」はどこから来たのだ。

(2008/10/01 22:10:47 PDT)

らむ太語録

らむ太はロボットになりたいようだ。

(2008/09/13 16:39:32 PDT 多バイト文字とDFA)

ときどきの雑記帖:

flex の森 - ひげぽん OSとか作っちゃうかMona-
誰か多バイト文字に対するDFA構築手法をわかりやすく解説してくだちい。

文字クラス中の文字は大抵近接した領域に固まってるので、 全部utf-8にしてオクテット列をacceptするDFAにできなくはなさそうな (文字クラスでの分岐が一段じゃなくツリーになるけど、近い領域に固まっていると ツリーの根元が多く共有される&リーフは何でも良い場合が出てくる、ので 圧縮できるんではないかなあと)。 ただ、DFAでそれをやってるのは見たことないから思ったより圧縮できないのかも。 Spencerの新しい方のDFA(Tclに使われてるやつ)も確かいちいちucs-4に展開して、 さらにDFAをon-demandで作ることでサイズを抑えていたと思う。

GaucheのregexpエンジンはNFAだけど基本的にオクテット列に対して動作する ように展開される。ただ、文字クラスについてはオクテット列のツリーに するのが面倒だったので、一度文字を構築してレンジチェックをかけている。 オクテット列のままやったらどのくらい差が出るか測ってみたいんだけど 当分そんな暇は無さそう。

(2008/09/04 19:50:51 PDT v8とかスクリプトとか)

lucille development blog - V8 benchmarked

py2llvm の経験から、スクリプト言語はネイティブの 100 ~ 1000 倍遅く、JIT したとしても数十 ~ 100 倍くらい遅いもんだと思ってました.

[...]

もはやあと数年もしたら、動的言語やスクリプト言語が、ネイティブ版とほぼ変わらないくらいの速度で実行できるほどに JIT 技術が進化しそうだ.

「スクリプト言語」の定義が曖昧なので厳密な議論にはならないのだ けれど、大島さんも書いているように 動的言語であるCommon Lispはon-the-flyでコンパイルして Cにほぼ匹敵する速度(*)も可能だったわけで、何が足を引っ張っていたかというと 単に実装者がさぼっていただけだと思うなあ。

もちろんここでの「さぼる」は悪い意味じゃなくて、工学はトレードオフなので、 そこに手間をかけるよりも優先度が高いところがあったってことだ。 特にネイティブコードでがりがり最適化をかけるような話は開発リソースを 喰うので、開発リソースがscarceな状況で手を出すのは得策ではない。 従って、Googleみたいにリソースをつぎ込めるところが手を出してくれるのは 有難いことである。

C++が速い、というが、その速さの源は言語そのもののの性質だけではなく、 コンパイラベンダが巨大な開発リソースをつぎ込み、プロセッサ メーカもそれに合わせたアーキテクチャを作ってるってところが大きいと思う。 一般の開発者は、その成果に乗っかる形でコードを書いているわけだ。 ある意味、分業による効率化とも言える。

Clojureを作ったRich Hickeyは、 「VM、GC、JIT、OSインタフェースなどはリソースのあるところにまかせて、 言語開発者はもっと上の方の言語デザインに力を割くべき」みたいな ことを言っていた (ClojureはJVM上で走る)。

その見方をとれば、Googleがリソースをつぎ込んで爆速JavaScript実装を 広めてくれれば、「JavaScriptへとコンパイルして後はJavaScript処理系に 任せる」という方針はぐっと現実味を帯びてくる。 BiwaSchemeとか、 時代を先取りしてたかもね。

いずれにせよ、速い実装がポピュラーになれば既存の実装への プレッシャーになることは間違いなく、 Gaucheでもますます 色々試してみたい時代になってきた。

(* Cコンパイラもナイーブだった頃。global analisysをやるような最適化 コンパイラに対しては、ローカルな情報しか使えないインクリメンタルコンパイルは 負けるだろう。ただ、開発中のインクリメンタルなモードではコンパイル速度を重視し、 アプリが完成したらバッチでコンパイルするといった複数のモードをつけられない 理由はない)

そうそう、 http://d.hatena.ne.jp/squeaker/20080904 :

高速化のためには数値型や文字列に関する仮定は置かなくてはならないので、 例外なしに完全にできるわけではないですが、四則演算みたいなものの 定義は書き換えたら遅くなっちゃうけど、それら以外は別にIntegerやStringであっても 少々変えても大丈夫、というようなものにはできると思います。

Lispのネイティブ実装は、例えば加算ならデフォルトのfixnum additionのコードを 吐いておいて、オペランドがfixnumでなかった場合はtype error例外が飛ぶので それを捕まえてより複雑な加算処理を行う、みたいなのがよく使われてたと思う。 この方式だと加算の意味を後から追加していっても、多くのケースで性能は犠牲にならない。 ただこれはハードウェア命令がタグチェック→例外をサポートしてくれてる ことが大きいんで、現代のプロセッサでタグチェックを一般命令で挿入すると どのくらいアドバンテージが出るかはわからない。

(2008/09/02 02:08:10 PDT 100年後の言語)

LL Futureにはかなり前から出演を 頼まれていたのだけれど、7月のキプロス行きの後で腰を痛めて、 今回もLA行きの直後に飛行機旅行が続くと腰が持つかどうか心配になり、 えんどうさん他スタッフに申し訳ないけれど辞退させてもらった。 (開催が近くなってからのキャンセルでご迷惑おかけしました)。 実際、体力的にきつかっただろうなと思う。

さて、blogをあちこち見ていたんだけれど、 「100年後の言語」セッションに関してとてもおもしろい問題提起が あったのでちょっと考えてみた。

ユメのチカラ : LL Future

それこそコンピュータアーキテクチャがノイマン型(プログラム内蔵方式のコンピュータ)で あるならば、どっかのレベルではメモリという概念が必要になってきて、 関数型のOSやらshellを用意したところで、どうしてもC的なレイヤがでてくる。

ここで言う「C的」とはハードウェアの状態変化によく対応しているという意味だと思う。 実際、C言語は長らくポータブルアセンブリとして活躍してきたわけだが、 ぼちぼちその抽象化がハードウェアに合わなくなっているんではないかという気がしている。

ハードを気にしてコードを書くなら、今や階層化されたメモリや メモリアクセスのリオーダリングなどを考えざるを得ないが、C言語そのものには そういった機構を明示的に扱う仕様は組み込まれていない。 その一方で、aliasing ruleを破っているコードは何の警告もなく直感に 反するような動作をする (e.g. strict aliasing rule)。

要するにCで書いてハードに直接触っているというのは全くの幻想で、 Cで書いててもプログラマはやっぱり抽象化されたモデルを扱っているにすぎず、 しかもそのモデルにはあちこち漏れがあるというわけだ。 (むしろ、怪しい動きがあれば開発中のREPLで直ちにdisassembleして ネイティブコードを確認するLispプログラマの方が、 ハードに近いかもしれない←単にコンパイラを信用してないだけとも。)

メモリとプロセッサのやりとりがどんどん非同期になっていって、 マルチコアやヘテロなコアになって、ひとつのファイル内で ある部分と別の部分は違うアーキテクチャのコアで実行されているなんて ことになってくれば、見た目はCでもハードからの距離はさらに遠いものに なってゆくだろう。

で、別にCが悪いとかそういう話ではない。 ただ、「C言語的」なモデルが「ハードに近いレイヤ」であったのは歴史の一時点の ことであって、C言語をこれからもそのように扱うのは多分間違いだ。 たとえノイマン型は変わらないとしても、スレッドやメモリバリア、 キャッシュ、ヘテロなコアなどを最初から考慮に入れて新たに 「ハードに近い、高級アセンブラ」を考えるとすれば、 違ったモデルが出てくるだろう。 そして、それが例えば疎結合なメッセージパッシングに基づいたものになったとしても 私は驚かない。その時C言語は、メッセージパッシングなプリミティブが エミュレートする「古き良き時代のCPUとメモリのモデル」上で走る高級言語になるかもしれない。

ユメのチカラ : LL Future

文法の独自拡張は、そのコミュニティを分断することになるのではないかと思ったりする。 つまりXXの機能を利用するためにYYという文法定義が必要で、 それが従来のZZとコンフリクトするので素直には利用できない。 ライブラリやパッケージでも同様な問題はおきなくはないが、 文法は通常一緒なので最悪コピペ的に回避することは不可能ではないが、 文法をいじってしまうと、それも簡単ではない。

これはLispのマクロに対して良く言われることと同根なのだけれど、 このような懸念はモジュラリティの問題であって文法の話とは全く関係がない。

ライブラリであってもグローバルな影響をもたらすライブラリ同士は 回避不可能なコンフリクトを起こす。 (動的言語でありそうなtrivialな例としては、演算子'+'の意味をグローバルに 変えてしまうようなライブラリを複数使いたい場合とか。 もっとnon-trivialな例として、ライブラリAとライブラリBが異なるGCを採用している場合とか。)

結局、文法だろうがライブラリだろうが、 モジュール機構などで「スコープを限定できること」が コンフリクト回避の鍵であって、スコープを限定できないようなものがあれば それは本質的にコンフリクト回避不可なのだ。

(ただし、ライブラリがリンクもしくは実行時に影響してくるのに対し、 文法の拡張はコンパイル時に影響を与えるので、依存関係の処理が若干面倒に なるのは確かだ。これはどっちかというと処理系作成者が悩むところだが)

Programming language design and security

I think programming language designers are not exempted from the responsibility of (at least trying to) making computer systems secure. If I could hear more constructive ways of solving the security problems in the answer from one of the panelists, such as:

then I would have been much more convinced. But now I should suspect that quite a few programming language designers just don't care about the security consequences of the features they build into the language.

こちらは、これからの言語はセキュリティを考えに入れないといかんでしょうという 問題提起。

で、私が考えるのは、セキュリティの問題というのは仕様と実装の齟齬の問題の 一形態であるということ (セキュリティポリシー(=仕様)を決めない限り、 何がセキュリティフローかは決まらない)。なので、究極の回答というのは 仕様からそれを満たすプログラムを合成するって話かなあと思う。 たぶんあろはさんが詳しそう。 (仕様をどう記述するのが良いかって問題は別に残るけど)。 ただそれが実用規模で実現するのはもうしばらくかかりそうだ。

なので、ポイントになってくるのは静的動的さまざまなプログラム検証って ことになると思う。

プログラム検証は検証で色々やられているが (例えば、上に引用した部分でrace conditionについて触れられてるけど、 Tachio Terauchi, Checking race freedom via linear programmingは実用規模のCプログラムに対して 静的解析でメモリアクセスに対する競合が起き得るかどうかを検証している)、 言語作成者としては「実用性を保ちつつ、かつ検証しやすい言語仕様とは何か」 を考えてゆくことになる。

鍵となりそうなアイディアはいくつか。

上でも挙げたけど、モジュラリティ。ある操作の影響範囲が明確に限定できて、それが 必要以上に大きくないこと。検証は範囲を限定すればするほどやりやすい。

なおモジュラリティという意味では、スレッド+グローバルなmutationというモデルは 最悪で、そこだけ見てればちゃんと動くはずのプログラムが、全然関係なさそうな ところの変更に影響を受ける可能性がある。なので言語としては別のモデルを 提供するのが吉。

関数型のモデルは状態の管理がローカルになるという点で強力な武器になる。 けれど、それとは別に複数の制御の流れを綺麗に扱えるモデルが必要だろう。 π計算みたいなものをうまく取り入れられるのか、それともlindaみたいに 同期機構をマクロに見るのがいいのか、そのへんはよく知らない。

ただし、これらの理論を純粋に採り入れて 制限をきつきつにしてしまうと今度は実用プログラムが書きづらくなる。 で、実用のために制限に穴をあけたくなるわけだが、無制限に穴をあけると そこで「何でもあり」になってしまう。 なので、下の層として「ハードに近いけれど頑健な」モデルがあるといい (それは間違ってもC言語じゃない)。上で挙げたようなメッセージパッシング かもしれないし、型付きアセンブラみたいなものが使えるかもしれないし、 そのへんは住井さんが詳しいと思うけれど、 under the hoodに降りてビットを直接いじってるんだけどそれが検証可能である、 というふうになって行くんじゃないだろうか。

もひとつ、これも上に挙げた文法のカスタマイズにつながるんだけれど、 問題のドメインがはっきりしている場合、それ用のDSLで書いてある方が 検証しやすい。たとえばAlan KayのとこでIan Piumartaらが やってるプロジェクトでは、RFCに書かれてるTCPの仕様をDSLとして解釈して コンパイルすると実際に動作するTCPプロトコルスタックになる、というのを 書いたそうだが(大島さん、間違ってたらツッコミお願い)、 ここまでやって問題が出たらそれは仕様のバグってことになるわけだ。 ここまでやらずとも、DSLを使うというのは、問題領域で使われる概念に良く対応する 言葉を組み合わせてプログラムするということだら、プログラマの意図がより明確であり、 その意図に照らした検証がしやすいと言えるだろう。

あともひとつ。これもIanの受け売りに近いんだけど、こうやってメタプログラミングを 極めて行くと複雑なシステムがえらくコンパクトに書けるようになる可能性がある。 実際、彼らはOS・言語処理系からアプリに至るまでの全てを20000行で書くという プロジェクトをやっていて、ネイティブコンパイラが1000行ちょい、とかは 既に実現されてる。 で、1000万行のシステムと2万行のシステムなら後者の方が検証ははるかに 楽だろう。1000万行のシステムの99.8%が機械的に除去可能な冗長性でない限り。 (そうそう、Ianのやつは上の「C的なレイヤ」の話の反例にもなってると思う。)

私としては未来はそっちの方向かなあという気がしてて、Gaucheのシステムも だんだんメタに記述していって記述量を減らして行きたいと思っている。

(2008/08/27 04:36:09 PDT 『ミスト』のラスト)

こちらこちらで 批判されてる映画評論家がいて、 好奇心でその人の映画評 をいくつか読んでみた。私もまるきり勘違いすることがよくあるので人の批判はできない んだが、『ミスト』評 (リンク先ネタバレ注意)でラストを「救済」としているのが気になった。 というのは、『蝿の王』を知らないとあのラストは救済に見えるかも、と思うからだ。 (あと、あのラストを「衝撃狙いの悪趣味な演出」みたいに言っている評も見たけど、 それもバックグラウンドを知らないせいだと思う)。 もちろん観客それぞれの背景によって解釈は色々あっていいんだけれど、 あれを救済で済ませてしまうのはあまりに勿体ないと思うので書いておこう。 できるだけ見た人にしかわからないように書くつもりだけど、 どうしたってラストに触れるので『ミスト』未見の人は注意。

『蝿の王』はもう古典なのでストーリー出しちゃっていいかな。 出しちゃうよ。ネタバレ嫌な人はここでストップ。 少年達を載せた飛行機が無人島に不時着し、大人がいない状況で 少年達のコミュニティが理性と秩序から次第に本能と混沌へと変貌してゆく様子を描く。 で、まあ最後には大人がやってきて少年達は助かる。

助かるのだけれど、助けにやって来たのは軍隊だ。 『蝿の王』小説中でわずかに触れられるが、外の世界では戦争をしている。 このラストの意味については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 02:54:03 PDT デバッガ)

未来のいつか/hyoshiokの日記

アプリケーションの開発時にはデバッガーを使うのはあたりまえだろう。 そのデバッガーを使えなくて何がプログラマだ、くらいの事は思うのだけど、 世のプログラミング言語の入門書にデバッグの仕方もましてやデバッガーの使い方も載っていない。

おごちゃんの雑文 - デバッガなんて使わねーよ

この手の言い草はよく聞くけれど、私はデバッガはほとんど使わない。使ってもせいぜい、どうしても他に資料のないコアダンプを解析しなきゃいけない時だけで、普段はまるっきり使わない。そこにソースがあるなら、怪しい箇所を推理しつつprintfをつっこむ。なぜなら、私はプログラムを書く時に一番大切なものは、そういったツールを使う能力ではなくて、

思考力

であると思うからだ。それと共に、本当にクリティカルなバグには、デバッガは無力だからでもある。

ハンドアセンブルが長かったので、CP/Mが動くようになってDDTという デバッガを最初に使った時は感動したものだ。ハンドアセンブルではprintfデバッグ は簡単ではない。コードを挿入するとアドレスがずれてジャンプオフセットの計算を やりなおさないとならない。インストラクションの頭をRST命令で潰すのが定石だが 戻し忘れると面倒なことになる。それを自動でやってくれて、対話的にレジスタの 内容が見られて、ステップ実行まで出来るというのは衝撃だった。 そのあとコアダンプを見るのにadbを覚えて、gdbを使うようになったのはだいぶ 後だなあ。一時期はgdb+Emacsで何でもやってた。

でも今ではデバッガは滅多に使わなくなった。使うときもソースレベルで ブレークポイント設定しまくってさらにステップ実行…というのはほとんどやらない。 インタラクティブな逆アセンブラ/メモリダンパとしての使い方が多いかなあ。 GC絡みの怪しい挙動の解析とか、最適化のかかったコードの振る舞いを追ったりとか、要するに ビットに直接触る必要がある場合限定。 通常のデバッグはprintfスタブを使い、もう少し込み入った問題であれば その問題限定の検証ツールを組み込んだりしている。

ソフトウェアって多くの層の積み重ねで、 gdbみたいなスタイルのデバッガがぴたっとサポートできるのは そのうちの特定の層だけなんだよね。 仕事の主要部分がその層に集中していればデバッガは強力な武器になるけれど、 そうでないとあまり役に立たない。で、昔はよく使ってたのに何で使わなくなったのか なあ、と考えてみたのだけれど、 ソースレベルデバッガは出発点としているモデル:「メモリ、レジスタ、 CPUの状態変化とソースとを関連付けて追っかける」っていうのが崩れてきているって 背景があるんじゃないかなあと。

ソフトウェアの一番下が状態機械である以上、その層を覗くツールとしての 現在のスタイルのデバッガの有用性は今後も残るだろうけど、 より一般的なツールとしての「デバッガ」に求められる異なるモデルっていうのが 必要になってるんじゃなかろうか。状態遷移よりは静的・動的な検証というものが 主役になるような気がする。言語の方にもそれに結びついた仕様が入って行くだろうし。 というか大きな企業はこのくらい既に考えてるだろうから最近流行りの「えんたーぷらいず」 言語の開発環境にはそういう支援が入ってたりしないんだろうか。

Visual Studioで作業してる若い人なんかを見ていると、実行環境からすぐにデバッガに 入ってがしがし編集してすぐ再実行して…ってサイクルを回してて、それはそれで 悪くないんだけれど、何て言うのかな、 「手元のデバッガが面倒を見られる層に無意識的に作業リソースを集中させてしまう」 というおそれがあるようにも思う。無意識に「デバッガで見られる状態機械の レイヤを越えた抽象化を避ける」というか。杞憂ならいいんだけど。

(追記2008/08/27 01:56:39 PDT: ちなみに、もちろんロートルLisperは 「実行環境からすぐにデバッガに入ってがしがし編集してすぐ再実行」なんだけどさ。 20年前から。でももっと良いやり方があるんじゃないかなあ、と思うのだ。)

(2008/08/20 22:21:42 PDT らむ太とteapot)

らむ太はなぜかUtah teapotがお気に入りで、画面にteapotが写ると大騒ぎする。 あんまり騒ぐのでかみさんがセコンドハンドショップで普通のティーポットを買って与えたら 喜んで遊んでいる。

CGアニメーションの特集番組でテクスチャマッピングか何かの説明で teapotが映り、ぐるっと一回りするシーンを見たらむ太は、 自分のティーポットを床に置くとそれを見ながら周囲を一周して 「おんなじ、おんなじ」と騒いでいた。 確かに、world coordinateでtransformするのと カメラ位置を(逆行列で)transformするので得られる映像は同じである。

らむ太語録

(2008/08/02 22:04:12 PDT rfc4180の曖昧性)

CSV形式はRFC:4180でフォーマルに定められているのだが…

これって、ファイル末尾がCRLFで終わっている場合、

  1. それがrecord終端のCRLFなのか、
  2. その後ろにひとつの空のfieldを持つrecordがあって、その後ろのCRLFが省略されているのか、

わからないよなあ。

一応「各レコードのフィールド数は同じでなければならない」って規定があるから それまでに2つ以上のフィールドが出てきてれば(2)の可能性は排除できるけど。

まあ慣例的にはCRLFの後ろにEOFが来てればCRLFが終端だとするだろうけれど、 それを形式的に(EBNFとかPEGで)かつ簡潔に記述するのって結構面倒なような。

と、PEGのテスト用のCSVパーザをいじってて思った。

(2008/07/31 12:54:23 PDT 病院の一日)

一昨日昼前くらいに、らむ太の目の中にごみが入っているのをかみさんが見つけた。 白目の部分に0.5mmくらいの黒いものがくっついている。 eye washを買ってきて流そうとしてみたのだが、全く移動する気配がない。 そのうちeye washを嫌がってらむ太も散々泣いたんだが、それでも動かない。 見た感じ、真っ黒で表面はなめらか、周囲もスムースな円形の何かだ。 放っておくとそんなに気にするふうでもないのだけれど、 感染などすると心配なので午後からかかりつけのpediatricianに連れて行った。 ところがドクターもそれが何だかわからない。 (視線をじっと固定できずにきょろきょろするもんだからじっくり見られないってのもある。) 結局Kapiolani Hospitalの眼科を紹介してもらう。

で、昨日午前にまず眼科。瞳孔を開く薬を入れてまず眼の中を検査し、 何かが深く刺さっているのではないことを確認。Kapiolani Hospitalは産科と小児科が メインなので、さすがに子供の扱いには慣れている。 それでも、いざスワブで取り除こうとするとらむ太は散々暴れた。 目薬で表面麻酔を入れてるんだけど、やっぱり怖いらしい。 押さえつけてどうにかスワブで拭ってもらうが全然取れない。

結局、全身麻酔をかけて取り除くことになった。

全身麻酔となると色々おおごとになる。 かみさんはこのへんの知識があって、 麻酔前に食事が出来ないことを見越して朝食を抜いていたのが奏功。 午後には処置を受けられることになる。 食事のことを思い出させないようにひたすららむ太の気を惹いているうち、 本人も疲れたのだろう (緊張してハイテンションになっていたのもあるだろうが) 麻酔をかける直前に眠ってしまった。 それでも、静脈注入だったので針が入る時には起きて少し暴れたが 程なく大人しくなり、眼医者がピンセットで取り除いた。 回復室で眼を覚ますまで待って、結局丸一日潰れたが 無事に済んで何よりだ。

結局モノは何だったのかというと、虫であった。 顕微鏡を実家に置いてきてしまったので詳しくは見られないが、 何かの甲虫類っぽい。そいつがしがみついていた模様。

(2008/07/25 14:28:51 PDT 環境設定メモ)

サブマシン(Athron 64X2, socket 939)のオンボードGPUがしばらく前に壊れてしまった。 ビデオカードだけ挿そうにも、マザーボードの挿し口はPCIE、 手持ちのビデオカードはAGPのやつしかない。 で、置き換えを検討していたのだが、 新しめのマザボはどれもsocket AM2でDDR2になってしまっている。 どうせCPUとメモリまで総取っ替えするなら、もう6年使ってるメインマシンの方を変えたい。 ということで中身総取っ替え計画発動。メインマシンをCore2 Quad / DDR2 にして、 サブマシン用には壊れたマザボと同世代のやつ(ただしオンボードGPU無し、AGP、DDR)を 購入、メインマシンのビデオカードを流用することにした。サブのCPUとメモリも流用。

メインの新しいボードはSATAなので、HDDはIDE-SATAコンバータを介して接続。 さて、grubから/bootにあるカーネルを読むまではいいんだがlogical volumeが 見つけられないと申す(元のシステムはFedora8/i386)。Ubuntu 64のインストールCDで 立ち上げたらちゃんとlogical volumeも見えてマウントできるのに。もう面倒なので そのままUbuntuをインストールしてしまうことにする。

Ubuntu 7.10 x86_64 をCDからインストール。だいたいスムースに進む。 ただ、nvidiaのドライバがうまく動かないのと、オンボードether (Realtek 8111c) が認識されるにもかかわらずパケットが出てかない。

Update managerから8.04へとアップグレード。 localedefで刺さる問題に引っかかる。killall locale-genでインストールを通してから 古いカーネルでリブートしてdpkg --configure -aでOK。 8.04ではnvidiaドライバもオンボードetherもout of boxで使えた。

iptablesの設定がデフォルトでは何にも無いのだが、クライアント用途だからかな。 設定手書きも面倒くさいのでFirestarterを入れた。

XEmacsでトラブル。日本語を表示しようとすると落ちる。ぐぐるとx86_64でしばしば 見られる症状のようだが、解決法が見つからない。emacsに生活の大部分を依存している 身としてはemacsで日本語が使えないと話にならないので、たぶん10年以上慣れ親しんだ XEmacsから決別してGNU Emacsに乗り換えることにする。

んでemacs-snapshot (GNU Emacs 23.0.60.1)を入れてみたところ、mew (5.2) でメールを フェッチする際にArgument out of boundでエラーになることがある。 この問題っぽい。 原因となったasetの仕様については こちら。 文字列にunibyte stringとmultibyte stringがあって、unibyte stringに asetでASCIIレンジ外の文字をセットしようとするとout of boundエラーになると。 (こういう、ascii stringとそれ以外を区別することのあまりの煩わしさがGaucheを 作ることになった強い動機なのであった)。 この問題はmewのMLのスレッドを見るとより新しいemacsのHEADでは直っているっぽいが、 emacsをビルドするのも面倒なのでmewの方をいじって誤魔化した。

*** mew-header.el.orig  Fri Jul 25 11:26:36 2008
--- mew-header.el       Fri Jul 25 11:25:45 2008
***************
*** 276,282 ****
        (setq str (string-as-unibyte str))) ;; A bug of Emacs 20.7
      (let* ((i 0) (len (length str))
           (par-cnt 0) (tmp-cnt 0) (sep-cnt 0)
!          (tmp (make-string len ?x))
           c ret)

        (catch 'max
        (while (< i len)
--- 276,283 ----
        (setq str (string-as-unibyte str))) ;; A bug of Emacs 20.7
      (let* ((i 0) (len (length str))
           (par-cnt 0) (tmp-cnt 0) (sep-cnt 0)
!          ;(tmp (make-string len ?x))
!          (tmp (make-string len ?\x3030))
           c ret)
        (catch 'max
        (while (< i len)

バッファの文字列を無理やりmutibyte stringで作るだけ。

文字列をmutableなarrayと考えることについても大いに問題ありと思うが、 さすがにemacsくらい巨大なソフトになると簡単には変えられないだろうなあ。

(2008/07/19 12:26:52 PDT キプロス土産)

そうそう、ぎっくり騒ぎで遅くなっていたが キプロスでχαλλούμιチーズΚουμανδαρίαワインを買ってきたのを 昨日楽しんだのだった。ハルーミはそのまま焼くと形を崩さずに膨らんで、もちもちした食感と 香ばしい香りが良い。こんなに美味いならもっと買ってくればよかった。 コマンダリアは甘いデザートワインだが、ちょっと薬用酒みたいな感じもする。 アルコール度数は普通のワイン並み(15%)で、すぐ酔っ払って寝てしまった。

(2008/07/19 11:03:46 PDT クレジットカードと信用)

メッセージ - アメリカのクレジットカードの話

ところが、アメリカでいざ旅行しようとしてみると、クレジットカードがないとなにもできないという。クレジットカードがないとホテルが予約を受け付けてくれないらしい。

[...] それで、そのおばちゃんの言うことがどこまで本当か(確実なのか)よく分からないのだけど、クレジットカードがないと(現金を持っていても)ホテルに泊まれないという話が本当だとすれば、ひどい話だなぁと思う。それはつまり、現代の身分制じゃないかい?と。

[...] 社会的ステータス(収入とか学歴とか)の多寡で、クレジットカードを持てるかどうか決まるというアメリカのシステムは、そしてクレジットカードがないといろんなことができないという社会システムはどうなのかなぁと今回思った次第。

予約を取るのは難しいかもしれない。ホテル側とすれば部屋を抑えておいて客が 現れなかったら丸損だから。ウォークインで行って部屋が空いてれば現金をデポジット することで泊まれるはず。なので、クレジットカードが無いとどこにも泊めてもらえない とかそういうことはない。(まあ、現実的に繁忙期に予約無しで旅行するのと大変なことになる (Shiro:log:2003後半の(2003/08/06 01:54:08 PDT)参照)のでかなり旅が制限 されるのは確かだが)。)

もしかすると、かなり余裕を見て予約を頼み、小切手か為替でデポジットを送付するなら 予約できるかもしれない。例外的な手続きだが、米国では意外にこういう例外的 手続きも筋が通っていれば受け付けてくれることがある。(特に小さな組織で、 権限がある人と直接話せる場合)。そのへんは案外大雑把。

クレジットカードの話 - odz buffer

U.S. では credit history で支払い能力の信用を作るという話があったりして。credit card を作るには credit history が必要とかいうなんだか鶏が先か卵が先かみたいな話も。

[...]あとまぁ、保証人制度みたいなのもなくて、credit history が自身の収入証明みたいなので、支払い能力を示すのが一般的らしい。

その通りで、生活のいろんな場面でリスクをなんらかの形で担保する必要があり、 クレジットカードが便利な手段としてほぼユニバーサルに使われることになった ってことだろう。

「クレジットヒストリーが無いとクレジットカードが作れない、でも クレジットカードが無いとクレジットヒストリーが作れない」という問題については、 「銀行にそれ専用の口座を開き、そこに預けた金額の9割までを与信枠として使える」という クレジットカードがある。私も米国に来てすぐの時はそれでカードを作った。 なので、ある程度長期の滞在で現金も持ってるなら、「カードが作れない」という ことはない。(最近、銀行口座を作ること自体が難しくなってるかもしれないけれど--- 旅行者は社会保障番号を取れないとか---でも旅行者向け口座を用意している銀行はある)。

逆に、こういう基本的な身分保証が国の制度となってしまうほうが怖いように思う。 それこそ、江戸時代の身分制度の復活なんじゃなかろうか。

(2008/07/19 10:34:08 PDT ぎっくり腰再び)

またやってしまった。4年前のパターンとまるきり同じで、最初は鈍い痛みからはじまり 数時間で痛みがひどくなって動けなくなるというもの。 直接のきっかけはジムでフリーウェイトしてた時なんだけど、たぶんその前の 長時間の飛行機の移動で歪みが来ていたんじゃないかと。 帰ってからすぐに整体に行っとけば良かったかも。

火曜にやってから基本的に寝て暮らしてる。3日目には歩き回れるようになったが まだ上体を折って屈むことができないし、長時間座ることもできない。 前回世話になったスポーツドクターの予約が月曜まで取れなかったので、週末もこのままだなあ。

(2008/07/15 03:57:56 PDT 泥とかなんとか)

IT業界では泥のように働くのかどうかとか再び盛り上がっているようだが (泥カンについて一言)、 Lisperにとっては答えは自明である。

LISP is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud.

どっちかっつうと「泥遊び」という感じだがな。

-*-*-

まあ、どんな業界のどんなポジションにいても仕事の大半は泥をいじくるような ものであるはずで (社長と平とで「泥」の中身は違うけど泥はやっぱり泥)、 だから「泥かどうか」みたいな問いは立て方が間違ってるんだろうな。 駒として搾取され消耗されてしまうのが嫌なわけで、 もしそれを警戒している学生達に「そんなことないよ」と言いたいのなら、 「うちは泥のように働いてないよ」じゃなくて、 どうしても泥沼を抜けなくちゃならない羽目になった時にどうしたか、 どうすればいいか、っていう話をしたほうがいいんじゃないかとは思う。

(2008/07/12 05:34:48 PDT 帰った)

カンファレンスは金曜までなんだけれど、あまり長く家を開けられないので 木曜にキプロス出発。最初の米澤先生の招待講演を聴いて (おもしろかった) ちょっと話させてもらってから会場を出発。

せっかく車なので、PaphosからLarnacaへフリーウェイ一直線で帰るのでは なく、ちょっと寄り道してOlympus山に登ってみた。時間的に厳しかったので 頂上までは行ってないけど、回りに広がる高原地帯であるTroodos地区を ひとまわり。標高があがると緑も増え空気も涼しくなって快適だった。

Heathrowに夜着いて、在ロンドンの友人と食事。高校時代の友人なんだけれど あんまり変わってない感じだ。翌朝も1.5時間くらい余裕があったのでその友人に ロンドンを少し案内してもらった。

ロンドンは安宿でネットが使えなかったのでHeathrow空港でメールを 読もうとしたんだが、メンバー登録してるtmobileにうまく接続できなくて (dhclientからしてだめ)、 アクセスポイントが異様にたくさんあった別のプロバイダの一時チケットを 買った。ところがログインで何度やってもしくじる。£4近く払ったのに くやしい。結局もう一度tmobileに挑戦して接続できたんだけどもはや時間切れで ろくに読めなかった。

Heathrowを昼12時すぎに出て、LAXに16時。税関があるので荷物は一度 ピックアップしないとならないようだ。LAXを18時に出て、ホノルル20時。 感覚的には昼でて夜ついてるんだけど、時差が11時間あるから、 乗り換え含めて19時間乗ってたことになる。Heathrowで買ったキングの新作を 半分すぎまで読み進めた。後は寝ていた。

(2008/07/08 09:46:28 PDT Cyprus)

DLS2008で喋るので

キプロスに来ている。ネタはPPLで喋ったやつ。あんまり考えずに投稿したんだけど、 通ってからあわてて飛行機を調べたらハワイからだとえらい遠かった。 ほぼ地球の反対側(ハワイが西経160度くらい、キプロスが東経30度くらい。 時差12時間(夏は13時間)) だから仕方ないか。 LAとロンドンで乗りついで46時間 (ロンドンで一泊を含む)。

北緯35度だから東京と同じくらいなのか。でもものすごく暑い。 北緯21度のハワイよりずっと暑い。ハワイの日差しと東京の湿度を足して1.2倍した感じだ。 昼間に外を歩くとあっという間に汗だくになる。

ハワイの土は赤か黒だけれど、キプロスの土は基本的に白い。 火山で出来たか岩の侵食で出来たかの違いかな。強い日差しが白い土に反射するから なお暑くなる。

カンファレンス(ECOOP)自体はこじんまりしていて(参加者200名ちょい)良い感じ。 DLS自体の参加者は30-50名ってとこだったかな。招待講演のClojure の話が非常におもしろかった。正しいデザインに見える。

(追記2008/07/09 21:52:15 PDT): 公共交通機関が不便だし、タクシーも高いしで車を 借りているのだが (英国風? に"car hire" という)、日本と同じ右ハンドル、 左側通行のせいか、日本車がたくさん走っている。 それも、車内の説明書きが日本語のままなので、日本の(たぶん中古車を)そのまま 持ってきてるっぽい。 で、カーナビがついていたので電源を入れてみたら、入っていたディスクが日本の ものだった。現在地を表示させようとしたら「地図の範囲外です」ってそりゃそうだな。 一体どうしろと?

(2008/07/04 05:11:29 PDT)

明日、というかもう今日の早朝に出発しないとならんのだが Linux/X60sの外部モニタ出力が出ない件ではまってた。 (3月のPPLとGoogle talkで問題に気づいてたのにぎりぎりまで 対応しないのがいかんのだが)。

こちらの方法で成功: http://www.thinkwiki.org/wiki/Xorg_RandR_1.2

ただ、うちにあるモニタのうちひとつはつなぐと一瞬写ってすぐ ブランクになってしまう (no signalではない)。 カンファレンス会場のプロジェクタではまる危険があるので またWindows側でも使えるような予備のスライドを作っとかないとなあ。

ヨーロッパ用のACプラグ変換器を買おうと思ったんだが Ala Moanaではどこも売り切れだった。Independence Dayの休暇前に みんな買っちゃったんだろうか。LAの乗り換えで少し時間があるので LAXの近くのFry'sに寄ればいいや…って思って気楽に構えてたんだけど 今気づいたんだが明日はIndependence Dayじゃん。Fry's休みかな。 まあHeathrowでもストップオーバーがあるからどっかで買えるだろう。 (ちなみにユーロのキャッシュをちょっと買ってこうとおもったら こちらも行きつけの銀行では売り切れでちょっと彷徨ってしまった。 普通は注文しないとだめらしい。やっぱり田舎なんだなあ。 ユーロのT/Cなんてものも扱ってないし。)

(追記2008/07/04 17:57:07 PDT: LAXのターミナルで買えた。)

(2008/07/02 12:36:56 PDT)

らむ太語録

なぜ今の時期にクリスマスかというと、らむ太は映画"The Polar Express"が 大好きで以前何度も観ていたために内容をすっかり覚えてしまい、 今でも気が向くとストーリーをアクションつきで説明してくれるのだ。

(2008/07/01 03:37:10 PDT クランクアップ)

怒涛のような16日間の撮影終了。まだ細かい場面のピックアップは あるかもしれないけれど。

主役じゃないので現場に行ったのは半分位だったけど、 それでも体力は相当使う。低予算なので一日にたくさんシーンをこなすからなおさらだ。 芝居での仕込みと本番がいっぺんに来る感じ。 ワークアウト始めといて良かった。3ヶ月前の体力では到底のり切れなかっただろう。

「脚本の順番と撮影の順番が完全にバラバラ」というのも 本格的な経験としては今回が初めてだった。 芝居だけやっていた時は、いったいどうしたらそんなことが可能なんだろう と不思議に思っていたが、これについては昨秋にとった"Acting for the Camera" のクラスでやったことが大いに役立った。おおまかにまとめると、 脚本分析によって各シーンの役割を理解しておくことと、 そのシーンの撮影開始前までに、テンションと感情を必要な状態にしておくこと、 だろうか。芝居が2時間のマラソンなら、撮影は短距離走って感じもする。

ただ、実際にシーンをやってみた後でわかってくることというのが あって、その後のシーンの解釈を微妙に変えたくてもそれが既に 撮り終わっていたりすると悔しい。 準備段階ですべてわかっているべきなんだろうか。


Last modified : 2009/01/10 02:53:54 UTC