✳flâneur — a map of the web's best reading

Programming Bottom-Up

paulgraham.com · 930 words · saved by 1 readers

(This essay is from the introduction to On Lisp.) It's a long-standing principle of programming style that the functional elements of a program should not be too large. If some component of a program grows beyond the stage where it's readily comprehensible, it becomes a mass of complexity which conceals errors as easily as a big city conceals fugitives. Such software will be hard to read, hard to test, and hard to debug. In accordance with this principle, a large program must be divided into pieces, and the larger the program, the more it must be divided. How do you divide a program? The traditional approach is called top-down design: you say "the purpose of the program is to do these seven things, so I divide it into seven major subroutines. The first subroutine has to do these four things, so it in turn will have four of its own subroutines," and so on. This process continues until the whole program has the right level of granularity-- each part large enough to do something substan

Programming Bottom-Up --> 1993 (This essay is from the introduction to On Lisp .) Arc 's name.--> It's a long-standing principle of programming style that the functional elements of a program should not be too large. If some component of a program grows beyond the stage where it's readily comprehensible, it becomes a mass of complexity which conceals errors as easily as a big city conceals fugitives. Such software will be hard to read, hard to test, and hard to debug. In accordance with this principle, a large program must be divided into pieces, and the larger the program, the more it must be

Explore this link on the map →

related reading