コンテンツにスキップする

「ハッカーと画家」を読んだ

投稿時刻2023年12月12日 15:27

ハッカーと画家」を 2,023 年 12 月 08 日に読んだ。

目次

メモ

はじめに v

身の回りのすべてのものがコンピュータへと変わりつつある。
タイプライターは消え、コンピュータになった。
電話もコンピュータになった。
カメラもそうだ。
テレビもすぐにそうなるだろう。
自家用車に入っているコンピュータは、1970年に一部屋まるまる占めていたメインフレームよりも強力だ。
手紙も百科事典も新聞も、そして身近な小売商店さえも、インターネットで置き換えられようとしている。
だから、今私たちがどこにいてどこへ向かおうとしているのかを理解したかったら、
ハッカーの頭の中で起こっていることを知るのが役に立つ。

p1

奇妙なことだが、これは偶然ではないかもしれない。
米国人には得意なこともあるが、苦手なこともある。
映画やソフトウェアを作るのは得意だけれど、車や都市を作るのは下手くそだ。
そして私が思うに、米国人が作るのが得意なものが得意である理由と、苦手なものが苦手である理由とは、同じなんだ。
米国人は一度何かをしたいと思い立つと、それがうまくできないんじゃないかとか、世間的に角が立つんじゃないかとか、あるいは無謀な試みだと人に思われるんじゃないかとか、そういうことを気にしない。
何かしたくなったら、ナイキのコマーシャルみたいにするんだ。「とにかく、やる」。

p2

矛盾しているように聞こえるかもしれないが、ソフトウェアでは腕の良さは素早い仕事を意味する。
ゆっくりと念入りに仕事をしていると、出来上がるものは当初のアイディアを精密に実現したものになるだろう。
ただし、そのアイディアは間違っているだろうけどね。
遅く念入りな仕事は早すぎる最適化だ。
むしろプロトタイプを素早く作り上げて、それによって新しいアイディアを得てゆくほうがよい。

p5

「とにかくやる」方法と、注意深く進める方法のどちらかを選ばなければならないのだとしたら、私ならとにかくやるほうを選ぶだろう。
でも、本当に選ばなくちゃならないんだろうか。
両方を同時にやることはできないだろうか。
米国人は、ソフトウェアをうまく作れるあの短気で独立心に富む精神を保ったまま、良い住環境を作ることができないんだろうか。
ほかの国で、醜いショッピングモールをはびこらせることなく、技術企業や研究所にもっと個人主義を持ち込むことはできないんだろうか。
私は楽観的だ。
ほかの国について予測するのは難しいが、少なくとも米国では、私たちは両方を得ることが可能だと思う。

p9

ルネッサンス初期を代表する天才アルベルティは、「人生のすべてを賭けずして極められる技などない」と書いている。
米国の学校の生徒が人気を得るために努力するほどに、熱心に頑張っている人間は世界中探してもほかにいないのではないか。
海軍の特殊部隊や神経外科医のインターンだってそれに比べればゆったりしたものだ。
休暇を取ったり趣味を持つことさえできるからね。
米国のティーンは人気を得るために、起きている時間すべて、365日絶え間なく頑張っている。

p11

問題は、子供が自分たちで作る世界は最初はとても残酷な世界だということだ。
11歳の子供たちを好きにさせておいたら、そこにできるのは『蝿の王』の世界だろう。
他の多くの米国人の子供と同じように、私もこの本を学校で読まされた。
もしかするとこれは偶然じゃなかったんじゃないか。
私たちは野蛮人で、自ら残酷で愚かな世界を作り出したんだと誰かが知らせたかったんじゃないか。
この本は私には難しすぎた。
確かにありそうな話だとは思ったが、それ以上のメッセージを得ることはできなかった。
僕らは野蛮人で、僕らの作った世界は馬鹿げている、そう誰かがはっきりと教えてくれたらよかったのに。

p25

残念なことに、美しいものは論文になりやすいとは限らない。
第一に、研究は独創的でなければならない。
そして、博士論文を書いた経験のある人なら誰もが知っているように、確実に処女地を探し当てて開拓する一番良い方法は、誰も向かおうとはしない場所へ向かうことだ。
第二に、研究にはある程度の量的なまとまりが必要だ。
そして、へんてこなシステムであるほど、たくさんの論文が書ける。
そいつを動かすために乗り越えなければならなかったいろんな障害について書けるからね。
論文の数を増やす最良の方法は、間違った仮定から出発することだ。
人工知能の研究の多くがこれに当てはまる。
知識は抽象概念を引数に取る述語論理式の羅列で表現できる、と仮定して始めれば、それを動かすためにたくさんの論文を書くことになるだろう。
リッキー・リカルドが言ったように、「ルーシー、君はたくさん説明することがあるね」ってなわけだ。

何か美しいものを創るということは、しばしば既にあるものに微妙な改良を加えたり、
既にある考えを少しだけ新しい方法で組み合わせたりすることによってなされる。
この種の仕事を研究論文にするのはとても難しい。

p26

自分の仕事を他人に誤解されるよりも悪いことがある。
それは、あなた自身が自分の仕事を誤解することだ。
アイディアを探すとき、人は関連した分野を見にゆく。
あなたが計算機科学科にいたとしたら、ハッキングは理論計算機科学に対する応用だとか思ってしまうかもしれない。
私は大学院にいたころずっと、もっと理論を知らなくちゃならないという思いが心の底にあって、居心地の悪い思いをしていた。
期末試験から3週間後にはすっかり全部忘れてしまうことを、ずいぶん後ろめたく思ったものだ。

