From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 27 Jan 93 15:20:55 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <1993Jan23.073029.29713@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
>
>Far be it for me to speak for Larry, but I've been reading this thread
>long enough to see that the other side of the story isn't being told.

Really?  Perhaps this time, but the case against Lisp syntax is told
again and again, in my experience.

I'd like you to ask yourself something.  How could _anyone_ (who wasn't
a complete idiot) possibly think Lisp was _easier_ to read than other
languages?  Could it be that maybe, for them, it really is easier,
and that they aren't just confused or in the grip of "what they're
used to"?  

Just what do you think the story is here?  What's wrong with these
people, in your opinion?  

>In article <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>>    Date: Thu, 21 Jan 1993 18:06 EST
>>    From: Larry Wall <lwall@netlabs.com>
>>
>>    : In what way is Lisp "bland ... all the way through"?
>>
>>    There's little visual distinctiveness to distinguish mentally
>>    distinctive constructs.

As compared to ... what?  For instance?  Let's have some examples of
this visual distinctiveness.  Let's have it compared to Lisp as
presented in Algol-ish style (ie, different fonts for different
things, as in some of the Scheme texts), or whatever.

>                       There's little debate that unindented Lisp is 
>just as hard to read as unindented C, but few of us write unindented C, 
>and ALL Lisp is partly unindented any time two parens are adjacent.

What?  All languages are partly unindented every time two visible
characters appear on the same line, no?  What exactly is the problem
in Lisp that you're referring to?

In properly indented Lisp, it isn't necessary to pay attention to
individual parens when reading the code.  Even the general structure
of parens is largely redundant, serving chiefly to reinforce the
impression created by the indentation and our knowledge of the
operators involved.  Programmers new to Lisp often try to make it
more readable by putting individual close-parens along on a line
(like they might with an "end" in Algol or a "}" in C).  This
generally makes it _less_ readable.

>However I think the real case to be made for Lisp's relative illegibility 
>is one of procedural languages vs. functional languages.  When a process is
>decomposed into separate tasks which are presented sequentially, the reader
>has the least work to do in understanding the intent of the programmer.

Do you think functional languages such as ML or Haskell have this
problem?

Now, it's true that sequential is often easier to understand;
and that's one reason why Lisp programmers often write things
out sequentially.  On the other hand, nested function calls
are used in almost every language.  Lisp programmers are probably
used to a bit more complexity here than, say, C programmers;
but in well-written Lisp programs procedure definitions tend
to be fairly short, and the complexity of individual expressions
is kept under control.

Moreover, sequential isn't always easier to understand, which
is why we don't break every expression down into single steps
in (virtually) any language.

>The other perspective is one of general expressibility:  does Lisp succeed
>where other languages fail in producing readable source code and efficient 
>executables, leading to maintainability, modularity, and extensibility?
>To answer this, Lisp must be compared on its own merits, without CLOS or
>Genera. 

CLOS is part of Common Lisp.  Let's deal with actual Lisps, please,
such as Common Lisp, Scheme, EuLisp, and Dylan, and not with an
abstract "Lisp".  Common Lisp, EuLisp, and Dylan all have object
systems as part of the language.  EuLisp and Dylan were designed 
post-CLOS, and their object-oriented aspects are not extensions
even historically.

>When stripped of its extensions and superb development environment,
>Lisp doesn't appear to me to have a clear upper hand over a language like
>Modula 2 or even Ada, not in any general sense. 

I might even agree with that as a general point, though I don't think
Modula 2 or Ada are very good examples.  Indeed, I usually try to say
that some people (like me) find Lisp better (at least for a wide range
of tasks) and that there's more than one good kind of language.  I
think Lisp is _a_ good language, but not the only one; and I don't
expect everyone to prefer the same kind of language.  

Where I disagree is when people seem to be saying that Lisp is worse
than other languages.  I don't think that is so, in general, though it
often is so for certain specific purposes.

>Prefix notation and functional expressions are two `gotos considered good'
>in Lisp.  Violating either of these will either shut down your equations
>or excommunicate yourself from the Brotherhood.  They're both proscriptive.

To me, your entire argument more or less boils down to this: prefix
notation and functional expressions are bad.  There's obviously
something to be said for this.  However, for me and a number of other
people, it turns out that, all things considered, Lisp is more readable
than other languages.  So either prefix notation and functional
expressions aren't as big a problem as some think, or else there
are compensating advantages.  Because I just don't think we're that
different from everyone else.

This is not to say that everyone ought to see things our way.  Nor am
I saying that it's entirely a matter of opinion or personal preference.
I think it's like this: when the alternatives in question are sufficiently
good, then it's not wrong to pick any of them.  At this point, it's
individual factors that decide, and it has to be that way, because
there isn't One True Answer.

>Lisp isn't the most legible language, nor the fastest in execution, nor the
>smallest in executables, nor the most portable among OSes, nor the easiest 
>to integrate with 3rd party applications.  These are all excellent reasons 
>to prefer other languages when these considerations outweigh Lisp's
>comparative strengths in rapid prototyping, implementation sbstraction, 
>flexible data structures, and run-time flexibility.  [...]

>THAT'S why Lisp isn't a mainstream language.

What are these mainstream languages, anyway?  C, and what else?

-- jd