Subject: Re: Which one, Lisp or Scheme?
From: Erik Naggum <erik@naggum.no>
Date: 1997/01/24
Newsgroups: comp.lang.lisp,comp.lang.scheme
Message-ID: <3063102967705823@naggum.no>


* Martin Cracauer
| CMUCL is as fast and even smaller than most commercial implementations on
| Unix.  The only things I miss are threads and a better garbage collector
| (although CMUCL's superior warnings help not to produce as much gargabe
| in first place).

ah, agreed, but CMUCL is a breed apart from the rest.  it compiles to
native code directly for a number of platforms, which is a formidable task,
and it is exceptionally good at helping the programmer declare types of
values when it could have used a hint.  the code it generates is also quite
good.  however, this is not the norm for free Lisp implementations.

out of the several hundred free Lisps and Schemes out there, most are toys.
they may be fun toys, but they are still toys.  I think this is because it
is so easy to write a toy Lisp or Scheme, and so hard to write a fully
functional Lisp system.

| A commercial implementation has a nice environment, nice browsers, maybe
| an editor in Common Lisp and therefore controllable from Lisp and I found
| it very valuable to have such a visualization toolkit around when I
| learned Common Lisp. But I think Eric missed the point here.

well, those have been immaterial to me, but I'm sure we meet different
aspects of Lisp systems according to our experience.  I have never used a
real Lisp system for real until I got Allegro CL, so I was impressed by how
much the system knew about itself, how much time the source code manager
saved me, how well the debugging is integrated with the cross-referencing
utilities, etc.  example: I have about 200 functions in a package I'm
writing, spread across several files, and I can ask who calls a given
function, directly or indirectly.  I know which functions and files to
recompile after changing a macro by asking for who uses it.  I can ask the
system to tell me which functions bind, set, and/or reference a variable.
I have needed this functionality for _years_, not just in Lisp.  Allegro
also has search lists that can do wondrous things, too.  it's everything
_outside_ of the common Common Lisp stratum that impresses me most.

| In fact, I already had an argument with the author of Xlisp about it
| after some magazine compared Lisp and perl (that is Xlisp and perl) and
| headlined that Lisp is slow.
| 
| The problem here is that people choose a free implementation by other
| criteria than speed and then complain it is too slow because they
| underestimated the amount of efficiency they give up.

I see a possible pattern here.  if C was slow on some machine or in some
particular implementation, nobody would blame C or headline that C is slow.
the myth is that Lisp is slow, and every time somebody meets a slow Lisp,
that myth is reinforced.  that you can compile with CMUCL at high speed
settings and beat the sh*t out of C is just as much as an aberration as C
running under some bounds-checking and memory-tracking package is slow.

yes, we all know that Lisp can be incredibly fast.  we all know that Scheme
can be statically typed, too, as in the Stalin compiler.  neither changes
the naive perceptions and the myths that will be reinforced the next time a
small, neat, fun toy, somewhat like SIOD, is released and tested by
somebody who carries those myths with him.

that's how I meant that the free Lisps have mostly worked to turn people
away from Lisp.  I didn't mean that you can't find free Lisps that people
would have flocked to if they would only get over their prejudices.  I
meant that they don't, because of the many toys they have used and think
are the norm.  it seems, for instance, that in educational settings, Lisp
and Scheme are not at all presented with anything resembling speed in mind,
and so students who are used to C and C++ and ads reading "X compiles Java
at over 10,000 lines per second", will have trouble _not_ remembering that
speed was never discussed, that their compilers and interpreters were slow,
etc, etc.  I mean, we have people come in here and state that Lisp is an
interpreted language at least once a week!  it's an image problem, and it's
a tragic element of that story that as Lisp implementers focus on other
things, students and amateur programmers are turned into speed fanatics
because that is the only forte of those other languages and systems.  (and
never mind that Allegro CL for Linux produces code that runs rings around
C++ under Windows NT on the same machine.  *sigh*)

#\Erik
-- 
1,3,7-trimethylxanthine -- a basic ingredient in quality software.