I originally posted this to ··········@cons.org but didn't get much
feedback. My question is this:
Why does Clisp seem so much more popular & widely supported than CMUCL
when CMUCL is a more "industrial strength" lisp? PLEASE NOTE that I am
NOT trying to start a flame-war. I am just seeking insight into what
Clisp users are seeing that I am not.
--
··········@att.net
In article <·················@worldnet.att.net>, Ted Sandler wrote:
>I originally posted this to ··········@cons.org but didn't get much
>feedback. My question is this:
>
>Why does Clisp seem so much more popular & widely supported than CMUCL
>when CMUCL is a more "industrial strength" lisp? PLEASE NOTE that I am
>NOT trying to start a flame-war. I am just seeking insight into what
>Clisp users are seeing that I am not.
one advantage clisp has over cmucl is that it is pretty parsimoneous
with memory resources and starts up fast. if the speed is good enough
for an application this could count.
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
··@paradise.nirvananet (Hartmann Schaffer) writes:
>one advantage clisp has over cmucl is that it is pretty parsimoneous
>with memory resources and starts up fast. if the speed is good enough
>for an application this could count.
CMUCL starts faster than clisp.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>, Martin Cracauer wrote:
>··@paradise.nirvananet (Hartmann Schaffer) writes:
>
>>one advantage clisp has over cmucl is that it is pretty parsimoneous
>>with memory resources and starts up fast. if the speed is good enough
>>for an application this could count.
>
>CMUCL starts faster than clisp.
it didn't when i still had an intel; at least it felt that way. i should
get another intel so that i can work on a port
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
··@paradise.nirvananet (Hartmann Schaffer) writes:
> In article <·············@counter.bik-gmbh.de>, Martin Cracauer wrote:
> >··@paradise.nirvananet (Hartmann Schaffer) writes:
> >
> >>one advantage clisp has over cmucl is that it is pretty parsimoneous
> >>with memory resources and starts up fast. if the speed is good enough
> >>for an application this could count.
> >
> >CMUCL starts faster than clisp.
> it didn't when i still had an intel; at least it felt that way. i
> should get another intel so that i can work on a port
It didn't 30 seconds ago when I ran both.
It took 6s for CMUCL to get to a prompt. CLISP took a small fraction
of a second.
Now, it's fair to say that this ought not to be a tremendously
important issue for _interesting_ applications.
_Interesting_ applications are likely to run long enough that a 6
second difference in start time shouldn't be terribly relevant.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://vip.hex.net/~cbbrowne/resume.html
"Women who seek to be equal to men lack ambition. "
-- Timothy Leary
>>>>> On Sun, 29 Apr 2001 03:21:08 GMT, cbbrowne ("cbbrowne") writes:
cbbrowne> _Interesting_ applications are likely to run long enough that a 6
cbbrowne> second difference in start time shouldn't be terribly relevant.
That depends on who the user is; generally it really does matter.
Most users of most applications on most kinds of desktops want
their programs to start quickly. Startup speed is one typical
criterion for corporate IT departments selecting among competing
applications.
"Christopher Stacy" <······@spacy.Boston.MA.US> wrote in message
··················@spacy.Boston.MA.US...
> Most users of most applications on most kinds of desktops want
> their programs to start quickly. Startup speed is one typical
> criterion for corporate IT departments selecting among competing
> applications.
But not THAT important (as long as it is within reason). Otherwise, we'd
never see Microsoft applications being selected by corporate IT departments.
faa
Ted Sandler <··········@worldnet.att.net> wrote:
+---------------
| Why does Clisp seem so much more popular & widely supported than CMUCL
| when CMUCL is a more "industrial strength" lisp?
+---------------
1. CLISP is smaller and starts up faster.
2. It's almost *trivial* to build CLISP from sources on a new platform
compared to building CMUCL on a new platform (or even on the *same*
platform, for that matter!).
Having said that, I don't agree with your implied assertion that
CLISP is either more popular *or* more "widely supported" (whatever
that means) than CMUCL (or the converse). Both have their followers.
Both have fairly good levels of support -- albeit from volunteers,
in both cases.
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
>>>>> "rw" == Rob Warnock <····@rigden.engr.sgi.com> writes:
rw> Ted Sandler <··········@worldnet.att.net> wrote: +---------------
rw> | Why does Clisp seem so much more popular & widely supported
rw> than CMUCL | when CMUCL is a more "industrial strength" lisp?
rw> +---------------
rw> 1. CLISP is smaller and starts up faster.
rw> 2. It's almost *trivial* to build CLISP from sources on a new
rw> platform compared to building CMUCL on a new platform (or even on
rw> the *same* platform, for that matter!).
I have no experience working with these Lisps as a maintainer, but
I've used them (or tried) in projects, and they both seem to support a
lot of the same features. When you build the vanilla versions of
each, they have different options. For example, the default CLOS that
comes with CLISP doesn't support MOP, and as far as I know is limited
in some ways that the PCL version that defaults with CMUCL is not.
I'm a big fan of CLISP. It's one of those really simple environments
which I've found to be *definitely* slower in my applications, but
very nice to develop with. I've recently ported my strokes.el from
XEmacs to CLISP (though it should run equivalently well under CMUCL
using CLX), and CLISP wasn't too fussy about it.
I recently did a job using LispWorks and then ported part of the
program to CLISP, and compared speeds, and LispWorks blew CLISP away.
But when I asked myself it that speed mattered, it didn't, and so, as
the previous poster said, if speed isn't an issue, CLISP is nice.
One thing that sucks about CLISP is its license. It's got that GNU
GPL contagion that makes it hard to ship your stuff without source.
It's nice that you can partially compile stuff into fsl files and ship
those, but if you're trying to protect your stuff, it's hard with
CLISP. CMUCL doesn't suffer from this. If CLISP were LGPL it would
be better, in my opinion. With CLISP, even if you compile an image
and try to ship that binary image, you have to make your src
available. I'm not a big fan of this, because it's a bit restrictive
in certain commercial settings.
I've also had problems loading dotfiles with CLISP. I don't know if
it has something to do with my (outdated) version I'm running or what,
but that's been frustrating since lots of my dotfiles are written
entirely in Lisp.
CMUCL was definitely not designed with buiding ease in mind. But as
far as Lisps go, it's a much more sophisticated compiler. CLISP's
byte-compiled files are like Java class files in the sense that
they're cross-platform as well. CMUCL has two compilation modes, one
byte-compiled, and the other full compilation. I believe that CMUCL's
partial compilation even beats CLISP in many areas, but don't know
first-hand (don't take my word).
CLISP is *massively* portable, and that's what I like about it. It's
a huge plus. It doesn't support threads (as far as I know), which
makes it hard to develop commercial applications, but it does support
networking, and there are some database packages that work well with
CLISP, one of which is a PGSQL interface.
Some of the issues that have been raised about CMUCL are addressed in
the SBCL (Steel Bank Common Lisp: http://sbcl.sourceforge.net). It is
a project which forked off from CMUCL, but uses a lot of the same
sources, and so it's probably about as good in most areas as CMUCL,
and should be easier to build from sources on your target platform.
While there's not as much content in this message as I'd like to have
accomplished with this amount of text, I think the most valuable thing
to do is to get your hands dirty using one or both of them. I'd start
with CLISP just because it's simpler. If its performance and license
are ``parsimonious'' for you, then use it. You may consider building
it with PCL (I've never done it, but I think it's feasible), if you
want to explore MOP programming. But that's probably down the line
anyway.
dave
>>>>> "dave" == David Bakhash <·····@alum.mit.edu> writes:
dave> While there's not as much content in this message as I'd like
dave> to have accomplished with this amount of text, I think the most
dave> valuable thing to do is to get your hands dirty using one or
dave> both of them. I'd start with CLISP just because it's simpler.
dave> If its performance and license are ``parsimonious'' for you,
dave> then use it. You may consider building it with PCL (I've never
dave> done it, but I think it's feasible), if you want to explore MOP
dave> programming. But that's probably down the line anyway.
Also, I don't know how much of the MOP is in PCL, except that PCL is
more complete in its implementation of CLOS than what CLISP has.
dave
> * In message <··············@alum.mit.edu>
> * On the subject of "Re: Why choose Clisp over CMUCL?"
> * Sent on Sat, 28 Apr 2001 05:21:47 GMT
> * Honorable David Bakhash <·····@alum.mit.edu> writes:
>
> One thing that sucks about CLISP is its license. It's got that GNU
> GPL contagion that makes it hard to ship your stuff without source.
This is false.
the CLISP COPYRIGHT file specifies that you can distribute your work as
a memory image (+ your fas files, CLISP sources and build instructions).
--
Sam Steingold (http://www.podval.org/~sds)
MS Windows vs IBM OS/2: Why marketing matters more than technology...
>>>>> "sam" == Sam Steingold <···@gnu.org> writes:
>> * In message <··············@alum.mit.edu> * On the subject of
>> "Re: Why choose Clisp over CMUCL?" * Sent on Sat, 28 Apr 2001
>> 05:21:47 GMT * Honorable David Bakhash <·····@alum.mit.edu>
>> writes:
>>
>> One thing that sucks about CLISP is its license. It's got that
>> GNU GPL contagion that makes it hard to ship your stuff without
>> source.
sam> This is false.
sam> the CLISP COPYRIGHT file specifies that you can distribute your
sam> work as a memory image (+ your fas files, CLISP sources and
sam> build instructions).
You and I have a different definition of what effective source code
is. Probably best to leave it at that. I see your point, and it's
exactly what I was referring to.
dave
David Bakhash wrote:
> You may consider building it with PCL (I've never done it,
> but I think it's feasible)...
I have, and it is more than feasible, it is straightforward, if
you use the clisp PCL port...
:)will
Ted Sandler <··········@worldnet.att.net> writes:
> I originally posted this to ··········@cons.org but didn't get much
> feedback. My question is this:
> Why does Clisp seem so much more popular & widely supported than
> CMUCL when CMUCL is a more "industrial strength" lisp? PLEASE NOTE
> that I am NOT trying to start a flame-war. I am just seeking
> insight into what Clisp users are seeing that I am not.
CLISP is easily ported to just about any platform supporting a C
compiler and an I/O API that is moderately similar to Unix.
In contrast, CMUCL is much more challenging to port to additional
platforms.
I can run CLISP atop Windows, Linux/IA-32, and Linux/Alpha, three
platforms that I tend to have occasion to care about. The only one of
those three that CMUCL supports at present is Linux/IA-32.
None of that makes CMUCL "bad," but the facts do support some decision
criteria that lead to CLISP being used when CMUCL _can't_ be used...
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://vip.hex.net/~cbbrowne/resume.html
"Since a cat always lands on its feet, and a piece of buttered toast
always lands buttered side down, if you strap a piece of buttered
toast to the back of a cat, which side will it land on?"
-- .sig file on rec.humor
Ted Sandler <··········@worldnet.att.net> writes:
>I originally posted this to cmucl-help at cons.org [edited] but
>didn't get much feedback. My question is this:
*Please* do not post the exact list address to usenet. Please cancel
that article and repost.
Thanks
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
> * In message <·················@worldnet.att.net>
> * On the subject of "Why choose Clisp over CMUCL?"
> * Sent on Sat, 28 Apr 2001 02:18:32 GMT
> * Honorable Ted Sandler <··········@worldnet.att.net> writes:
>
> Why does Clisp seem so much more popular & widely supported than CMUCL
> when CMUCL is a more "industrial strength" lisp?
I don't think one can claim that one is "more popular" or "more widely
supported" than the other. One can certainly say that CMUCL has a more
advanced compiler, but this is not the only criterion to look at.
License:
CLISP: GNU GPL [you can distribute your work as a memory image (+ your
fas files, CLISP sources and build instructions)].
CMUCL: Public Domain [you can rename cmucl.tar.gz to my-cl.tar.gz,
slap a license you like and sell it as you wish]
UI (even though one is "supposed to" use Emacs/ILisp, this matters!):
CLISP: GNU readline
CMUCL: no command line editing facilities
(but it has Hemlock - an Emacs-like editor)
Compiler:
CLISP: platform-independent byte-codes
CMUCL: native code, very advanced compiler
Portability:
CMUCL: most unix implementations, win32, os/2 &c
CMUCL: a few unix implementations
Resource requirements [these are "order of magnitude" estimates, don't
be harsh on me!]:
CLISP: 2MB RAM
CMUCL: 20MB RAM
If you want industrial-strength fast number-crunching, CMUCL is your
friend.
If you want to do networking, the Lisp speed probably will not be a
problem, so you can use either.
If you want to write scripts (and Perl is not for you :-), CLISP will
foot the bill very nicely.
My personal recommendation is to write portable code which would run
under both implementations and use both until you decide which one is
for you (if you need features which are not in the ANSI CL standard,
like sockets, shell access, Gray streams &c, you might find CLOCC/PORT
useful, see <http://www.podval.org/~sds/data/port.html> and
<http://clocc.sourceforge.net>: you code will run without modifications
on Allegro, LispWorks, CLISP, CMUCL).
--
Sam Steingold (http://www.podval.org/~sds)
Life is a sexually transmitted disease with 100% mortality.
On 30 Apr 2001 12:17:20 -0400, Sam Steingold <···@gnu.org> wrote:
> Portability:
> CMUCL: most unix implementations, win32, os/2 &c
> CMUCL: a few unix implementations
You probably meant CLISP in the first entry.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/