でも私は間違っていたんだ。
ハッカーは、画家が絵の具に関する化学を理解するのと同程度に計算理論を理解していればいい。
時間的および空間的な複雑度の計算法と、パーザを書くときのために、状態機械の概念くらいを知っておけばいいだろう。
画家は絵の具の化学について、そんなことよりもっとずっとたくさんのことを覚えなければならないんだ。

私は、アイディアの最高の源は「コンピュータ」が名前に付いている分野じゃなくて、ものを創る人々が住んでいる他の分野にあるということに気付いた。
絵画は計算理論よりもずっと豊富なアイディアを提供してくれたんだ。
例えば大学で私は、コンピュータに手を触れる前に紙の上でプログラムを完全に理解しなければならないと教わった。
でも私はそういうふうにはプログラムできなかった。
私が好んだやり方は、紙の前ではなく、コンピュータの前に座ってプログラミングすることだった。
しかも、辛抱強くすべてのプログラムを書き上げてから正しいことを確認するなんてことはせずに、めちゃくちゃなコードをおっぴろげて、それを次第に形にしてゆくのだった。
デバッグとは書き間違いや見逃しを捕まえる最終段階の工程だと教わったけれど、実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。

そのことで私はずいぶんと長い間、引け目を感じていた。
ちょうど小学校で教わった鉛筆の持ち方と違う持ち方をしていることに引け目を感じていたのと同じように。
他のものを創る人々、画家や建築家がどうやっているかを見れば、
私は自分のやっていることにちゃんと名前が付いていると気付いていただろう。
スケッチだ。
私の知る限り、私が大学で教わったプログラミングのやり方は全部間違っていた。
作家や画家や建築家が創りながら作品を理解してゆくのと同じで、プログラマはプログラムを書きながら理解してゆくべきなんだ。

これを知ることは、ソフトウェアの設計に大きな意味を持つ。
まず、プログラミング言語は何よりも柔軟でなければならないということが言える。
プログラミング言語はプログラムを考えるためのものであって、既に考えたプログラムを書き下すためのものじゃない。
それはペンではなく鉛筆であるべきなんだ。
静的型付けは、私が大学で教わったようにプログラムするなら良い考えだと思う。
でも私の知るハッカーたちはそんなふうにはプログラムしない。
私たちに必要なのは、落書きしたりぼかしたり塗りつぶしたりできる言語であって、
型の紅茶茶碗を膝に置いて、落とさないようバランスをとりながら、
作法にうるさいコンパイラおばさんとお上品な会話をするような言語じゃない。

静的型付けの話が出たついでにもうひとつ、科学が抱えている問題で、もの創りの人々ならば避け得るものを挙げておこう。
数学に対する羨望だ。
科学にかかわる人は誰しも、数学者は自分より聡明だという思いを密かに抱いている。
そして、数学者たちもそう信じているんじゃないだろうか。
結果として科学者 たちは、程度の差こそあれ、自分の仕事をなるべく数学っぽく見せようとしが ちだ。
物理学のような分野ではこのことはあまり悪影響を及ぼさないだろう。
しかし自然科学から離れれば離れるほど、これはより大きな問題となってくる。

数式で埋め尽くされたページは、それはそれは格好良く見える(もっと格好良くしたいのなら変数にギリシャ文字を使うといい)。
だから、重要な問題よりも形式的に扱える問題のほうに取り組みたいっていう誘惑はとても強い。
ハッカーを作家や画家といった他のもの創りと同列に並べて考えるなら、そんな誘惑は感じないだろう。
作家や画家は数学を羨んだりしない。
数学とは全然関係ないことをやっていると思っているだろう。
ハッカーもそう感じるべきだと、私は思う。

p28

デザインで勝負に打って出るべき場所は、誰も要塞を築いていない新しいマーケットだ。
そこでなら、デザインに大胆なアプローチを採り入れ、そして同一人物がデザインと実装を受け持つことで、大きく勝つことができる。
マイクロソフトだって最初はそこから始まったんだ。
アップルもそうだし、ヒューレットパッカードもそうだ。
おそらくどんな成功したベンチャー企業もそうだと思う。

p29

ソフトウェアに関してのこの問題への解答は、実は他のもの創りの人々には既に知られている。
昼間の仕事 (day job) というやつだ。
この言葉はミュージシャンの間で発生した。
彼らは夜に演奏するからだ。
より一般的に言えば、生活費のためにひとつの仕事を、愛のためにもうひとつの仕事をするということだ。

ほとんどすべてのものを創る人たちは、駆け出しのころには昼間の仕事を持っていた。
画家と小説家は特にそうだ。
運が良ければ、本業と関係が深い昼間の仕事を見つけることができるだろう。
ミュージシャンはよくレコード店で働いている。
プログラミング言語やOSをハックしているハッカーは、それらを使う昼間の仕事を見つけることができるかもしれない。

昼間の仕事を持ち、美しいソフトウェアを別の時間に書くということがハッカーへの答えだと言ったが、これは目新しいことでもなんでもない。
オープンソースのハッキングとはそういうものなんだ。
オープンソースのモデルに間違いはあるまい。
なぜならそれは元々、他のもの創りの人々によって実証されたものなんだからね。

p30

多くのもの創りは同じだと思う。
作家と建築家はそうだ。
ハッカーもたぶん、画家と同じように振る舞うのがいいんじゃないかと思う。
ひとつのプロジェクトを何年も続けて、新しいアイディアを新バージョンとして取り込むのではなしに、時々はゼロから始めてみるんだ。

p33

