Original blog: https://www.paulgraham.com/progbot.html

(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 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 which

could be called bottom-up design-- changing the language

to 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're

writing a program you may think "I wish Lisp had such-and-such an

operator." So you go and write it. Afterward

you 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 been

designed for it.

And when language and

program fit one another well, you end up with code which is

clear, small, and efficient.

It's worth emphasizing that bottom-up design doesn't mean

just writing the same program in a different order. When you

work 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 are

merely bookkeeping, what's left is much shorter;

the higher you build up the language, the less distance you

will have to travel from the top down to it.

This brings several advantages:

Convert your blog to audio at https://www.anoncast.net/ , or browse generated episodes at https://www.anoncast.net/generated