What are CLISP's "selling" points?

Hi,

I'm wondering what attracts people to CLISP. Maybe developers could then 
concentrate efforts on these distinguishing areas.

My likes:
+ small size (both disk & run-time)
+ works on many many platforms (many unixes)
+ portability stresser, e.g. any place which might cause an error actually 
signals an error (except declarations :-) at run-time
+ robustness -- for years, I had no single crash using Amiga-CLISP which I 
could not trace down to a bug in gcc(!) or in CLISP, which got fixed soon. Very 
few crashes in total. This generates warm feelings for every Amiga user. These 
days however, CLISP sadly has a few known GC-triggered bugs somewhere in its 
code, seemingly hard to nail down.
+ ...?

~ perhaps UNICODE, but Allegro seems to have the reputation of The Lisp with 
excellent unicode support

~ perhaps speed?
This came out as a surprise to me yesterday, but my Logfile-analysis 
application works faster in CLISP than in Corman Lisp (which compiles to native 
code), even without my recent FAST-VECTOR-POSITION accelerator hack!
So far, it's not a fair comparison: I spent days analysing where slowness 
occurred in CLISP (e.g. certain calls to parse-integer), and just compiled the 
thing in CormanLisp, without any optimization settings. More on this another 
time.


I don't believe people are attracted by:
- FFI (too restrictive in the past, but with some jewels, esp. the very 
expressive def-call-out)
My bet is people just want the interface stuff to work, so that they can 
concentrate on the application instead.

- CLOS/MOP
Several people (e.g. Tim Bradshaw) were turned away by CLISP's CLOS missing MOP 
features or other restrictions in CLISP's implementation of CLOS.
I once suggested that CLISP might contain FAQ/documentation entries on how PCL 
can be used instead of its builtin-closs. Each CLISP release could ensure that 
it still runs with the latest PCL. Then people in havy needs of a full CLOS/MOP 
could use that, like I believe CMUCL does.
FWIW, CLISP's CLOS once was PCL, before it got replaced by a more efficient but 
more restricted builtin-version of its own.
I cannot propose to do that, since I don't have any need for CLOS+MOP.

- inspector/debugger/stepper, yet Corman's seems even less powerfull (more 
lacking?) than CLISP's (grain of salt here, I have only been using CormanLisp 
for 2 days)

- GUI - no McClim, no cello, don't know about garnet, ...
What are CLISP-users using here?

- ...?

I also received feedback by some people who considered CLISP much easier on the 
beginner than e.g. CMUCL. I fail to understand this, but maybe this is 
something to concentrate upon: first impressions count a lot. Many SW-packages 
get tossed away within half an hour of toying with them.
Maybe CMUCL beginners get turned away by the warnings about special 
declarations they dont' understand when they use (setq x 123) at top-level, 
which beginners tend to do a lot? -- but this is just a supposition of mine.

Your suggestions/ideas are welcome,
        Jörg Höhle.


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com