ポール・グラハム：第2章ハッカーとアーティスト（Habr版）

現在、ポール・グラハムは政府や大学にスタートアップのハブを作成する方法を教えていますが、以前は...高級プログラマーとアーティストの間で素晴らしい類似性を引き出しました。

13年間、本のタイトルと同じ名前の章はネット上で失われました。 便宜上、さまざまなアーカイブから断片的に収集して公開します。

アナスタシア・グリズノヴァ、ヤナ・シュチェコトヴァによる翻訳。 テキストを整理する-CaptainCrocus 出版に関するヘルプはEdisonです。

オリジナル- ハッカーと画家 （2003年5月）


コンピューターサイエンスの大学院を卒業した後、私は絵画を勉強するために美術科に行きました。 コンピューターの男が突然絵に興味を持つようになったことに多くの人が驚いた。 これらの人々は明らかに、ハッキングとアートは非常に異なる職業であると信じていました。ハッキングは冷たく、正確で系統的で、アートは原始的な衝動の激しい表現でした。

両方のビューが正しくありません。 ハッキングとアートには多くの共通点があります。 多くの異なるタイプの人々のうち、ハッカーとアーティストはおそらく最も類似しています。

ここには、共通点が1つあります。それらと他のクリエイターの両方です。 それらも他も、質的なことをしようとします。 作曲家、建築家、作家のように。 そして、それらのために、研究のために研究を行っていません（ただし、定性的なものを作成する過程で新しい方法が開かれた場合、それでもなお良いです）。

コンピュータサイエンスという用語は好きではありませんでした。 主に、そのような科学は存在しないからです。 「コンピューターサイエンス」-歴史がゆるやかに結びついた一連の科学分野を気まぐれに捨てていたがらくたの袋-ある種のユーゴスラビアが判明した。 極端な場合、自分の仕事をコンピューターサイエンスと呼んでDARPAの助成金を受け取る数学者。 赤道で-ある種のコンピューターサイエンス：たとえば、ネットワークを介してデータを送信するときのアルゴリズムの動作。 また、極端な例ではハッカーがいます。 彼らは面白いソフトウェアを書いており、彼らのためのコンピューターは、建築家のためのコンクリートや芸術家のための絵具のような単なる表現媒体です。 数学者、物理学者、建築家を1つの学部に導くことと同じです。

ハッカーの仕事は「ソフトウェアエンジニアリング」（ソフトウェアエンジニアリング）と呼ばれることもあります。 この用語も混乱を招きます。 同じ成功を収めた場合、エンジニアを建築家と呼ぶことができます。 アーキテクチャとエンジニアリングの間にはあいまいな境界線がありますが、実際には存在します。 それは「何」と「どのように」の間を行き来します。アーキテクトは何をすべきかを決定し、エンジニアはどのように計算します。

何をどのように分離すべきではありません。 何をすべきかを決定しようとしており、方法を理解せずに、単にトラブルを求めています。 しかし、もちろん、ハッカーは仕様の実装方法を決定する方法を知っているだけではありません。 ピーク時には、仕様をハッキングすると作成されますが、仕様を作成するには、実装するのが最善です。

いつか「コンピューターサイエンス」がユーゴスラビアのようなコンポーネントにバラバラになる可能性があります。 たぶんそれは最高のためです。 特に私の祖国-ハッキング-が主権になった場合は特に。

おそらく、管理の観点から、これらのさまざまなクラスをすべて1つの学部にまとめるのが便利です。 これだけが非常に紛らわしいです。 「コンピューターサイエンス」という用語が嫌いなもう1つの理由を次に示します。 赤道にいる人々がほぼ実験科学に従事していると仮定します。 しかし、極のそれら、数学者とハッカーは、科学とは何の関係もありません。

数学者は気にしないようです。 彼らは喜んで数学の学部の他の数学者のように定理に閉じこもり、すぐに、「コンピューターサイエンス」という記号が彼らが仕事に行く家の外にぶら下がっていることに気づかなくなると思います。 しかし、この兆候からハッカー-1頭痛。 ハッカーが科学に従事している場合、科学的な方法で行動する必要があります。 そして、大学や研究室のハッカーは、優れたプログラムを作成するために、科学論文を書くべきであり、望んでいることをするべきではないと考えています。

