1993
（このエッセイはOn Lispの序文からである。赤いテキストはArcの名前の起源を説明している。）
プログラムの関数要素は大きくしすぎるべきではない、というプログラミングスタイルの原則に基づいている。 もしプログラムのある部品が簡単に理解できる大きさを超えて肥大すると、大都市が逃亡者を隠すのと同じくらい容易に誤りを隠す複雑さの固まりになってしまう。 そのようなソフトウェアは読みにくく、テストしづらく、デバッグしにくい。
この原則によると、大きなプログラムは小さな塊に分割しなければならない、そしてプログラムが大きければ大きいほどさらにそれを分割しなければならない。 どうやってプログラムを分割するか？ 伝統的なアプローチはトップダウンデザインと呼ばれる： あなたはこう言うだろう、「プログラムの目的はこれらの7つをすることなので、7つの主要なサブルーチンに分割する。 最初のサブルーチンはこれらの4つのことをしなければならないので、それには、それ自身の4つのサブルーチンが順番にあり」 、などなど。 全体のプログラムが正しい粒度になるまでこのプロセスが繰り返される。 －－各部分は何か実質的なことをするのに十分な大きさで、しかし単一の単位として理解できるくらいに十分小さい。
経験豊富なLispプログラマは異なるやり方でプログラムを分割する。 トップダウンデザインと同様に、彼らはボトムアップデザインと呼ばれる原則に従う －－問題に合うように言語を変えて。 Lispでは、あなたはただプログラムを言語に向かって書き下すだけではなく、言語をあなたのプログラムに向かって築き上げるのだ。 プログラムを書いているとき、あなたは「Lispにこんなオペレータがあったらなぁ。」と思うだろう。 だからあなたはそれを書く。 すると、新しいオペレータはプログラムの別の部分のデザインを簡略化するのに気づくだろう。 言語とプログラムが一緒に発展する。 戦争している2つの州の間の境界のように、あなたの問題が自然が開発した山や川に落ち着くまで、言語とプログラムの間の境界は何度も描きなおされる。 最終的に、まるで言語があなたのプログラムのために設計されたかのように見えるだろう。 そして言語とプログラムがお互いによくフィットすると、明確で、小さくて、効率的なコードに落ち着く。
ここでボトムアップデザインが同じプログラムを単に異なる順序で書くことを意味しないと強調する。 ボトムアップを扱うとき、あなたは通常異なったプログラムに落ち着く。 単一の、そして、一枚岩的なプログラムの代わりに、あなたはより抽象的なオペレータを持つもっと大きな言語と、その言語で書かれたもっと小さいプログラムを手に入れるだろう。 横木の代わりに、あなたはアーチを得るだろう。
典型的なコードでは、書き下しただけの部分を抽象化し去ると、残りはずっと短くなるだろう。 言語を高く構築するほど、頂上から下りなければならない距離は短くなる。 これはいくつかの利益をもたらす:
ボトムアップデザインはLisp以外の言語でもある程度は可能だ。 あなたがライブラリ関数を見るときはいつも、ボトムアップデザインは起こっている。 しかしながら、Lispはこの分野より大きな力をを与え、言語の拡大は比例してより大きな役割を演じる。 －－なのでLispは単に異なる言語というだけでなく、まったく異なるプログラミングの方法である。
このスタイルの開発が小さなグループが書くことができるプログラムにより合うということは本当だ。 しかしながら、同時に、それは小さいグループができることの限界を広げてくれる。 人月の神話の中で、フレデリック・ブルックスはプログラマのグループの生産性がそのサイズによって直線的に増加しないと提案した。 グループのサイズが増加するのに従って、個々のプログラマの生産性は落ちてしまう。 Lispプログラミングの経験はこの法則を言葉で表すより愉快な方法を提案する： グループのサイズが減少するのに従って、個々のプログラマの生産性は上がります。 相対的に言えば、小さなグループが勝利する、ただ単にそのグループのほうが小さいからという理由で。 小さいグループはまた、Lispが可能にする技術の利点を得るので、完勝する。
New: On Lisp をただでダウンロード
[1] 「しかし、すべての新しいユーティリティを理解しないとプログラムを読むことができない」。 そのような文章がなぜ通常まちがっているかについては、セクション4.8を見よ。