偉大なソフトウェアも、同じように、美に対する熱狂的な没頭を必要とする。
良いソフトウェアの中身を見てみれば、誰も見ないような箇所でさえ美しく創られていることが分かるだろう。
私がコードを書く時には、それと同じ調子で日常生活を送ったら医者から薬を支給されるだろうな、というような調子で書いている。
めちゃくちゃにインデントされたコードとか、ひどい変数名を見ると気が狂いそうになる。

p34

私の知る限り、複数の画家が一枚の絵に取り組む時、決して2人以上が同じ箇所を描くことはない。
親方が主要人物を描き、助手が他の人物と背景を描くというのはよく行われていた。
しかし、ある画家が別の画家の描いた上に描き足すということは決してなかった。
ソフトウェアにおける協調開発でも、これは正しいモデルだと思う。
協調ということをあまり押し出しすぎないことだ。
あるコードが、特定の所有者を決めずに3人も4人もの人間にハックされると、それは共有部屋のようになる。
雑然としていて見捨てられたような雰囲気が漂い、埃が積もってゆく。
私が思うに、協調開発の正しい方法は、プロジェクトをはっきりと定義されたモジュールに分割し、
各モジュールの所有者を決め、そして注意深く、できればプログラミング言語そのものほどに明快に設計されたインタフェースをモジュール間に定めることだ。

p37

さて、ハッキングが絵を描くことや小説を書くことと同じだとして、それは同じくらいクールだろうか。
結局のところ、あなたには1回の人生しか与えられていない。
他のすごいことに人生を使ったほうがいいかもしれないじゃないか。

残念ながら、この問題に答えるのは難しい。
名声は大きく遅れてくるのが常だ。
まるで遠くの星から届く光のように。
絵画は現在では大きな価値があると認められているが、それは500年前に偉大な画家たちが活躍したからだ。
彼らが活躍していた当時は、誰もそれを、今私たちが考えるほど価値あるものだとは思っていなかった。
1465年の人々は、ウルビーノのフェデリーコ・ダ・モンテフェルトロ公が、ピエロ・デッラ・フランチェスカの描いた絵の奇妙な鼻を持つ男として知られる日が来ると聞いたら、ずいぶん変に思ったに違いない。

だから、ハッキングが現在、絵を描くことほどクールには思えないとしても、
絵画の栄光の時代に絵を描くことは今ほどクールに思われていなかったということを気に留めておく必要があるだろう。

いくばくかの自信を持って言えることは、いつか、ハッキングの栄光の時代が来るだろうということだ。
多くの分野で、偉大な仕事は早い時期になされた。
1430年から1500年の間に描かれた絵画はいまだに他の追従を許さない。
シェークスピアは、職業としての芝居が生まれつつある時期に現れ、その表現方法をあまりに深くまで追求したために、
その後の脚本家はすべて、彼の影の中に生きることを強いられてきた。
アルブレヒト・デュラーは版画で、ジェーン・オースティンは小説で同じことをした。

繰り返し繰り返し、同じパターンが見られる。
新しい表現方法が現れ、それに熱狂した人々が、最初の2世代くらいの間にその表現方法の可能性のほとんどを探求し尽くしてしまう。
ハッキングはまさにその段階にある。

レオナルド・ダ・ヴィンチの時代には、絵画はそれほどクールではなかったが、
彼の作品のおかげで後世ずっと重要視されるようになった。
ハッキングがどれだけクールになるかは、私たちがこの新しい表現方法で何ができるかにかかっているんだ。

p61

1995年夏、私は友人のロバート・モリスと共にベンチャー企業を立ち上げる決心をした。
株式公開を目前にしたネットスケープのPRキャンペーンが大々的に展開され、「オンラインコマース」という言葉が報道でもてはやされていた頃のことだ。
当時、Web上で運営されていたオンラインストアの数は30やそこらだっただろうか、そのどれもが手作りだった。
オンラインストアの数が大きく増えていくとしたら、サイトを構築するソフトウェアが必要とされるだろう、私たちはそう読んで開発に乗り出した。

最初は普通のデスクトップアプリケーションを作るつもりだったが、1、2週間ほど経ったある日、ひらめいた。
Webサーバ上でソフトウェアを走らせたらどうだろう?
Webブラウザをインタフェースとして使えばいいのでは?
Webで動くようにコードを書き直してみて、これが進むべき方向だとはっきりした。
ユーザにとっても私たちにとってもすべてが簡単になるからだ。

開発は成功裏に終わり、今、このソフトウェアは押しも押されもせぬ人気オンラインストアビルダーとなっている。
ユーザ数2万を超えるYahoo! Storeがそれだ。

p73

ソフトウェアを直ちにリリースできるということは大きな励みになった。
出勤する途中でソフトウェアに加えたい変更を考えて、その日のうちに実装してしまうことがよくあった。
大きな機能でもこれはうまくいった。
書くのに2週間かかるようなものでさえ (それ以上かかるプロジェクトなんてほとんどなかったが) 、出来上がったら直ちにその効果を見られると知っていたからだ。

効果を見るのに1年後のリリースを待たねばならなかったとしたら、これらのアイディアの多くを、少なくともしばらくの間はどこかにしまっていたことだろう。
でも、アイディアが大事なのは、それがもっと多くのアイディアに結び付くからだ。
腰を据えて何かを書き始めて、書き上がってみたらその中のアイディアの半分は書きながら思いついたことだった、っていう経験はないかい?
ソフトウェアにもそういうことがある。
ひとつのアイディアを実装してゆく過程で、もっとたくさんのアイディアがひらめくんだ。
だから、アイディアをしまっておくことは、ただ単にそれの実装が遅れるだけでなく、それを実装することで得られたであろうすべてのアイディアを失うことになる。
実際、アイディアを寝かせておくことは、新しいアイディアを得る邪魔にさえなり得る。
新しい機能を考え始めるたびに、やるべきことがたまっている棚が目に入って、「うーん、でも次のリリースまでにやりたいことがもうこんなにあるんだよな」となるからだ。