彼らの科学的研究はせいぜい形式的なものです。 ハッカーはクールなソフトウェアを作成してから、このソフトウェアに関するレポートを作成します。レポートは、ソフトウェア製品によって表される成功を確認します。 しかし、多くの場合、事態は複雑になります。 toいものを美しいものよりも好むのは簡単すぎます。いものは研究報告書でよく見えます。

残念ながら、すばらしいことは常にレポートにとって理想的なトピックとはほど遠いものです。 まず、科学的研究は独創的である必要があります-そして、候補者を擁護した誰もが知っているように、処女の領土への唯一の道があります：誰も喜んで侵入しないサイトを杭打ちする必要があります。 第二に、科学的研究は堅実である必要があります。より曲がったシステムのレポートはより有益です-すべてがうまくいく前に著者が克服した障害について書くことができます。 実質的な作業の場合、最初は誤った結論に勝るものはありません。 人工知能のほとんどの例は、この例です。 引数が抽象的な概念である一連の肯定的な論理式で知識を表すことができると結論付けた場合、それを機能させる方法について多くの学位論文を書くことができます。 リッキー・リカードがかつて言ったように、「ルーシー、あなたは説明することがたくさんあります。」

そして、美しさを生み出すために、既存のものを少し回転させ、古いアイデアを少し異なる方法でつなぐだけでよい場合がよくあります。 そのような活動は、論文で説明するのは簡単ではありません。

それでは、なぜ大学や研究室はまだ科学出版物のハッカーを判断しているのでしょうか？ そして、なぜ「学習能力」が単純なテストとプログラマの生産性、つまりコードの行数によって測定されるのか。 理由は同じです。

テストは簡単に実行でき、動作するように見えるテストほど魅力的なものはありません。

ハッカーが実際に何をしようとしているのか、つまり優れたプログラムを評価するのははるかに困難です。 良いデザインを判断するには、微妙にデザインを感じる必要があります。 そして、良い発展を認識する能力と、それを認識できるという自信は、否定的でない限り相関しません。

最良の基準は時間です。 時間が経つにつれて、美しいものが繁栄し、いものは忘却の中で失われます。 悲しいかな、人間の生活にかかるよりも時間がかかるかもしれません。 サミュエル・ジョンソンは、作家の評判を築くには100年かかると言った[1] ：著者の影響力のある友人が亡くなってから、ファンになるまで。

事故はハッカーの評判に大きな役割を果たします-私の意見では、これに我慢する必要があります。 この意味で、ハッカーは他のクリエイターとそれほど違いはありません。 多くの人と比較して、ハッカーは幸運です。 絵画では、ファッションの影響がはるかに強くなります。

人々はあなたの仕事を理解していません-ひどいですが、もっと悪いことがあります。 あなた自身があなたの仕事を理解していない場合はさらに悪い。 アイデアを探して、関連分野を掘り下げます。 たとえば、コンピューターサイエンスの学部では、ハッキングは理論的なコンピューターサイエンスの理論の応用バージョンであると確信するのは非常に魅力的です。 大学院では、理論にもっと注意を払うべきであるという漠然とした考えに絶えず苦しめられ、最終試験の3週間後にそれを完全に忘れることは非常に無謀でした。

今、私は自分が間違っていたことを理解しています。 ハッカーが計算の理論を必要とするのは、アーティストが色の化学を必要とするのと同じです。 時間と空間の複雑さの計算方法、およびチューリングの完全性について知る必要があります。 パーサーまたは正規表現のライブラリを作成する場合、有限状態マシンの概念さえ覚えていても問題ありません。 実際、芸術家は塗料の化学組成をもっと覚えておく必要があります。

アイデアの最良の情報源は、「コンピューター」という言葉が現れる名前の領域ではなく、クリエイターによって作成された領域であることがわかりました。 絵画は、計算理論よりもはるかに豊富な情報源です。

