NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/lisp/3345

Text File | 1993-01-23 | 8.0 KB | 156 lines

Newsgroups: comp.lang.lisp
Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!linus!linus.mitre.org!boole.mitre.org!crawford
From: [e-mail] (Randy Crawford)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Message-ID: <[e-mail]>
Sender: [e-mail] (News Service)
Nntp-Posting-Host: boole.mitre.org
Organization: The MITRE Corporation, McLean, VA
References: <[e-mail]> <[e-mail]>
Date: Sat, 23 Jan 1993 07:30:29 GMT
Lines: 143


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.
So here's my tuppence.

In article <[e-mail]> [e-mail] (Scott McKay) writes:
>    Date: Thu, 21 Jan 1993 18:06 EST
>    From: Larry Wall <[e-mail]>
>
>    : In what way is Lisp "bland ... all the way through"?
>
>    There's little visual distinctiveness to distinguish mentally
>    distinctive constructs.
>
>This is simply not a valid criticism.  There is little visual
>distinctiveness in English to distinguish mentally distinctive
>constructs, and yet you do not fault English.  In fact, one could argue
>that "visual distinctiveness" is a principally a matter of typography.

Not a good analogy.  Not only is english an unstructured language (as
compared with programming languages) but parsing english is legendary
for its difficulty.  Without punctuation and semantic context, it's
trivial to write correct english which is effectively illegible; that's
illegible to man _or_ machine.  The same is not true even of obfuscated
C; compilers handle it nicely.  So legibility in english is _not_ a
simple matter of typography.

Likewise context free languages can be difficult to read for more reasons
than just syntactic sugar.  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.

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.
Whenever processes are nested and one process generates temporary values
which are then fed directly into other processes, as in Lisp, the delineation
between tasks (prior vs. successor) is less clear.  Certainly we don't write
english sentences from the inside out, why should we expect programmers to
read source code which is written that way?

>
>    : Are you saying that you think that the true challenge in programming
>    : is the actual struggling with the language, rather than the addressing
>    : the deeper issues (such as, what it is you are trying to do)?
>
>    I haven't noticed people struggling that much less with Lisp than with
>    most other languages.  Admittedly, nroff is a bit tougher, unless
>    you're just trying to do text processing...  :-)
>
>Perhaps it is the sort of software I do, but I emphatically do notice
>people struggling more with most other languages than with Lisp.  Let's
>look at memory management, for instance.  In most other languages, such
>as C, programmers must confront the issue of memory management head on,
>[...]  The point is that, in most other
>languages, programmers must immediately tackle programming tasks that
>are only incidentally related to the problem at hand.

I see two ways to interpret what Larry said.  One is to state that Lisp's
bag of tricks is no bigger than that of other languages.  How readily does
a language protect the programmer from having to consider implementation
details like precision loss or the free use of memory?  Does it provide
sufficient resources to off-load the myriad system support details which
are tangential to implementing an algorithm?  I'd say that any language
as large as CL probably _is_ going to serve a programmer's every need,
albeit one-size-fits-all.  But I don't think that's the better case that
can be made against Lisp, although that seems like what you defended.

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.  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.  It's not more legible,
more intuitive, more efficient in execution.  Lisp fares most poorly (IMHO)
when compared like this with newer languages like Modula 3, which were
designed largely for their legibility and modularity.

It's from this point of view that I too would say that I've seen few people
struggling more with Ada or Modula 3 than with Lisp.  Compare the mysteries
of writing in Motif or Wcl with writing in CLIM or Clu.  Not so different.

>
>    : In what way does Lisp "push down so hard" on morphology?
>
>    Essentially, Lisp assumes that humans like to write programs the same
>    way the machines like to execute them, and so conflates the human
>    representation with the machine representation.  True, there are Lisp
>    compilers, but the "ideal" is still that the machine and the programmer
>    are interpreting the exact, same, one-size-fits-all data structure.
>
>I fail to see that Lisp makes any such assumption.  What machines
>directly execute mapping operators?  Reduction operators?  What machines
>directly execute generic arithmetic, including integers, large integers,
>floating point, and ratios?  Hash tables?  Sequences and collections?
>This claim just cannot be made to stick.

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.

>
>I also think you have confused what you call "machine representation"
>with "parsed representation".  The fact that the human-readable
>representation is the same as the basic parsed representation is one of
>the great sources of Lisp's power -- it allows Lisp programs to
>effortlessly talk about Lisp programs.

Sort of the effortless way that Forth programs read?

>
>    That said, I should back off a little and admit that there are a few
>    things that are easier in Lisp than in other languages.  But your
>    assumption seems to be that it's better to use an all-around mediocre
>    language for most everything than to use each language for what it does
>    best.  [...]
>
>I don't claim that Lisp is an all-around mediocre language.  It's an
>all-around excellent language.  Sure, there are some languages that have
>a few features that are better than what I can find in Lisp, but so what?
>  [...]
>For general programming, I'll take Lisp nearly every time.  Moral: use the
>right tool for the job.

Perhaps by choosing an all-around excellent language?  :-)

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.  In the PC applications
arena or systems or networking or communications or accounting or number-
crunching or distributed software, Lisp isn't even in the running.

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

| Randy Crawford        [e-mail]        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102