The rise of "Almost better" Design Philosophy

From: http://www.aqee.net/the-rise-of-worse-is-better/

I and almost all the designers of Common LISP and Clos (Common LISP Object System) are deeply influenced by the design style of MIT/Stanford. The essence of this style can be summarized by the phrase "the right thing. For such designers, it is important to follow these design concepts:

• Simplicity-design must be simple, which is both an implementation requirement and an interface requirement. The simplicity of interfaces is more important than the simplicity of implementation.
• Correctness-the design should be correct in any noteworthy aspect. It is absolutely not allowed.
• Consistency-the design must be consistent and compatible. The design allows a small amount of simplicity and integrity to avoid inconsistency. Consistency and correctness are equally important.
• Integrity-the design must cover various important scenarios of practical applications. All predictable situations must be covered. Simplicity cannot excessively damage integrity.

I believe most people will agree that these ideas are some good implementation principles. I call this design philosophy "MIT approach )". Common Lisp (including clos) and scheme represent the design and implementation of the MIT method.

The concept of "Almost better is better" is slightly different:

• Simplicity-design must be simple, which is both an implementation requirement and an interface requirement. The simplicity of implementation is more important than the simplicity of interfaces. Simplicity is the most important factor in design.
• Correctness-the design must be correct in any noteworthy aspect. For simplicity and correctness, slight concessions can be made.
• Consistency-design cannot be overly incompatible. For simplicity, consistency can be sacrificed in some aspects, but it is better to lose them than to allow those parts in the design to handle less common situations to increase implementation complexity and inconsistency.
• Integrity-the design must cover various important scenarios of practical applications. All predictable situations should be covered. Integrity can be sacrificed to ensure the quality of other features. In fact, integrity must be sacrificed once simplicity is compromised. Consistency can sacrifice the integrity of the implementation. The most important thing is the consistency on the interface.

Early UNIX and C languages were representative of the use of this design theory. I called the method of adopting this design strategy "New Jersey approach )". I have been satizing this "almost better" theory intentionally, making people believe that it is obviously a bad theoretical idea. The New Jersey method is a bad software implementation method.

However, I believe that even under the illusion that this "almost better" theory has a larger room for survival than the "correct practice" theory, that is, in software development, the New Jersey theory is more practical than the MIT theory.

Let me repeat a story to show you the real difference between the MIT method and the New Jersey method, and why the supporters of each theory fully believe that their theory is better.

Two famous figures, one from MIT and the other from Berkeley (but Unix ). Once they had a discussion about the operating system. People from Marathon are familiar with its (the operating system of the MIT Artificial Intelligence Lab) and have read the Unix source code. He is very interested in how UNIX solves the loser-ing problem of PC. When a user program calls a system routine to execute a long time and contains important operations, such as IO buffer, loser-ing problems may occur. If the operation is interrupted, the user program State must be saved. Because the call to the system routine is usually a single command, the PC running the user program cannot capture the Process status of the routine. The system routine either exits or forcibly continues running. The "correct way" is to exit and restore the user program to call the command of the system routine so that the user program can resume operation after interruption, for example, re-enter the system routine. This is called "PC
Loser-ing, because a PC is forced into a "loser" mode, where "weak" is a love term for "users" by MIT.

Massachusetts Institute of Technology did not see any code to handle this situation and asked the New Jersey people how UNIX handled this problem. The New Jersey said UNIX people are aware of this problem, but the solution is to address the situation where the system routine can normally be completed. When the system routine cannot be completed successfully, it returns an error code indicating that the operation failed. A correct user program needs to check the error code to determine whether to call this system routine again. MIT workers do not like this solution because it is not "the right way ".

New Jersey says the Unix solution is correct, because the Unix design theory is simple, and this "correct approach" is too complicated. In addition, programmers can easily add such error probes and repeat their operations. The MIT Administrator pointed out that this implementation scheme is indeed simple, but functional interfaces become more complex. New Jersey pointed out that this is a proper choice for Unix design. The simplicity of implementation is more important than the simplicity of interfaces.

The MIT manager muttered and said: Sometimes you need to turn a strong person into a weak chicken. New Jersey didn't understand what he meant (or I don't quite understand ).

Now, I started to claim that "Almost better" is indeed better. C language is a language designed for Unix development. It is designed using the New Jersey method. C language is therefore a language that can easily write beautiful compilers. It requires that the Code Compiled by programmers be easily interpreted by the compiler. Some people call C language an advanced assembly language. Early UNIX and C compilers were very simple and easy to transplant and required a small amount of hardware resources to run, it allows you to get 50%-80% features from an operating system and programming language.

Half of the existing machines are below the medium configuration level (smaller, slower) in any aspect ). While UNIX and C languages run well on them. The "almost better" theory shows that the simplicity of implementation has the highest priority, which means that UNIX and C languages can easily be transplanted on these machines. Therefore, if any machine, UNIX and C, can provide 50% of the functionality, it will be everywhere. UNIX and C are like this, isn't it?

UNIX and C language are the ultimate computer viruses.

Another benefit of the "almost better" theory is that programmers can sacrifice some security and convenience to achieve excellent performance and fewer resources. Software developed using the New Jersey method can run on both big machines and small machines. The program is highly portable because it is written in a virus program.

It is very important that the initial virus must be basically easy to use. The spread of viruses is guaranteed due to its portability. Once the virus spreads, the pressure will prompt it to further improve and increase the number of features to nearly 90%, however, at this time, the user is used to something that is worse than "correct practice. Therefore, "almost better" software will first get people's acceptance, then there will be limits to let users lower expectations, and finally improve until "the right way ". In actual situations, the Lisp compiler in 1987 and the C compiler were both excellent at that time, but many compiler experts still tried to make the C compiler better.

The good news in 1995 was that we had a good operating system and programming language, and the bad news was that they were UNIX and C ++.

"Almost better" has the last benefit. Because New Jersey-style languages and systems are not really powerful enough to develop Complex Giant Software, large systems must be designed to reuse components. Therefore, the tradition of integration rapidly emerged.

What is the "correct approach? We have two common models: "complex large systems" and "diamond treasure.

The "Complex Large System" pattern is usually like this:

First, "correct practices" need to be designed. Then the implementation process needs to be designed. Finally, implement it. Because this is "the right way", it will provide 100% of the expected features, the simplicity of implementation is never a factor to consider, so you need to spend a long time to complete it. It is huge and complex. It requires complex tools and tools must be correctly used. Among them, 20% of the features will take 80% of your energy, so it takes a long time to complete the "correct approach, its operation is satisfactory only on hardware that adopts advanced technologies.

The "diamond treasure" pattern is usually shown as follows:

"The correct method" takes a lot of time to design, but this method does not actually take a large proportion in a single function point. The implementation of this design is either impossible or beyond the capabilities of most developers to make it run fast.

The first mode is also the development mode of the classic AI software.

The "Right Approach" usually comes out of large software, but there is no other reason for this, except that the "Right Approach" will make the software design huge. That is to say, many functions of large software are used by accident.

What we learned from these things is that people generally do not like to do things according to "correct practices. But you 'd better adopt half of the "correct practices" to make your software spread like a virus. Once people are attracted to it, they take the time to improve it and bring it close to 90% of "correct practices".

A wrong idea is to understand what it means and think that C language is a powerful weapon for developing AI software. 50% a solution with the correct approach is usually feasible, but it cannot be done with AI.

However, we can draw a conclusion that the lisp community really needs to seriously reflect on their position in the lisp design. I will talk about this issue more in the future.