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

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

そもそもプログラミングの世界は、常に小さなプログラムに魅了されてきた。何十年ものあいだ、プログラマーたちは1Kや4Kという制限の中で競い合ってきた。6502のアセンブラから、今日のJavaScriptコンテストまで。
突き詰めれば、難解なC言語コンテストでさえ、その大きな要素はミニマリズムにある。

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

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

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