2005/02/26

昨年、ある脳生理学者が、Lispハッカーがハッキングに没頭している時の 脳波を計測した。すると「人間らしさ」を司る前頭前野において、α波が 優位になりβ波が低下したという。

α波はリラックスしている時に見られる脳波と言われる。「たくさんの 開き括弧と閉じ括弧が、寄せては返す波のリズムのように作用し、脳に 影響をあたえているのではないか」と研究を行ったエム博士は述べている。

エム博士はインタビューでさらに衝撃的な理論を明らかにした。 「この波形は痴呆症の患者のものとよく似ている」というのだ。 「Lispは専門家の間ではとても危険な言語として知られています。 JavaやC++といった正統的な言語では、プログラマはよく考えてから プログラムを書かないと、実行する以前にコンパイルエラーになってしまいます。 しかし、Lispにはそのような規律が全くありません。でたらめなコードでも 実行できてしまい、エラーが起きてもそこで適当に数値を書き換えて実行を続ける ことができてしまうのです。こんな言語を使っているプログラマは ものを考えなくなり、適当に式を打ち込んで、動けば良いという習慣が ついてしまいます。」

エム博士は続けた。「考えることを止めたルーズなLispプログラマは、やがてコンピュータに 合わせてプログラムを書くのではなく、あたかも自分がコンピュータを 操っているかのような全能感に囚われます。自分が一番であるというこの 全能感のために、Lispプログラマは他の言語を使うプログラマを馬鹿にし始める のです。」博士はそのようなプログラマの脳は「Lisp脳」になっているのだと言う。 「この感覚は麻薬のようなものです。一度溺れてしまうと、 そこから抜け出すのは容易ではありません。」 Lisp脳の症状としては、「他の言語を馬鹿にする」の他にも、 「定められた勤務時間を無視する」、「見積りを出す前にプログラムを書き上げてしまう」、 「会議でじっと上司の話を聞いていることができない」、 等があるという。

Lispの一種であるSchemeというプログラミング言語は、プログラミングの入門 教育で使われることがある。そのことにインタビュアーが触れると博士は激昂した。 「それは殺人教育です。 アメリカでは軍事予算でLispの研究をやっている。 日本でも最近はゆとり教育だの何だのと言って子供に好きなようにやらせている。 もともと日本には、芸事はまず形から入るという文化があった。 師匠の真似をして、一通り形ができるようになって、それから心がわかるのです。 まずは紙の上で、誤りが一切無いプログラムを書けるようになるまで 修行すべきです。私が学生の頃は皆そうやっていた。」

また最近の研究では、Lispプログラマの能力と、高機能自閉症の一種である アスペルガー症候群との間に関連が見られるという。 「Lispで自閉症になるんです」 エム博士はこう断言する。 「コンピュータを自由自在に操れる全能感に溺れ、自分の殻の中に閉じこもるのです。」 博士は一枚の紙を取り出した。「典型的なLispプログラムの見かけはこのようなものです。」

