> > I think it is useful that it be possible to write a conforming R6RS
> > program that is at the same time a valid Unix/Posix script. That
> > requires some minimal standardization in R6RS. Non-Unix
> > implementations need to not get confused by a Unix script header.
>
> It doesn't require standardization in R6RS. An SRFI is a perfect
> place for this sort of operating system-specific thing. RnRS has
> always been very careful not to introduce this sort of non-portable,
> operating system-specific behavior.
>
> And why should Unix implementations own the top line of every script
> file? What happens when another operating system wants control over
> the top line?
Many of the discussions we've been having remind me of Richard Gabriel's
essay "Lisp: Good News, Bad News, How to Win Big" (
http://www.dreamsongs.org/WIB.html). Here's an excerpt. For those who
haven't seen it you may find it an interesting read. Or not. :-)
2.1 The Rise of Worse is Better
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.
...
Received on Thu Nov 16 2006 - 12:00:51 UTC