ハッカーと画家読書ノート ¶

ある米国人プログラマーの随想集。

著者:: Paul Graham
訳者:: 川合史朗
出版社:: オーム社
発行年:: 2005 年
ISBN:: 978-4-274-06597-2

目次以前のローマ数字ページ ¶

扉ページの絵画はブリューゲル筆バベルの塔？
<過去 30 年ほどの間に裕福になった人々の多くがプログラマであった、ということに気づいただろうか>
<本書は見かけの無秩序の下にある秩序について述べたものだ>

第 0 章 ¶

アメリカのプロヴィデンスってどのへん？辞書を引いたら北米東海岸ってあった。
<そして私が思うに、米国人が作るのが得意なものが得意である理由と、苦手なものが苦手である理由とは、同じなんだ> (p. 1) 著者はアメリカ人だ。
<コードは、ピラミッドみたいに、慎重な計画をしてから苦労して組み立てていくものじゃない> (p. 1)
<だが車に関しては、むしろ彼ら（引用者註：日本人）の文化に、デザインと職人の仕事を尊ぶところがあることが重要なのだと思われる> (p. 3)
著者は日本人を <ものをうまく作ることに取り憑かれているんだ> (p. 3) と評する。
<アップルは元気づけられる例だ。ソフトウェアを書くのに必要な、短気でハッカー的な精神を十分残していながら、アップルのノート PC を手にすると、それは米国的には感じられない。米国製にしてはうまくでき過ぎている。まるでスウェーデンか日本の企業が作ったみたいに> (p. 5)

第 1 章 ¶

訳注によると、訳文中の「オタク」が原文では nerd(s) であるとか。訳者はしっくりこないのを承知で「オタク」と訳したようだ。

<学校のランチテーブルを人気の度合いで区分けした地図> (p. 7)
<オタクであることと人気者であることの間にはもっと強い負の相関がある> (p. 7)
<例えばティーンの子供は服装にものすごく気を遣う。（略）ただ格好良くしていたいだけだ。でもそれは誰にとってだ？> (p. 9)

第 2 章ハッカーと画家 ¶

本章のタイトルが本書のタイトルになった。

<実際、私が知っているあらゆる種類の人々のうちで、ハッカーと画家が一番よく似ている。（略）どちらもものを創る人間であるということだ。（略）良いものを創るということだ> (p. 23)
<計算機科学とは、ほとんど関連のない分野が歴史的な偶然からいっしょくたに袋に放り込まれたもので、言ってみればユーゴスラビアみたいなものだ> (p. 23) ユーゴときたか。
<アイディアの最高の源は（略）ものを創る人々が住んでいる他の分野にあるということに気付いた> (p. 26)
<静的型付けの話が出たついでに> (p. 27) とあるが、そんな話は出ていないような。
<プログラマは、プロダクトマネージャのビジョンとかいったものをコードへと翻訳する技師と見なされていたのだ> (p. 28)
<大企業はすごい製品を作ることで勝つのではなく、他の企業よりも下手を打たないことで勝つからだ> (p. 28)
<マイクロソフトの最初の製品> (p. 29) とは何だ。
<画家は作品を足跡として残してゆくから、彼らが絵を描きながら学んでゆく様子をうかがい知ることができる。画家の作品を年代順に並べてみれば、それぞれの絵はその前の絵で学んだことの上に創られていることが分かるだろう。絵画上でうまくいったものがある時、通常はそれより前の作品群の中に、より小さな形でのバージョン 1 を見て取ることができる> (p. 30) 最後の一文が秀逸だ。
<ハッカーは最初から独自の仕事をする> (p. 30)
<プログラムの仕様に完璧さを期待するなんて非現実的だ。そのことをまず認めて、仕様がプログラムを書いている最中に変わっていっても、それを受け入れられるような書き方をするべきなんだ> (p. 31)
さすが「ハッカーと画家」という題を付けるだけのことはある。ダ・ヴィンチ作の肖像画を引用 (p. 32) して、細部の作り込みの重要性を訴え、 <良いソフトウェアの中身を見てみれば、誰も見ないような箇所でさえ美しく創られていることが分かるだろう> (p. 33) と、主張する。
<協調ということをあまり強く押し出しすぎないことだ> (p. 34)
<名声は大きく遅れてくるのが常だ> (p. 37)

第 3 章 ¶