例えば、私は大学で教えられました：コンピューターに近づく前に、プログラムは完全に紙に書き留められるべきです。 私が間違ってプログラムしたことがわかります。 紙の上ではなく、コンピューターの前でプログラミングするのが好きでした。 さらに悪いことに、エラーをチェックしてプログラム全体を辛抱強く書かず、絶望的に湾曲したコードを吐き出し、徐々に正常に戻しました。 彼らが教えてくれたデバッグは、タイプミスや脱落をキャッチする最後のアプローチです。 プログラミングが無限のデバッグのようになるように働きました。

長い間、私はこのことを心配していました-小学校で教えられたように鉛筆を持たなかったという事実の結果として。 他のクリエイター、アーティスト、建築家を見てください。私の手法にはスケッチという名前があることを理解しています。 私が理解している限りでは、大学ではプログラミングは完全に間違っていると教えられていました。 アーティスト、建築家、作家のように、執筆プロセスでプログラムを作成します。

この事実の認識は、ソフトウェア開発に本当に影響します。 プログラミング言語は、まず柔軟でなければなりません。 プログラミング言語-プログラムについて考えるためであり、既に考え抜かれたプログラムを定式化するためではありません。 ペンではなく鉛筆。 静的な型制御は、大学で教えられているように実際にプログラムされていれば、悪いことではありません。 しかし、私が知っているハッカーは一人もいません。 私たちは、落書きをしたり、しみをつけたり、洗ったりすることができる言語を必要とします。そして、データ型のカップに座って、厳しい年配の叔母コンパイラと丁寧に話すのが好きではありません。

静的制御について話しているので、ここにあります。 自分自身をクリエーターと呼び、科学を悩ませているもう1つの問題、en望から数学までを取り除きます。 科学者は誰でも、数学者のほうが賢いと信じています。 数学者はこれを他の人たちよりも劣らないと信じているようです。 しかし、最終的に、科学者たちは自分たちの研究を限界まで数学的に見せようとしています。 いくつかの物理学ではこれは問題ではないかもしれませんが、自然科学から遠くなるほど、問題は悪化します。

もちろん、式のページは印象的です。 （ヒント：表現力を高めるために、ギリシャ語の変数を導入します。）そして、重要な問題についてではなく、正式にアプローチできる問題に取り組むのは魅力的です。

ハッカーがクリエーター-ライターやアーティスト-を自分で見たら、そのような誘惑は起こらなかっただろう。 作家や芸術家は数学者にjeしていません。 彼らは数学とは全く関係のないことをしていると信じています。 ハッカーのように、私は思う。

大学や研究所では、ハッカーが好きなことをすることを許可していません-ハッカーは企業に居場所を持っているのでしょうか？ 残念ながら、ほとんどの企業はこれも許可していません。 大学と研究所は、ハッカーを科学者にし、企業をエンジニアにします。

私自身、最近これを発見しました。 YahooがViawebを購入したとき、彼らは私に何をしたいのか尋ねてきました。 私はビジネスの面があまり好きではなかったので、ハッキングだけに関与したいと言いました。 ヤフーに着いたとき、彼らにとってそれはソフトウェア製品を作成するのではなく実装することを意味することを発見しました。 それらのプログラマーは、マネージャーのビジョンを翻訳する技術者です（まあ、それを呼び出しましょう）。

大企業では、それだけのようです。 企業は、最終的に平均偏差率を下げるためにこれを行います。 真にソフトウェアを作成できるハッカーはごく少数であり、それらを把握するのは容易ではありません。 したがって、企業は将来のソフトウェア製品を独創的なローン会社に引き渡すのではなく、製品がグループによって作成されるようにすべてを手配し、ハッカーはそれを具体化するだけです。

あなたがお金を稼ぎたいなら、それを常に覚えておいてください-これがスタートアップが成功する理由の一つです。 大企業は、災害を望まないため、最終製品の平均偏差を減らします。 しかし、変動を均等化すると、下の極端だけでなく、上の極端も失います。 大企業にとって、これは冷たくも暑くもない。なぜなら、彼らは独創的な製品を犠牲にして勝てないからだ。 他の大企業ほどひどくないので、彼らは勝ちます。

