A familiar reason for choosing Common Lisp over Scheme is that CL has
a rich set of features "ready to go", whereas Scheme requires one to
gather libraries in order to obtain a comparable feature set.
My question is, Does anyone have practical experience of this being a
problem with Scheme? If I were to begin a project using Scheme, I
would choose libraries, in order of preference,
(1) Portable R5RS-compatible libraries usable by any R5RS
implementation (whether or not the libraries happen to be SRFIs).
(2) Native SRFIs that come with a particular implementation.
If for some reason I wish to switch Scheme implementations, the new
candidate would obviously need to support the SFRIs in (2). If my
unit tests pass with the new implementation, I am done. If they do
not, I flame the mailing list of that Scheme implementation, heaping
scorn and ridicule upon them for falsely claiming to support an SRFI.
Problem solved.
In other words, I don't quite understand the above argument in favor
of CL, as it seems like a non-issue for the reasons I gave. Surely
there is something I'm missing? Suppose for the moment that I prefer
Scheme for aesthetic, non-practical reasons. What are the practical
reasons for not using it?
BTW I am posting in comp.lang.lisp instead of comp.lang.scheme not for
flaming purposes but because I am interested in answers from those who
use CL, not Scheme.
Thanks,
--FC
There is a contradiction in your question.
Compare this:
·············@gmail.com wrote:
> My question is, Does anyone have practical experience of this being a
> problem with Scheme?
with that:
> BTW I am posting in comp.lang.lisp instead of comp.lang.scheme not for
> flaming purposes but because I am interested in answers from those who
> use CL, not Scheme.
So what do you actually want to know?
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Apr 14, 8:45 pm, Pascal Costanza <····@p-cos.net> wrote:
> There is a contradiction in your question.
>
> Compare this:
>
> ·············@gmail.com wrote:
> > My question is, Does anyone have practical experience of this being a
> > problem with Scheme?
>
> with that:
>
> > BTW I am posting in comp.lang.lisp instead of comp.lang.scheme not for
> > flaming purposes but because I am interested in answers from those who
> > use CL, not Scheme.
>
> So what do you actually want to know?
Um, huh? Where is the contradiction? As I said, "a familiar reason
for choosing Common Lisp over Scheme is that CL has a rich set of
features 'ready to go'..." It might be a contradiction if nobody in
comp.lang.lisp has any practical knowledge or experience with Scheme.
I am interested in the Scheme-to-Lisp converts, not those already
invested in Scheme.
Hi,
As always, it all depends on the application.
> A familiar reason for choosing Common Lisp over Scheme is that CL has
> a rich set of features "ready to go", whereas Scheme requires one to
> gather libraries in order to obtain a comparable feature set.
For my own purposes, it's more about the available libraries'
portability rather than about the featureset of the base language. Of
course, library portability depends on the featureset of the base
language, so...
> In other words, I don't quite understand the above argument in favor
> of CL, as it seems like a non-issue for the reasons I gave. Surely
> there is something I'm missing?
Well, you're assuming that there actually are as many R5RS+SRFI-
portable Scheme libraries as there are portable CL libraries (by which
I do not necessarily mean `portable' in the ANSI sense, but rather
portable in the sense of being usable on all the CL implementations
I'm interested in). I'm not one to judge whether this assumption is
correct or not, I'm just pointing it out. Maybe you ought to look for
those portable libraries you need. If you can find them and like the
way they work, there's an answer (for your specific application, of
course). If not, there's an answer as well.
~ Matthias
> If for some reason I wish to switch Scheme implementations, the new
> candidate would obviously need to support the SFRIs in (2). If my
> unit tests pass with the new implementation, I am done. If they do
> not, I flame the mailing list of that Scheme implementation, heaping
> scorn and ridicule upon them for falsely claiming to support an SRFI.
> Problem solved.
Although it may give you some satisfaction to have a rant at the
maintainer, I don't think I would call this "problem solved".
--
Phil
http://phil.nullable.eu/
My question takes as a starting point that we have already decided
upon the implementation and libraries. In order to make use of pipes,
threads, processes and such, we have no choice but to commit to a
particular implementation anyway, whether we are talking about Common
Lisp or Scheme.
(Incidentally since I do not believe all the available alternatives to
CLOS are "half-baked" or "crippled," I will consider that line of
reasoning a non-sequitur.)
So given that we have already chosen and are satisfied with the
implementation and libraries, what is the actual advantage of CL after
that? I see both CL and Scheme heavily dependent on implementation
issues, so the portability argument for CL does not hold in this case.
If CL had the functionality of Ruby (not that it should --- just a
hypothetical), then CL would be the obvious hands-down winner. But it
doesn't, so CL and Scheme are relatively in the same boat in this
regard.
·············@gmail.com writes:
> My question takes as a starting point that we have already decided
> upon the implementation and libraries. In order to make use of pipes,
> threads, processes and such, we have no choice but to commit to a
> particular implementation anyway, whether we are talking about Common
> Lisp or Scheme.
Why do you take that as a starting point? Portable libraries for Common
Lisp exist for some of these, and if you can't find one you like/that
works with your Lisp, writing code for each Lisp you want to support is
probably not going to be the most difficult or time-consuming part of
your program. I can't speak for the Scheme world.
> (Incidentally since I do not believe all the available alternatives to
> CLOS are "half-baked" or "crippled," I will consider that line of
> reasoning a non-sequitur.)
IIRC from the last discussion here, all the CLOS-alikes are incomplete
subsets and aren't especially fast either. For a person who wants CLOS
(that would be me), it doesn't sound like they cut it.
I'm not sure what you want to compare here. You're just ignoring some of
the best reasons to choose CL: good portability between implementations,
including a big standard library.
·············@gmail.com writes:
Forgive me for this observation, but it appears to me that in the
following you are telling us that you have already chosen Scheme, that
you are happy with your choice, and that any practical issues we might
raise here are things you don't care about.
So, what, exactly, do you want from us? Validation that you made the
right choice?
> My question takes as a starting point that we have already decided
> upon the implementation and libraries. In order to make use of pipes,
> threads, processes and such, we have no choice but to commit to a
> particular implementation anyway, whether we are talking about Common
> Lisp or Scheme.
Not necessarily true. There are some portability packages for web
servers, multi-processing and numerous other libraries. I'm not sure
what you mean by pipes. Are these the unix-like pipes?
> (Incidentally since I do not believe all the available alternatives to
> CLOS are "half-baked" or "crippled," I will consider that line of
> reasoning a non-sequitur.)
>
> So given that we have already chosen and are satisfied with the
> implementation and libraries, what is the actual advantage of CL after
> that? I see both CL and Scheme heavily dependent on implementation
> issues, so the portability argument for CL does not hold in this case.
If you are already satisfied, why even bother asking? One can make
exactly the same argument with any language: "Given that we have
already chosen and are satisified with C++ and its libraries, what is
the advantage of Common Lisp?". Clearly, from your point of view, there
isn't any advantage.
> If CL had the functionality of Ruby (not that it should --- just a
> hypothetical), then CL would be the obvious hands-down winner. But it
> doesn't, so CL and Scheme are relatively in the same boat in this
> regard.
--
Thomas A. Russ, USC/Information Sciences Institute
On Apr 15, 6:20 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> ·············@gmail.com writes:
> > So given that we have already chosen and are satisfied with the
> > implementation and libraries, what is the actual advantage of CL after
> > that? I see both CL and Scheme heavily dependent on implementation
> > issues, so the portability argument for CL does not hold in this case.
>
> If you are already satisfied, why even bother asking? One can make
> exactly the same argument with any language: "Given that we have
> already chosen and are satisified with C++ and its libraries, what is
> the advantage of Common Lisp?". Clearly, from your point of view, there
> isn't any advantage.
The problem will become apparent if we take the extreme case.
Suppose I said that I was satisfied with using Brainfuck
http://en.wikipedia.org/wiki/Brainfuck and (amazingly) it contained
the libraries I needed. With the language implementation and
libraries issue aside, why should I choose Lisp over Brainfuck?
Brainfuck seems to be sufficient, so what am I missing?
Now, replace Brainfuck with Scheme.
> Suppose I said that I was satisfied with using Brainfuckhttp://en.wikipedia.org/wiki/Brainfuckand (amazingly) it contained
> the libraries I needed. With the language implementation and
> libraries issue aside, why should I choose Lisp over Brainfuck?
Supposing you've studied both options and are happy with Brainfuck,
then use it. It's as simple as that. I mean, if there's some kind of
magical library for Brainfuck that lets you say "FOO!" and be done
with your application, I'd readily use that instead of Lisp.
Well. I guess such a library doesn't exist. Bummer. I wonder why.
~ Matthias
P.S. If the message isn't clear enough: What I'm talking about is that
the whole point is that your assumptions _aren't_ true in practice
(practical concerns are what you asked for, remember?) in most cases,
so your line of reasoning isn't interesting. They may be true for
your specific application, but that doesn't magically make CL's
advantage in this regard disappear in general. And really, I don't
believe you can find such a wealth of portable libraries for Scheme as
for CL that are as easy to combine and use. Not having a nice,
standardised, actually-used-in-practice condition system is a really
nasty source of pain, for instance.
On Apr 16, 6:18 am, Matthias Benkard <··········@gmail.com> wrote:
> Not having a nice,
> standardised, actually-used-in-practice condition system is a really
> nasty source of pain, for instance.
That is a good point. Someone people want such a system, some don't.
Either way you will survive.
You need that or not? If you want that, Scheme doesn't have it.
·············@gmail.com wrote:
> On Apr 15, 6:20 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
>>·············@gmail.com writes:
>>
>>>So given that we have already chosen and are satisfied with the
>>>implementation and libraries, what is the actual advantage of CL after
>>>that? I see both CL and Scheme heavily dependent on implementation
>>>issues, so the portability argument for CL does not hold in this case.
>>
>>If you are already satisfied, why even bother asking? One can make
>>exactly the same argument with any language: "Given that we have
>>already chosen and are satisified with C++ and its libraries, what is
>>the advantage of Common Lisp?". Clearly, from your point of view, there
>>isn't any advantage.
>
>
> The problem will become apparent if we take the extreme case.
> Suppose I said that I was satisfied with using Brainfuck
> http://en.wikipedia.org/wiki/Brainfuck and (amazingly) it contained
> the libraries I needed. With the language implementation and
> libraries issue aside, why should I choose Lisp over Brainfuck?
> Brainfuck seems to be sufficient, so what am I missing?
>
> Now, replace Brainfuck with Scheme.
Can I replace "clown" with "troll" instead? Because above you are rater
torturously trying to keep a stupid trollbaitish thread going instead of
being a gentleman and moving on.
We have a pool and a pond....
maybe you are merely trying to solve the wrong problem.
Cor
--
SPAM DELENDA EST http://www.clsnet.nl/mail.php
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Alle schraifvauden zijn opsettelick, teneynde ieder lafaart de cans te
gevuh over spelingk te mekkuh instede de inhaut
·············@gmail.com wrote:
snip
>
> If CL had the functionality of Ruby (not that it should --- just a
> hypothetical), then CL would be the obvious hands-down winner. But it
> doesn't, so CL and Scheme are relatively in the same boat in this
> regard.
Could you expand on this? What functionality are you referring to
you feel is missing?
Sure, there are little differences btn Ruby and CL, but the languages
are quite similar, and a lot of the differences have counterparts
in CL.
The biggest difference I've found btn Ruby and CL is not the language,
but the differences in their libraries. I like Ruby's libraries better,
but think CL is a better language. Choose the best tool for the job.
Thank you!
On Tue, 15 Apr 2008 10:09:36 -0700 (PDT), ·············@gmail.com wrote:
> If CL had the functionality of Ruby (not that it should --- just a
> hypothetical), then CL would be the obvious hands-down winner. But it
> doesn't, so CL and Scheme are relatively in the same boat in this
> regard.
Well, this may sound trivial, but if all you want is Ruby, it may be ok
to use Ruby... You really don't have to *use* either Scheme or Common
Lisp as `Ruby substitutes'.
·············@gmail.com writes:
> BTW I am posting in comp.lang.lisp instead of comp.lang.scheme not for
> flaming purposes but because I am interested in answers from those who
> use CL, not Scheme.
When I used Scheme (before the year 2001), I missed a powerful portable
CLOS-like system. Maybe you could try to find out if there is a portable
Scheme library nowadays which plays in the same league as CLOS. If not, I
would consider this to be an argument in favor of Common Lisp.
Nicolas
·············@gmail.com wrote:
> A familiar reason for choosing Common Lisp over Scheme is that CL has
> a rich set of features "ready to go", whereas Scheme requires one to
> gather libraries in order to obtain a comparable feature set.
>
> My question is, Does anyone have practical experience of this being a
> problem with Scheme? If I were to begin a project using Scheme, I
> would choose libraries, in order of preference,
>
> (1) Portable R5RS-compatible libraries usable by any R5RS
> implementation (whether or not the libraries happen to be SRFIs).
>
> (2) Native SRFIs that come with a particular implementation.
>
> If for some reason I wish to switch Scheme implementations, the new
> candidate would obviously need to support the SFRIs in (2). If my
> unit tests pass with the new implementation, I am done. If they do
> not, I flame the mailing list of that Scheme implementation, heaping
> scorn and ridicule upon them for falsely claiming to support an SRFI.
> Problem solved.
>
> In other words, I don't quite understand the above argument in favor
> of CL, as it seems like a non-issue for the reasons I gave. Surely
> there is something I'm missing?
Possibly not. If you do not want to share your code with another Schemer
you are good to go. And please don't call me Shirley.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
On Apr 15, 4:37 pm, Ken Tilton <···········@optonline.net> wrote:
> ·············@gmail.com wrote:
>
> > In other words, I don't quite understand the above argument in favor
> > of CL, as it seems like a non-issue for the reasons I gave. Surely
> > there is something I'm missing?
>
> Possibly not. If you do not want to share your code with another Schemer
> you are good to go.
But my point was the converse. As long as I stick to R5RS libraries
and a couple (or no) SRFIs, and include unit tests for those SRFIs,
then there should be little or no compatibility problems. I don't see
a solid case for the compatibility argument against Scheme, provided
one takes these precautions. Maybe there is one of which I am not
aware. I was afraid to ask at comp.lang.scheme for fear of getting
mere high-fives in response. I am interested in refutations, not
confirmations.
> And please don't call me Shirley.
OK, Loretta.
·············@gmail.com wrote:
> On Apr 15, 4:37 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>·············@gmail.com wrote:
>>
>>
>>>In other words, I don't quite understand the above argument in favor
>>>of CL, as it seems like a non-issue for the reasons I gave. Surely
>>>there is something I'm missing?
>>
>>Possibly not. If you do not want to share your code with another Schemer
>>you are good to go.
>
>
> But my point was the converse. As long as I stick to R5RS libraries
> and a couple (or no) SRFIs, and include unit tests for those SRFIs,
> then there should be little or no compatibility problems. I don't see
> a solid case for the compatibility argument against Scheme, provided
> one takes these precautions. Maybe there is one of which I am not
> aware. I was afraid to ask at comp.lang.scheme for fear of getting
> mere high-fives in response. I am interested in refutations, not
> confirmations.
Ironically, the confirmation you would have gotten is that you would
/not/ be able to share your code. That was the one thing the Scheme High
Fivers conceded during the last flamewar (years ago).
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
From: Edi Weitz
Subject: Re: Practical problems with Scheme?
Date:
Message-ID: <uabjueoq3.fsf@agharta.de>
On Tue, 15 Apr 2008 15:17:43 -0700 (PDT), ·············@gmail.com wrote:
> But my point was the converse. As long as I stick to R5RS libraries
> and a couple (or no) SRFIs, and include unit tests for those SRFIs,
> then there should be little or no compatibility problems. I don't
> see a solid case for the compatibility argument against Scheme,
> provided one takes these precautions. Maybe there is one of which I
> am not aware.
You're probably too optimistic. I attended Alexey Radul's talk at the
Boston Lisp User Group two weeks ago
http://web.mit.edu/~axch/www/boston-lisp-mar-08-slides.pdf
and my impression (not having much Scheme experience myself) was that,
compared to Common Lisp, there are absurdly many details where Scheme
implementations are allowed to diverge.
I think the talk was meant to be pro Scheme, but to me it acted as a
deterrent. Maybe I'm biased, though...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Apr 15, 5:29 pm, Edi Weitz <········@agharta.de> wrote:
> You're probably too optimistic.
People say the said the same thing about Eiffel, yet Gobo has thrived
on one mans herculean efforts.
You can do what you like if you want to put the work in. Take SLIB,
for example...
> Maybe I'm biased, though...
Think so? hahaha :)
>>>>> "fc" == furtive clown <·············@gmail.com> writes:
fc> But my point was the converse. As long as I stick to R5RS libraries
fc> and a couple (or no) SRFIs, and include unit tests for those SRFIs,
fc> then there should be little or no compatibility problems. I don't see
fc> a solid case for the compatibility argument against Scheme, provided
fc> one takes these precautions. Maybe there is one of which I am not
fc> aware.
Hi,
this is what happened some years ago. My first non-toy Scheme program
ran too slow on the implementation I used (Guile), so I wanted to try a
few others.
None of the alternative implementations I tried had the required
combination of features:
internal define
complex numbers
bignums.
I believe that these are still "optional" in R5RS, the situation might
be getting better with R6RS, but I hear that this new standard is
quite controversial in Scheme circles.
HTH
Roland
fc> A familiar reason for choosing Common Lisp over Scheme is that CL has
fc> a rich set of features "ready to go", whereas Scheme requires one to
fc> gather libraries in order to obtain a comparable feature set.
(i never was using Scheme, but judging from experience with other languages)
unlike core functionality, third-party libraries are often:
* non-orthogonal: there are multitude of libraries with aproximately same
functionality, but slightly different
* inconsistent: they are written in different styles and do not play well
with each other
* half-backed: often you can find library that is amazing, but not longer
supported and has known bugs
so, obviously, you have to do more work finding/choosing libraries and
maintaining thier working condition.
also, there might be issues with more than one person working on a
project -- there might be individual style/library preferences..
OTOH core functionality is core functionality, it is same for everybody. if
you're joining project other people are working on, chances are they are
using LOOP (unless they are too creative, certainly), and there is no need
to learn ITERATE, COLLECT, SERIES, or whatever is considered fancy in this
season. and chances are you'd be using CLOS, and not some half-backed
crippled in-house OO library.