<道徳にも流行がある> (p. 39) この本は名言がボロボロ出てくる。
<何が良くて何が駄目かと判断されるかは、社会によって大いに異なっている。だから自分の文化のアイディアと他の文化のそれとの diff を取ってみてもよいだろう（それをする最良の方法はそういう文化を訪ねてみることだ）> (p. 44) この表現はいかにも著者流ハッカーのそれだ。
<コペルニクス自身は弾圧されなかったのに> (p. 46)
<汚物愛好者> (p. 46) ―きれいな君の汚物。
<自分で自分をクールだと思っている人々は、並の集団から自分を区別したいのだ> (p. 47)
<「それは真か偽か」と問うてみればいいんだ> (p. 49)
<私が知っている、偉大な仕事をなした人は、自分はダメだが、他のみんなはもっとダメだ、と考えている> (p. 49)なんとなく賛同できる。
<デカルトはフランス人であると言われるが、多くの思索をオランダで行った> (p. 53)

第 4 章 ¶

<いくつかの会社が著作権を、コピーを防ぐ機構として使っている> (p. 56)
<プログラミングというものは正確で厳密なものだと思われているようだが、それは違う。正確で厳密なのはコンピュータのほうだ> (p. 59)
<コンピュータの世界では、最も賢い解というのは悪ふざけと紙一重であることがよくある> (p. 59)

第 5 章 ¶

この章は分量が多い。じっくり読もう。

Web ベースのソフトは、
- <キーボードと画面と Web ブラウザがついた何かがあればいい> (p. 62)「何か」という言いまわしに重点がある。
- <クライアント上には置かれない。だからそれを使うのにインストールする必要もない> (p. 64)
- <それは単一のバイナリではなく、むしろ違ったタイプのプログラムの集合になるだろう> (p. 65)
- リリースについては <段階的な変更の連続になる> (p. 67) と指摘。頻度も違う。
- <バージョンという考え方は Web ベースソフトウェアには馴染まない> (p. 69)
- <とても安価に始められる> (p. 90)
<「私のコンピュータ」という概念はそっくり「私のデータ」に取って代わられるだろう> (p. 63) 著者の読みは外れていない。
小さな変更だけで次々にリリースするやり方を、<床は常にきれいに掃かれていて、後で邪魔になりそうなものはきちんと片付けられている> (p. 70) と喩えている。
関数型プログラミング言語の関数は <状態を持たないから、独立してテストするのが簡単だ> (p. 71) そうだ。
<それをどうやるかが分かった時点では、もうその実装が終わっている状態だった> (p. 73)
『人月の神話』で指摘されている、「プロジェクトへの人員増加で、進捗がかえって遅れる法則」の裏をかく。<グループが小さくなればなるほど、ソフトウェアの開発効率は指数的に増大する> (p. 75)
<だって Web ベースアプリケーションを負かすには、ブラウザというモデルを壊さないとならないからね> (p. 89)

第 6 章 ¶

この章は「富」という単語が頻繁に出てくる。

<良い投手になるのに物理学を知る必要はない> (p. 93) が、著者は基礎となる原理を理解しておくことは有利だろうと考えている。
<ベンチャー企業のほとんどが（略）新薬やコンピュータソフトウェアを売っているのはなぜなんだろう> (p. 93)
通常の一生分の労働時間を数年間に圧縮する働き方はベンチャーで有利。 <技術の分野では早い仕事に価値がある> (p. 93) から。
成功するにはハードな努力だけではなく <恐ろしいほどの幸運> (p. 95) も必要。
<富とは、私たちが欲しがるもの> (p. 96) 単純に <人々が貨幣と交換したがるもの> (p. 97) と定義して議論を進めていく。
<子供は、自覚こそしていないが、自分が富を作り出せることを知っている> (p. 98) のパラグラフが実に面白い。
<プログラマは文字通り、製品を頭の中から一行一行紡ぎ出すんだ> (p. 99)
<就職するということが、まるでもうひとつの組織に所属することのように> (p. 100) うんぬんの意味がわからない。
<人々が欲することを始めることが必要なんだ> (p. 101)
<会社はあなたの仕事の価値を測る手段を持っていない> (p. 102) ということで <自分の生産性が測れる地位に就かなければならない。でないと頑張っただけ支払ってもらえないからだ> (p. 103)
<全員で平均を取るより少数精鋭で平均をとったほうがいいに決まっている> (p. 104)
大企業は技術を素早く開発することができない。(p. 106)
<一人の発明者がはっきりしている技術はほとんどない> (p. 107)
<ドッグフードのポータル> (p. 108) では生き残れない。
<どこをどうしたら速くなるかを推測に頼っているときは、その推測はまず確実に間違っている> (p. 110) 最適化問題については、どの本の著者も同じことをいうようだ。

第 7 章 ¶

