From: SWM@stony-brook.scrc.symbolics.com (Scott McKay)
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
X-Unparseable-Date: Thu
Organization: LCS news/mail gateway
Date: Thu, 28 Jan 1993 23:27:06 GMT

    Date: Thu, 28 Jan 1993 16:04 EST
    From: Larry Wall <lwall@netlabs.com>

    In article <19930127153328.7.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
    : I believe that an important point that is being lost in the shuffle is
    : whether or not the language is malleable enough to provide "control
    : abstraction" (analogous to the way classes, structures, etc., provide
    : data abstraction).  If the language cannot provide good control
    : abstraction, then *it's not good enough*.

    The question is, of course, good enough for what?

    : (Of course, the lack of
    : control abstraction does not render a language useless any more than the
    : lack of data abstraction does -- it just makes life much more difficult
    : than it needs to be, and really, isn't programming is hard enough
    : already?)

    Depends on what you trade away to get your abstraction.  Abstraction
    doesn't come for free.  Abstraction is most appealing to those folks
    who are highly intelligent.  By definition, they're in the minority.
    Ordinary people tend to avoid abstraction: "Forget that ivory tower
    stuff, just get the job done."

Of course abstraction doesn't come for free.  The question is, does the
investment made in abstraction pay for itself (or make a profit) down
the road.  The answer for data abstraction is a pretty clear yes, and
has been for over twenty years.  Most Lisp afficionados will claim that
the answer is yes for "control abstraction" as well.

    People learn to love Lisp from they're instructors, fine.  I'm not
    saying we shouldn't try to teach people to do abstraction.  But
    let's not expect people to like doing what they don't like to do.
    Castigating the Huddled Masses for huddling is a mild form of snobbery.

On the contrary, assuming that the majority of programmers are "huddled
masses" is a veiled form of arrogance.  I guess I just don't know what
"ordinary people" you are talking about.  Surely anyone clever and
patient enough to learn C or perl can learn about abstraction, which is
after all, in its most basic and useful form, just a formal name for the
simple concept of naming or abbreviating a common idiom.

    : In my opinion, almost every modern programming language fails to provide
    : control abstraction.  One reason Lisp manages to provide it is that the
    : syntax of the language makes it easy to use Lisp as its own meta-
    : language.  There are other ways to do this (e.g., add features to the
    : language that allow the language to talk about its own parsed
    : representation),...

    Gee, when you point out the upside of Lisp's narcissism, it's central.
    When I point out the downside, you tell me I'm stuck in 1972.

You will probably not find many people who think that linguistic
introspection is a form of narcissism.

    :                    ...but to the best of my knowledge, there aren't any
    : languages that do this in any serious way.

    Thank goodness.  Simplify here, complexify everywhere else.  TANSTAAFL.

Again, the burden is on you to show exactly what has been complexified.

    Your turn to have the last word.

OK.  Um, here, let's try this:

As an experienced assembly-language and microcode programmer and an avid
user of Teco from its PDP-10 days, I am sympathetic with your desire to
play with primitive languages, because it can be fun to hack when all
the odds are against you.  Unfortunately, some people just don't have
time to indulge in that simple pleasure.  They need programming
languages that allow them to write serious software in bounded time.
They need languages that allow old programs to be re-read years later
without huge effort.  I no longer have that luxury, so I mostly (but not
exclusively) use Lisp.  It pleases me that some people do have the
luxury of time, or never need to go back and look at their old code; let
them use Teco and C++.  Or more likely they're using Cobol and Fortran
only because they have to, which is a shame.