((((;ﾟДﾟ)))

「ほら、冷汗をかいて震えている人間のように見えませんか。これはLispプログラマの 対人恐怖という潜在意識がプログラムコードの上に滲み出ているからなのです。」

---- 『Lisp脳の恐怖』出版記念インタビュー記事より抜粋

Tag: Lisp

2005/01/25

What you'll wish you'd knownはこれまで訳したPaulのエッセイの中で公開後3日間の最多ヒットを記録した。 リファラをたどって感想を読んでいると、色々な見方があって参考になる。 無理矢理分類すると次の3つが主流っぽい。

• 後悔 (俺も高校生の時に知っておきたかったよ)
• 元気が出る (俺の方向は間違ってなかった / 今からだって始められる)
• ふーん

現役高校生と思しきblogで「ふーん」が散見されたのは、良いことだと思う。 自分も、高校の時に聞いていたらそんなに熱くならずに、「まあそりゃもっともだねぇ」と 思っていただろう。ただ、それが正しいということを経験を以って支持してくれる 人がいる、ということを知るのは、悪くない。

たぶんあの頃の年代は、上の世代からハッパをかけられると、 それが正しくても何か素直に従いたくないものがあるんだと思う。 自分でやりたいから、先回りされてやることを言われるのが面白くないのだ。 背中を押されるよりも、それで良い、という確認の方が素直に受け取れるんだろう。 (「あまり苦労をかけさせるなよ」と笑いながら、「やりたいならおやんなさい」 と言ってくれた劇部の顧問の先生を思い出す。)

Tag: PaulGraham

2005/01/23

半年くらい前に Paulの反オブジェクト指向のメモを 翻訳していたのを 公開するのをすっかり忘れてた。 Jonathan Reesのメッセージの方の 公開をちょっと待つ事情があって、待ってるうちに忘却の彼方に 消えてしまっていたのだった。

Tags: PaulGraham, 翻訳

2005/01/22

Paul Grahamのエッセイの新作が出てた。ひさしぶりに熱い内容だったので 一気に訳してしまった。

自分の高校時代を振り返ってみると、たぶん半分くらいは、 いや3/4くらいは、本当に好きなことをやっていたと思う(その大半は 演劇部だった)。でもどこかでブレーキをかけていたところがあった (「こんなに忙しくて大変だ」って思ってたからね。その時の自分に 数年後のスケジュールを教えたらどう思ってただろう)。 Paulがいうように、高校でできることの大部分はそれ以降の本物の仕事に比べたら 誤差くらいのものなんだから、遠慮無しにやってれば良かった。 今、時を遡ってあの時の自分に会えるなら、絶対後悔しないから もっとやれ、とハッパをかけるだろう。

でも、人生の到達点はそれまでの積分なんだから、同じアドバイスが どの時点でも有効なはずだ。やりたいことはたくさんある。それなら、 絶対後悔しないから、貪欲に、遠慮せずにやればいい。

Tags: PaulGraham, 翻訳

2005/01/17

yomoyomoさんとこより、 メンテナンス可能なコードの書き方、およびその関連で Great Programmers。 良いコードとは、つまるところ適切なカプセル化とユニットテストにある、という 主張には基本的に同意。

ただ、「カプセル化 encapsulation」はオブジェクト指向界隈で「実装の隠蔽」 の意味で使われることが多いような気がする (例) ので個人的には避けたい用語だ。本当に重要なのは、(a)あるコードの変更が 影響を及ぼす範囲が容易に確定できること、(b)あるコードの意味に影響を 与える範囲が容易に確定できること (両者は同じことの表と裏だが、実際に コードをいじっている時には両方を考慮している)、であるはずだ。 私はこれをモジュラリティと呼んでいる。

実装の隠蔽はモジュラリティを実現する一つのツールだが、必要でも十分でもない。 実装を完全に隠蔽してもモジュラリティの低いコードはいくらでも書けるし、

実装を隠蔽しないでもモジュラリティの高いコードは書ける。うっかりミスを 防ぐ意味では有用かもしれない、という程度だと思う。 しかも、本当に厄介なバグは実装の隠蔽だけでは防げないような種類のものだ。

モジュラリティにとってより重要なのは、状態の管理だ。 何かが状態を持ち、そのふるまいが状態によって変化する場合、 あるコードの意味はそのコードの静的なスコープだけでなく、 対象となるものの状態にも依存する。静的に確定できるスコープの 外でそのものの状態が勝手に変えられてしまうと、もはやコードの 見た目を信頼することができない。

実装の隠蔽によって状態をさわれる箇所を限定することでこの問題は ある程度軽減できるが、それは対症療法にすぎない。例えばpublicな getterとsetterを用意してインスタンス変数を隠蔽することは この問題に対してほとんど何の解決にもなっていない。 もう少しソフィスティケートされたAPIを用意したとしても、 実装者の想定した方法以外でオブジェクトの状態を変えるパスがどこかに 存在する限り、問題は残る。

本当の問題は、状態を持つことそのものにある。ただ、現実の世界が ステートフルである以上、そことつき合うプログラムもまた状態を 持たざるを得ない。状態という猛獣をいかに飼い慣らすかという視点で 設計を行うべきだろう。実装の隠蔽も、状態を常に実装者の想定に 従うように管理するという目的で使われる場合には、有用だ。 もっとも、状態遷移が明示的にAPIの一部になっていることの方が重要で、 カプセル化はその安全ネットを提供するにすぎないと思うが。

形式的に状態を制御して扱えるようにするには、現実的には 静的型が必須のように思える。(Schemeでモナドを書いても Haskellのように綺麗にならない。) ただ、そこまでやらなくても いくつかのアドホックなテクニックを使うことで、 かなり安全に状態を制御することはできるだろう。

Tag: Programming