Re: [dev] lisp

From: Craig Brozefsky <>
Date: Sat, 29 Jun 2013 11:12:39 -0500

Andrew Gwozdziewycz <> writes:

> I don't speak for the suckless community, but despite the fact that I
> love it, Lisp is complicated and not very simple at all, which I'm
> guessing is why you don't hear about it. I'm currently playing around
> with attempting to make a minimal, embeddable, unix friendly, without
> complications dialect, called tin. I have no idea if I'll succeed in
> any of those goals, but it'll be fun regardless.

Fun project, but I disagree 8^)

Lisps (and I include scheme varianets in this) are very simple languages
for the most part -- with obvious exceptions like Common Lisp. Minimal
syntax, a few natve data types, programs are code, and functional

The runtimes however can vary in complexity depending upon their
implementation goals. Highly performant lisp means an intelligent
compiler. A common lisp design trope is to pay complexity costs in
implementation for maximizing simplicity of use.

I think the classic "Worse Is Better" essay by Gabriel is worth checking
out. Here is an excerpt:

    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

    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

    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

Worse is Better - Richard Gabriel

Craig Brozefsky <>
Premature reification is the root of all evil
Received on Sat Jun 29 2013 - 18:12:39 CEST

This archive was generated by hypermail 2.3.0 : Sat Jun 29 2013 - 18:24:05 CEST