p81

大企業が余分に支払っている金の多くは、それをその会社に売り込むために使われている
(例えば、国防省がトイレの便座に1000ドル払っているとしよう。
それがそんなに高価なのは、トイレの便座を1000ドルで売るには多大な経費がかかるからだ)。

この原理のおかげでイントラネットソフトウェアは、おそらく悪いアイディアであるにもかかわらず、長く生き残るだろう。
単にそれが高価だというだけで。
この難問に対してできることはほとんどない。
だから、最初に小さな顧客を相手にするのがよいだろう。
残りは後からついてくる。

p90

ビジネスに関しては、2つのことだけを知っておけばいい。
ユーザが気に入るものを作るということと、使った金より多くの収入を得るということだ。
この2つがちゃんとできれば、それだけで多くのベンチャー企業よりも進んでいることになる。
残りはやってゆくうちに分かってくるだろう。

p93

裕福になりたいと思ったらどうすればいい?
一番分の良い方法はおそらく、ベンチャー企業(スタートアップ)を起こすか、それに参加するかだ。
これはここ数百年にわたって、裕福になる信頼性の高い方法である。
「スタートアップ」という言葉が使われるようになったのは1960年代からだが、
その中身は、中世に資本家がスポンサーとなっていた貿易航海で行われていたこととほとんど同じだ。

ベンチャー企業は通常、新しい技術と関連がある。
だから「ハイテクベンチャー」というのは冗長な言い回しとも言える。
ベンチャー企業とは、困難な生的問題に挑戦する小さな企業だ。

p97

社会がより専門化してゆく過程で発明された解法は、交換を2段階にするというものだった。
バイオリンを直接じゃがいもと交換する代わりに、それを例えば銀と交換する。
そしてその銀を必要な他のものとまた交換する。
この中間に使われるもの、交換媒体は、希少で持ち運びができるものなら何でもよい。
歴史的には金属が広く使われてきたが、近年、私たちは実際に物理的には存在しない「ドル」と呼ばれる交換媒体を使うようになった。
それは物理的に存在しないが交換媒体として利用できる。
米国政府がその希少性を保証しているからだ。

交換媒体の利点は、それにより交易が可能になるというものだ。
しかし交易の本当の意味が分かりにくくなるという欠点もある。
人々はビジネスというのはお金を儲けることだと思い始めた。
だが、お金は欲しいものを手に入れるための単なる中間段階、省略記法にすぎない。
ほとんどのビジネスがやっていることは富を生み出すことだ。
人々が欲しがることをやるんだ。

パイの誤り p97

驚くほど多くの人々が、子供のころ持った、世界には限られた富しかないという考えを持ち続けている。
普通の家庭のある時点では、確かに限られたお金しかない。
でもそれは同じことじゃない。

そういう文脈で富が語られるとき、それはよくパイに例えられる。
政治家はよく、「パイを大きくすることはできない」と言う。
ある家族の銀行口座にあるお金とか、政府の年間の税収とかについての話ならば、それは真実だ。
誰かが余計に取ればその分誰かが損をすることになる。

私も子供のころ、もし少数の裕福な人々が全部のお金を取っちゃったら、他の皆には少ししか残されないじゃないかと思ったのを覚えている。
どうも大人になってもこのことを信じている人が多いようだ。
人口のxパーセントがyパーセントの富を所有している、といった議論の背景には、たいていこの誤りがある。
もしあなたがベンチャー企業を立ち上げようとしているなら、自覚の有無にかかわらず、このパイの誤りを証明しようとしていることになる。

人々が間違える理由は、お金による抽象化だ。
お金は富ではない。
富を移動する手段にすぎないんだ。
だから、ある時点(例えば今月の家計)に決まった量のお金しかほかのものと交換するのに使えないからといって、世界中に決まった量の富しかないということにはならない。
富は創り出すことができるんだ。
人類の歴史のどの時点でも、富は生み出されたり、消滅したりして(だが、 トータルとしては創り出されてきた)きた。

職人 p98

富が創り出されるものだということに気付きやすいのは、ものを作るのが上手な人々、職人だ。
職人の手作りの作品は、店で売られるものになる。
だが、工業化が進むにつれ、ものを作る職人はどんどん少なくなってきた。
現存するなかで最も大きいグループのひとつが、コンピュータプログラマだ。

p105

スティーヴ・ジョブズは、ベンチャー企業の成功と失敗は最初の10人の従業貝で決まると言ったことがある。
私もそれに同意する。
もし言い換えられるなら、最初の5人と言ってもいいだろう。
ベンチャー企業をすごい場所にするのは、ただ小さくあるだけじゃなくて、選り抜かれた小さい集団であることだ。
村のような意味で小さい集団でなく、オールスターチームのような集団が必要なんだ。

集団が大きくなればなるほどその平均は人口全体の平均に近づいてゆく。
したがって、他の条件がすべて同じなら、大企業にいる非常に能力の高い人は損をしていることになる。
彼の成果は他のより低い成果に足を引きずられてしまうからだ。
もちろん他の条件はいつも同じではない。
お金を儲けることに関心がない人だっているし、大企業の安定性を重視する人だっている。
だが、お金に関心があり、かつ能力のある人は、同じような仲間との小さな集団で働くほうがよいだろう。

