Note: This article is for use only, please do not use it as other purposes, thank you! Since the end of the bottom
Deng Hui (translation)
For a long time, we have been following such a principle of programming style: a function of a program should not be too large. If the size of certain components in the program exceeds the scope of easy understanding, it will cause a lot of complexity, which is easy to hide errors, just like it is easy to hide sin in a big city. This procedure is difficult to understand, it is difficult to test, it is difficult to debug.
According to this principle, a large program must be divided into some small pieces, and the degree of segmentation should be commensurate with the scale of the program. So how do you split the program? Traditionally, we generally use the Top-Down Design: Program intend to complete 7 tasks, then divide it into seven major subroutines. The first routine should do 4 things, then divide it into four subroutines. This process continues until the entire program has an appropriate particle size. The appropriate meaning here is that each part is large enough to complete some substantive work, and is small enough to be a understandable unit.
Experienced Lisp programmers are divided into their procedures in a different way. Corresponding to the top of the top, they call it upward design (Bottom-Up ": changing the language, making it suitable for solving problems. In Lisp, you are not using language to write programs, and you have to promote language and make it more suitable for your program. When you write a program, you will think so: "I hope that Lisp has a certain operator." So you will write it out. Then you find that a new operator will simplify the design of the other parts of the program. Language and programs evolve together. Just like two borders located in the country of war, the boundary line between language and procedures is constantly residing until the last stay in the mountains and rivers, the most suitable for your problem. Natural borders. Finally, your program looks like a language specifically designed to design it. When language and programs are very matched with each other, the code will become more clear, short, and efficient.
It is worth emphasizing that it is not only a program to write the same program in different order. When working at the bottom up, it is usually a completely different programs. Get is not a single-chip microcomputer, but a language with more abstract operators, more semantic, and a shorter program written in this language. Not only getting a result, you have also got more powerful expression.
When we write code, once the part of the remaining core is stripped, the remaining core part will become very short, the higher the abstraction level of the language, the higher from the top to it. short. This will bring the following benefits:
1. By making language more work, the procedure produced by the design is more short, more agile. A short program does not have to split into a lot of parts, and less components means that the program will be more readily read and modified. Procedures with fewer parts also means having less associations between components, so there is less likely to be wrong. As an industrial designer strives to reduce the number of moving parts in the machine, experienced LISP programmers are also designed to reduce their programs and complexity.
2, the code is encouraged to reuse from the bottom up. When you have written two or more programs, many tools you have written for the first program will work in subsequent programs. Once you have a large tool base library, the workload required to write a new program will greatly be lower than the original LISP.
3. Design from bottom to make the program more readily read. Is a well-utilized operation compliance? Is it a good understanding of a particular purpose operation for a particular field? 4. Design from bottom to help to clarify their design ideas because it will force you to look for the mode in your code. If two different parts are very similar, you will be guided to pay attention to these similarities and redesign the program with a simpler way.
In addition to LISP, in other program languages can also be implemented to some extent. As long as you see the library function, it uses the upward design. However, LISP provides a broader support in this regard, making it in terms of Lisp style programming: Lisp is more than just a different language, but a completely different programming method.
Obviously, this type of development is more suitable for small team development. However, it also extends the limitations of a small team that can be completed. In the "Moon Myth" book, Frederick Brooks pointed out that the productivity of the programmer team will not grow with the scale of the team. When the scale of the team expands, the productivity of the individual programmers will decline. The experience of LISP programming has expressed this law in a more exciting way: with the narrowing of the team's scale, the productivity of individual programmers will rise. A small-scale team will succeed, this is just because it is smaller. When a small team also controls the technique of LISP, then it will make more thoroughly.