<富める国と貧しい国に旅行に行ったら、人々の銀行残高をわざわざ調べないでも、どちらの国にいるのかを見て取ることができるだろう> (p. 116)
<一番富を話題にしたがる人々（略）が、富を創り出すことに関して一番経験を持たない人々だから> (p. 116)
<エドワード朝の子供たち> (p. 117)
技能や覚悟が <一人の人間の中に凝縮されているということ> (p. 118) が一流の人々の本質。
<私自身、技術の梃子が伸びていくのを自分の目で目撃した> (p. 122)
<残りはやっぱりアイスクリームを売っているだろう> (p. 122)
タイムマシンの例が面白い。<1800 年には、蓋付きの空のペットボトルは職人の奇跡のように思われていただろう> (p. 123) ペットボトル本体ではなく、蓋の部分に注目するのがさすが。
<避けたいのは絶対的な貧困であって、相対的な貧困じゃない> (p. 126)

第 8 章スパムへの対策 ¶

脚注によると <このエッセイに関しては、Lisp コードを数学式に置き換える以外に、書き換えを行っていない。したがって、ここに書かれたいくつかの事実は既に正しくなくなっている> (p. 127) そうなので、フィルタリングアルゴリズムの詳細に興味がわいたら、著者のサイトで確認したほうがいいみたい。

第 9 章 ¶

美学とか審美とか、そういう話題。

<ひとつの分野での美に関する知見を他の分野でも使えないだろうか> (p. 137)
<単純でなければならないと強制されれば、本物の問題を向き合わなければならなくなる> (p. 138)
<ずっと未来にも良く見えるものを作れたとすれば、それはそのものの真価が受け入れられたわけで、流行に乗ったからではない> (p. 138)
<ソフトウェアにおいては、ユーザが自分の思う通りにまるでレゴのように組み合わせることができる、少数の基本要素を提供すべきだ> (p. 141)
<再帰とは、葉脈の模様のような、部分構造への繰り返しと言ってもよい> (p. 144) しゃべりで再帰を説明する場面になったら、これを拝借しよう。
<オープンソースソフトウェアはバグの可能性を認めているがゆえにバグが少ない> (p. 146)
<15 世紀、フィレンツェには何かが起こっていたのだ> (p. 149)

第 10 章 ¶

<何かをするための命令が多くなればなるほど、バグを見つけるのは難しくなる> (p.152)
機械語でプログラムを書くと他のコンピュータでそれを動作させることが原則できないが、<高級言語を使っていれば、コンパイラだけを書き直せば済む> (p. 153)
<オープンソースソフトウェアは、専門家同士で審査される論文のようなものだ> (p. 154)
<機械語はだいたいどれも似たような命令しか持っていないが、これらの高級言語は、プログラムを構成するための概念として非常に異なるものをそれぞれ提供している> (p. 154)
<ハッカーの一部は、自分の慣れた言語を好み、ほかのすべてを嫌う。他のハッカーの一部は、すべての言語は同じだと言う。真実はこの両極端のどこかにある> (p. 155)

第 11 章 ¶

<COBOL は（略）ネアンデルタール言語なんだ> (p. 161) 進化が行き止まる。
<どんな時点でも、進化樹の主要な枝にいることは一番幸せなことだろう> (p. 162)
<100 年後には私たちはプログラムなんてしているんだろうか。してほしいことと言うだけでコンピュータがやってくれるようにならないんだろうか> (p. 163)
<プログラミング言語の進化の速度というのは、移動手段や通信手段よりは、数学表記の進化に近いだろう> (p. 163) 著者は言語が飛躍的に進化するとは考えていない。
<技術が進むにつれ、各世代はその前の世代だったらもったいないと思っていたようなことを平気でできるようになる> (p. 164)
<多くのデータ構造は速度のために存在する> (p. 165)
「エッセイ」という単語はフランス語の「試す」という単語から来ている。(p. 166)
<本当の非効率性とは、マシンの時間を無駄にすることではなく、プログラマの時間を無駄にすることだ> (p. 166)

第 12 章 ¶

エリック・レイモンドの「ハッカーになろう」はどこで読める？
- Python と Java なら、習得するのはどちらか一方でいい感じがする。
- Lisp を勉強するのは <それをものにした時の素晴らしい悟りの体験のために> (p. 174) だと。
<もし、他の誰もが使っているからという理由で技術を選ぶなら、 Windows を走らせておけばいいのさ> (p. 174)
<ビジネスでは、驚きは軍隊ほどに価値がある> (p. 177)
チューリング等価に関する p. 178 脚注の文章。読み返しても理解できない。
<ある年齢に達すると、プログラマは自分から使う言語を変えることはほとんどなくなる。どの言語を使っていようと、これで十分だと思ってしまうのだ> (p. 179) この「ある年齢」は全員で同じ値なのか、興味がある。
Basic には再帰がない。(p. 180)
<この記事の目的は（略）既に Lisp に興味を持っている人の後押しをしようということなんだ> (p. 182)
ライバル企業を人材募集記事から見分けるコツ。<一番安全なのは Oracle の経験者を募集しているところだ。そういうところを警戒する必要は全くない。また、Java や C++ プログラマを募集しているところも安全だ> (p. 183)

