1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
Previous: [1]Lisp's Apparent Failures Up: [2]Lisp's Apparent Failures
Next: [3]Good Lisp Programming is Hard
The Rise of ``Worse is Better''
By Richard Gabriel
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:
* 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.
The worse-is-better philosophy is only slightly different:
* 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.
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 into ``loser mode,'' where ``loser'' is the affectionate name
for ``user'' at MIT.
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.
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.
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.
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 and C are the ultimate computer viruses.
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.
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++.
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 the ``diamond-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.
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.
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.
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.
rpg@lucid.com
References
1. https://web.archive.org/web/20000816191611/http%3A//www.ai.mit.edu/docs/articles/good-news/section3.2.html
2. https://web.archive.org/web/20000816191611/http%3A//www.ai.mit.edu/docs/articles/good-news/section3.2.html
3. https://web.archive.org/web/20000816191611/http%3A//www.ai.mit.edu/docs/articles/good-news/subsection3.2.2.html
|
