"ハッカーと画家" Paul Graham 著

お盆は酒びたりである。今日も朝っぱらから飲んでいる。ウィスキーの綺麗な琥珀色に、日の出間近の薄明るさが交わると、夕日に見えるので、時間としては全く問題ない。そして、ほど酔い気分で本棚を眺めていると、なんとなく読み返したい本を見つけた。本書は、数年前に読んで感動したような気がする。世間が夏休みの間に処理しておくのも悪くない。過去に良書と思ったものは、なるべく記事に残していきたい。

本書は、タイトルが示すとおり、ハッカーと画家の類似性について語る。つまり、優秀なプログラマは芸術のセンスを持っているということだ。これは、科学者や数学者にも見られる。科学者は、自然法則を見つけるために、芸術的な実験方法を模索する。数学者はエレガントなアプローチで証明に迫る。ハッカーというと、一般的にはコンピュータに侵入する連中と思われがちだが、コンピュータの世界では優れたプログラマのことを指す。Hackという言葉には、達人を思わせる臭いがあり、なんとなく知的好奇心をくすぐられる。最近、Hackという言葉が専門書の間で賑わっているのも、優れた世界に触れてみたいという表れであろう。実際に接したエンジニアでも10倍ぐらいの能力差がある。それが、ハッカーとなると平気で100倍以上は違うのだろう。おいらは優れたハッカーを知らない。ハッカーは優れたハッカーと一緒に仕事をしたがる習性があるという。類は友を呼ぶということか。ところで、ハッカーを見分ける方法はあるのだろうか？履歴書なんか見ても無駄だ。一緒に仕事をしてみるしかないだろう。しかし、おいらには優秀過ぎる人間は宇宙人に見える。そう言えば、宇宙人のような発想をする人に何度か出会った。ひょっとすると彼らがハッカーかもしれない。企業は、優秀な人材を集めるために、履歴書を見て面接をする。面接官は、なぜ技術者の生産物を検分しようとしないのだろうか？ハッカーの生産物が芸術作品であるならば、その芸術を理解できる人間でないと見分けられない。良い製品を造る上で、良いデザイナーを集めれば、解決するという考えがある。しかし、良いデザイナーって誰が見分けるんだ？かつて「成果主義」という言葉が世間を賑わした。成果って誰が評価するんだ？プログラマは、優れたハッカーになりたいと願う。では、どうすればなれるだろうか？賢くなる方法は分からないが、馬鹿になる方法は分かる。プロジェクトの成功例はあまり役に立たないが、失敗例は参考になることが多い。世の中には、実に多くのハウツウものが出回る。しかし、成功例は複雑系の中にあり、そこにある偶然性を見極めなければならない。

本書を読んで、少しでも優秀な人と関わった気分になれるのは幸せなことである。ハッカーは、一般的にはオタクで野暮ったいと見られがちだ。しかも、異端児で天邪鬼と言われ、多くの管理者に嫌われる。こうした印象だけなら、おいらと大して変わりはない。しかし、本書は、表面的には無秩序のように見えても、隠された秩序があるという。そこには、外見は汚くても、生成されるコードは緻密で、極めて神経質な世界がある。本書は、プログラムコードは、都市計画のように慎重に計画して組み立てるものではないという。それは、画家がスケッチするように、使い捨てを覚悟でコードを書き始め、徐々に詳細化していく。作品を創りながら理解してくところは、むしろ芸術に近い。慎重に計画して仕事をすれば、当初のアイデアを精密に実現できるだろう。だが、当初のアイデアというものは大抵間違ったものとなる。技術業界で仕様変更はつきものだということは、ほとんどの人が理解しているだろう。そこで、できるだけ早くプロトタイプを提示し、改善していくといった手法がとられる。そこには、新しいアイデアをどんどん取り入れるといった柔軟性が現れる。本書は、作成の過程で新しいアイデアを受け入れることは、なによりも士気を保つことができるという。士気の持続しないところに良いデザインは生まれない。芸術作品は決して完成することはない。
本書は、ソフトウェアには、「Just Do It! (とにかくやる)」という思想があると語る。個人主義的で、不服従的な性格がなければ、芸術は現れない。多くの管理者は、従業員の不服従な態度を警戒するが、ハッカーにとって不服従は独創性の副産物に過ぎない。技術の仕事には、なによりも革新が必要である。本書は、革新と異端は実質的には同じ方向にあるという。優れた技術者は、全てを疑問に思う習慣がある。本書は、社会にうまく適合できず偶像崇拝を嫌う者が、ハッカーになりやすいと語る。おいらは、思考をある程度まとめてからでないとプログラムが書けない。頭が悪い人間には、ある程度の方向性を定めないと作業ができない。それでも、考えてみれば、とりあえず使い捨てのコードを書いたりする。厳密な仕様書を書かないと作業する気がしないと言いながら、最初に書く仕様書は実にいい加減なものだ。ドン臭いおいらでも、本書にはなるほどと思わせるところが多い。ただし、酔っ払いは、世間のお邪魔にならないように心掛けなければならない。