そのため、ソフトウェアがプロダクトマネージャーによって作成されているかなり大きな企業との開発戦争に参加する方法を見つけた場合、その企業はあなたに追いつくことはありません。 唯一の機会-猫は泣いた。 大企業を開発戦争に引きずり込むことは困難です。要塞で掘った敵を白兵戦に引き込むことは困難です。 たとえば、ワードプロセッサの作成はMicrosoft Wordよりも優れていますが、難しいことではありませんが、Microsoftはオペレーティングシステムの独占という難攻不落の城で、おそらくプロセッサに気付かないでしょう。

誰も要塞を建てていない場合、新しい市場での開発戦争を繰り広げるべきです。 そこで、大胆な製品を作成し、同じ人がそれを作成して実装するよう手配することで、大きな勝利を収めることができます。 マイクロソフトは当初、このように機能していました。 そしてアップル。 そしてヒューレット・パッカード。 成功したスタートアップはすべてそうしていると思う。

したがって、優れたプログラムを作成する1つの方法は、独自のスタートアップを開くことです。 ただし、2つの問題があります。 まず、スタートアップでは、プログラムの作成に加えて、多くのことを行う必要があります。 Viawebでは、私は幸運にも、四分の一の時間ハッカーになっていた。

残りの4分の3の時間に、退屈なものからひどいものまで、たくさんのことをしました。 出発点がありました。ある日、私は理事会を辞めて印を押さなければなりませんでした。 ドリルを楽しみにして歯科用の椅子に座っていたのを覚えており、休暇中のように感じます。

別の問題は、お金をもたらすソフトウェアと、書くのが面白いソフトウェアがあまり重ならないことです。 プログラミング言語を書くのは興味深いことであり、本質的に最初のマイクロソフト製品は1つでしたが、今ではプログラミング言語の費用はかかりません。 お金が欲しいなら、誰も無料で解決できない問題に取り組む必要があります。

これは作成者の問題です。 価格は需要と供給によって決定され、作業に興味があるものは、すべての消費者が直面する地上の問題の解決策よりも需要が少なくなります。 彼らはゴリラの靴でフェアを走り回るよりも、ブロードウェイ以外のプレイをする方が安い。 小説を書くため-ガベージコレクションを宣伝するためよりも少ない。 また、ハッカーのプログラミング言語の場合-企業データベースをWebサーバーにフックするソフトウェアの場合よりも少ないです。

ソフトウェアの分野では、ほとんどすべてのクリエーターが知っている概念、つまりデイワークによって問題が解決されると思います。 このフレーズは、夜に演奏するミュージシャンによって紹介されました。 一般的に、これは、ある人がお金のために働き、別の人が愛のために働くことを意味します。

ほとんどすべてのクリエイターは、キャリアの初めにフルタイムで働いていました。 これはアーティストや作家で有名です。 運がよければ、実際のビジネスに関連する仕事を見つけるでしょう。 ミュージシャンはしばしば音楽店で働きます。 プログラミング言語またはオペレーティングシステムで作業するハッカーは、これらすべてが役立つ作業を見つけることができます。 [2]

もちろん、アイデアは新しいものではありません。 これは、すべてのオープンソースプログラミングが構築される場所です。 実際、オープンソースは適切なモデルかもしれません。他のすべてのクリエイターは、その正確性を独自に確認しています。

雇用主がハッカーがオープンソースプロジェクトに取り組むことを許可したがらない場合、私は驚くでしょう。 Viawebでは、しなかった人を渋々採用しました。 インタビューでは、プログラマーが空き時間にどのようなソフトウェアを作成するかについて最も興味がありました。 仕事が嫌いな人はうまく働けないでしょうし、ハッキングが好きな人は必然的に自分のプロジェクトに取り掛かります。 [3]

ハッカーは科学者ではなく作成者であるため、科学ではなく、他の作成者の間で比phorを探すべきではありません。 絵画は他に何を教えてくれますか？

