In the various discussions up till now in comp.lang.lisp of the
advantages and disadvantages of Scheme vs CL, the general conclusion
seems to be that CL is much better for most purposes than Scheme and
that Scheme programmers who try to use CL tend to only use it in a
limited way and not understand what they're missing by not taking full
advantage of it.
Those conclusions seem to be based on the issue being the CL standard
vs the Scheme standard. But what happens if the issue is changed to
specific CL implementations vs specific Scheme implementations? What
if portability to other implementations of the same language is not an
issue for a particular project, and the issue in question is whether
to use a particular Scheme implementation vs a particular CL
implementation?
For example, consider Mzscheme. It's a bigger language built on top
of Scheme. Can anyone give specific reasons why a specific CL
implementation is better for most purposes than Mzscheme? Or any
specific features of CL which are much better than the corresponding
Mzscheme features?
"Software Scavenger" <··········@mailandnews.com> wrote in message
································@posting.google.com...
> For example, consider Mzscheme. It's a bigger language built on top
> of Scheme. Can anyone give specific reasons why a specific CL
> implementation is better for most purposes than Mzscheme? Or any
> specific features of CL which are much better than the corresponding
> Mzscheme features?
The simple answer is use them and see.
Maybe your question should be, which specific features of LispWorks (or
Allegro CL) are better than the Mzscheme features? Both LWW and ACL have
functionality beyond the CL standard with multi-threading, GUIs, CORBA,
ODBC, FFI .... Does MzScheme?
Generic CL (ANSI spec) is more complete than generic Scheme. I know generic
CL has more features than generic Scheme. I am just assuming that LWW is
more capable than Mzscheme. I know generic CL can do the job, generic
Scheme takes more custom extension.
Why are you concerned??? You can confuse yourself forever making a choice
of programming environment. (Java, Smalltalk, CL, Delphi, VB). What's it
going to be? Personally, I am tired of half-ass tools, give me the biggest,
most mature, bug-free, thought-out tool around. My feeling is that the CL
tools are just that.
Wade
From: Michael Livshin
Subject: Re: Common Lisp vs specific Scheme implementations
Date:
Message-ID: <s3k7tlyz0l.fsf@yahoo.com.cmm>
··········@mailandnews.com (Software Scavenger) writes:
> For example, consider Mzscheme. It's a bigger language built on top
> of Scheme. Can anyone give specific reasons why a specific CL
> implementation is better for most purposes than Mzscheme?
can't say anything about specific CL implementations in this context,
but consider these points about MzScheme:
* the object system is no match for CLOS, to put it mildly.
* the base language tends to change according to the current
research. this is (probably) a good thing for teaching, research
and experimentation, but a bad thing for production. it changed
alot from v103 to v200, and I don't see any reason for something
like that not to happen again, many times over.
* last I checked, the debugger wasn't very good. (i.e. the fancy GUI
thingie in the PLT suite didn't support the whole Scheme language,
and there weren't another debugger that I could see. maybe there
is).
it's a great Scheme implementation, though, if you are into that kind
of thing. the new macro/module system in v200 is very interesting,
for example.
--
I have seen the future, and it does not work.
··········@mailandnews.com (Software Scavenger) writes:
> In the various discussions up till now in comp.lang.lisp of the
> advantages and disadvantages of Scheme vs CL, the general conclusion
> seems to be that CL is much better for most purposes than Scheme
Well, that's the opinion of people who post here; that is, people who like
CL. Put another way, people who've chosen CL think that CL is better for
their needs than not-CL. That's not very surprising. I happen to be one
of those people, and I'm happy with my choice. But my choice is not a
condemnation of Scheme--it simply me making a choice that works for me.
As for grand sweeping claims about these languages comparatively, my feeling
is that it's good that Schemers have a community where they are happy and
we have a community where we are happy. I don't think it hurts for someone
from either community to pick up a feature from the other and say "hey, this
is kinda cool--would it work well transplanted?" (The answer might be "no",
but the question can be worth asking as long as the asker is aware that it's
not a no-brainer that something that works well in one-language will
automatically work in another.)
> and
> that Scheme programmers who try to use CL tend to only use it in a
> limited way and not understand what they're missing by not taking full
> advantage of it.
The problem isn't the attempt of "Scheme programmers" to use CL. The
problem is the willing of people from any programming language X to
use language Y without _actually_ learning its semantics. Semantics
matter. My Spanish teacher was careful to teach us that words that
look the same in one language don't necessarily mean the same in
another ("false cognates"). We (living in the Panama Canal Zone) were
taught horror stories about Americans encouraging their Panamanian
maids about the laundry: "Usa mas sopa." ("Use more soup." ... sopa =
soup, not soap) And we were taught about the woman who, learning
horseback riding from an instructor in Spain, got tired of being led
around everywhere on a tether and asked "Vamos sin ropa?" ("Can we go
without clothing?" ... ropa = clothing, not rope) Instilling in users
of a language a proper sense of fear about using words they do not
understand is really quite helpful. Programmers tend to be headstrong
and not consult a text to begin with, and this is made worse if they
are (as so many today are) taught that if it compiles without warning,
it's probably "Right" ... that doesn't get them the critical background
they need.
The problems with Schemers using CL are _not_ simply failure to take full
use of it. This is a very common bug in CL use by Schemers, for example,
and is perfectly valid CL code, just not something most people would ever
write because of the problem it causes:
(defun add-n-to-all (n)
(defun add-n (x) (+ x n))
(mapcar #'add-n '(1 2 3)))
It's even more confusing when it appears to work nearly all of the time,
especially in single-threaded lisps. (It's hopefully immediately obvious
why it loses in multi-threaded lisps.) But Scheme programmers think the
inner DEFUN is local to the outer one, as nested DEFINE would be in Scheme.
> Those conclusions seem to be based on the issue being the CL standard
> vs the Scheme standard. But what happens if the issue is changed to
> specific CL implementations vs specific Scheme implementations? What
> if portability to other implementations of the same language is not an
> issue for a particular project, and the issue in question is whether
> to use a particular Scheme implementation vs a particular CL
> implementation?
>
> For example, consider Mzscheme. It's a bigger language built on top
> of Scheme. Can anyone give specific reasons why a specific CL
> implementation is better for most purposes than Mzscheme? Or any
> specific features of CL which are much better than the corresponding
> Mzscheme features?
All comparative discussions, whether language-to-language or
implementation-to-implementation, become intensely personal. Your words
here are not specific enough to allow an objective analysis. You may
succeed in provoking a discussion from which you can learn, in spite of
the problems, but you should be aware of the problems in how you're going
about this query.
For example, even if I had access to only one of these implementations
and never planned to port, standards are still important in several ways:
- Use of standards mean that you can find more experienced programmers
who are familiar with standard tools than you can find people
experienced with a particular implementation.
- Use of standards means that if the implementation disappears, there is
a chance that something else will emerge (or has already emerged) which
can act as "second source". [Some like to point out that open source
leaves you able to provide such a "second source" yourself, but that's
really a minor item. In particular, it doesn't contradict the point
I'm making here; it's just an opportunity for gratuitous banner waving.]
- Use of standards means that if new platforms come along, there is a
chance that an appropriate implementation will exist for them. [Open
source may give you a leg up on this, but is not necessarily a panacea.]
- Use of standards precludes gratuitous change because standards change
slowly. I call this "temporal porting". Some people want their code
to port to other implementations; you're saying you don't. But you may
still want your code to port to the next release of the vendor Lisp, and
it's standards that make this more likely.
So my real point is that escaping the language and considering only the
implementation is a choice you can make, but not one I would. If you
merely want to debate X or Y extension to the langauge, in the context of
a standard framework, that seems to me to be a different discussion; whether
you think it's a better discussion, I guess, is personal taste.
Btw, I doubt a huge number of people here know Mzscheme. Most people
don't take the time to do detailed checking of implementations of
languages they don't use, and a lot of people on this newsgroup don't
use Scheme at all, or haven't used it recently, or use it only rarely.
Why not make a list of the features you like and ask about them
specifically? I think you will get MUCH poorer grade discussion by
assuming people know what you're talking about and assuming people
will actively admit ignorance. Most will just be silent. I'll just
say I don't use or know about Mzscheme and so am not going to engage
this discussion directly on the level you request simply for that
reason. You can't tell the difference between silence on this question
meaning "I know these systems and no features of X are better than Y"
vs "I don't know these systems, and for all I know there are many features
of X better than Y".
Next, each individual person you talk to probably has experience in only
one or a small handful of application areas, so any time you ask questions
with "is better for most purposes than", don't expect to find many experts.
Ask your question in the form of an existential instead of a universal
quantification and you may get more competent answers.
Furthermore, if you enumerate specific features you care about, you keep
discussions of features that no one cares about from wasting a lot of
community energy. And you also allow people with differing experience with
similar features in other dialects of either CL or Scheme to get involved.
Just out of curiosity how did the animosity between CL and Scheme
start? Did it have anything to do with that failed attempt to merge the
two?
--
Alexander Schofield
From: Christopher C. Stacy
Subject: Re: Common Lisp vs specific Scheme implementations
Date:
Message-ID: <ubsewzngb.fsf@theworld.com>
>>>>> On Sun, 10 Feb 2002 22:06:59 -0500, Alexander Schofield ("Alexander") writes:
Alexander> Just out of curiosity how did the animosity between CL and
Alexander> Scheme start? Did it have anything to do with that failed
Alexander> attempt to merge the two?
I don't think that there is general animosity, beyond the differences
between any other two similar religions. Some people simply would say
that Common Lisp is better suited for some purposes, and Scheme may be
best for certain others. Few very experienced programmers would claim
that one size always fits all, and it's just a matter of where you draw
the boundaries. To the extent that people get religous about the two
languages, I would characterize the Scheme believers as "fundamentalist"
in both senses of the word. Their core belief is that the world is made
of a small number of things, and that the way to build real-world complexity
is to build directly from that set. Furthermore, they tend to denounce
Common Lisp with loaded words: "Scheme is more pure than Common Lisp".
Common Lisp programmers tend to prefer a world that is more pragmatic.
The two communities serve different application interests, but also
compete in some areas, and compete for external identification as "Lisp".
This is all further aggrevated by the fact that both parties want new
believers, and both like to capitalize on the fact that outsiders do
not recognize that there is more than one religion called "Lisp".
It's also important to remember that what one sees in newsgroups are
not neccesarily accurate representations of the real world, and things
are often blown out of proportion.
··········@mailandnews.com (Software Scavenger) writes:
> In the various discussions up till now in comp.lang.lisp of the
> advantages and disadvantages of Scheme vs CL, the general conclusion
> seems to be that CL is much better for most purposes than Scheme and
> that Scheme programmers who try to use CL tend to only use it in a
> limited way and not understand what they're missing by not taking full
> advantage of it.
I wouldn't know. I know Scheme and I take advantage of about 80% of CL.
> Those conclusions seem to be based on the issue being the CL standard
> vs the Scheme standard. But what happens if the issue is changed to
> specific CL implementations vs specific Scheme implementations? What
> if portability to other implementations of the same language is not an
> issue for a particular project, and the issue in question is whether
> to use a particular Scheme implementation vs a particular CL
> implementation?
Well, a non portable program is best written in Assembly code for a specific
architecture. :)
> For example, consider Mzscheme. It's a bigger language built on top
> of Scheme. Can anyone give specific reasons why a specific CL
> implementation is better for most purposes than Mzscheme? Or any
> specific features of CL which are much better than the corresponding
> Mzscheme features?
Tell us what is in MzScheme that you do not find in a specific CL
implementation.
Just off the MzScheme page, you do not have a multimethods. Moreover
you do not have native compilation, but only compilation to C like
ECL.
Therefore, you are always better off using a CL implementation to
start with.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
>
> Tell us what is in MzScheme that you do not find in a specific CL
> implementation.
>
> Just off the MzScheme page, you do not have a multimethods.
And many other things which could impede a programmer. I first too tried
MzScheme but abandoned it:
a) Scheme does not have 2d-arrays (yes, yes implementation is maybe easy and
straightforward)
b) I am quite sure that Lisp has got manifold options for handling formats (e.g.
set the precision of a number and write it to a file)
bb) I am also quite sure that Lisp can handle binary formats; which Scheme at
least can not (I have witnessed some discussions on comp.lang.scheme which
supports my guess)
> Moreover
> you do not have native compilation, but only compilation to C like
> ECL.
Admittedly, the compilation with Microsoft Visual C++ works just seamingless
(really). But I find it hard dumb to confornt the user (especially when wants to
introduce some new "paradigms") with C. This was then the reason for me to opt
for Lisp; maybe every Lisp out there is written in C but I do not care nor did I
ever had to use any C compiler when programming in Lisp (okay lets aside the dll
and some legacy C code).
> Therefore, you are always better off using a CL implementation to
> start with.
This is true. I would suggest not to start any projects in Scheme or Clean
before one does not really clear whether it is possible in Scheme (or Clean) or
not. Try to write a number in Clean to a file with lets say 5 significant
digits...
S. Gonzi
From: Brian P Templeton
Subject: Re: Common Lisp vs specific Scheme implementations
Date:
Message-ID: <87u1sknaf4.fsf@tunes.org>
Siegfried Gonzi <···············@kfunigraz.ac.at> writes:
> Marco Antoniotti wrote:
>
>>
>> Tell us what is in MzScheme that you do not find in a specific CL
>> implementation.
>>
>> Just off the MzScheme page, you do not have a multimethods.
>
> And many other things which could impede a programmer. I first too tried
> MzScheme but abandoned it:
>
> a) Scheme does not have 2d-arrays (yes, yes implementation is maybe easy and
> straightforward)
> b) I am quite sure that Lisp has got manifold options for handling formats (e.g.
> set the precision of a number and write it to a file)
> bb) I am also quite sure that Lisp can handle binary formats; which Scheme at
> least can not (I have witnessed some discussions on comp.lang.scheme which
> supports my guess)
>
>> Moreover
>> you do not have native compilation, but only compilation to C like
>> ECL.
>
> Admittedly, the compilation with Microsoft Visual C++ works just seamingless
> (really). But I find it hard dumb to confornt the user (especially when wants to
> introduce some new "paradigms") with C. This was then the reason for me to opt
> for Lisp; maybe every Lisp out there is written in C but I do not care nor did I
> ever had to use any C compiler when programming in Lisp (okay lets aside the dll
> and some legacy C code).
>
I'm fairly certain that ZetaLisp and Symbolics Common Lisp are not
written in C. :)
>
>
>> Therefore, you are always better off using a CL implementation to
>> start with.
>
> This is true. I would suggest not to start any projects in Scheme or Clean
> before one does not really clear whether it is possible in Scheme (or Clean) or
> not. Try to write a number in Clean to a file with lets say 5 significant
> digits...
>
>
> S. Gonzi
>
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
From: Brian P Templeton
Subject: Re: Common Lisp vs specific Scheme implementations
Date:
Message-ID: <87eljrr2ok.fsf@tunes.org>
··········@mailandnews.com (Software Scavenger) writes:
> In the various discussions up till now in comp.lang.lisp of the
> advantages and disadvantages of Scheme vs CL, the general conclusion
> seems to be that CL is much better for most purposes than Scheme and
> that Scheme programmers who try to use CL tend to only use it in a
> limited way and not understand what they're missing by not taking full
> advantage of it.
>
> Those conclusions seem to be based on the issue being the CL standard
> vs the Scheme standard. But what happens if the issue is changed to
> specific CL implementations vs specific Scheme implementations? What
> if portability to other implementations of the same language is not an
> issue for a particular project, and the issue in question is whether
> to use a particular Scheme implementation vs a particular CL
> implementation?
>
> For example, consider Mzscheme. It's a bigger language built on top
> of Scheme. Can anyone give specific reasons why a specific CL
> implementation is better for most purposes than Mzscheme?
Yes. CL implementations mostly stick to the standard, and the
extensions don't often change dramatically between versions. When I
try to use mzscheme in order to use some program, the
implementation-dependent features have changed to the extent that
programs won't work between (fairly close) versions. This was
particularly annoying when I attempted to compile the MzScheme-based
constraint solver of GZigZag, and the macros written for another
version (apparently with a very different macro system) wouldn't work.
I've never had problems of this nature in CL.
[...]
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Let me try to give an account of some of my experiences with Guile
Scheme.
I have followed lisp for a number of years, have had for a long time a
fair grasp of Emacs Lisp and have bought and read CLtL2, but my first
extended programming experiences in the lisp world was with Guile
Scheme. Note that this lies a few years back and a lot may have
happened to Guile since (the active community was one of the reasons
why we chose Guile at the time).
Like so many other schemes, Guile offers a lot of extensions over the
RnRS standard.
I would count the CLOS-like OO (includes multimethods and
multiinheritance and some MOP) and a rather fully fledged integration
with UNIX as the main points.
The biggest drawbacks is performance (Guile is an interpreter, a fast
one at that, but none the less an interpreter which is significantly
slower than a native compiler) and the lack of development tools such
as a good debugger or a profiler. Some might also think that the UNIX
integration makes it difficult to port Guile to non-UNIX
platforms.
We found the Guile module system quite annoying. Having been there and
now doing CL packages, I must say that I far prefer the latter.
Generally, however, CL just has more of everything. Even for something
as extended as Guile, CL still has more to offer. The portable Scheme
Library (SLIB) goes a long way to bring some CL features to scheme,
but one still often runs into limitations of that such the `format'
implementation using a lot of global variables such that it would not
work in a multi-thread setting.
One of the things that is good in CL is the many generic sequence
functions. In scheme, particular if you are confined to something
portable such as SLIB, you often needs to stay with or the other
representation.
And as un-type-ically correct the equality between false and the empty
list is in CL, it saves you for a lot of special casing and and asking
whether it really is ok to take the car of an object.
An lambda lists of course. Trying to do optionals and keyword args in
scheme is a nightmare, Guile certainly hadn't any support for that (at
the time), and if you start of the slippery slope of doing a defun
macro you very soon be in a situatioin where you must ask yourself why
you are still using scheme.
Not in any way a complete list, but I hope it helps a bit.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)