- Gabriel, Richard
“the right thing” approach
- Simplicity: the design must be simple, both in implementation and interface. Simple interface is preferred.
- Correctness: incorrectness is not allowed.
- Consistency: the design must be consistent. It 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.
- Simplicity: the design must be simple, both in implementation and interface. Simple implementation is preferred over simple 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 be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
- Lisp follows “the right thing” philosophy
- C, C++, Unix follow “worse-is-better”
- worse-is-better survives better
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.
- worse-is-better has better performance. It will run on old computers and will spread faster. Once spread, the user will be willing to improve it. Perhaps up to 90% of what’s possible (but users are conditioned to accept less).
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++.
- worse-is-better is not powerful enough to build complex monolithic software. That means that large systems must be designed to reuse components.
“the big complex system” scenario
- Basically, a big monolith that is thoroughly designed and implemented. It covers ~100% of required functionality. But, because implementation simplicity is not prioritized, it takes long to develop.
“diamond-like jewel” scenario:
- 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 big complex system” corresponds to Common Lisp; “diamond-like jewel” corresponds to Scheme.
- 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. #insight #startup