p111

常に注目しておかねばならないことは、富とは人々が欲するものであるという基本原理だ。
富を作り出すことで裕福になろうとしているなら、人々が欲するものは何かを知っていなければならない。
顧客を幸せにすることに本当に注意を払っているビジネスはほとんど存在しない。
内心びくびくしながら、店に入ったり、会社に電話をかけたりすることは多いだろう。
電話で「あなたの電話は私たちにとって重要です。どうかしばらくお待ちください」という録音されたアナウンスを聞いて、うん、いいぞ、これで大丈夫だ、なんて思うかい?

レストランは、たまには焦げた料理を出しても何とかやっていける。
でも技術の分野では、ひとつの料理を皆が食べるんだ。
人々が欲するものとあなたが作るものとのギャップは、何倍にも拡大される。
顧客全員を喜ばせるか、煩わせるかだ。
顧客が欲しがるものに近づけば近づくほど、生み出せる富は大きくなる。

富の父親モデル p116

5歳の頃の私は、電気はコンセントで作られているものだと思っていた。
電気を生み出している発電所がどこかにあるなんて思いもつかなったんだ。
同じようにたいていの子供は、富が生み出されなければならないものだということに気付かない。
富とは、親から流れ出してくるもののように思っているようだ。

こういう経験のために、子供は富について誤解しがちだ。
富を貨幣と混同してしまうのだ。
つまり、世の中にはそれが決まった量しかないと思ってしまう。
さらに、それは何らかの権威によって分配されていて(したがって等しく分配されなければならず)、
創り出さなければならない(しかも、偏って創り出されるかもしれない)ものとは考えないんだ。

実際には、富は貨幣ではない。
貨幣は、富の一形態を別の形態と交換するための、ひとつの便利な方法にすぎない。
富は、その下にある、私たちが購入する物やサービスのことだ。
富める国と貧しい国に旅行に行ったら、人々の銀行残高をわざわざ調べないでも、どちらの国にいるのかを見て取ることができるだろう。
富を目にすることができるはずだ。
建物や街路、衣服や人々の健康状態なんかにね。

これらの富はどこから来るのだろう?
人々が創り出すんだ。
ほとんどの人々が農業に従事していて、必要なさまざまのものを自分たちの手で創り出していた時代には、このことはもっと分かりやすかった。
家や倉や家畜の群に、それぞれの家族が創り出した富を見て取ることができただろう。
世界の富はパイの切れ端のように決まった量を皆で分けるのではないということもまた、明白だったはずだ。
もっと富が欲しければ、創ることができた。

このことは現在でも真実だが、多少の家庭内の作業を除いては、私たちが自分自身で富を直接創り出すことはほとんどなくなった。
多くの人々は、他の人々のために富を創り、それと交換に貨幣を受け取り、次にそれを自分が欲しい富の形態と交換するのだ。

p121

中産階級の台頭により、富はゼロサムゲームではなくなった。
ジョブズとウォズニアックは、自分が裕福になるために残りの人々を貧しくする必要はなかった。
むしろ逆なんだ。
彼らは、私たちの生活を物質的により豊かにするものを創り出したんだ。
彼らがそうしなかったら、私たちは彼らにお金を支払いはしなかっただろう。

しかし、世界の歴史のほとんどの部分で、富への道が盗むことであったという事実から、私たちは裕福な人々につい疑いの目を向けてしまう。
理想に満ちた学生が過去の著名な作家の本を読んでいて、自分が無意識に信じていた、子供の富のモデルを承認する記述を目にすることがある。
「間違い」と「時代遅れ」の不幸な出会いだ。

p123

ブランドは唯一、技術で安価にできないものだ。
現在、ブランドのことをしょっちゅう耳にするようになったのはそのせいだ。
裕福な者と貧しい者の物質的な差が消滅して、ブランドだけが残されているんだ。
でも自分の物にどんなラベルが付いているかなんて、それを持つことと持たないこととの差に比べれば取るに足らないことじゃないか。

1900年には、自分で馬車を持っていたら、誰もそれが何年式でどこのブランドかなんて尋ねなかったろう。
それを持ってさえいれば裕福だったんだ。
裕福でなければ、乗り合い馬車に乗るか、てくてく歩くしかなかった。
現代では、最も貧しい米国人でも車に乗っている。
広告をさんざん見せられたせいで、特に高価な車を見分けることができるから、差を感じているだけなんだ。

p124

それに金持ちの時間の使い方だって、他のみんなと似たようなものだ。
ウッドハウスが書くジーヴスとバーティのバーティ・ウースターのような生活は、もう過去のものだ。
現代では、働かないでもよいくらい裕福な人の多くは、やっぱり働いている。
社会的にそうしないと格好がつかないというだけでなく、何もしないでいるのは寂しいし、つまらないからだ。

p125

ここで、別の考え方を提唱してみたい。
現代社会では、収入の格差はむしろ健全性のしるしであるというものだ。
技術は生産性の格差を線形以上の比率で拡大する。
もし収入がそれと同じ比率で拡大しないのなら、そこには3つばかりの説明が考えられる。
(a) 技術革新が止まってしまったか、(b) 富を創れる人々が富を創っていないか、(c) 富を創り出している人々がその富に対する対価を得ていないか、だ。

(a) と (b) の理由については、悪いことだと言ってしまってよいだろう。
反対するなら、800年のフランク王国の貴族と同じ資源だけを使って1年間生活してみてから、どうだったかを教えてほしい(石器時代と言わなかっただけましだろう?)。