本書で、技術者として興味を惹くのは、プログラミング言語に関する問題である。ハッカーが、芸術家のように、生産物を作りながら理解していくならば、その手段であるプログラミング言語は柔軟でなければならない。プログラムは使う言語によって何を言えるかが決まる。日常言語にしても、思考によって発達するものだ。必然的に言語選択は、プログラマの思考方法に大きな影響を与える。状況に応じて最適な言語を選ぶことは、有効なビジネス手法の一つと言えるだろう。本書は、ハッキングする上で、プログラミング言語以上の方法はないと語る。
「実はハッカーというのは、言論の自由に対してものすごく執着するものなんだ。」
仕事の要求が高ければ、それだけ優れた言語を使う意味は大きい。しかし、実際には、それほど要求の高くないプロジェクトがゴロゴロしている。よって、慣れ親しんでいる言語を使ったり、流行を追いかけるのも悪い選択ではないだろう。過去の資産や、政治力によって強要されることもある。プログラミング言語には宗教のようなところがあって、洗脳されるケースも多い。実際にExcelをI/Fにして、データ解析している者もいる。ただ、近寄りたくはない。ところで、人気のある言語はそれに見合っているのだろうか？そもそも良い言語の定義とは何か？本書は、それを理解する方法は、ハッカーが何を欲しがっているかを観察することで得られるという。大抵の人々は言語の利点で選ぶことはない。また、ハッカーが良いと考える言語が、一般的に支持されるとは限らない。技術の進化は速い。しかし、人間の扱う言語の進化は遅い。言語は人間の思考に深く結びつくからである。プログラミング言語にも同じことが言えるだろう。数学や科学は、人間が分かりやすくするために抽象化方法を選ぶことはない。単に証明を短くするために抽象化方法を選ぶ。しかし、芸術は人間が理解するためのものであり、デザインは人のためにする。本書は、言語は使いやすいものでなければならないと語る。
言語の論争には二つの派閥がある。一つは、プログラムの間違った行いを防ぐべきだとする考え、もう一つは、プログラムのやりたいことは何でも許すべきだとする考え。以前、「オブジェクト指向」という言葉が流行した。そこには、プライベート情報を隠蔽する概念がある。ただ、C++には、フレンド関数によって覗き見することが許される。おいらは人見知りが強いので、C++となかなかフレンドリーになれない理由である。

1. ハッカーと画家
ハッカーと画家は、どちらも良いものを創ろうとしている点では共通している。本書は、ハッカーにとって、コンピュータは単なる表現の媒体に過ぎないという。そして、ハッキングの最良の形態は仕様を作ることだと語る。多くのプログラマは、仕様変更を想定しながら書き進めるだろう。ソフトウェアで、早期の最適化の危険性を知っている人も多い。そこで、柔軟性を持たせるために、なるべく抽象化しようとする。プログラマの生産性が、コードの行数で測られるのはナンセンスである。偉大な画家が観賞者が見ないところにも気を配るように、ハッカーもプログラムの書き方にこだわる。これがプロ意識というものだろう。本書は、「ソフトウェア工学」という言葉が、ハッカーをエンジニアと誤解させていると語る。しかし、多くの企業では、ハッカーをエンジニアとして強要する。プログラマは、管理者のビジョンをコードへ翻訳する技師と見なされる。そして、仕事のやり方を規制することによって、一定の生産性と品質の確保を求める。大企業が、生産性のばらつきを抑えるのは、大失敗を避けたいからである。しかし、ばらつきを抑えると、低い点は無くなると同時に高い点も無くなると語る。

2. 共感能力
芸術作品には、人を惹きつける何かがある。それは観賞者の気持ちを理解しているということだろう。そこには共感能力がある。ハッカーと偉大なハッカーの違いは、この共感能力の違いだという。ハッカーの中には、非常に賢いが共感できず自己中心的な人間がいる。そして、ユーザの視点でものを見ることができない。共感能力のないところに、偉大なプログラムは生まれないという。共感能力を見る良い方法は、技術知識のない人に、技術の説明をしている様子を観察することだという。能力が優れていても、滑稽なほど説明の下手な人がいる。ユーザに対する共感と、コードを読む人に対する共感が必要である。コードを他人に読まれることは、自分のためにもなる。著者は、人に説明することが難しいことから脱Perl宣言をした人を多く知っているという。

