1993(This essay is from the introduction to On Lisp.)It's a long-standing principle of programming style that the functionalelements of a program should not be too large. If some component of aprogram grows beyond the stage where it's readily comprehensible,it becomes a mass of complexity which conceals errors as easilyas a big city conceals fugitives. Such software will behard to read, hard to test, and hard to debug.In accordance with this principle, a large program must be dividedinto pieces, and the larger the program, the more it must be divided.How do you divide a program? The traditional approach iscalled top-down design: you say "the purpose of theprogram is to do these seven things, so I divide it into seven majorsubroutines. The first subroutine has to do these four things, soit in turn will have four of its own subroutines," and so on.This process continues until the whole program has the right levelof granularity-- each part large enough to do something substantial,but small enough to be understood as a single unit.Experienced Lisp programmers divide up their programs differently.As well as top-down design, they follow a principle whichcould be called bottom-up design-- changing the languageto suit the problem.In Lisp, you don't just write your program down toward the language,you also build the language up toward your program. As you'rewriting a program you may think "I wish Lisp had such-and-such anoperator." So you go and write it. Afterwardyou realize that using the new operator would simplify the design of another part of the program, and so on.Language and program evolve together.Like the border between two warring states,the boundary between language and program is drawn and redrawn,until eventually it comes to rest along the mountains and rivers,the natural frontiers of your problem.In the end your program will look as if the language had beendesigned for it.And when language andprogram fit one another well, you end up with code which isclear, small, and efficient.It's worth emphasizing that bottom-up design doesn't meanjust writing the same program in a different order. When youwork bottom-up, you usually end up with a different program.Instead of a single, monolithic program,you will get a larger language with more abstract operators, and a smaller program written in it. Instead of a lintel,you'll get an arch.In typical code, once you abstract out the parts which aremerely bookkeeping, what's left is much shorter;the higher you build up the language, the less distance youwill have to travel from the top down to it.This brings several advantages: By making the language do more of the work, bottom-up designyields programs which are smaller and more agile. A shorterprogram doesn't have to be divided into so many components, andfewer components means programs which are easier to read ormodify. Fewer components also means fewer connections between components, and thus less chance for errors there. Asindustrial designers strive to reduce the number of moving partsin a machine, experienced Lisp programmers use bottom-up designto reduce the size and complexity of their programs. Bottom-up design promotes code re-use.When you write twoor more programs, many of the utilities you wrote for the firstprogram will also be useful in the succeeding ones. Once you've acquired a large substrate of utilities, writing a new program cantake only a fraction of the effort it would require if you had to start with raw Lisp. Bottom-up design makes programs easier to read.An instance of this typeof abstraction asks the reader to understand a general-purpose operator;an instance of functional abstraction asks the reader to understanda special-purpose subroutine. [1] Because it causes you always to be on the lookout for patternsin your code, working bottom-up helps to clarify your ideas aboutthe design of your program. If two distant components of a programare similar in form, you'll be led to notice the similarity andperhaps to redesign the program in a simpler way.Bottom-up design is possible to a certain degree in languagesother than Lisp. Whenever you see library functions,bottom-up design is happening. However, Lisp gives you much broaderpowers in this department, and augmenting the language plays aproportionately larger role in Lisp style-- so much so thatLisp is not just a different language, but a whole different wayof programming.It's true that this style of development is better suited toprograms which can be written by small groups. However, at thesame time, it extends the limits of what can be done by a smallgroup. In The Mythical Man-Month,Frederick Brooksproposed that the productivity of a group of programmersdoes not grow linearly with its size. As the size of thegroup increases, the productivity of individual programmersgoes down. The experience of Lisp programming suggests a more cheerful wayto phrase this law: as the size of the group decreases, theproductivity of individual programmers goes up.A small group wins, relatively speaking, simply because it'ssmaller. When a small group also takes advantage of thetechniques that Lisp makes possible, it can win outright.New: Download On Lisp for Free.[1] "But no one can readthe program without understanding all your new utilities."To see why such statements are usually mistaken,see Section 4.8.