したがって、ますます繁栄しているにもかかわらず収入の格差が増加しない社会があったら、考えられる可能性は (c) しかない。
すなわち、人々は富をたくさん創り出し、しかしその対価を受け取らないという社会だ。
例えば、ジョブズとウォズニアックが一日20時間を費やしてAppleコンピュータを作り出し、
でも税引き後の給料が大企業で9時から5時まで働いている人と同じくらいであるような社会だ。

対価を得ないでも人々は富を創り出すだろうか。
それ自体が楽しいことなら、そうするだろう。
ただでオペレーティングシステムを書いてしまう人だっている。
でも彼らだって、それをインストールし、サポートの電話を受け、顧客がそれを使えるように教えるというところまではやらない。
どんなハイテク企業だって、少なくとも90%の仕事は、後者のあまり面白くない種類のものだ。

p142

良いデザインをするのは難しい。
素晴らしい仕事をした人々を見ると、彼らに共通するのは並外れた努力であることが分かる。
努力しないで美しいものを作ろうなんて、それは時間の無駄というものだ。

困難な問題は多大な努力を要求する。
数学では難しい証明には技巧的な解法が必要で、それはまた興味深いものにもなる。
工学でも同様だ。

山を登る時は、不必要なものは荷物に入れないだろう。
同じように、建築家は難しい建築物や限られた予算を前にすれば、エレガントなデザインを強いられることを悟る。
流行や華美な装飾は、そもそも問題を解くという困難な仕事の中に入ってくる余地がないのだ。

どんな頑張りでもよいというわけではない。
良い苦しみと、悪い苦しみがある。
走っている時に感じるような苦しみなら結構だが、釘を踏み抜いた時のようなひどい苦しみは御免だ。
困難な問題はデザイナーにとって良いものだが、気まぐれな顧客や信頼できない素材はそうではない。

美術では、伝統的に最も価値を認められてきたのが人物画であった。
これには理由がある。
他の画が押さない、私たちの脳内のボタンを人の顔の画が押すとかいうことだけではない。
人間が人の顔を見分ける能力があまりに優れていあるため、人の顔の画を描く者は観る者を満足させるために非常な努力をしなければならないのだ。
木を描いて、枝の角度を5度ばかり変えたとしても、誰も気が付くまい。
だが、誰かの目を5度傾けて描いたら、みんな気付くだろう。

バウハウスのデザイナーがサリヴァンの「形態は機能に従う」という方針を採用したとき、
彼らが意図したのは「形態は機能に従うはずだ」ということだった。
そして機能が難しいものであるなら、形態もそれに従わざるを得ない。
誤りを犯す余地はないからだ。
野性の動物が美しいのは、彼らが困難な生を生きているからだ。

p163

もちろん、100年後のプログラミング言語がどんなだろうと尋ねる時点で私はひとつの大きな仮定をおいている。
100年後には私たちはプログラムなんてしているんだろうか。
してほしいことを言うだけでコンピュータがやってくれるようにならないんだろうか。

そっち方面では、これまでのところ大した進歩はない。
私の推測では、100年後でも、現在の私たちがプログラムと呼ぶようなものを使ってコンピュータにしてほしいことを伝えているだろう。
もちろん、現在の私たちがプログラムを書いて解決している仕事のうち、プログラムを書かないでもよくなるものはあるだろうが、
それでも現在の私たちがやっているようなプログラムはまだたくさん必要とされているだろうと思う。

どんな技術であれ、100年後を予想できるなんて考えるのは傲慢だと思われるかもしれない。
しかし、私たちは既に50年の歴史を持っているということを考えてほしい。
過去50年の言語の進化がいかにゆっくりとしたものであるかを考えれば、100年後を見るということも考え得る範囲だろう。

言語がゆっくりと進化するのは、それが本当は技術ではないからだ。
言語は表記だ。
プログラムは、コンピュータに解いてほしいと思う問題の正式な記述なんだ。
だからプログラミング言語の進化の速度というのは、移動手段や通信手段よりは、数学表記の進化に近いだろう。
数学の表記は確かに進化するが、技術の分野に見られるような巨大な飛躍はない。

p166

100年後のプログラマが求めているものは、たいていの場合、
信じられないほど非効率な最初のバージョンのプログラムを、最低限の努力ででっち上げれるような言語だろう。
現在の私たちの言葉を使えば、だが。
彼らに言わせれば、単に「簡単にプログラムできる言語」ということになるだろう。

非効率なソフトウェアが醜いのではない。
醜いのは、プログラマに不要な仕事をさせる言語だ。
本当の非効率性とは、マシンの時間を無駄にすることではなく、プログラマの時間を無駄にすることだ。
コンピュータが速くなればなるほど、このことははっきりしてくる。

p195

じゃあ、力の弱い言語を使うことによってどれだけ損をするんだろう。
これに関しては多少データがある。

力を測る一番簡単な方法はたぶんコードサイズだろう。
高レベル言語を使う理由は、より大きな抽象化を可能にしてくれることだ。
より大きな煉瓦を使えば必要な壁を作るのに少ない煉瓦で済む、というようなものだ。
だからよりパワフルな言語を使えばプログラムは短くなる(もちろん文字数だけでなく、言語の要素に関してもだ)。

