昨日と今日、linenoise（http://github.com/antirez/linenoise）と向き合う時間を少し持つことができた。readlineのシンプルで小さな代替となることを目指して作られた、最小限のライン編集ライブラリだ。
いくつかのプルリクエストをマージし、不具合を修正し、同時にリファクタリングも進めていた。そこで感じたのは、一種の涅槃のような感覚だった。小さく、自己完結していて、しかも役に立つコードを完全にコントロールしているという感覚だ。

シンプルなコードには、何か特別なものがある。ここで言っているのは、複雑さや過剰設計と戦うためのシンプルさではない。シンプルさそれ自体、自己目的的で、美しさ、理解しやすさ、そしてエレガンス以外に目的を持たないシンプルさのことだ。

そもそもプログラミングの世界は、昔から小さなプログラムに魅了されてきた。何十年ものあいだ、プログラマーたちは1kや4kといった制約の中で競い合ってきた。6502のアセンブラから今日のJavaScriptコンテストまで。
あの難読化Cコンテストでさえ、ミニマリズムが大きな要素を占めている。

なぜ小さなコードをいじるのはこれほど素晴らしいのだろうか。小さくてシンプルだということ、それだけで二つの良い点になる。完全に理解し、支配することができる。小さなコードは、気の利いた工夫が報われる世界で唯一の場所だから、思い切り賢さを発揮できる。大規模なプロジェクトでは、長い目で見れば分かりやすさの方がはるかに重要だからだ。しかし、それだけではないと私は思う。小さなプログラムは完璧になり得るのだ。わずかな言葉で紡がれたソネットのように完璧に。サイズやスコープの制限は、「もっと良くできるかもしれない」という罠を避けるための知的な策略となる。その「より良い」が実際には測定もできず、明らかでもないときに。こうした厳しい制限の下では、プログラムが「やらないこと」よりも「やること」の方がはるかに興味深くなる。実際、制約こそが、そうでなければ無用になりかねない解法の創造性にとって最も肥沃な土壌なのだ。スケールが大きくなれば、何をするにも常により正しく、よく理解され、正統とされるやり方があるのだから。

マイクロソフト創業初期のビル・ゲイツのインタビューで、彼が有名なMicrosoft BASICインタプリタを書いていたときのこの感覚について語っているものがある。当時の制限は、今日私たちが楽しみのために、コンテストで、あるいはただそれ自体のために自らに課している制限と同じだった。自分たちの創作物において完璧さを経験できたプログラマーの世代がいたのだ。そこでは、ある変更が本当にプログラムの改善につながったかどうかを測り、理解することが明白だった。空間と時間が極端に乏しい領域で。そこには無駄や不要な複雑さが入り込む余地などなかった。

今日のソフトウェアは、ある意味で、ソフトウェアのもう一つの現実の勝利である。複雑さの層が重なり、専門家でない人々の手の中でも数多くの可能性を引き出す、驚くべきデバイスやインフラ技術をもたらしたのだ。しかし、ソフトウェアが完璧であり得た古き時代から、今も守るべきものがあるのかもしれない。自分が作っているものには構造があり、単に動くコードの寄せ集めではないという感覚だ。十分に引いて見れば、大きなプログラムもまた実際にはとても小さく見えてくる。そして少なくともそのスケールでは、それは完璧さに似ていなければならない。少なくとも、完璧さを目指すべきなのだ。