Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.mathworks.com!fu-berlin.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: <1997Jan23.150438.27424@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>
Date: Thu, 23 Jan 97 15:04:38 GMT
Lines: 49
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:24787 comp.lang.scheme:18063

Erik Naggum <erik@naggum.no> writes:

>| They are mature enough. Don't buy anything commercial.
>| Use Emacs and whatever scheme implementation you find convenient.
>| Guile, MIT Scheme... whatever.

>this is disquieting.  the strongest effects of free Lisp implementations to
>date have been to turn people away from Lisp due to low performance, high
>memory usage, etc; to perpetrate the _myth_ that all Lisps are interpreted,
>that the language is slow, etc; to make people believe that Lisps don't fit
>in with the rest of the operating system, that you can't make executables;
>etc ad nauseam.

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

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. 

I agree with the point that many free Lisp implementations are slow
and fail to point out in their documentation that one can run the same
program faster. 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.

The Scheme community with eval implemented as write/read to disk
sometimes and total lack of declarations, but implementations that
take numbers as 32bit-limited without programmers permission is
another issue. While the author is not responsible, slib was what
turned me away from Scheme rather quickly. Some slib functionality in
unbeleivable slow in many implementation, functionality that is
standard in Common Lisp and Perl and therefore implemented either in C
or as overhead-free, declared code.

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