よりパワフルな言語を使って、どうやって短いプログラムが書けるんだろう。
ひとつのテクニックとして、もし言語がそれを許すなら、ボトムアッププログラミングと呼ばれるものがある。
アプリケーションをベース言語で書く代わりに、まず自分の書きたいプログラムに適合する言語をベース言語で書いて、
次にその言語を使ってプログラムを書くんだ。
両者を合わせたコードサイズはすべてをベース言語で書いた場合よりずっと小さくなるはずだ。
実際、これは圧縮アルゴリズムの動作原理と同じだ。
ボトムアッププログラムは変更するのも楽だ。
多くの変更は言語の層に手を加えなくても済ませられる。

コードサイズは重要だ。
プログラムを書く時間はプログラムの長さに大きく依存する。
プログラムが別の言語を使ったら3倍のサイズになるんだとしたら、それを書くのに3倍の時間が必要になるだろう。
そして、それはプログラマを増やすことではカバーできない。
あるサイズを超えたら、新しく人員を投入するのは全体として効率を下げるだけになる。
フレデリック・ブルックスがこの現象を有名な『人月の神話』で述べているが、私が見聞きしたすべてのことは彼が言うことを裏付けるものだった。

簡潔さ p206

どんな言語にも必要な3要素、つまり、フリーの実装、本、そしてハックすべきものが揃ったとして、
さてどうやって言語をハッカーの好むものにできるだろう。

ハッカーが好む要素のひとつは簡潔さだ。
ハッカーは怠惰だ。
数学者やモダニズム建築家が怠惰であるのと同じように。
余分なものは嫌われる。
これからプログラムを書こうとしているハッカーは少なくとも無意識的に予測される総タイプ量によってプログラミング言語を選んでいる、と言っても真実からそれほど遠くはあるまい。
これがハッカーの考える方法と正確に一致していないとしても、言語設計者はそう仮定することでうまくやれるだろう。

最も重要な簡潔さは、言語をより抽象的にすることで得られる。
そもそも、高級言語を使う理由がまさにそこにあるからだ。
抽象化できることが多いほど良いだろう。
言語設計者は、いつもプログラムを眺めて、これをより少ないトークンで表現する方法はないだろうかと自問すべきだ。
ひとつのアイディアで、たくさんの異なったプログラムを短くできたとしたら、それは偶然ではないだろう。
おそらく新しい抽象化手法を発見したんだ。

ライブラリ p210

もちろん、究極の簡潔さとは、欲しいプログラムが既に書かれていてそれを呼ぶだけ、というものだ。
そこで、プログラミング言語の中でますます重要になってゆくと思われることに話を移そう。
ライブラリだ。
Perlは文字列操作の豊富なライブラリのおかげで人気が出た。
この種のライブラリは書き捨てのプログラムでは特に重要だ。
データを変換したり取り出したりするものが多いからだ。
たくさんのPerlプログラムは、最初はいくつかのライブラリコールをつなぎ合わせただけのものから始まるだろう。

この先50年のプログラミング言語の進化は、ライブラリ関数についてのものになるだろうと思う。
未来のプログラミング言語は、言語の核と同じくらい慎重に設計されたライブラリを備えているだろう。
プログラミング言語の設計の重点は、静的型付けか動的型付けかとか、オブジェクト指向か関数型かとかそういうことではなく、
どうやったら素晴らしいライブラリを設計できるかということになってゆくだろう。
型システムの設計みたいなことを考えるのが好きな言語設計者は身震いするかもしれない。
ライブラリの設計だなんて、アプケーションを書くみたいなことじゃないか!
残念でした。
言語はプログラマためのもので、プログラマが必要としているのはライブラリなのだ。

良いライブラリを設計するのは難しい。
たくさんのコードを書けばよいというものではない。
ライブラリが大きくなり過ぎると、必要な関数を探し回るより自分で書いてしまったほうが早いなんてことが起こる。
ライブラリは、コア言語と同様に、少ない数の直交性の高いオペレータを使って設計されなければならない。
プログラマが、どのライブラリが欲しい機能を実行できるかを推測できるようになっていなければならない。

時間 p213

人気のある言語が必要とする最後の要素は時間である。
誰も、消えてしまう言語でプログラムを書きたいとは思わない。
そしてたくさんの言語が現れては消えていく。
たいていのハッカーは、言語が作られてから最低でも2年間くらい経ってようやく、それを使うことを考え始める。

新しい素敵なものを考え出す発明家はしばしば見落とすのだが、人々にメッセージが行き渡るには時間がかかるのだ。
私のある友人は誰かに何かを頼まれても、1回目は何もしようとしない。
人々はよく何かを思いつきで頼んで、後からそれが不要だったと分かることが多いと彼は知っているからだ。
時間を浪費しないために、彼は3回か4回目のリクエストが来るまで待つ。
そのころにはリクエストを出した人はかなりいらついているが、少なくともその人はそれが本当に必要だということが分かっている。

たいていの人は、耳にする新しいことに対して、似たようなフィルタを身に付けている。
何かを10回は耳にするまで、人々はそのことに注意を払おうとさえもしない。
これは全く正当なことだ。
新しくてホットななんとやらの大部分は時間の無駄で、消えていってしまうものだからだ。
私自身、VRMLを学ぶせることでそれを学ぶことそのものを避けることができた。

再デザイン p215

「最も良い書き方は書き直すことだ (The best writing is rewriting)」 と E.B. ホワイトは書いた。
良い作家は皆これを知っている。
ソフトウェアについてもこの命題は真実だ。
デザインの最も重要な段階は再デザインである。
プログラミング言語は特に十分に再デザインされていない。

良いソフトウェアを書くには、2つの相反する考えを頭に置いておかなくちゃならない。
若いハッカーの無邪気な自信と、ベテランの懐疑主義だ。
「こんなの簡単だよ」と頭の半分で考える一方で、「こんなのうまくいきっこない」ともう半分で考えるのだ。