3. プログラミング言語
プログラミング言語は、どれを選ぶのが最適だろうか？尽きない論争である。用途によって、より効果的な言語は存在するだろう。酔っ払いには、動的な記憶領域の管理などランタイムに任せるのが身のためだと考えている。したがって、スクリプト言語を多用する。だが、自分で書いたPerlは暗号に見える。しかも、脳の中に暗号解読機がないから困ったものだ。言語を選ぶ上で、有効なものに抽象レベルがある。ハードウェアが進化すれば、より高レベルの言語を選択するケースも増える。動作効率を考慮したければ、低レベルの言語を使えば高速なコードが得られる。また、特定の問題を解決するために、豊富なライブラリを具えた言語で開発効率を上げることも検討するだろう。最初に書くプログラムは、最低限の努力ででっち上げたいものだ。本書は、非効率性とは、マシン時間を無駄にするのではなく、プログラマの時間を無駄にすることだと語る。

4. Lisp
著者は、実際にLispを使って素早く開発し事業に成功したと、その魅力を熱く語る。現代のプログラム構造は、動作部からデータ構造へと注目点が移った。本書は、Lispハッカーは、データ構造を柔軟に持つことの価値を知っていると語る。そして、最初のアプローチで、なんでもリストで処理するように書くことが多いという。ところで、どこまでデータ構造を抽象化できるだろうか？配列は、ハッシュテーブルのキーが整数のベクタであると考えることができる。更に、ハッシュテーブルもリストに置き換えられるのだろうか？数値というデータ型も、整数nはn個の要素を持つリストとして表現できる。そして、基礎的なデータ型から数値を取り除くことができるのだろうか？Lispの抽象度は非常に高いらしい。本書は、Lispを学べば、実際にLispプログラムを作ることがなくても良いプログラマになれると語る。リスト型の言語には、データ構造の本質でも覗かせてくる何かがあるのだろうか？おいらには、Emacs-Lispを、数十行書いたことがある程度で、全く経験がない。いずれ挑戦してみたいと考えているが、なかなか手を付けないでいる。それも、括弧だらけの奇妙な構文を見るだけで、なんとも怪しげな香りがするからだ。本書は、奇妙な構文というより、構文そのものが無いと言った方がいいという。高級言語の中にも抽象度の差がある。あらゆる高級言語が機械語よりも強力であることは誰もが認めるだろう。中でもLispが最も強力だという。そんなに強力ならば、なぜみんなが使わないのか？全ての高級言語の中から、力の差を把握できるのは、最も強力な言語を理解した者だけだという。Lispが最も強力な言語というのが事実ならば、Lisp使いにしか分からないということか。大抵のプログラマは、使っている言語に大きな不自由を感じなければ、それで我慢する。Lispの最大な武器はマクロで、これが多くの括弧と深い関係にあるのだという。マクロ機能は、ほとんどの言語でサポートされるので、真新しいものを感じないが、Lispのマクロは特有らしい。Lispのコードは、Lispのデータオブジェクトからできているという。ソースコードは、パーサに呼び込まれると、人が解析できるデータ構造になる。他の言語なら、コンパイラが構文解析をして、内部に構文木を作る。ところが、Lispは直接プログラムとして書き下すという。構文木はプログラムからアクセスできるので、構文木を直接操作できるということらしい。Lispでは、これをマクロと呼ぶそうだ。本書は、Java、Perl、Python、Rubyと登場した順を見ていくと、だんだんLispに近づいているという。ただし、Javaをけちょんけちょんに貶しているあたりは、ストレス解消に良い。優れたものでも、早く登場しすぎて、時代に受け入れられないものがある。もし、Lispがそんなに良いものであるならば、少しずつ近づく言語が登場して大衆を誘導するのかもしれない。それが、PythonだったりRubyだったりするのだろうか？

5. ハッカーが求めるもの
科学者や数学者がそうであるように、ハッカーは簡潔さを求める。簡潔さは、抽象度を上げることによって得られる。そもそも高級言語を使う理由がここにある。本書は、プログラムを眺めて、より少ないトークンで表現できないかを常に自問するべきだと主張する。究極の簡潔さは、すでにライブラリで用意されていて、それを呼ぶだけというものだろう。だが、ライブラリがやたら多く、探すのに苦労したり、使い方がへんてこなものでは困る。本書は、ハックのしやすさを強調する。つまり、プログラマがやりたいことがやれることが重要だという。良いプログラマは、しばしば危険で不道徳なことをする。それは、高レベルで抽象化されたデータの内部構造をいじってみるといったことだ。ハッカーはハックするのがお好きである。これは知的快感という人間の心理を反映している。そして、プログラミング言語は、書き捨てのプログラムを書くのに適したものを求めるという。大きなプログラムを書く手法は、書き捨てのプログラムから始めて改善し続ける。これは、Perlの例が印象的で、Perl自身が書き捨てのためのプログラムだったという。