# 人気の言語を作るには（原題: Being Popular） Paul Graham, May 2001（新しい Lisp のための一種のビジネスプランとして書かれた） **中心主張**: プログラミング言語はハッカーのものであり、ハッカーに好まれてこそ言語たりうる。だから良い言語を作りたければ、定理やコンパイラ設計ではなく、ハッカーを観察して彼らが何を欲しているかを学ぶべきだ。人気は言語の良さと無関係ではない——良い言語であり続けるには人気が必要で、人気があるには良い言語である必要がある。 **実践指針** - 言語や道具を設計する場面では、優れたハッカーの意見だけを聞け。普通のプログラマの多数意見は指標にならない。優れたハッカーは少数だが、他のプログラマが何を使うかを決める立場にいることが多い。 - 新しい言語を広めたい場面では、まず**独立した20人のユーザ**を目標にせよ。0から20は20から1000より難しい。最良の方法はトロイの木馬——人々の欲しいアプリケーションを、たまたまその言語で書いて提供することだ。 - 言語を設計する場面では簡潔さを最優先せよ。ハッカーは無意識に「予測される総タイプ量」で言語を選んでいる。`add x to y giving z` のような冗長な英語風構文は侮辱と受け取られる。 - 抽象化を設計する場面では、ユーザを自分のミスから守るのではなく、設計者が考えもしなかったことを実現する天才として扱え。ランタイムを壊すぎりぎりまで内部へのアクセスを開けておく。「後から批判され修正されることを恐れるな」。 - 言語を普及させたい場面では、**書き捨てのプログラム**を書くのに適した言語にせよ。大きなシステムはそこから始まる。ゼロから巨大なものを設計すると泥沼になるか、貧弱な結果に終わる。 - 速いコードが欲しい場面では、強い型付けやコンパイラ最適化より**非常に良いプロファイラ**を作れ。ボトルネックの位置はプログラマがよく読み違える（Knuth）。 - 新しいものを発明した場面では、何年もメッセージを繰り返す覚悟をせよ。人が注意を払うのは、あなたがそこに居ると気付いた時ではなく、**まだそこに居る**と気付いた時だ。 - 設計を良くしたい場面では、再デザインの回数を確保せよ。ユーザは改善の助けであると同時に改善を止める要素でもあるから、慎重に選びゆっくり増やす。委員会は再デザインを不可能にするので避ける。 - インタフェースを設計する場面では、水平でなく**垂直**に設計せよ。モジュールを抽象化の階層として上下に積めば、下のモジュールが上のモジュールの使う言語となり、インタフェースの責任が片方に定まる。 **根拠となる事例・考え方** - 外部要因: 人気が出る言語は「人気のあるシステムのスクリプト言語」である。Fortran/Cobol は初期IBMメインフレーム、C は Unix、Perl も後にそうなり、Tcl は Tk、Java と JavaScript はブラウザのスクリプト言語として構想された。Lisp は MIT のスクリプト言語だった1960〜70年代の名残で人気を保っている。Common Lisp が孤児（Lisp Machine と共に沈んだ）なのが不人気の一因。 - 言語には、フリーの実装、良い本（薄く、良い例が詰まったもの。K&R が理想）、そしてハックすべきものが必要。オライリーから本が出ているかがハッカーの関心を測るテストになりつつある。 - ハッカーは意図されたモデルを破りたがる。それは問題を解決できるからだけでなく、外科医が内臓をのぞき込む時のような密かな快感があるからだ。Lisp は歴史的にこれがうまく、初期の Lisp は何でもありだった。 - 健全なマクロ (hygienic macro) は変数の捕捉から守ってくれるが、変数の捕捉こそマクロでやりたいことの一つである、と著者は批判する。 - 書き捨てのプログラムは第二次大戦中に建てられた「一時的な」大学の建物のように、捨てられず使われ続けて本物のプログラムへ進化する。Perl はレポート生成ユーティリティ集として産声を上げ、書き捨てが大きくなってから言語へ進化した。 - ライブラリの重要性: 今後50年の言語の進化はライブラリ関数に関するものになる。ライブラリはコア言語と同様、小さく直交性の高い操作で設計され、「どのライブラリが欲しい機能を実行するか推測できる」必要がある。Common Lisp の失敗点はここ（原始的な文字列ライブラリ、OSアクセスの欠如）。 - 有機的成長 vs ビッグバン: Multics と Common Lisp はビッグバン型、Unix と MacLisp は有機的成長型。今日有力な技術の大抵は有機的に成長したもの。 - 発展の二サイクルエンジン: 第一フェーズでは「こんなの簡単だよ」という無邪気な確信で狂ったように取り組み、第二フェーズでは「こんなのうまくいきっこない」と冷たい朝日の下で欠陥を見つめる。この楽観と懐疑のバランスが自転車を漕ぐようにプロジェクトを進める。 - 「最も良い書き方は書き直すことだ (The best writing is rewriting)」（E. B. White）。散文は作者が満足するまで書き直されるが、ソフトウェアには**ユーザ**がいるため十分に再デザインされない。 - 夢の言語像: 美しく、明快で、簡潔。会話的なトップレベルを持ち素早く立ち上がる。小さなコアと、コアと同じくらい慎重に設計された強力で直交性の高いライブラリからなる。抽象化の高い層は低い層から透過的に構成され、必要なら低い層を直接叩ける。プログラマを言語設計の参加者として扱い、プログラマの書いたものは可能な限り組み込みと同じ地位を得る。 **キーワード** - **臨界点となる初期ユーザ層 = 20人**: 言語が本物になるのに必要な、自分でその言語を選んだ独立ユーザの数。 - **トロイの木馬**: 最初の20人を得る方法。欲しいアプリケーションを、たまたまその言語で書いて配る。 - **書き捨てのプログラム (throwaway program)**: 限定された仕事のために手早く書くプログラム。大きなシステムはここから育つ。 - **健全なマクロ (hygienic macro)**: 変数捕捉を防ぐ安全なマクロ。著者は「プログラマの望むところを規定しようとする危険思想の古い例」と批判。 - **アクティブプロファイラ**: 求めた時だけでなく、常にパフォーマンスデータをプログラマに示し続けるプロファイラ（例: エディタがボトルネックを赤く表示する）。 - **有機的成長 vs ビッグバン**: 少数ユーザと口コミで育つ技術と、資本と宣伝で一気にユーザベースを得る技術。前者の方が結果的に良い技術と支持者を得る。 - **二サイクルエンジン**: 楽観（問題は解ける）と懐疑（この解では不十分）を交互に回すことで設計を前へ進める心の運動。