まず、私たちが学ぶ絵画の例で-いずれにしても、ハッキングを学ぶ方法を確認します。 主に絵を描くことで、絵を描くことを学びます。 ハッキングについても同じです。 ほとんどのハッカーは、大学のプログラミングコースを勉強することではなく、独自のプログラムを作成することでこの技術をまったく学びません。13歳からです。 学校では、ハッキングのみを学びます。 [4]

アーティストはキャンバスを離れます。これにより、彼がどのように勉強したかを追跡できます。 アーティストの作品を時系列で考えると、後続の各写真には前の作品の経験が含まれていることが明らかになります。 原則として、初期の作品では、後の創造的な成功の胚が発見されます。

それがほとんどのクリエーターの仕事だと思います。 作家や建築家もそうです。 ハッカーがアーティストとして行動し、絶えずゼロから始め、1つのプロジェクトで何年も働いておらず、最新のアイデアをそれに当てはめようとする方が便利かもしれません。

ハッカーがこのプロセスで再び学習するという事実は、ハッキングと科学の違いを示しています。 科学者はその過程で科学を学ばず、研究室で研究を行い、タスクを策定します。 科学者は完璧な仕事から始めます-誰かが彼らのためにした仕事を再現しようとしているという意味で。 そして、彼らは最終的に独自の何かをすることができます。 ハッカーは、最初から何か独自のことをしています。 まだ悪いです そのため、ハッカーはオリジナルから始めて完璧に仕上げ、科学者は完璧から始めてオリジナルに仕上げます。

より多くのクリエイターが例から学びます。 アーティストにとって、美術館は芸術的手法の参考になります。 何百年もの間、芸術家の伝統的な訓練の要素は偉大な巨匠の作品をコピーすることでした。なぜならコピーすることで、キャンバスがどのように作られるかをより詳しく見るからです。

作家もそうしています。 ベンジャミン・フランクリンは、アディソンとスティールのエッセイの要点を要約し、それらを再現しようとすることを学びました。 レイモンド・チャンドラーは探偵小説でも同じことをしました。

また、ハッカーは、外部からだけでなく、ソースコードからも高品質のプログラムを学習することで、プログラミングを学ぶことができます。オープンソースプログラミングの最も知られていない利点の1つは、プログラミングトレーニングが大幅に簡素化されることです。私が勉強していたとき、私たちはほとんど本から例を学ぶ必要がありました。当時の唯一の大きなコードはUnixでしたが、それでもオープンソースではありませんでした。

それを読んだ人のほとんどは、1977年に書かれたジョン・ライオンズの本で違法コピーを研究しましたが、1996年にのみ出版を許可されました。

そして、ここに絵画が私たちに教えているものがあります。絵画は段階的な改善によって作成されます。通常、絵はスケッチから始まります。詳細が徐々に追加されました。しかし、追加されただけではありません。元の計画に誤りがある場合があります。多くの絵画では、X線でそれらを見ると、腕や脚が動かされたり、顔が再描画されたりします。

これは絵画から学ぶことができました。私の意見では、ハッカーはまさにそれをすべきです。プログラムの仕様が完璧であることを期待するのは愚かです。すぐに承認して、その場で仕様を変更するプログラムを作成する方が良いでしょう。
（大企業の構造ではこれが許可されていないため、スタートアップもここで有利になります。）

誰もが時期尚早な最適化の危険性を認識しているようです。時期尚早の開発を心配する理由があると思います-それは、プログラムが何をすべきかを決定するのが早すぎるからです。

適切なツールは、この危険を回避するのに役立ちます。油絵の具のような優れたプログラミング言語を使用すると、簡単に考えを変えることができます。動的な型制御は大きなプラスです。特定のデータプレゼンテーションをすぐに購読する必要はありません。しかし、柔軟性の鍵は、言語を非常に抽象化することです。短いプログラムは書き換えが簡単です。

パラドックスのように聞こえますが、すばらしいキャンバスは本来よりも優れているはずです。その中で、彼は各葉を注意深く処方しました。多くの芸術家は、それが単なる背景、頭のフレームだと思っていました。誰が茂みを綿密に研究しますか？


