ハッカーと画家
Original2003年5月
(このエッセイは、ノースイースタン大学での以前の講演を組み込んだ、ハーバード大学でのゲスト講演から派生したものです。)
コンピューター科学の大学院を卒業した後、私は絵画を学ぶために美術学校に行きました。コンピューターに興味があるsomeone が絵画にも興味があるのは、多くの人々にとって驚きでした。彼らは、ハッキングと絵画は非常に異なる種類の仕事であると考えているようでした。ハッキングは冷たく、正確で、体系的であり、絵画は何か原始的な衝動の狂乱的な表現であると。
これらの両方の像は間違っています。ハッキングと絵画には多くの共通点があります。実際、私が知っている様々な種類の人々の中で、ハッカーと画家は最も似ている人々の1つです。
ハッカーと画家が共通しているのは、彼らが両方とも制作者であるということです。作曲家、建築家、作家とともに、ハッカーと画家が目指しているのは良いものを作ることです。彼らは厳密な研究をしているわけではありませんが、良いものを作る過程で新しい技術を発見した場合、それはさらに良いことです。
私は「コンピューター科学」という用語が好きではありません。その主な理由は、そのようなものは存在しないからです。コンピューター科学は、歴史的な偶然によって一緒に集められた、ほとんど関連性のない分野の集合体です。まるでユーゴスラビアのようなものです。一方の端には、数学者と呼ばれている人々がいますが、DARPAの助成金を得るためにコンピューター科学と呼んでいます。中間には、コンピューターの自然史のようなものを研究している人々がいます。ネットワークを介したデータルーティングアルゴリズムの動作を研究するなどしています。そして反対の極端な側には、興味深いソフトウェアを書こうとしているハッカーがいます。彼らにとってコンピューターは、建築家にとってコンクリートや、画家にとっての絵の具のような表現の媒体にすぎません。数学者、物理学者、建築家がすべて同じ部門に所属しなければならないようなものです。
時には、ハッカーの行うことは「ソフトウェア工学」と呼ばれますが、この用語も同様に誤解を招きます。優れたソフトウェア設計者は、建築家ほど工学者ではありません。建築と工学の境界は明確に定義されていませんが、それは存在します。それは「何を」と「どのように」の間にあります。建築家は「何を」するかを決め、エンジニアは「どのように」するかを解決します。
「何を」と「どのように」は余りにも分離されるべきではありません。仕様を決めずに、それをどのように実装するかを決めようとすると、トラブルが起きます。しかし、ハッキングは単に仕様を実装すること以上のものになることができます。最高のレベルでは、仕様を作成することです。ただし、それを実装することが最良の方法であることがわかります。
いつかは、「コンピューター科学」がユーゴスラビアのように、その構成要素に分割されるかもしれません。それは良いことかもしれません。特に、私の祖国であるハッキングが独立できれば、なおさらです。
これらの異なるタイプの仕事をすべて1つの部門にまとめるのは、管理上は便利かもしれませんが、知的には混乱を招きます。これが、私が「コンピューター科学」という名称を好きではない別の理由です。議論の余地はありますが、中間にいる人々は何かの実験科学のようなことをしているかもしれません。しかし、両端にいる数学者とハッカーは実際には科学をしているわけではありません。
数学者はこのことを気にしていないようです。彼らは数学科の他の数学者と同じように定理を証明することに喜んで取り組み、おそらくすぐに「コンピューター科学」と書かれた建物で働いていることを忘れてしまうでしょう。しかし、ハッカーにとってはこのラベルが問題です。自分の行っていることが科学と呼ばれると、科学的に振る舞うべきだと感じてしまいます。
最良の場合、論文は単なる形式に過ぎません。ハッカーはクールなソフトウェアを作り、それについて論文を書き、その論文がソフトウェアによって表される業績の代替物になります。しかし、しばしばこのズレが問題を引き起こします。美しいものを作るのではなく、研究論文に適したより醜いものを作るように流れていってしまうのです。
残念ながら、美しいものは必ずしも最良の研究対象にはなりません。第一に、研究は独創的でなければならず、誰も望んでいない分野を開拓することが確実に未踏の領域を探索することになります。第二に、研究は実質的でなければならず、扱いにくいシステムの方が論文になりやすいのは、それらに取り組むために克服しなければならない障害について書くことができるからです。間違った前提から始めるほど、より肉厚な問題が生まれます。AIのほとんどがこのルールの例です。知識を抽象的な概念を表す述語論理式のリストとして表現できると仮定すると、それを機能させるための多くの論文を書くことができます。リッキー・リカルドが言ったように、「ルーシー、説明しなければならないことがたくさんあるわ」。
美しいものを作る方法は、しばしば既存のものに微妙な変更を加えたり、既存のアイデアをわずかに新しい方法で組み合わせたりすることです。このような仕事は、研究論文では伝えにくいのです。
では、なぜ大学や研究所はハッカーの業績を論文で評価し続けるのでしょうか? 「学業適性」が単純な標準化テストで測定されるのと同じ理由です。プログラマーの生産性がコード行数で測定されるのと同じ理由です。これらのテストは適用が簡単で、うまくいくような簡単なテストがあまりにも魅力的だからです。
ハッカーが実際に目指しているものを、美しいソフトウェアを設計することを測定するのは、はるかに難しいでしょう。良いデザインの感覚が必要です。そして、良いデザインを認識する能力と、それができると自信を持つ能力の間には、おそらくマイナスの相関関係しかありません。
唯一の外部テストは時間です。時間が経つと、美しいものは繁栄し、醜いものは捨てられていきます。残念ながら、その時間は人間の寿命よりも長いことがあります。サミュエル・ジョンソンは、作家の評判が収束するのに100年かかると言いました。作家の影響力のある友人が死に、その追従者たちも死ぬまで待たなければなりません。
私は、ハッカーは自分の評判に大きな偶然的な要素があることを受け入れざるを得ないと思います。他の制作者と同じです。実際、ハッカーは比較的恵まれています。ファッションの影響は、絵画ほど大きくはありません。
作品を誤解されるよりも、自分で作品を誤解してしまうことの方が危険です。関連分野を探して新しいアイデアを見つけるのが良いでしょう。コンピューター科学の部門にいると、理論的コンピューター科学の理論が応用版のハッキングだと信じてしまう誘惑があります。
大学院時代は、理論をもっと知るべきだと気になっていました。しかし今では、ハッカーが計算量複雑度やチューリング完全性を知る必要はないと分かりました。パーサーや正規表現ライブラリを書く際に、状態機械の概念を覚えておくと便利でしょう。
最良のアイデアの源は、「コンピューター」という言葉が付いた分野ではなく、メーカーが活躍する分野です。絵画の方が計算理論よりもはるかに豊かなアイデアの源となっています。
大学では、紙の上で完全にプログラムを設計してから、コンピューターに取り掛かるべきだと教えられました。しかし実際には、壊れまくったコードを徐々に修正していくのが私の方法でした。デバッグは最終工程ではなく、プログラミングの大部分を占めていました。
これは、鉛筆の持ち方を教えられた小学校の時と同じように、自分の方法が間違っていると感じていました。しかし、画家や建築家を見れば、私の方法には「スケッチ」という名称があることが分かりました。大学で教えられた方法は間違っていたのです。プログラムは書きながら考えるべきなのです。
プログラミング言語は、柔軟性が何より重要です。プログラムを考えるための道具であって、既に考えたプログラムを表現するためのものではありません。鉛筆のようなものであって、ペンではありません。静的型付けは、大学で教えられた方法で本当にプログラムを書く人にとっては良いアイデアかもしれません。しかし、私の知っているハッカーはそうではありません。
数学への羨望も避けるべきです。科学者は数学的に見せかけようとしがちですが、これは重要な問題から逸れる危険があります。ハッカーは、作家や画家のように自分のアイデンティティを見つけるべきです。
大学や研究所ではハッカーを科学者として扱いますが、企業ではエンジニアとして扱います。ハッカーが本当にやりたいことをさせてくれる場所はなかなか見つからないのが現状です。
デザイン戦争を戦う場所は、まだ誰も防御陣を築いていない新しい市場にあります。そこでは大胆なデザインアプローチを取り、製品の設計と実装を同じ人が行うことで大きな勝利を収めることができます。マイクロソフト自身がそうしたのと同様に、アップルやヒューレット・パッカードも同じことをしてきました。ほとんどの成功したスタートアップがそうしてきたと思います。
そのため、素晴らしいソフトウェアを構築する1つの方法は、自分のスタートアップを立ち上げることです。しかし、これには2つの問題があります。1つは、スタートアップでは単にソフトウェアを書くだけでなく、それ以外のことも多くしなければならないということです。Viaweb では、私は時間の4分の1しかコーディングできないと考えていました。残りの3分の4の時間は、退屈なこともこわいこともやらなければなりませんでした。私にはこの基準がありますが、それは取締役会の会議から抜け出して歯の治療をしたときのことです。歯科医の椅子に座って、ドリルを待っている間、私は休暇を楽しんでいるように感じたものです。
スタートアップの別の問題は、お金を稼ぐソフトウェアと書くのが面白いソフトウェアの間にほとんど重複がないということです。プログラミング言語は書くのが面白いですし、実際にマイクロソフトの最初の製品もそうでしたが、今ではプログラミング言語を誰も買いません。お金を稼ぐには、誰も無料では解決したくないような厄介な問題に取り組まざるを得なくなります。
すべてのメーカーがこの問題に直面しています。価格は供給と需要によって決まり、楽しんで取り組めるものよりも、個々の顧客の単純な問題を解決するものの方が需要が高いのです。オフブロードウェイの舞台に立つよりも、トレードショーの誰かのブースでゴリラの着ぐるみを着るほうが稼げます。小説を書くよりも、ごみ処理機の広告コピーを書く方が稼げます。そして、プログラミング言語をハックするよりも、ある企業の遺産データベースをWebサーバーに接続する方法を見つけるほうが稼げるのです。
私は、この問題に対するソフトウェアの場合の答えは、ほとんどすべてのメーカーに知られている概念、すなわち「日中の仕事」だと思います。この言葉は、夜に演奏する音楽家から始まりました。より一般的には、お金を稼ぐための仕事と、愛する仕事の2つがあるということを意味しています。
ほとんどすべてのメーカーは、キャリアの初期に日中の仕事を持っています。画家や作家がそうであるのはよく知られています。幸運なことに、自分の本当の仕事に密接に関連した日中の仕事を得ることができます。ミュージシャンは多くの場合、レコード店で働いているようです。プログラミング言語やオペレーティングシステムに取り組むハッカーも、同じようにそれを使う日中の仕事を得られるかもしれません。[1]
ハッカーが日中の仕事を持ち、余暇に美しいソフトウェアに取り組むべきだと提案しているのは、新しいアイデアではありません。これがオープンソースのハッキングについてのものなのです。私が言っているのは、オープンソースが恐らく正しいモデルだということで、なぜなら他のすべてのメーカーによっても独立して確認されているからです。
ハッカーがオープンソースプロジェクトに取り組むことを雇用者が嫌がるのは、私には驚きに思えます。Viaweb では、そうでない人を雇うことを躊躇していたでしょう。プログラマを面接するとき、私たちが最も気にしていたのは、彼らが余暇に何kind のソフトウェアを書いているかということでした。本当に上手にできるものは、それを愛さなければならず、ハッキングが好きなら必ず自分のプロジェクトに取り組むことになるからです。[2]
ハッカーはメーカーであって科学者ではないため、適切なメタファーを探すのは科学ではなく、他のメーカーの中にあります。ハッキングについて絵画から何を学べるでしょうか?
絵画の例から学べるか、少なくとも確認できることは、ハッキングを学ぶ方法です。絵を描くのは主に実践することで学びます。同様に、ハッキングも同じです。ほとんどのハッカーは、13歳のときにプログラムを書くことで、ハッキングを学びます。大学の授業でも、ハッキングは主にハッキングすることで学びます。[3]
絵画家は作品を残すので、彼らが学習しながら成長していく過程を見ることができます。ある画家の作品を時系列で見ると、各作品が前の作品で学んだことを基に構築されていることがわかります。ある作品の中で非常に上手く機能しているものは、通常以前の小さな作品の中にその原型を見つけることができます。
ほとんどのメーカーはこのように働いていると思います。作家や建築家も同様のようです。ハッカーも、長年同じプロジェクトに取り組み、後の考えを改訂として組み込もうとするのではなく、定期的に最初から一から始め直すことが良いかもしれません。
ハッカーがハッキングを実践することで学ぶのは、ハッキングが科学とどれほど異なるかを示す別の証拠です。科学者は実験やプロブレムセットを行うことで科学を学びます。科学者は最初から完璧な仕事、つまり誰かがすでに行ったことを再現しようとする仕事から始めます。やがて、オリジナルの仕事ができるようになります。一方、ハッカーは最初からオリジナルの仕事をしていますが、それはとてもひどいものです。つまり、ハッカーは最初からオリジナルで、上手になっていくのに対し、科学者は最初は上手で、やがてオリジナルになっていくのです。
メーカーが学ぶ別の方法は、見本から学ぶことです。画家にとって、美術館は技術の参考文献庫です。何世紀もの間、偉大な画家の作品をコピーすることが画家の伝統的な教育の一部となっているのは、コピーすることで作品の作り方を詳しく見る必要があるからです。
作家も同じようにします。ベンジャミン・フランクリンは、アディソンやスティールのエッセイの要点をまとめ、それを再現しようとすることで、書くことを学びました。レイモンド・チャンドラーも同じようにミステリー小説で行いました。
同様に、ハッカーもよいプログラムを見ることで、プログラミングを学ぶことができます。それも、プログラムの動作だけでなく、ソースコードも見ることが重要です。オープンソースムーブメントのあまり宣伝されていない利点の1つは、プログラミングを学びやすくしたことです。私がプログラミングを学んだ時代は、主に本の中の例を頼りにしなければなりませんでした。当時利用できる大きなコードベースはUnixでしたが、それでさえオープンソースではありませんでした。Unixのソースコードを読んだ人の多くは、1977年に書かれたジョン・ライオンズの本の違法コピーを読んでいたのですが、その本は1996年まで出版が許可されませんでした。
[1] 私は、ハッカーが自分の仕事の一部をオープンソースプロジェクトに捧げることを提案しているのではありません。むしろ、ハッカーが自分の仕事の一部を自分のプロジェクトに捧げることを提案しています。
[2] 私は、ハッカーが自分の仕事の一部をオープンソースプロジェクトに捧げることを提案しているのではありません。むしろ、ハッカーが自分の仕事の一部を自分のプロジェクトに捧げることを提案しています。
[3] 私は、ハッカーが自分の仕事の一部をオープンソースプロジェクトに捧げることを提案しているのではありません。むしろ、ハッカーが自分の仕事の一部を自分のプロジェクトに捧げることを提案しています。
絵画から学べるもう一つの例は、絵画が段階的な洗練によって作られる方法です。絵画は通常スケッチから始まります。徐々に詳細が埋められていきます。しかし、それは単に埋めていくプロセスではありません。時には、最初の計画が間違っていたことがわかります。X線で見ると、無数の絵画で、肢体が移動したり顔の特徴が調整されていたりすることがわかります。
ここに、絵画から学べるケースがあります。私は、ハッキングもこのように機能するべきだと考えています。プログラムの仕様が完璧であると期待するのは非現実的です。これを最初から認めて、仕様が即座に変更できるようにプログラムを書くほうがよいでしょう。
(大企業の構造がこれを難しくしているので、これもスタートアップが有利な点の1つです)
今では誰もが、早期最適化の危険性を知っているはずです。私は、早期設計、つまり、プログラムが何をすべきかを早期に決めすぎることにも同じくらい気をつける必要があると考えています。
適切なツールを使えば、この危険性を避けられます。良いプログラミング言語は、油絵のように、考えを変えるのを簡単にするはずです。動的型付けは、事前に具体的なデータ表現にコミットする必要がないので、ここでは有利です。しかし、柔軟性の鍵は、言語を非常に抽象的にすることだと思います。変更しやすいプログラムは、非常に短いものです。
これは逆説的に聞こえますが、素晴らしい絵画は、必要以上に優れている必要があります。例えば、レオナルド・ダ・ヴィンチがジネヴラ・デ・ベンチの肖像画をナショナル・ギャラリーに描いたとき、彼は彼女の頭の後ろにジュニパーの木を描きました。そこでは、一枚一枚の葉を丁寧に描きました。多くの画家なら、これは単に彼女の頭を額縁するための背景に過ぎないと考えただろう。誰も近くで見ないだろう。
レオナルドはそうではありませんでした。絵の一部にどれだけ熱心に取り組むかは、誰がそれをどれだけ注意深く見るかには全く関係ありませんでした。彼はマイケル・ジョーダンのようでした。執拗でした。
執拗さが勝つのは、総合的に見ると、見落とされた細部が見えるようになるからです。ジネヴラ・デ・ベンチの肖像画を見る人は、作者がレオナルド・ダ・ヴィンチだと書かれているのに気づく前から、その絵に引き付けられることが多いです。あの見落とされた細部が全て合わさって、まるで千の小さな声が調和して歌っているかのような、圧倒的な何かを生み出しているのです。
優れたソフトウェアも、美への狂気的な献身を必要とします。良いソフトウェアの内部を見ると、誰も見ないはずの部分までが美しいことがわかります。私は自分が素晴らしいソフトウェアを書いていると主張するつもりはありませんが、コードを扱う際の私の行動は、日常生活でそうしたら処方箋が必要になるようなものです。 インデントが悪かったり、変数名が醜かったりするコードを見るとイライラします。
ハッカーが単なる実装者で、仕様書をコードに変換するだけなら、端から端まで掘り進むように作業できるでしょう。しかし、ハッカーが創造者なら、インスピレーションも考慮に入れる必要があります。
ハッキングでは、絵画と同様に、仕事のサイクルがあります。時には新しいプロジェクトに熱中して1日16時間働きたくなりますが、他の時は何も面白くありません。
良い仕事をするには、これらのサイクルを考慮に入れる必要があります。なぜなら、それらはあなたの反応によって影響を受けるからです。 手動変速車でhill上を走っているときは、エンストを避けるためにクラッチを戻す必要があります。同様に、野心を失わせないためにも、時には後退することが必要です。 絵画とハッキングの両方には、恐ろしいほど野心的な仕事と、安心できるルーティンの仕事があります。低迷期に簡単な仕事を取っておくのは良い考えです。
ハッキングでは、これが文字通り、バグを溜め込むことを意味します。私はデバッグが好きです。それが、ハッキングが人々が考えているほど単純であるたった1つの時期だからです。完全に制約された問題があり、解決するだけでよいのです。プログラムはxをするはずだったのに、yをしている。どこが間違っているのか? 最終的に勝つことがわかっているので、壁を塗るのと同じくらくつかえます。
絵画の例から、自分の仕事の管理方法だけでなく、協力して仕事をする方法も学べます。過去の偉大な芸術作品の多くは、複数の手によるものですが、美術館の壁に1人の名前しか書かれていないことがあります。レオナルドはヴェロッキオの工房で見習いをしており、キリストの洗礼の中の天使の1体を描きました。これは例外ではなく、むしろ一般的な慣行でした。ミケランジェロは、自分で天井画の全ての人物を描いたことで特に熱心だと考えられていました。
私の知る限り、画家が一緒に絵を描くとき、同じ部分を描くことはありませんでした。通常、主要な人物は師匠が描き、補助者が他の部分や背景を描きました。しかし、お互いの仕事の上に描くということはありませんでした。
これがソフトウェアの共同作業にも適した方法だと思います。それ以上に押し進めるべきではありません。3、4人の人間が、誰もが本当の所有者ではない部分を書き換えているコードは、共同利用の部屋のようになり、寂しく放置された感じになり、ごみが溜まっていきます。 適切な共同作業の方法は、明確な所有者がいて、可能な限り慎重に設計された、プログラミング言語のようなインターフェースを持つ、明確に定義されたモジュールに分割することだと思います。
絵画と同様、ほとんどのソフトウェアは人間の視聴者を対象としています。したがって、ハッカーも画家のように共感性を持つ必要があります。ユーザーの視点に立って物事を見ることができなければなりません。
子供のころ、いつも他人の立場に立って考えるよう言われていました。実際にはこれは、自分の望むことをせずに、他人の望むことをするよう言われていたのです。これが共感性に悪い評判をつけ、私は意図的にそれを育てないようにしていました。
私は間違っていました。他人の視点から物事を見ることが、成功の秘訣だと分かりました。それは自己犠牲を意味するわけではありません。むしろ反対のことをしなければならない場合もあります。例えば戦争などです。[4]
ほとんどのメーカーは人間の観客のために物を作ります。観客を引き付けるには、彼らのニーズを理解する必要があります。最高の絵画のほとんどが人物画なのは、人間が人間に興味があるからです。
共感力は、優秀なハッカーと卓越したハッカーの間の最も重要な違いかもしれません。ある程度頭が良いハッカーでも、共感力がほとんどない孤独な人もいます。そのような人は、ユーザーの視点が分からないため、素晴らしいソフトウェアを設計するのが難しいのです。[5]
共感力のある人かどうかを見分ける一つの方法は、技術的な背景を持たない人に技術的な質問を説明するのを見ることです。そのような人は滑稽なほど下手です。夕食会で誰かがプログラミング言語とは何かと尋ねると、「オブジェクトコードを生成するためにコンパイラが使う入力が高水準言語です」などと答えるでしょう。高水準言語? コンパイラ? オブジェクトコード? プログラミング言語がわからない人にはこれらの用語もわかりません。
ソフトウェアの一部の役割は自己説明することです。したがって、良いソフトウェアを書くには、ユーザーがどれほど理解していないかを理解する必要があります。 ユーザーはマニュアルを読まずに、ソフトウェアに近づいてきます。それが彼らの予想通りに動作しなければなりません。私が見た中で最高のシステムは1985年のオリジナルのマッキントッシュでした。ソフトウェアがほとんどしないことをしたのです:それは単に動作しました。[6]
ソースコードも自己説明的であるべきです。プログラミングについての引用の中で、私がひとつだけ覚えてもらいたいのは、『コンピュータ・プログラムの構造と解釈』の冒頭にあるものです。
プログラムは機械を実行するためではなく、人間が読むために書かれるべきです。
ユーザーだけでなく、読者に対しても共感する必要があります。それはあなたの利益になります。なぜなら、あなたもその一人になるからです。 多くのハッカーが自分で書いたプログラムを6か月後に見返したとき、どのように動作するかわからなくなっているのを知っています。Perlを避けると誓った人も何人かいます。[7]
共感力の欠如は知性と関連付けられていますが、実際には相関関係はありません。数学や自然科学で優秀になるには共感力を学ぶ必要はありません。そのため、この2つの資質が関連付けられてきました。しかし、共感力が乏しい愚かな人もたくさんいます。トークショーに電話をかけてくる人々の話を聞いてみてください。彼らは質問を非常に回りくどい方法で尋ねるので、ホストがしばしば質問を言い換える必要があります。
つまり、ハッキングは絵画や文章のように機能するのでしょうか? それほど素晴らしいのでしょうか? 結局のところ、人生は一度きりです。素晴らしいことに取り組むべきです。
残念ながら、この質問に答えるのは難しいです。威信には常に大きな時間差があります。遠い星からの光のようなものです。絵画は500年前の偉大な作品のおかげで今日威信を得ています。当時は、ピエロ・デッラ・フランチェスカの絵画に描かれた奇妙な鼻を持つフェデリコ・ダ・モンテフェルトロ公が主に知られるようになるとは、誰も思っていませんでした。
したがって、ハッキングが今のところ絵画ほど魅力的に見えないことは認めますが、絵画自体も栄光の時代にはそれほど魅力的には見えなかったことを覚えておく必要があります。
私たちが確信できることは、ハッキングの栄光の時代は今だということです。ほとんどの分野では、偉大な仕事は初期に行われます。1430年から1500年の間に制作された絵画は未だ凌駕されていません。シェイクスピアは専門的な演劇が生まれたばかりの時期に現れ、その分野を大きく前進させました。以来、すべての劇作家がその影響下にあります。アルブレヒト・デューラーは銅版画で、ジェーン・オースティンは小説で同じことをしました。
同じパターンが繰り返されています。新しいメディアが登場すると、人々はそれに夢中になり、最初の数世代でその可能性のほとんどを探求します。ハッキングもこの段階にあるようです。
レオナルドの時代、絵画はそれほど魅力的ではありませんでした。ハッキングがどれほど魅力的になるかは、この新しいメディアで何ができるかによって決まります。
注
[1] 写真がもたらした絵画への最大の被害は、最高の日雇い仕事を奪ったことかもしれません。歴史上の偉大な画家の多くは、肖像画を描いて生計を立てていました。
[2] マイクロソフトは従業員が自由時間に オープンソースプロジェクトに貢献することを 奨励していないと聞きました。 しかし、最高のハッカーの多くがオープンソースプロジェクトに取り組んでいるため、 この方針の主な効果は、一流のプログラマーを雇えなくなることかもしれません。
[3] 大学で学ぶプログラミングについては、本や服装、デートについて学ぶのと同じようなものです。つまり、高校時代の悪趣味を学ぶということです。
[4] 共感力の応用例を示します。 Viaweb では、2つの選択肢の間で決められない場合、競合他社が最も嫌がるものは何かを尋ねていました。ある時、競合他社がほとんど役に立たない機能をソフトウェアに追加しましたが、それが自社にはなかった数少ない機能の1つだったため、業界紙で大々的に宣伝していました。 その機能が役に立たないことを説明することもできましたが、代わりに競合他社を怒らせるために、その日のうちにそれを自社でも実装することにしました。
[5] テキストエディタやコンパイラは例外です。ハッカーはこれらを設計するのに共感力は必要ありません。なぜなら、彼ら自身が典型的なユーザーだからです。
[6] ほぼ完璧でした。利用可能なRAMを若干オーバーシュートしたため、ディスクの頻繁な入れ替えが面倒でしたが、数か月以内に追加のディスクドライブを購入することで解決できました。
[7] プログラムを読みやすくする方法は、コメントを詰め込むことではありません。私はAbelsonとSussmanの引用をさらに一歩進めます。プログラミング言語は、アルゴリズムを表現するように設計されるべきで、それらを実行する方法をコンピューターに伝えるのは付随的なものでなければなりません。優れたプログラミング言語は、英語よりもソフトウェアを説明するのに適しているはずです。コードに問題のある部分を読者に警告する必要がある場合にのみコメントを使うべきです。道路に急カーブがある部分にのみ矢印があるのと同じように。
Trevor Blackwell、Robert Morris、Dan Giffin、Lisa Randallに、このドラフトを読んでいただき、ありがとうございます。また、Henry LeitnerとLarry Finkelsteinに講演の機会を与えていただき、感謝しております。