プログラミングのボトムアップ

1993年1月

(このエッセイは、On Lisp* の序文からのものです。)*

プログラムの機能要素は大きすぎない方が良いというプログラミングスタイルの原則は、長い間存在しています。プログラムの構成要素が、容易に理解できる範囲を超えて大きくなると、それは、大都市が逃亡者を隠すように、エラーを隠してしまう複雑さの塊になります。このようなソフトウェアは、読みづらく、テストしづらく、デバッグしづらくなります。

この原則に従って、大きなプログラムは、いくつかの部分に分割する必要があります。プログラムが大きければ大きいほど、分割する必要があります。プログラムをどのように分割するか？伝統的なアプローチは、トップダウン設計と呼ばれます。「プログラムの目的は、この7つのことを行うことなので、7つの主要なサブルーチンに分割します。最初のサブルーチンは、この4つのことを行う必要があるため、さらに4つのサブルーチンを持つことになります。」というようにです。このプロセスは、プログラム全体が適切な粒度になるまで続きます。各部分は、何か実質的なことを行うのに十分な大きさですが、単一のユニットとして理解できるほど小さいです。

経験豊富なLispプログラマーは、プログラムを異なる方法で分割します。彼らは、トップダウン設計に加えて、ボトムアップ設計と呼ばれる原則に従います。つまり、問題に合わせて言語を変更します。 Lispでは、単にプログラムを言語に向かって書き下すだけでなく、言語をプログラムに向かって構築していくのです。プログラムを書いていると、「Lispにこんな演算子があればいいのに」と思うことがあります。そこで、その演算子を作成します。その後、新しい演算子を使用すると、プログラムの別の部分の設計が簡素化されることに気づき、というようにです。言語とプログラムは、一緒に進化していきます。戦争中の2つの国の国境のように、言語とプログラムの境界線は、引き直され、最終的には、問題の自然な境界線である山や川に沿って落ち着きます。最終的に、プログラムは、言語がそのプログラムのために設計されたかのように見えるようになります。そして、言語とプログラムが互いにうまく適合すると、明確で、小さく、効率的なコードが得られます。

ボトムアップ設計は、単にプログラムを異なる順序で書くだけではないことを強調しておく必要があります。ボトムアップで作業すると、通常は異なるプログラムが得られます。単一の巨大なプログラムではなく、より抽象的な演算子を持つより大きな言語と、その言語で書かれたより小さなプログラムが得られます。リンテルではなく、アーチが得られます。

典型的なコードでは、単なる帳簿処理の部分を抽象化すると、残りははるかに短くなります。言語を高く構築すればするほど、トップダウンで言語に到達するまでの距離は短くなります。これには、いくつかの利点があります。

ボトムアップ設計は、言語に多くの作業をさせることで、より小さく、より機敏なプログラムを生み出します。短いプログラムは、それほど多くのコンポーネントに分割する必要がなく、コンポーネントが少ないということは、プログラムが読みやすく、変更しやすいということです。コンポーネントが少ないということは、コンポーネント間の接続も少なくなり、エラーが発生する可能性も低くなります。工業デザイナーが機械の可動部分を減らすように、経験豊富なLispプログラマーは、ボトムアップ設計を使用して、プログラムのサイズと複雑さを減らします。

ボトムアップ設計は、コードの再利用を促進します。 2つ以上のプログラムを作成する場合、最初のプログラムのために作成したユーティリティの多くは、後続のプログラムでも役立ちます。多くのユーティリティの基盤を手に入れると、新しいプログラムの作成は、生のLispから始めなければならない場合よりも、はるかに少ない労力で済むようになります。

ボトムアップ設計は、プログラムを読みやすくします。

このタイプの抽象化の例は、読者に汎用的な演算子を理解させることを要求します。機能的抽象化の例は、読者に特殊な目的のサブルーチンを理解させることを要求します。[1]

ボトムアップで作業すると、常にコードのパターンを探しているので、プログラムの設計に関するアイデアを明確にするのに役立ちます。プログラムの2つの離れたコンポーネントが形式的に似ている場合、その類似性に気づき、プログラムをより単純な方法で再設計するよう促されます。

ボトムアップ設計は、Lisp以外の言語でも、ある程度までは可能です。ライブラリ関数を見ると、ボトムアップ設計が行われています。しかし、Lispは、この分野でより広範な権限を与えており、言語の拡張は、Lispスタイルにおいて、比例的に大きな役割を果たしています。Lispは、単なる別の言語ではなく、まったく異なるプログラミングの方法なのです。

確かに、この開発スタイルは、小規模なグループで書かれたプログラムに適しています。しかし同時に、小規模なグループでできることの限界を押し広げています。The Mythical Man-Monthで、 Frederick Brooks は、プログラマーのグループの生産性は、その規模に比例して増加するわけではないと主張しました。グループの規模が大きくなると、個々のプログラマーの生産性は低下します。Lispプログラミングの経験は、この法則をより楽観的な言い回しで表現することを示唆しています。グループの規模が小さくなると、個々のプログラマーの生産性は向上します。小規模なグループは、単に規模が小さいという理由で、相対的に有利になります。小規模なグループが、Lispによって可能になったテクニックを活用すると、完全に勝利することができます。

新着: On Lispを無料でダウンロード。

[1] 「しかし、誰もあなたの新しいユーティリティをすべて理解せずに、プログラムを読むことはできません。」このような主張がなぜ通常は誤っているのかについては、第4.8節を参照してください。