そうではないレオナルド。彼は各断片に慎重に取り組みました-とにかく、彼らは慎重にそれを調べるかどうか。彼はマイケル・ジョーダンのようでした。容赦ない。

容赦ないことが勝利への鍵です。見えない細部が一緒に見えるようになります。ジネヴラ・デ・ベンキの肖像を通り過ぎると、人々はしばしば「レオナルド・ダ・ヴィンチ」のサインのあるプレートを見さえせずに彼に注意を払います。目に見えない細部はすべて一緒に驚くほどの何かを形成します。

素晴らしいプログラムには、美への熱狂的な献身も必要です。優れたプログラムの内部を見ると、誰も見ないような断片でさえ、その中に美しいことがわかります。私は素晴らしいソフトウェアを書くと主張していません。ただし、コードで行ったのと同じように日常生活で振る舞うと、薬を処方されることになります。コードのフォーマットが適切でない場合、またはコードにい変数がある場合、私は恐れています。

ハッカーが仕様をコードに変換する単純な実行者である場合、彼はあたかも溝を掘るかのように最初から最後まで働きます。しかし、ハッカーが作成者である場合、インスピレーションを考慮する必要があります。

ハッキングでは、絵画のように、作業はサイクルで行われます。新しいプロジェクトがキャプチャされ、1日16時間動作する準備ができている場合があります。そして、時には何も本当にキャッチしません。

効率的に作業するために、これらのサイクルを忘れてはなりません。サイクルをどのように認識するかに依存します。手動のギアボックスを備えた車で上り坂を走行するとき、失速しないように減速する必要がある場合があります。リトリートはデザインを保存し、ストールしません。ペイントとハッキングの両方で、いくつかのタスクは恐ろしく野心的ですが、他のタスクは快適に普通です。単純なタスクを、それらなしで単純に死ぬ瞬間まで続けるのが賢明です。

ハッキングでは、これは文字通りバグを残すことを意味します。私はデバッグが好きです：デバッグ中、ハッキングは簡単で、誰もがそうだと考えています。特定の問題があり、それを解決する必要があります。プログラムはXを実行する必要があります。また、Yを実行します。何が問題なのですか？あなたは最終的にあなたが勝つことを理解しています。壁をペイントするようにリラックスします。

絵画は、私たち自身の仕事に対処するだけでなく、一緒に働くことも教えてくれます。過去の偉大な作品の多くは、数十人の手作業の成果であるが、おそらく博物館のプレートにはたった一つの名前しか現れていない。レオナルドは、ヴェロッキオの工房で学び、キリストの洗礼で天使を書きました。そのような場合は、例外ではなく規則でした。ミケランジェロは、システィーナ礼拝堂の天井にすべての人物を書くことを主張したため、特に熱心であると考えられました。


私の知る限り、キャンバスで一緒に作業しているアーティストは、同じ断片を決して書きません。通常、マスターは主人公とヘルパーを描いた-残りと背景。しかし、他の人の作品の上に書いた人はいません。

私の意見では、これはプログラミングにおける協力の成功モデルです。行き過ぎないでください。 1つのコードが3人または4人で作成され、実際には誰のものでもない場合、最終的にはある種の共通の部屋になります。放棄されたジョイレスは、ほこりを収集します。私の意見では、プロジェクトを厳密に定義されたモジュールに分割し、それぞれがモジュールを配布し、モジュール間のインターフェイスをプログラミング言語のようにきちんと、理想的には明確に開発する方が正しいと思います。

絵画のようなプログラムは、主に人々を対象としています。したがって、優れた作品を作成するには、アーティストなどのハッカーが共感できる必要があります。ユーザーの目を通して製品を見てください。

子供の頃、私は常に外国の観点から何かを見ることを勧められました。実際、これは常に、誰かが望むように行うべきであり、私が望むようにするべきではないことを意味していました。この共感から悪い評判を得て、私は彼に注意を払わなかった。

主よ、私はどのように間違っていました。他人の目を通して見る能力は、実際に成功への鍵であることが判明しました。共感は必ずしも自己犠牲ではありません。まったくありません。他人の視点を理解していても、他人の利益のために行動するという意味ではありません。いくつかの状況では-たとえば戦争では-あなたはまったく反対に行動します[5]。