第 13 章 ¶

Lisp 信奉者である著者がこの記事で最も言いたいメッセージはこれではなかろうか。 <各言語は次第に Lisp に近づいてきている> (p. 187)
<Lisp は 1958 年にジョン・マッカーシーによって最初に発見された> (p. 187)
<Lisp はプログラミング言語として設計されたんじゃなかった> (p. 187)
<Lisp を比較する対象は 1950 年代のハードウェアではなく、例えばクイックソートのアルゴリズムだ。それは 1960 年に発見され、未だ汎用ソートアルゴリズムとして最速だ> (p. 189)
<Lisp における「マクロ」という用語はほかの言語におけるそれとちょっと違う> (p. 192)
<おそらくプログラミングのほとんどは、既存の部品をつなぎ合わせる小さな糊付けプログラムを書くようなものだ> (p. 193)
<「最先端」と「会計」はあんまり馴染まない> (p. 197)
<人間コンパイラ> (p. 201)

第 14 章 ¶

<未来のプログラミング言語は、言語の核と同じくらい慎重に設計されたライブラリを備えているだろう> (p. 210)
<ライブラリが大きくなり過ぎると、必要な関数を探し回るより自分で書いてしまったほうが早いなんてことが起こる> (p. 210)
<速いコードを得る現実的な方法は（略）非常に良いプロファイラを作ることだ> (p. 211)
<だが現場では、実際のプログラムを改善するには速いコードを生成するコンパイラよりも良いプロファイラのほうが役に立つ> (p. 211)
<律速> (p. 213)
<ユーザーベース> (p. 214)
<デザインのもっとも重要な段階は再デザインである> (p. 215) 本当によいものを作るには、何度も同じことを繰り返さないとダメか。

第 15 章 ¶

<米国人は会話の始めに「どんなお仕事をなさっていますか」と尋ねることがとても多い> (p. 219) この質問をもらうのがうれしいという人がいたら、うらやましい。
<あるユーザの集合を決めるんだ。（略）大事なことは、特定のグループのユーザを対象とすることだ> (p. 220)

第 16 章 ¶

<プログラマ間の差はあまりに大きく、そのため上のほうと下のほうでは別の種類のプログラマと言ってもよいくらいだ> (p. 226) 生産性の差について。
<Java のプロジェクトで働くために雇われるプログラマは、Python を使うプロジェクトで雇えるプログラマほど賢くはないだろう> (p. 227) こういうことを言うから挑発的だとか非難されるのだろう。脚注で <Google は Java プログラミングの求人広告を出す時、賢明にも Python の経験を要求している> と入念におちょくっている。
<大企業は、オフィス空間の機能は地位を示すことだと考えている。だがハッカーにとって、仕事場はそれ以上のものだ。オフィスは、その中で考えるためのものなんだ> (p. 229)
<マイクロソフトは、大企業でありながら社内でソフトウェアが開発できているという点で非常に特殊だ> (p. 229) 他でも静かな空間を重視する技術者がいたな。
<だが Google は検索は退屈なものだとは思わなかった> (p. 230)
<美とは何かを知らずして、美しいものをつくり出すプロセスを管理することはできないんだ> (p. 231)
<マイクロソフトはデータ上の特異点なんだ> (p. 234)
<いつもどこへでも持ち歩いているカードに、彼の人生のすべての面を書き出す、という作業> (p. 235) 何だこれは。
<賢い人はみな、好奇心が強いと私は思っている。好奇心は単に知識の一階微分だからだ> (p. 237)

本の最後の方 ¶

用語解説 ¶

Ada は国策オブジェクト指向言語。
API はライブラリと同義だと思っていいことにしたい。
C++ の設計者の名前のカタカナ表記が絶妙。
JavaScript の説明文がいい。 <Java よりもさまざまな面で優れている。残念ながら、Web サイトで安っぽいトリックを実現するのに多用されたため不当に低く評価されている> (p. 241)
<Lisp の DNA> (p. 242)
オッカムの剃刀 の意味は <2 つの並立する理論のうち、簡単なほうを選ぶべきであるということ> (p. 245)
<文の存在自体が間違いであるという議論もあり> (p. 254)

謝辞 ¶

2 ページに亘って関係者に感謝している。

画像出典 ¶

やっぱり <アルバカーキ警察の厚意により掲載> (p. 259) がインパクトある。

監訳者あとがき ¶

<ポールの文章は 3 つの点で最適化されている。明解な主張、分かりやすい言葉、そして素晴らしいリズムだ。（略）そのような文章を日本語に翻訳するのは、あるアーキテクチャ向けにかりかりに最適化されたプログラムを別のアーキテクチャに移植するようなものだった> (p. 261)