Best, Simple versus Best

>Powell's approach to the optimizer was what he called "best simple": Do the
>best job you can while keeping the optimizer itself simple and easy to under-
>stand (and thus get right). He rejects many of the published algorithms as
>too complex, too hard to understand, and too unlikely to be useful in most
>programs.


The entire discussion to this point reminds me of an essay by Richard
Gabriel (I'm sorry I don't have even a minimal reference) contrasting
the "MIT/Stanford style of design" with the "New Jersey approach."


Following Lee, he suggests that the MIT/Stanford approach can be
captured in the phrase "the right thing." The following
characteristics are important: (I'll try and quote exactly)


        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.


Gabriel offers Scheme and Common Lisp (with CLOS) as examples of this
approach.


The New Jersey approach (also called "worse is better") is slightly
different. Their characteristics are (deliberately caricatured) as


        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 be sacrificed whenever
implementation simplicity is threatened. Consistency can be
sacrificed to achieve completeness if simplicity is retained;
especially worthless is consistency of interface.


Examples offered include C and early Unix.


Of course, C and Unix have been hugely successful, whereas Scheme and
Common Lisp are fairly uninteresting commercially. Perhaps that ends
the discussion for many people. Nevertheless, I'm still quite
attracted by the possibility that, if I'm willing to work hard enough,
I could build an optimizing compiler that isn't an embarrassment.


(BTW, I've only presented a brief summary of the first half of
Gabriel's essay. He actually concentrates on the design of Lisp and
makes many interesting points. If someone can give me a reference,
even a title, for this thing, I'd be obliged.)


Preston Briggs
--

Return to the comp.compilers page.
Search the comp.compilers archives again.