Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.acsu.buffalo.edu!news.uoregon.edu!arclight.uoregon.edu!news.mathworks.com!newscaster-1.mcast.net!informatik.uni-bremen.de!cs.tu-berlin.de!news.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: Which one, Lisp or Scheme?
Message-ID: <1997Jan26.191946.24040@wavehh.hanse.de>
Reply-To: cracauer@wavehh.hanse.de
Organization: '(a (cons structive organization))
References: <slrn5e5geh.dl.yunho@csl.snu.ac.kr> <5c0th8$iqd@nntp.hut.fi> <3062798163303133@naggum.no> <1997Jan23.150438.27424@wavehh.hanse.de> <3063102967705823@naggum.no>
Date: Sun, 26 Jan 97 19:19:46 GMT
Lines: 111
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:24863 comp.lang.scheme:18158

Erik Naggum <erik@naggum.no> writes:

>* Martin Cracauer
>| 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.

Again, I think the difference between commercial and free
implementations is not so much that free implementations don't offer
such functionality, but that all this nice functionality is offered in
a very easy way. Tools like this are availiable for example in Mark
Kantrowitz' (spelling?)  tools. Since many people what to design their
own tools -maybe for severl implementations, the availiable source for
free tools can become even more important.

As I stated earlier, I think it can be very important for a new user
to have such functionality offered without further thinking and
therefore to be free to concentrate on languages issues. This is at
least where I found my commercial implementation useful (Lispworks). 

I think the most important thing the free commercial Lisp for Windows
and ACL for Linux is that new Common Lisp user get a much better
chance to become productive in Common Lisp before they give up.

Later, I found CMUCL and free tools not to be second rate anymore.

Comfortable CLOS browsing is another issue when talking about free
alternatives, though. 

>| 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.

In my opinion, the problem is that many Lisp and especially Scheme
tool implementors couple their tools to an inefficient
implementation. No C programmer would do so.

Of course, many Scheme tools require extending the language, whereas C
tools usually can force the programmer to use clumsy interfaces.

But I think Lisp and especially Scheme tools implementors overrated
language elegancy and gave up intergrating their tools into the best
availiable language implmentation too early.


>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*)

I think it's not *that* bad.

In my opinion, people tend to rate Lisp as interpreted because they
can't get the idea of a dynamic language that is compiled. They hear
of Lisp features and automatically say "interpreted" where they may
have thought "dynamic".

In other words, the problem is not a bad image of Lisp, but the fact
that people are ignorant and tend to fail to recognize what
performance problems are really involved with a dynamic language.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org  Fax.: +4940 5228536
"As far as I'm concerned,  if something is so complicated that you can't ex-
 plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