ほとんどのクリエーターは人々のためにそうします。そして、視聴者を引き付けるには、必要なものを理解する必要があります。ほとんどすべての絵画において、人々は人々が人々に興味を持っているからです。

共感は、おそらく良いハッカーと素晴らしいハッカーの最も重要な違いです。一部のハッカーは非常に賢いですが、共感の点では-ただ独断主義者です。このような人々が優れたソフトウェアを作成することは困難です[6]。彼らはユーザーの目を通して製品を見ません。

人々に共感がどのように与えられているかを確認するには、技術について何も理解していない対話者に技術的な質問をどのように説明するかを観察します。誰もが知り合いであり、実際には賢明ですが、この問題をコミカルに解決することはできません。夕食時にプログラミング言語とは何かを尋ねると、彼らは次のように答えます。「まあ、高レベル言語は、コンパイラが入力でオブジェクトコードを生成するために使用するものです。」高級言語？コンパイラ？オブジェクトコード？プログラミング言語が何であるかを知らない人は、これらの単語を知りません。

ソフトウェアはそれ自体を部分的に説明します。したがって、優れたソフトウェアを作成するには、ユーザーがほとんど理解していないことを理解する必要があります。彼はわずかな準備をせずにソフトウェアを使用しますが、ユーザーが指示を読まないため、ソフトウェアがユーザーの期待を欺かず、必要なことを実行する方が良いでしょう。この観点から私が知っている最高のシステムは1985 Macです。彼はソフトウェアが通常はしないことをしました：それはただ動きました[7]。

ソースも自分自身を説明する必要があります。私は、単一のフレーズをプログラミングに関するティーチ人々に望んでいた場合、私は彼らに«プログラムの構造と解釈コンピュータ»の最初に与えられた引用を教えてくれる[8]は：

プログラムはそう人々がそれらを読むことを書かれて、そして時には唯一の-車はそれらを実行します。

共感は、ユーザーだけでなく読者にも必要です。それはあなたの利益のためです-あなた自身はそれらの1人になります。多くのハッカーは最初にプログラムを作成しましたが、6か月後、これらのプログラムがどのように機能するかわからないことがわかりました。そのようなケースの後の私の知り合いの何人かは、Perlで二度と書かないことを誓いました[9]。

共感の欠如は知性に関連している-特定のサークルではそれが何らかの形で流行しさえする程度に。私はそれらが何らかの形で相関するとは思わない。数学と自然科学では、共感をなくすことができます。そのような分野では、人々は通常頭がいいので、これらの2つの資質が集まっています。しかし、共感を得られない多くの馬鹿があります。トークショーで質問して電話をかける人の話を聞きます。彼らはこれらの質問を非常に曲がりくねっているので、ホストはしばしば彼らのために再定式化しなければなりません。

それで、ハッキングのメカニズム-絵画や文学のメカニズムと同じ-それはとてもクールですか？結局のところ、人生はただ1つです。おそらくそれを素晴らしいものに捧げた方が良いでしょうか？

残念ながら、簡単な答えはありません。栄光はいつもとても遅いです。遠い星の光のように。絵画は、500年前に作成された素晴らしい絵画で認められています。それから、これらの絵画は今日よりもはるかに重要性が低くなりました。当時、ウルビーノ公爵フェデリコ・ダ・モンテフェルトロが、ピエロ・デッラ・フランチェスコの写真で主に奇妙な鼻を持つ男として知られることは、人々にとって非常に奇妙に思えたでしょう。


はい、私は今、ハッキングは絵画ほどクールではないことを認めていますが、全盛期の絵画はそれほどクールではないことを覚えておく必要があります。

ある程度の確実性をもって、次のように言うことができます。今-ハッキングの全盛期。他のほとんどの領域では、素晴らしい作品が以前に作成されています。 1430年から1500年の間に作成された絵画は、今日に至っています。シェイクスピアは、プロの劇場が最初に登場したときに登場しました。シェークスピアは彼を、今日のどんな劇作家も彼の影に住むような高さに持ち上げました。アルブレヒト・デューラーは彫刻でも同じことをし、ジェーン・オースティンは小説でも同じことをしました。

