🚀 go-pugleaf

In article <1991May28.033548.26907@cs.cmu.edu> ram+@cs.cmu.edu (Rob MacLachlan) writes:

>I am a Lisp implementor, and a Lisp advocate, but I think a lot of damage has
>been done by advocating Lisp as being:
>    "The same as FORTRAN/C/Ada, only better". 

I agree with much of what you say.  It's a mistake to try to compete
with FORTRAN/C/Ada on every front.  We should emhasise Lisp's strengths
rather than its weaknesses.  Lisp is higher level, and "many of the
advantages (and disadvantages) of Lisp are exactly the advantages
(and disadvantages) of high-level programming."

However, I think a lot of damage has been done by saying that Lisp
shouldn't try to be like C, even though I agree that it shouldn't.
It too often functions as a reason for failing to fix problems that
should be fixed.

For years, I have been hearing that it doesn't matter that Lisp
requires vast amounts of memory, because menory is so cheap.  For
years, I have been hearing that it doesn't matter that Lisp is
so poor at delivering applications because it's so great at
development.

I still don't have a machine that's big enough to run the big Common
Lisp implementations together with their programming environments
unless I use a machine that I share with many other users and so make
it much less useful for them.  

No matter how good the development environments are, they don't help
me unless I can run them.  And the C tools I can use aren't as bad as
some people seem to think.  In a cost benefit analysis, C often comes
out ahead even without considering such things as Sabre C.

There are a number of other cases where C again comes out ahead.
If I want to write a program that uses the X Window System in
interesting ways, it's often a choice between writing it in C
and being able to run it or writing it in Lisp and watching
it page.  (A possible compromise is to use C for the graphics
part.)  I often write little programs, and I'd like to write them 
in Lisp.  Buf if, for example, I want to write a Unix command,
I shouldn't write it in Common Lisp, because the runtime overheads 
are too great.  And so on.

Quite a bit can be accomplished by picking the right implementation,
but it's a pain to end up using several varieties of Scheme and Common
Lisp in order to get reasonable results.  Too many implementations of
Common Lisp seem to have decided that it hardly matters how big they
are, thus leaving many users with too little choice.

It's convenient to think that Lisp will survive as a development
tool while other languages are used for applications.  What may
happen instead is that (a) development tools for other languages
will improve so that Lisp's advanatges are less great, (b) Lisp's
reputation as too big and slow will cause many people to think
it will be faster to start in C rather than switch to it later
on, and (c) as Lisp is used less there will be less incentive to
learn it or teach it.  

A language can be high level without having such problems.  Prolog and
Scheme are examples.  However, in many quarters Lisp is being judged
by the performance of commercial Common Lisp systems, not by what can
be done with Elk or Scheme-to-C.

I will continue ot use Lisp whenever possible.  But I want to use Lisp
in more cases, more of the time, have greater choice and not pay so big 
a price.  I also want it to work better with C (and other languages)
so that I can mix and match.

-- jd