I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.’’ To such a designer it is important to get all of the following characteristics right:
我和几乎所有的Common Lisp和CLOS(Common Lisp Object System)的设计者都极度深受麻省理工学院/斯坦福大学(MIT/Stanford)设计风格的影响。这种风格的本质可以用“正确的做法(the right thing)”这个短语来概括。对于这样的设计者，重要的就是要遵循下面的这些设计理念：
- Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
- Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
- Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
- Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.’’ Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.
- 简单性—设计必须简单，这既是对实现的要求，也是对接口的要求。接口的简单要比实现的简单更加重要。
- 正确性—设计在任何值得注意的方面都要保证正确。不正确是绝对不允许的。
- 一致性 — 设计必须保持一致兼容。设计可以允许轻微少量的不简单和不完整，来避免不一致。一致性和正确性同等重要。
- 完整性—设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都必须覆盖到。简单性不能过度的损害完整性。
我相信大部分的人都会同意，这些理念都是一些好的实施原则。我把采用这种设计哲学的方法叫做“麻省理工方法(MIT approach)”。Common Lisp(包括CLOS)和Scheme代表着麻省理工方法的设计和实现。
The worse-is-better philosophy is only slightly different:
“差点的更好(Worse is Better)”的理念只是稍微有点不同：
- Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
- Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
- Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
- Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
简单性—设计必须简单，这既是对实现的要求，也是对接口的要求。实现的简单要比接口的简单更加重要。简单是设计中需要第一重视的因素。
正确性—设计在任何值得注意的方面都要求正确。为了简单性，正确性可以做轻微的让步。
一致性— 设计不能过度不兼容一致。为了简单，一致性可以在某些方面做些牺牲，但与其允许设计中的这些处理不常见情况的部分去增加实现的复杂性和不一致性，不如丢掉它们。
完整性 — 设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都应该覆盖到。为了保证其它几种特征的品质，完整性可以作出牺牲。事实上，一旦简单性受到危害，完整性必须做出牺牲。一致性可以为实现的完整性作出牺牲；最不重要的是接口上的一致性。
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.’’ I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
早期的Unix和C语言是使用这种设计理论的代表，我把采用这种设计策略的方法叫“新泽西方法(New Jersey approach)”。我一直在有意的讽刺这种“差点的更好”理论，让人们相信它显然是一种不好的理论思想，新泽西方法就是一种不好的软件实现方法。
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
然而，我相信，即使在一种假象的情况下，这“差点的更好”理论也要比“正确的做法”理论有更大的生存空间，也就是说，在软件开发上，新泽西理论要比麻省理工理论更实用。
Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.
让我来复述一个故事，向大家展示麻省理工方法和新泽西方法之间的真实区别，以及为什么各个理论的支持者都完全的相信他们的理论更好。
Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing'' because the PC is being coerced intoloser mode,’’ where loser'' is the affectionate name foruser’’ at MIT.
两位著名的人物，一位是来自麻省理工，另一位来自伯克利学院(但是研究Unix的)。一次，他们遇到一起讨论操作系统问题。来自麻绳理工的人对ITS(麻省理工学院人工智能实验室的操作系统)非常熟悉，并阅读过Unix的源代码。他对Unix如何解决PC机的loser-ing问题非常有兴趣。当一个用户程序调用系统例程去执行一个长时间的、并包含有重要状态的操作时，例如IO缓冲，loser-ing问题就有可能出现。如果在执行这个操作时，发生了中断，用户程序的状态必须被保存下来。因为对系统例程的调用通常是单指令的，运行用户程序的PC机无法捕捉到例程的过程状态。系统例程要么退出，要么强行继续运行。“正确的做法”是退出，复原用户程序调用系统例程的指令，让用户程序在中断之后能重新恢复运行，例如，重新进入系统例程。这被叫做“PC loser-ing”，因为PC机被强制进入一种“弱势(loser)模式”，其中，“弱势”者是麻省理工对“用户”的一种爱称。
The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.
麻省理工的人没有看到有任何的用来处理这种情况的代码，问新泽西人，Unix是如何处理这种问题的。新泽西人说，Unix人清楚这个问题，但提供的解决方式是针对系统例程通常能正常完成的情况的，当系统例程不能成功的完成运行时，它会返回一个错误码，指示操作运行失败。一个正确的用户程序这时需要去检查这个错误码来决定是否需要再次调用这个系统例程。麻省理工人不喜欢这个解决方案，因为这不是“正确的做法”。
The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity.
新泽西人说，Unix的解决方案是正确的，因为Unix的设计理论是追求简单，而这“正确的做法”太复杂。除此之外的好处是，程序员能容易的添加这种错误探测，重复他们的操作。麻省理工人指出，这种实现方案确实简单，功能性上的接口却变的复杂。新泽西人指出，这就是Unix在设计上做出的合适的取舍。实现上的简单比接口上的简单更重要。
The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn’t understand (I’m not sure I do either).
麻省理工人这时嘟囔着说：有时你需要让一个强壮的人去变成一种软弱的小鸡。新泽西人没明白他是什么意思(我也不太明白)。
Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%–80% of what you want from an operating system and programming language.
现在，我开始主张“差点的更好”确实是更好。C语言是一种为开发Unix而设计的语言，它的设计采用的是新泽西方法。C语言因此是一种很容易就能写出漂亮的编译器的语言，它要求程序员编出的代码要易于编译器去解释。有些人称C语言为高级汇编语言。早期的Unix和C编译器都非常的简单，易于移植，需要很少的硬件资源来运行，它提供了你从一个操作系统和编程语言里想得到50%—80%的功能。
Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven’t they?
现有的机器有一半在任何方面都低于中等配置水平(更小，更慢)。而Unix和C语言在它们上面运行良好。“差点的更好”理论表明实现的简单性具有最高的优先级，这意味着Unix和C语言很容易在这些机器上进行移植。因此，如果任何一台机器，Unix和C能在功能性上提供50%的支持，那它就会无处不在了。Unix和C就是这样，不是吗？
Unix and C are the ultimate computer viruses.
Unix和C语言是终极电脑病毒。
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.
“差点的更好”理论另外一个好处是，程序员可以有条件的牺牲某些安全性，方便性，全力去获得优良的性能和较少的资源使用。使用新泽西方法开发的软件既能在大机器上运行，也能在小机器上运行，程序具有很好的可移植性，这是因为它们是在一个病毒程序是写出来的。
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
有一点很重要，初始病毒必须基本上好用。病毒的传播由于它的可迁移性而得到保证。一旦病毒传播开来，迎来的压力会促使它进一步改进，促使增加功能至接近90%完备的水平，但用户此时已经有条件的习惯了这种比“正确的做法”差一点的东西了。所以，“差点的更好”的软件会首先获得人们的接受，然后会有限制的让用户降低期望，最后进行改进，直至接近“正确的做法”。在实际情况中，1987年的Lisp编译器当时和C编译器都是非常的优秀，但是很多的编译器专家仍然努力让C编译器做的更好。
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
1995年的好消息是我们有了一个好的操作系统和编程语言；而坏消息是它们分别是Unix和C++。
There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up.
“差点的更好”还有最后一个好处。因为新泽西式的语言和系统不够真正的强大来开发出复杂巨型的软件，大型系统必须在设计上进行组件重用。因此，一种整合的传统就此迅速出现了。
How does the right thing stack up? There are two basic scenarios: the big complex system scenario'' and thediamond-like jewel’’ scenario.
那“正确的做法”的表现如何呢？我们有两种常见的模式：“复杂的大型系统”模式和“钻石类珍宝“模式。
The ``big complex system’’ scenario goes like this:
“复杂的大型系统“模式通常像这样：
First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.
首先，”正确的做法“需要去设计。然后实现过程需要去设计。最后，进行实现。因为这是”正确的做法“，它会提供100%预期的功能，实现的简单性从来不是一个可考虑的因素，所以你要用很长的时间去完成它。它巨大而且复杂。它需要复杂的工具，工具需要能正确的使用。其中20%的功能会花去你80%的精力，所以，”正确的做法“需要很长的时间来完成，它的运行只有在采用先进技术的硬件上才会表现的令人满意。
The ``diamond-like jewel’’ scenario goes like this:
“钻石类珍宝“模式通常表现如下：
The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors.
”正确的做法“花了大量的时间去设计，但这种方式，在单个功能点上，其实并没有占多大比重。这种设计的实现，如果想让它运行的快，要么是根本不可能，要么是超出了大多数开发者的能力。
The two scenarios correspond to Common Lisp and Scheme.
The first scenario is also the scenario for classic artificial intelligence software.
头一种模式也是经典的人工智能软件的开发模式。
The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance.
”正确的做法“出来的通常是大型的软件，但除了”正确的做法“会把软件设计的巨大外，没有其它的理由造成这种局面。也就是说，大型软件里很多功能是偶然会用到的。
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
从这些事情中我们学到的知识是，人们通常不喜欢按照”正确的做法“做事。但你最好要采纳一半的”正确的做法“，让你的软件能像病毒一样流传。一旦人们被它吸引，花时间去改进它，使它接近90%的”正确的做法“。
A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn’t.
一个错误的认识是只理解表面意思，认为C语言是开发AI软件有力的武器。50%正确做法的方案平常是可行的，但AI上不行。
But, one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design. I will say more about this later.
但是，有一点我们可以下结论，Lisp社区真的需要认真的反省一下他们在Lisp设计上的立场。我会在以后更多的谈论这个问题。
参考
1426
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