これは何度も繰り返されます。新しい環境が生まれ、人々を捕らえるので、最初の数世代では能力のほとんどすべてを絞ることができます。どうやら、ハッキングは現在この段階にあるようです。

レオナルドの時代、絵は彼の作品ほどクールではありませんでした。ハッキングがいかにクールになるかは、この新しい環境で何ができるかによって異なります。あなたがそれについて考えるなら、認識の一時的な遅れは美徳です。コンパイラやUnixカーネルを書いている人と通信するとき、少なくとも、女の子が写真を撮るためにこれをしないことを知っています。

注釈

[1]ジョンソンはシェークスピア版の序文で次のように書いています。
「彼は、本の芸術的価値を評価するために通常測定される期間である世紀を長く生き延びてきました。個人的な言及、地元の伝統、一時的な意見など、どんな利点があっても、それらは何年も前に失われています。そして、人工的な生活様式が彼に提供したすべての楽しいトピックまたは悲しみの原因は、かつて彼らがかつてカバーしたシーンを不明瞭にするだけです。サポートとライバル関係の影響は終わりました。彼の友好的で敵対的な関係は忘却に沈みました。彼の作品は誰かの理性的な意見を支持せず、告発的なスピーチを確執に与えません。彼らは虚栄心にも苦味にもふけることはできませんが、喜びのためだけに読まれるので、喜びが受け取られた場合にのみ称賛されます... "

[2]写真が絵画で行った最悪のことは、おそらく最高の作品を破壊したことでしょう。偉大な芸術家のほとんどは、ポートレートを作成して生計を立てました。写真の登場後まもなく、雇われた写真家の登場により彼らの数は減った。 （この方法は、シッターと一緒に作業するときにも使いやすくなります。）ある程度のテクニカルアーティストのクラスは存在しなくなり、絵画の評価におけるスキルの役割は、名前の名声（写真、またはより正確には写真に大きく依存します）によってシフトしました本や雑誌に掲載されています）。

[3]マイクロソフトは、空き時間であっても、従業員がオープンソースプロジェクトに貢献するのを阻止しています。しかし、現在、オープンソースプロジェクトに取り組んでいる優秀な専門家が非常に多いため、このようなポリシーの主な結果は、一流のプログラマーを雇うことがより難しくなることです。

[4]大学でのプログラミングについて学ぶことは、本や服について学ぶことと似ています。はい、あなたは学校の味がまったくありませんでした。

[5]ここに適用された共感の例があります。Viawebで2つのオプションから選択できなかった場合、どちらが競合他社を混乱させるかを自問しました。競合他社が製品にオプションを追加すると、実際には役に立たないが、それは私たちが追加しなかった数少ないオプションの1つであり、プロのプレスでは競合他社について多くのことを書いた。このオプションは役に立たないと説明することもできますが、自分で実装した場合、競合他社はさらに動揺することになると判断しました。一般的に、私たちはその夜にバージョンを書きました。

[6]テキストエディタおよびコンパイラに加えて。彼らにとって、典型的なユーザーはハッカー自身であるため、ハッカーには共感は必要ありません。

[7]まあ、ほとんど。彼らはそれをメモリで少し上書きし、それが不便なスワップを引き起こしましたが、これは追加のハードドライブを購入することで簡単に数ヶ月で修正されました。

[8] Abelson、Harold、およびGerald Sussman、「コンピュータープログラムの構造と解釈」、MITPress、1985年。

[9]プログラムの読みを単純化することは、それらをコメントで詰まらせることを意味しません。EbelsonとSassmanの考えを発展させます。プログラミング言語は、アルゴリズムを表現するために、ときどき-コンピューターにそれらの実行方法を伝えるために作成する必要があります。優れたプログラミング言語は、英語よりもソフトウェアをよく説明します。コメントが必要なのは、矢印が急な曲がり角だけにぶら下がっている道路のように、プログラムに読者に通知する必要がある何らかの過失がある場合のみです。