プログラムは短い方が良い

ずいぶん前の話ですが、SoftEtherの登氏が2007-03-24で、「1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる」とおっしゃっていました。まぁ、この記述自体は当該エントリの趣旨とは関係ないのですが、「たくさんプログラムを書く」ことを自慢している（？）所に、ちょっと違和感のようなものを感じたりしました。

それに対して、Life is beautifulさんの所のエントリ（Life is beautiful: ２万行のソフトウェア・プラットフォームは可能か？）では、アランケイの以下の言葉を引用して、（システムは短いソースコードで構成されるべきだという）思想に同意しています：

…同じことが2万行程度でできるはずである。2万行であれば一冊の本に印刷することができるし、数冊の説明をつければ1人の人間がすべてを理解することができるはずである。我々がNSFからの資金を受けてこれからやろうとしているのは、2万行でOS、グラフィックスシステム、ネットワークシステムからエンドユーザーシステムまですべてを書いたようなシステムを作ることである。

僕の感覚もこれに近い。というか、同じことができるプログラムなら、短い方がいいに決まってます。

なぜそうあるべきか、どうやって短くする・できるのかということに関しては、人によって意見が異なるかも知れません。僕が考えるポイントは、以下の通り。

まず一つ目は「適切な抽象化がなされているか、利用されているか」という点。"Computer science is a science of abstraction"とAhoとUllmanも言っています（文脈は違うかも？）。プログラムの部分部分を適切に抽象化し、冗長性の無いようにプログラムすれば、そうそうコードサイズは大きくならないのではないかと思います。また、ライブラリを使ってコード量が減るのなら、そうあるべきだと思います。すでにある抽象の界面を利用する、ということで。例えば、JavaでHashを自分で実装するのはナンセンスですよね。Cならともかく。

PARDSもサイズとしては十分小さいものだと思います。"fork"によるプロセス生成やスケジューリングという肝のところをOSの提供する機能を利用している所がポイントだと思います。

もう一つが、「問題解決するのにゴリゴリコードを書くより、短く見通し良くプログラムできる考え方を思いつく方がえらい」という価値観でしょうか。
例えばコンパイラの世界だと、SSA (Static Single Assignment)という考え方があります。コンパイラが最適化する際、変数の生死や依存関係を調べる必要があるのですが、いちいち文をたどるのは面倒です。そこで、最初に「代入は字面上1回だけ」になるよう、変数の名前を付け替えることで、この解析を簡単にするのがこの手法です。
ゴリゴリコードを書けば実現できることではあるのですが、見通しよく実現できる方法を提案したという点で、素晴らしい考え方であり、評価されているのだと思います。

そういう意味で、プログラムは「コーディングする」時点よりも、そこに至る前の「設計」の方がより重要です。その時点でどう抽象化するか、どういうアイデアを利用してプログラムするかがすでに決まっているはずなので。

まぁ、僕も若い頃はゴリゴリ腕力を使うのが好きだったのですがネ。