ポイントは、実はこの2つには矛盾はないということだ。
あなたは異なるものについてそれぞれ楽観的と懐疑的になっているのだ。
問題を解決できる可能性に関する楽観と、得られた解決の価値に対する懐疑だ。

素晴らしい仕事をする人はしばしば、自分がやっていることには価値がないと考えてしまう。
ほかの人が見ればその仕事はまさに驚異的なのに、それを創った当人には欠陥ばかりが目につく。
だが、その現象は偶然ではない。
その心配こそが、仕事を良くするものなのだ。

希望と心配のバランスをうまく取れれば、それはあなたが2本の足で自転車を漕ぐように、プロジェクトを前へ押し進めてくれる。
イノベーションの2サイクルエンジンを考えてみよう。
最初のフェーズでは、自分はその問題を解決できあるという確信に押されて、あなたは一心不乱に問題に取り組む。
第二フェーズでは、あなたは自分のやったことを冷たい朝日の下で眺め、その欠陥をはっきりと目にする。
だが批判的な精神が希望を押し潰さない限り、あなたは自分のシステムが不完全であることを認め、考えるのだ。
あとこんだけ頑張ればできるかな。
2つの力をバランスさせておくのは難しい。
若いハッカーでは楽観主義が支配しがちだ。
彼らは何かを創り出し、それが素晴らしいものだと信じて疑わず、より良くしていこうと思わない。
年老いたハッカーでは懐疑主義が支配し、野心的なプロジェクトに手を付けようとさえしない。

p224

プロトタイプから次第に詳細化してゆく方法が士気に良いのは、常に没頭していられるからだ。
ソフトウェアにおける私のルールはこうだ。
常に動くコードを持っていろ。
1時間後には試せるものを書いていれば、目の前にある見返りによってやる気を保っていられる。
芸術でも同じだ。
特に油彩画では。
多くの画家はぼんやりしたスケッチから始めて徐々に細部を描き込んでいく。
この方法をとれば、原理的に画が未完成に見えるまま一日が終わるということがない。
実際、画家の間でよく言われるせりふがある。
「画には終わりがない。ただ描くのを止めるだけだ」。
ソフトウェアの仕事をしたことのある人なら、この考えはよく分かるだろう。

士気の問題は、低いレベルのユーザのために何かをデザインするのが難しいことのもうひとつの理由でもある。
自分で気に入らない何かに対して興味を持ち続けるのはとても難しい。
良いものを作りたいなら、いつも「うーむ、こいつは素晴らしいぞ」と思い続けていなくちゃ。
「なんてひどいがらくただ。馬鹿どもは気に入るだろうがな」なんて考えるんじゃなくね。

デザインは、人間のために何かを作るということだ。
でもユーザだけが人間なんじゃない。
デザイナーもまた、人間なのだ。

p228

2年ほど前、友人のベンチャーキャピタリストが、彼がかかわっている新しいベンチャーについて話してくれた。
その時は、それはかなり有望に思えた。
次に彼と会った時、そのベンチャーはソフトウェアを Windows NT 上で開発することを決定し、
経験豊かな NT 開発者を最高技術責任者として招いたと彼は話した。
これを聞いて私は、ああそのベンチャーの運命は決まったと思ったものだ。
第一に、その最高技術責任者は一級のハッカーではあり得ない。
だって素晴らしい NT 開発者になるためには、 NT を何度も何度も、自分から進んで使わなくちゃならないだろう。
偉大なハッカーがそんなことをするなんて想像もできない。
第二に、もし彼が優秀だったとしても、プロジェクトが NT 上に構築されるなら、優秀な人物を集めることが困難だろうからだ。

p237

良いハッカーになる鍵は、たぶん、自分がやりたいことをやることだ。
私が知っている素晴らしいハッカーを考えてみると、彼らに共通することのひとつは、
彼らが自分から望まないことをやらせるのは極めて難しいだろうということだ。
これが原因なのか、結果なのかは定かではない。
もしかすると両方かもしれない。

何かをうまくやるためには、それを愛していなければならない。
ハッキングがあなたがやりたくてたまらないことである限りは、それがうまくできるようになる可能性が高いだろう。
14歳の時に感じた、プログラミングに対するセンスオブワンダーを忘れないようにしよう。
今の仕事で脳味噌が腐っていってるんじゃないかと心配しているとしたら、たぶん腐っているよ。

最高のハッカーはもちろん賢いけれど、それはほかのいろいろな分野でも同じだ。
ハッカーについてだけ特有な資質というのはあるだろうか。
何人かの友人に尋ねてみた。
最初にあがってくる答えは、好奇心だった。
賢い人はみな、好奇心が強いと私は思っている。
好奇心は単に知識の一階微分だからだ。
それでも、ハッカーはとりわけ好奇心が強いようだ。
特に、ものが動く仕組みに関してはある意味それは当然かもしれない。
プログラムというもの自体、実質的に、ものが動く仕組みの巨大な記述だからだ。

p258

最後に、懐疑主義を教えてくれた父と、想像力を教えてくれた母に感謝したい。
彼女を母に持ったことは、世界を色付きで見られることのようなものだった。

p261

ポールの文章は、 3 つの点で最適化されている。
明解な主張、分かりやすい言葉、そして素晴らしいリズムだ。
彼の文章を読んで心が浮き立つのは、その内容だけでなく、文章の完成度の高さにも依っている。
そのような文章を日本語に翻訳するのは、あるアーキテクチャ向けにかりかりに最適化されたプログラムを別のアーキテクチャに移植するようなものだった。