Lisp or Scheme?
Danja
I'm primarily a Java programmer but have recently started looking at XSLT.
This is essentially a (limited) functional language for transforming XML,
though it has a few procedural bits strapped on. I've barely looked at
functional languages in the past, so I thought I'd try and get a feel for
them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
Java too.
What I'm after is a standard, 'clean' version with free implementation on
the MS Windows platform (many of my existing tools are here). I was
wondering whether anyone had any advice on what to go for.
Am I right in thinking that Scheme has a simpler set of basic functions, and
so should be easier to learn?
Cheers,
Danny.
Johan Kullstam
> Hi,
>
> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.
>
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
i would try clisp.
> Am I right in thinking that Scheme has a simpler set of basic
> functions, and so should be easier to learn?
if by "learn" you mean know the whole thing, then yes, scheme is
smaller and therefore there is less of it to learn.
however, functionality that you do not use need not bother you.
however a lack in functionality may force you to implement something
low-level in order to get where you wanted to go. thus, in a rich
language it can be easier to learn to do something useful.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
sysengr
glauber
Hello, Danny,
check http://www.alu.org (Association of Lisp Users) for free Lisp
implementations. I'm partial to CLISP, but unless you already have emacs set
up, you may be better off with Corman Lisp, since your platform is Windows.
As for Lisp x Scheme, they're very similar. Lisp has more stuff built in, so
it's usually easier for novices like me. Scheme is good too, but it requires
more work, initially.
XSLT is a descendant of DSSSL, which contained most of the Scheme language in
it. I think most Lisp/Scheme people wouldn't recognize any of it in XSLT.
One last note: there are several nice implementations of Scheme in Java (no
Common Lisp yet, that i know of). Search for kawa in your favourite Internet
search engine, for one of them. Kawa can interact freely with Java, can
compile Scheme code into .class files, etc.
g
--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/
Steven Haflich
> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.
By all means you should learn Lisp, but that advice in this forum is
rather
like adice that you should brush your teeth every day.
However, you shouldn't learn Lisp as a way to learn about XSLT. XSLT is
not at all a functional language (like Lisp, C, Pascal, FORTRAN, COBOL)
but
is instead a pattern-matching-and-replace language. It is a rather
limited
on at that, since it permits only a single rewrite of each source form
or
subform.
See www.lisp.org for info about free implementations of Comon Lisp,
Scheme,
and other dialects. See xml.apache.org and look around for Xalan to
find a
free implementation of XSLT.
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
>
> Am I right in thinking that Scheme has a simpler set of basic functions, and
> so should be easier to learn?
This is a religious issue, rather like asking whether Christianity or
Islam
is easier to learn. Common Lisp is certainly larger than Scheme, but
the set
of operations necessary for simple learning is probably not much
different.
The extended features of CL probably make it easier to use for any
specific
purpose, since so many commonly-needed idioms are built in.
felix
>Am I right in thinking that Scheme has a simpler set of basic functions,
and
>so should be easier to learn?
>
Scheme is definitely easier to learn: You just have to understand a
relatively
small set of concepts, which you can apply in nearly every possible way.
Common LISP still keeps a load of old cruft that can be confusing.
Furthermore, implementations like MzScheme (check out <www.schemers.org>)
offer a wealth of functionality, and a nice set of development tools.
cheers,
felix
Eugene Zaikonnikov
* "Danny" == Danja <danny_avo...@panlanka.net> writes:
Danny> I've barely looked at functional languages in the past, so I
Danny> thought I'd try and get a feel for them by playing with
Danny> Lisp. Maybe I'll get some fresh ideas that I can use in Java
Danny> too.
Well, in some aspects Java is much closer to Lisp than, say, C++. It
also has GC, similar argument passing semantics and rudimentary
introspection mechanisms. There also exists a Scheme implementation
(Kawa (no relation with IDE of the same name)) which compiles directly
to Java bytecode. Guy Steele, one of the guys behind the Java project,
is also a key person in Scheme and Common Lisp history.
Danny> What I'm after is a standard, 'clean' version with free
Danny> implementation on the MS Windows platform (many of my existing
Danny> tools are here). I was wondering whether anyone had any advice
Danny> on what to go for.
As for CL, take a look at these:
- CLISP (clisp.cons.org), lightweight, free, compiles to bytecode, no
GUI;
- CormanLisp (www.corman.net), compiles to native code, free for
personal use, with inline assembler and provides COM interface to
the world;
- Allegro CL (www.franz.com), compiles to native, limited commercial
trial, includes Delphi-like GUI builder;
- Xanalys (www.xanalys.com) also has a trial of their good commercial
Lisp environment.
Can't speak about current Scheme implementations, but surely Scheme
people will enlighten you.
Danny> Am I right in thinking that Scheme has a simpler set of basic
Danny> functions, and so should be easier to learn?
The basic functions of CL and Scheme overlap alot, but CL has loads of
useful standard functions and a standard object system. Scheme makes
effort in being as elegant and non-redundant language as possible and
is widely used in academia, while CL is mostly focused on doing
practical stuff (the above doesn't means that Scheme isn't used in
industry or that Common Lisp is not elegant at all).
--
Eugene
brl...@my-deja.com
very suitable for learning functional programming; a variety of
textbooks use it.
"Danja" <danny_avo...@panlanka.net> writes:
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
I highly recommend DrScheme, which was designed with learning in mind.
A coworker has used it with success.
If you're doing Java-based web programming and are interested in Scheme,
please do give BRL a try, especially if you're doing database-driven
pages.
http://brl.sourceforge.net/
Learning either Scheme or CL will give you a head start on learning the
other. They have a lot in common.
--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
")) ; I rarely read mail sent to brl...@my-deja.com
Marco Antoniotti
"felix" <fe...@anu.ie> writes:
> >
> >Am I right in thinking that Scheme has a simpler set of basic functions,
> and
> >so should be easier to learn?
> >
>
> Scheme is definitely easier to learn: You just have to understand a
> relatively
> small set of concepts, which you can apply in nearly every possible
> way.
Including the first application of Scheme: reimplementing what is not there.
> Common LISP still keeps a load of old cruft that can be confusing.
Oh yeah. DEFSTRUCT is cruft, 2D arrays is cruft, a standard and
advanded Object System is cruft. Come on....
> Furthermore, implementations like MzScheme (check out <www.schemers.org>)
> offer a wealth of functionality, and a nice set of development tools.
Essentially a reimplementation of what is already there and standard
in Common Lisp.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Craig Brozefsky
> > Furthermore, implementations like MzScheme (check out <www.schemers.org>)
> > offer a wealth of functionality, and a nice set of development tools.
>
> Essentially a reimplementation of what is already there and standard
> in Common Lisp.
<toke on joint>
"Man, this time we're gonna nail it! It's gonna be cleaner, and
simpler, and just fuckin' better, man!"
"That's right, dude. It's gonna friggin' rock, man!"
<another pull on the bong>
"We got a unified namespace, continuations, and hygienic macros.
We're so stacked! Muthafuckin' CL can't touch us. They might call
it re-inventing the wheel, but it's gonna be the roundest damn wheel
there ever was."
"Dude, where's my car?"
PS: I have a secret crush on scheme which I cannot deny.
Eli Barzilay
> "felix" <fe...@anu.ie> writes:
> > Furthermore, implementations like MzScheme (check out
> > <www.schemers.org>) offer a wealth of functionality, and a nice
> > set of development tools.
>
> Essentially a reimplementation of what is already there and standard
> in Common Lisp.
So what? Is it bad for Allegro to reimplement what is standard in
Common Lisp? Or, given the fact that this functionality is standard
in MzScheme, would you say that it is "essentially" a reimplementation
of what is already there and standard in MzScheme?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Friedrich Dominicus
> Hi,
>
> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.
>
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
Now as I read trough the answers I do not find suggestions here. Now
there are some free implementatons of Common Lisp but I do not know if
one can get them to work easily on Windows. I'm using LispWorks for
Linux from
Xanalys here. You can get a free but somwhat restricted version for
Windows too. I downloaded that too and it seems to work
smoothless. The nice point about LispWorks is the good
documentation. It's a bit out-dated but helps you to find
through. Common Lisp is a really big language and even if people do
not like to here it a bit Perl is included "there is more than one way
to do it" ;-)
There is another relativly cheap version available called Corman
Lisp. It seems to work fine too.
Now to Scheme. I started learning Lispish languages with using
DrScheme and that things seems to work on a lot of platforms. Diverse
Unices, Windows, MacOS. The documentation is excellent too and it
comes with a bunch of extensions. And fills a big gap Scheme is still
leaving out. Scheme is really minimalistic, neverthless powerful. But
to get some work done needs usually extensions not covered by
Standard Scheme. Common Lisp offers here undoubtly much more. The
basics in both languages are nearly the same. But the differences show
up short after you have written some programs.
Because you are using Java quite a lot you might be interested in
Schemes which can be easily combined with Java. There are AFAIK two
implementations for Scheme but none for Common Lisp.
The Schemes are Kawa http://www.gnu.org/software/kawa/
and silk http://www.norvig.com/SILK.html
>
> Am I right in thinking that Scheme has a simpler set of basic functions, and
> so should be easier to learn?
The basic stuff is equally easy to graps in either Scheme or Common
Lisp maybe a bit easier in Scheme. At least that is what I found. But
I can recommend to learn both. You'll better judge yourself what suits
your needs.
Regards
Friedrich
Kirill Lisovsky
> I'm primarily a Java programmer but have recently started looking at
XSLT.
If you are interested in XSL Transformations in Scheme:
http://www.lh.com/~oleg/ftp/Scheme/web.html#eval-SXML
> What I'm after is a standard, 'clean' version with free implementation
on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
SILK is another Java-based Scheme implementation which is especially
useful for Servlet/Server Pages development:
http://www.cs.brandeis.edu/silk/silkweb/index.html
> Am I right in thinking that Scheme has a simpler set of basic
functions, and
> so should be easier to learn?
It is widely used for teaching, not necessary in the universities...
Best regards,
Kirill.
--
Kirill Lisovsky
liso...@acm.org
http://www.pair.com/lisovsky/
Danja
Thanks to everyone for the extremely helpful responses. Very interesting -
e.g. I didn't realise that so much had been done on the (web) server side.
Apologies for touching the apparently sensitive CL vs Scheme area ;-)
I've had a look at the resources mentioned (thanks again), and I think I'm
going to have a play with Dr.Scheme and then try Silk with some of my own
Java stuff. No offence to the CL lobby - the clinchers were the availability
of free Windows software, the development path Scheme -> DSSSL -> XSLT
(which I wasn't aware of before, thanks once more), and the Java facilities
of Silk.
Thanks too for the historical note about the dudes behind the development of
Scheme.
Cheers,
Danny.
"Danja" <danny_avo...@panlanka.net> wrote in message
news:9351qv$90kmv$1...@ID-57931.news.dfncis.de...
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > "felix" <fe...@anu.ie> writes:
> > > Furthermore, implementations like MzScheme (check out
> > > <www.schemers.org>) offer a wealth of functionality, and a nice
> > > set of development tools.
> >
> > Essentially a reimplementation of what is already there and standard
> > in Common Lisp.
>
> So what? Is it bad for Allegro to reimplement what is standard in
> Common Lisp? Or, given the fact that this functionality is standard
> in MzScheme, would you say that it is "essentially" a reimplementation
> of what is already there and standard in MzScheme?
It ain't in R^nRS, it ain't in Scheme. End of the story.
Remember: the main design goal of Scheme is the shortness of the R^nRS.
Christophe Rhodes
this discussion ]
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> It ain't in R^nRS, it ain't in Scheme. End of the story.
This strikes me as a particularly blinkered view on life. It may be
`true', for some values of the word, but it's not a particularly
useful definition. This is like saying, to take an example from a
related but distinct field, "It ain't in the dictionary, it ain't
English". Languages evolve. They really do. When does Theseus' ship
stop being Theseus' ship?
> Remember: the main design goal of Scheme is the shortness of the R^nRS.
Well, speaking as someone who learnt to programme via Scheme, and is
now happy with CL as a development tool, one of Scheme's other aims
(teaching) seems to have been successful. Single data points aren't
terribly useful, I know, but then I don't think the above is either.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})")
Joe Marshall
>
> It ain't in R^nRS, it ain't in Scheme. End of the story.
If it ain't in R^nRS, it ain't in R^nRS, but it might be in
MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
The larger Scheme implementations have quite a rich set of
`non-standard' features, and Jaffer's Scheme lib is portable to quite
a few of the other Schemes.
> Remember: the main design goal of Scheme is the shortness of the R^nRS.
This isn't true. Scheme has evolved over the years and has been
influenced by many design goals. I think the main design goals of the
various implementations have been to satisfy a pragmatic need.
The main goal of R^nRS has been to come up with a common set of core
elements that most or all Scheme implementations have, and most or all
Scheme implementors agree are `essential' to the language. R^nRS is
what everyone agrees is canonical, implementable, and pretty much `the
right thing'.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Marco Antoniotti
Christophe Rhodes <cs...@cam.ac.uk> writes:
> [ apologies for this -- I promise that I won't contribute any more to
> this discussion ]
>
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> This strikes me as a particularly blinkered view on life. It may be
> `true', for some values of the word, but it's not a particularly
> useful definition. This is like saying, to take an example from a
> related but distinct field, "It ain't in the dictionary, it ain't
> English". Languages evolve. They really do. When does Theseus' ship
> stop being Theseus' ship?
The problem is that Scheme has not been evolving. The main reason
being that "evolving", in this case, would mean "becoming" CL. :)
>
> > Remember: the main design goal of Scheme is the shortness of the R^nRS.
>
> Well, speaking as someone who learnt to programme via Scheme, and is
> now happy with CL as a development tool, one of Scheme's other aims
> (teaching) seems to have been successful. Single data points aren't
> terribly useful, I know, but then I don't think the above is either.
I still think that SICP is one of the best book about "programming"
ever written. The fact that it is in Scheme is its main drawback.
The point being that there is *no* reason not to use CL instead of
Scheme as a teaching tool.
Alas, we can go back in history only to see that we were not there at
the time. Personally I believe that Scheme *is* more elegant than CL
in many ways, and maybe, had the people deciding what went and what did
not go in the standard been a little braver, we would not have this
split nowadays. Not that I am in any position to criticize.
Let's just remember that tombs are full of hindsights. :)
Eli Barzilay
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> >
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
That's right - if you restrict yourself to `pure' Scheme, then you
couldn't do much, but such a restriction would be pretty just as
ridiculous as Lisp users implementing their own networking/threading
or whatever. Complaining about the absent of these things would get
an answer of "any good CL implementation that has them".
> > Remember: the main design goal of Scheme is the shortness of the R^nRS.
> [...]
> The main goal of R^nRS has been to come up with a common set of core
> elements that most or all Scheme implementations have, and most or
> all Scheme implementors agree are `essential' to the language.
> R^nRS is what everyone agrees is canonical, implementable, and
> pretty much `the right thing'.
Right, you can just treat the Scheme `Standard' as that common core,
nobody expects you to build any serious thing on top of that bare
standard. In this sense, the CL Standard is closer to something you
can actually work with, but still there are holes that implementations
fill. And even if you go through the nightmare of trying to abstract
such features into the standard (as done with the file system
interface), you'll still have problems with any new thing that people
happen to use in the future.
Eli Barzilay
> The problem is that Scheme has not been evolving.
The standard hasn't been evolving much. Implementations evolved a
*lot*.
> The main reason being that "evolving", in this case, would mean
> "becoming" CL. :)
As much as I like CL's great power, Scheme implementations have been
evolved in ways that are pretty different. Of course, a lot of the
functionality that these implementations provide is stuff that you
have in CL (after all, I'd be surprised to find a Scheme hacker that
doesn't know and had experience with Lisp), but what's so bad about
that as long as you as a user of an implementation can access that
functionality? I really don't think that the original intent of
Scheme was to have a language that is inherently less powerful than
Lisp, just a core that is cleaner, that allows expansion, in a
healthier way (were `healthier' in this context is probably a good
subject for flamewars).
> I still think that SICP is one of the best book about "programming"
> ever written. The fact that it is in Scheme is its main drawback.
The fact that the authors themselves consider Scheme as being one of
its major advantages indicates that something is fishy in your views.
> The point being that there is *no* reason not to use CL instead of
> Scheme as a teaching tool.
Yes, this is the kind of statements that would have high chances to
start a flame.
> Alas, we can go back in history only to see that we were not there
> at the time. Personally I believe that Scheme *is* more elegant
> than CL in many ways, and maybe, had the people deciding what went
> and what did not go in the standard been a little braver, we would
> not have this split nowadays. Not that I am in any position to
> criticize.
I think that many people like myself would love to see a `cleaned'
version of CL by adding all of its stuff on top of Scheme (IIRC, xlisp
was trying to do something similar). But the problem is that the
world keeps moving, and many concepts that are deep in the core of
Lisp (e.g, packages instead of modules) turned out to have better
solutions than these in Lisp, which makes Scheme implementation
diverge on them instead of converging back to Lisp.
Rob Warnock
+---------------
| ...many concepts that are deep in the core of Lisp (e.g, packages
| instead of modules) turned out to have better solutions than these
| in Lisp, which makes Scheme implementation diverge on them instead
| of converging back to Lisp.
In particular (since MzScheme *was* mentioned), the PLT groups's[*] work
on first-class compilation "units" (modules) seems quite significant
[see <URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node54.htm>
for technical details], and is backed up with both theoretical research
<URL:http://www.cs.rice.edu/CS/PLT/Publications/index.shtml#papers> and
several years of practical experience in implementing large systems with it
[the whole DrScheme/MrEd/MzScheme layering is based on units-with-signatures].
It would be interesting to see if there would be any benefit to adding
a similar scheme (no pun intended) to Common Lisp. [Or conversely, whether
there is any point in trying to extend MzScheme's single-inheritance object
system to multiple-inheritance.]
Or perhaps these two worlds are inherently incompatible with nothing
to learn from each other (which, if true, would be sad, IMHO).
-Rob
[*] I use the plural possessive here, since with the graduation
of several of their PhD's, the original Rice University PLT
(Programming Languages Team) has spawned additional "colonies"
at Brown & Utah (see <URL:http://www.cs.rice.edu/CS/PLT/>).
-----
Rob Warnock, 31-2-510 rp...@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Lieven Marchand
> I think that many people like myself would love to see a `cleaned'
> version of CL by adding all of its stuff on top of Scheme (IIRC, xlisp
> was trying to do something similar).
You could check out the IS-LISP standard for an attempt in that
direction. It's an interesting read and what they left out / changed
w.r.t CL could be a fine starting point for discussion.
> But the problem is that the world keeps moving, and many concepts
> that are deep in the core of Lisp (e.g, packages instead of modules)
> turned out to have better solutions than these in Lisp, which makes
> Scheme implementation diverge on them instead of converging back to
> Lisp.
Since standard Scheme doesn't have a module system, which
implementation's do you consider superior to CL packages? I've found
not much wrong with them once you take the time to understand
them. Most criticism seems to come from people who expect them to be a
static lexical concept like Ada packages, which they are not.
--
Lieven Marchand <m...@village.uunet.be>
Glaðr ok reifr skyli gumna hverr, unz sinn bíðr bana.
Oliver Bandel
In comp.lang.scheme Erik Naggum <er...@naggum.net> wrote:
> * Johan Kullstam <kull...@ne.mediaone.net>
> | if by "learn" you mean know the whole thing, then yes, scheme is
> | smaller and therefore there is less of it to learn.
> This is not the whole truth. Learning to use a language also means
> getting into the culture surrounding the language, as used by other
> people. This includes such things as idioms. I have found Scheme very
> hard to get into for this reason. It is somewhat like C++ in this way:
> The language itself is nearly useless, but once you get into it, you see
> that "billions and billions" of idioms and arcane ways to do non-trivial
> things that the language does not _really_ support need to be mastered as
> well. Since Common Lisp is so amazingly rich and powerful as is, there
> is little idiom and most everything can be done in a straight-forward
> way. There is an inverse relationship between language size and code
> size when the language has grown in size because very smart people have
> thought very carefully about what would make user programs smaller.
But to learn the language and it's pure semantic, it's maybe
better to start with a small language. When one knows, who
it works, one can use the bigger one, if needed and do the
things very lazy, reusing existing code/libraries.
If you want to learn C, you better start with a Unix-machine,
not with windows, and with Kernighan&Ritchies C-Programming
book, not with any other, describing big, but non-standard
libraries, as M$ it's libs.
After learning the basics of the language, one can choose
any library and is not afraid, when changing from one
platfor to another: If one knows, that C is pure and
the bloat is all libraries, then no confusion starts,
if one changes the plattform.
Many people, coming from win to linux doesn't know,
that C is small and that the libraries they used for
long time, are not part of the language itself.
Maybe it's littlebid different in the case of Lisp,
but one then - I think, with my Lisp-beginners knowledge -
is conatrained to ude Common Lisp. If I see it right,
that's the only standardized Lisp (?!).
> | however, functionality that you do not use need not bother you.
> On the contrary, the more you know about, the more you realize that you
> can do with existing language support and thus don't have to do yourself,
> the more you need, and thus over time the more you use. This is probably
> how Perl "succeeded", in the same way bacteria succeed.
Well, Perl itself is powerful enough and it's libraries are too.
All the additional Packages on CPAN are not part of Perl itself.
Comparing in this way, one can use Scheme and any library
developed for this language and name it Scheme too. But
that's not the language. It's a library, wiritten in that
language, but not part of it.
> | however a lack in functionality may force you to implement something
> | low-level in order to get where you wanted to go. thus, in a rich
> | language it can be easier to learn to do something useful.
> Exactly.
But as a beginner of a new language it may be better to learn a lot.
And that's done be doing it. And thats done by programming from
the scratch.
That's the same, when using Perl: Many people know little about
Perl-programming, but a lot of Modules. They look into books
or in on the CPAN and to a trial-and-error programming.
They would be better programmers if the read books like
"Programming Perl" and doing it from scratch.
After that - when they know enough of Perl -, they can use
the Modules (and better as in the other way).
(And it's really an advantage, when one knows how to program
in C.)
Tschüß,
Oliver
Johan Kullstam
> In comp.lang.scheme Erik Naggum <er...@naggum.net> wrote:
> > * Johan Kullstam <kull...@ne.mediaone.net>
> > | if by "learn" you mean know the whole thing, then yes, scheme is
> > | smaller and therefore there is less of it to learn.
>
> > This is not the whole truth. Learning to use a language also means
> > getting into the culture surrounding the language, as used by other
> > people. This includes such things as idioms. I have found Scheme very
> > hard to get into for this reason. It is somewhat like C++ in this way:
> > The language itself is nearly useless, but once you get into it, you see
> > that "billions and billions" of idioms and arcane ways to do non-trivial
> > things that the language does not _really_ support need to be mastered as
> > well. Since Common Lisp is so amazingly rich and powerful as is, there
> > is little idiom and most everything can be done in a straight-forward
> > way. There is an inverse relationship between language size and code
> > size when the language has grown in size because very smart people have
> > thought very carefully about what would make user programs smaller.
>
> But to learn the language and it's pure semantic, it's maybe
> better to start with a small language. When one knows, who
> it works, one can use the bigger one, if needed and do the
> things very lazy, reusing existing code/libraries.
everybody always starts small and works up. you can choose
1) a small simple language
2) a small and simple subset of a large rich language
in both cases you can learn. but in the former, you have to move to
something else. in the latter you have room to grow.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Eli Barzilay
> You could check out the IS-LISP standard for an attempt in that
> direction. It's an interesting read and what they left out / changed
> w.r.t CL could be a fine starting point for discussion.
Any pointers? Last time I've seen it, it didn't look too popular...
The problem is probably that between CL and Scheme no one will go for
it.
> Since standard Scheme doesn't have a module system, which
> implementation's do you consider superior to CL packages?
If wasn't clear from my previous posts, I'm using MzScheme. They have
an excellent system for seperate units, and an even much better module
system on its way (which should be out shortly). Lots of good ideas
and clean design went into it.
> I've found not much wrong with them once you take the time to
> understand them. Most criticism seems to come from people who expect
> them to be a static lexical concept like Ada packages, which they
> are not.
Like any other Scheme hacker that started with Lisp, I have no
problems at all with CL packages. But it has its limits... It
generally feels like something that started as a hack around an
existing language so you get seperate "namespaces" but still no
problems with old code. Not that I have anything against such hacks
(CLOS is another such hack which is one of the most beautiful things I
have ever seen), but the huge advantage of Scheme implementation is
that they don't have any historic chains to restrict them. Also, IMO,
because you can consider this thing an advantage of Lisp, then people
who use these two dialects of a great concept have such bitter fights.
Eli Barzilay
> Huh? What _is_ Scheme these days but restrictive historic chains? Once
> a virtual incubation chamber for fledgling ideas, many of which were
> really good, with much debate and spirited discussions that had far-flung
> repercussions, what's left of this once flexible language design is a
> "standard" so rigid that they can't even change the wording, and every
> good idea in Scheme is picked up in a better way by other languages that
> have not coagulated. What's left in Scheme is first-class continuations,
> which is probably not a good idea, after all.
1. There's a bit more than just continuations there (and I refuse to
get myself in the continuations-good-or-bad flame).
2. You're talking about Scheme - the standard, see below.
> However, _any_ implementation can have as much or little historic chains
> to restrict them as they wish. It is a very grave mistake to think that
> following a standard is restricting you in any way. I'm not saying you
> [...]
> [...]
> [...]
My main point is that the standard CL spec is taken by implementations
in a fundamentally different way than the way the Scheme Standard is
taken by Scheme implementations. There are these cases which CL
implementaions have to treat the standard similarly (or live without
sockets, ffi etc), but mostly they have a more well-defined path.
Scheme implementations always take the standard as the guide-line for
the core language, as the basis that they're supposed to add stuff
onto -- I have never seen any Scheme implementation that implements
the standard and nothing else, and the though of using something like
that deserve what your approach to Scheme is.
> You have implicitly argued that Common Lisp has historic chains that
> restrict an implememtation from implementing a module system like the
> _undoubtedly_ nifty thing that your favorite-among-thousands Scheme
> implementation has done. I suggest you show us those chains and just how
> they restrict a Common Lisp implementation. Or retract ths silly claim.
Again, I will not go into comparison of approaches (btw, CL does not
have any `modules' to begin with -- packages are not seperate units of
compilation), what I said is that when Lisp was developed to have
packages for symbols there were (a) not many alternatives at that
time, and (b) even if they were, since the language spec contains much
more you cannot play with ideas that damage the language as a whole.
I think that there is nothing wrong in my logic: define your 2
properties of your language and it is possible to extend it in many
ways, define 2000 properties of your language and it becomes harder to
extend it in a consistent way.
> | Also, IMO, because you can consider this thing an advantage of Lisp, then
> | people who use these two dialects of a great concept have such bitter
> | fights.
>
> Was that meant to be "advantage over Lisp"? I can't make sense of what
> you've written otherwise. Today, Scheme is nothing more than a dialect
> of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> for good measure. It used to be much more, but has been surpassed by
> almost everything.
No, what I said is that Lisp people treat their spec in a very
different way than Scheme people. This is the constant source of
flamewars, for example, you attack the Scheme standard, when people
try to defend their Scheme implementation.
> What makes for the bitter fights is that Scheme
> people want to call their pet language a Lisp, which actually hurts
> Common Lisp by instilling in people who do not yet know whom to trust or
> not, that all the silly problems they have with Scheme apply to _all_
> Lisps.
I don't believe that the problems that Scheme faces are related much
to the problems that Lisp has, certainly not as a philosophy since in
that aspect they are very different (but again, not when you compare
CL to some specific Scheme implementation). Second, I think that
people who call Scheme `Lisp' are pretty rare, a `dialect of Lisp' is
more common probably because people tend to generalize based on the
visual form of the language.
> If Scheme people could refrain from calling their Algol dialect a
> Lisp, a lot less animosity would result.
Also, of you refrain from calling their Scheme implementaion an Algol
dialect.
> I'm happy to leave people alone
> who only hurt themselves, provided they agree to go away and do it out of
> my sight, of course. Most Scheme people do. Some insist on posting yet
> more of their unfounded and vague nonsense about Common Lisp here.
I think I have established a long history of no posts here... My only
attempted point is to try to make people that it is not Scheme that
you should be talking about, but Scheme implementation. If you have
something against `pure Scheme' users (which probably don't exist)
then these problems don't apply to people who say anything about
Scheme here.
Lieven Marchand
> Lieven Marchand <m...@village.uunet.be> writes:
>
> > You could check out the IS-LISP standard for an attempt in that
> > direction. It's an interesting read and what they left out / changed
> > w.r.t CL could be a fine starting point for discussion.
>
> Any pointers? Last time I've seen it, it didn't look too popular...
> The problem is probably that between CL and Scheme no one will go for
> it.
>
Oh, I didn't mean to use as primary language, although there is a
commercial implementation now. I meant as a data point in comparing
the design space between CL and Scheme. E.g., unlike Scheme, they've
kept most of the CL reader syntax (#char stuff) but they didn't make
the reader programmer extendible, so no set-macro-character.
>
> > Since standard Scheme doesn't have a module system, which
> > implementation's do you consider superior to CL packages?
>
> If wasn't clear from my previous posts, I'm using MzScheme. They have
> an excellent system for seperate units, and an even much better module
> system on its way (which should be out shortly). Lots of good ideas
> and clean design went into it.
>
Any design document available or should I wait for the new release?
> Like any other Scheme hacker that started with Lisp, I have no
> problems at all with CL packages. But it has its limits... It
> generally feels like something that started as a hack around an
> existing language so you get seperate "namespaces" but still no
> problems with old code. Not that I have anything against such hacks
I don't know. Most people with comments like yours want either a
module system that enforces encapsulation or a Ada-like package system
that verifies correct types/existence of functions etc. I don't see CL
packages as a hack. I see them as a solution to a different problem,
letting different worlds coexist in one Lisp system. I don't know
where the package system was developed, but I think a fine example of
this is the Symbolics Lisp system, where you can have ZetaLisp and
Common Lisp and a number of other syntaxes coexisting and
cooperating. The CL package system is a dynamic solution to these kind
of problems, so it's bound to disappoint people who want a static
module system.
> (CLOS is another such hack which is one of the most beautiful things I
> have ever seen), but the huge advantage of Scheme implementation is
> that they don't have any historic chains to restrict them. Also, IMO,
> because you can consider this thing an advantage of Lisp, then people
> who use these two dialects of a great concept have such bitter fights.
You seem to call everything that can be implemented with macrology a
hack. I agree CLOS is a beautiful system, and one of best products of
a standardisation (sub)committee I know of, but the fact that one
original implementation was as a macro layer above CLtL1 (PCL) just
shows how versatile Lisp + a good macro system is. It shouldn't be
used as argument to call the product a hack.
Eli Barzilay
> Any design document available or should I wait for the new release?
It's probably a bit too early now...
> I don't know. Most people with comments like yours want either a
> module system that enforces encapsulation or a Ada-like package system
> that verifies correct types/existence of functions etc.
Actually I don't have any string opinion about using module system X
or Y. I was just giving it as an example.
> I don't see CL packages as a hack. I see them as a solution to a
> different problem, letting different worlds coexist in one Lisp
> system. [...]
> You seem to call everything that can be implemented with macrology a
> hack. [...]
This seems like a good point to use the jargon file -- looks like you
use hack in the first sense (a quick job that produces what is needed,
but not well), but I'm using the second one (an incredibly good, and
perhaps very time-consuming, piece of work that produces exactly what
is needed). I refer to most of my programs as "hacks". I hoped the
CLOS example would clarify that (being something I admire), certainly
no relation to something that can be implemented with or without
macros.
Rob Warnock
+---------------
| Eli Barzilay <e...@barzilay.org> writes:
| > I think that many people like myself would love to see a `cleaned'
|
| You could check out the IS-LISP standard for an attempt in that
| direction. It's an interesting read and what they left out / changed
| w.r.t CL could be a fine starting point for discussion.
Also see Henry Baker's paper "Critique of DIN Kernel Lisp Definition"
<URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.html>
<URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.ps.Z>
ISO/DIN DKLisp was another attempt to start with a "small & clean" kernel,
"a minimal language on top of which a larger language can be built."
Baker makes some telling points against *both* Common Lisp & Scheme...
-Rob
Reini Urban
>If wasn't clear from my previous posts, I'm using MzScheme. They have
>an excellent system for seperate units, and an even much better module
>system on its way (which should be out shortly). Lots of good ideas
>and clean design went into it.
scheme48 already has all this.
and better functionality than mzscheme, in several regards, btw.
just no graphics.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Eli Barzilay
> scheme48 already has all this.
> and better functionality than mzscheme, in several regards, btw.
> just no graphics.
1. Everything I could dig on Scheme48 is pretty dusty.
2. Scheme48 is specifically mentioned in the PLT proposal.
3. Why would you want to start a Scheme flamewar in this NG?
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
The key observation here is that Scheme implementations *cannot* and
*must* diverge from the standard, simply because the standard is so
restrictive that it is impossible to do anything with it.
In Common Lisp the number of "deviations" is actually circumscribed to
pretty much defined "libraries" for which each implementation defines
a specific interface. Given that the implementations are few, it is
still possible to write portable programs.
> > You have implicitly argued that Common Lisp has historic chains that
> > restrict an implememtation from implementing a module system like the
> > _undoubtedly_ nifty thing that your favorite-among-thousands Scheme
> > implementation has done. I suggest you show us those chains and just how
> > they restrict a Common Lisp implementation. Or retract ths silly claim.
>
> Again, I will not go into comparison of approaches (btw, CL does not
> have any `modules' to begin with
Scheme does not have modules. Remember, it ain't in R^nRS, it ain't
in Scheme. CL has packages, which can be used as modules and are,
especially in conjunction with "community defined standard" or
"specific vendor/implementation definitions": defsystem is one of
these objects. Note that here I am concerned about the "use" of the
system. If you object that I cannot write a "library" (a .dll or a
.so or a .a) in CL, I will respond with the request that you check
what each CL vendor/implementor actually does. You can also check the
old and not much used WACL in the AI.Repository.
The bottom line does not change. CL has DEFSTRUCT, Scheme does not.
> -- packages are not seperate units of
> compilation), what I said is that when Lisp was developed to have
> packages for symbols there were (a) not many alternatives at that
> time, and (b) even if they were, since the language spec contains much
> more you cannot play with ideas that damage the language as a whole.
> I think that there is nothing wrong in my logic: define your 2
> properties of your language and it is possible to extend it in many
> ways, define 2000 properties of your language and it becomes harder to
> extend it in a consistent way.
>
>
> > | Also, IMO, because you can consider this thing an advantage of Lisp, then
> > | people who use these two dialects of a great concept have such bitter
> > | fights.
> >
> > Was that meant to be "advantage over Lisp"? I can't make sense of what
> > you've written otherwise. Today, Scheme is nothing more than a dialect
> > of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> > for good measure. It used to be much more, but has been surpassed by
> > almost everything.
>
> No, what I said is that Lisp people treat their spec in a very
> different way than Scheme people. This is the constant source of
> flamewars, for example, you attack the Scheme standard, when people
> try to defend their Scheme implementation.
Exactly. I agree on this. Now, the value of the standard is
paramount. I just mplemented a non trivial piece of code and it runs
on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
implementations at hand). On two OS's.
There is no way I could have not achieved the same level of
portability using Scheme, simply because any two implementations just
differ too much.
What puzzles me is the strenght by which "Schemers" (I love that
name!) refuse to acknowledge this key point.
...
> I think I have established a long history of no posts here... My only
> attempted point is to try to make people that it is not Scheme that
> you should be talking about, but Scheme implementation. If you have
> something against `pure Scheme' users (which probably don't exist)
> then these problems don't apply to people who say anything about
> Scheme here.
I believe we agree on this here. The problem is the godzillion
different Scheme implementations out there, all subtly incompatible
and all trying to be different from CL.
Cheers
PS. As an aside on SICP. The fact that it uses Scheme, may be another
historical quirk. CL was not available when SICP was being shaped
at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
in the hands of freshmen. So, let's not confound history and
market forces with technical merit. It should be obvious to many
that they don't always mix well.
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> rur...@sbox.tu-graz.ac.at (Reini Urban) writes:
>
> > scheme48 already has all this.
> > and better functionality than mzscheme, in several regards, btw.
> > just no graphics.
>
> 1. Everything I could dig on Scheme48 is pretty dusty.
>
> 2. Scheme48 is specifically mentioned in the PLT proposal.
>
> 3. Why would you want to start a Scheme flamewar in this NG?
A case in point. The vendor/implementor flamewars on CLL most of the
time refer to the degree of adherence to the standard and (with one
notable exception) are always minor.
I do not recall any "major" flawar pitting one implementation against
the other. The competition is about performance and usability, not
about what CL feature that is not in R^nRS is being implemented or not
in implementation X. :)
Marco Antoniotti
Joe Marshall <j...@content-integrity.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> >
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
>
> The larger Scheme implementations have quite a rich set of
> `non-standard' features, and Jaffer's Scheme lib is portable to quite
> a few of the other Schemes.
Then why hasn't this set of features made it into the R^nRS? Also,
what is the content of Scheme Lib? (This is a rethorical question).
> > Remember: the main design goal of Scheme is the shortness of the R^nRS.
>
> This isn't true. Scheme has evolved over the years and has been
> influenced by many design goals. I think the main design goals of the
> various implementations have been to satisfy a pragmatic need.
>
> The main goal of R^nRS has been to come up with a common set of core
> elements that most or all Scheme implementations have, and most or all
> Scheme implementors agree are `essential' to the language. R^nRS is
> what everyone agrees is canonical, implementable, and pretty much `the
> right thing'.
CL is canonical, implementable and pretty much 'the right thing' as
well.
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Joe Marshall <j...@content-integrity.com> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > >
> > > It ain't in R^nRS, it ain't in Scheme. End of the story.
> >
> > If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> > MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> > Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
>
> That's right - if you restrict yourself to `pure' Scheme, then you
> couldn't do much, but such a restriction would be pretty just as
> ridiculous as Lisp users implementing their own networking/threading
> or whatever. Complaining about the absent of these things would get
> an answer of "any good CL implementation that has them".
We are not talking about threading (and yes, most CL implementations
have threading, and most of them follow a common ancestral API).
We are talking about STRUCTS and 2D Arrays.
If you restrict yourself to ANSI CL you can do much more
than what you can do if you restrict yourself to R^nRS.
Not only, if you restrict yourself to ANSI CL you can do much much much more
than what you can do if you restrict yourself to k Scheme implementations.
> Right, you can just treat the Scheme `Standard' as that common core,
> nobody expects you to build any serious thing on top of that bare
> standard. In this sense, the CL Standard is closer to something you
> can actually work with,
Then why do you use Scheme implementation X (and not Y)?
> but still there are holes that implementations
> fill. And even if you go through the nightmare of trying to abstract
> such features into the standard (as done with the file system
> interface), you'll still have problems with any new thing that people
> happen to use in the future.
People using CL are well aware of the limitations of the standard, but
most of the time they can leverage the much greater power of the
substrate to come up with truly portable solutions.
Eli Barzilay
> We are not talking about threading (and yes, most CL implementations
> have threading, and most of them follow a common ancestral API).
>
> We are talking about STRUCTS and 2D Arrays.
Which is what I said - different levels of drawing the lines.
> If you restrict yourself to ANSI CL you can do much more
> than what you can do if you restrict yourself to R^nRS.
If it wasn't clear enough that this is exactly what I said then: I
think that if you restrict yourself to ANSI CL you can do much more
than what you can do if you restrict yourself to R^nRS.
> Not only, if you restrict yourself to ANSI CL you can do much much
> much more than what you can do if you restrict yourself to k Scheme
> implementations.
I don't think that 1000 is a correct ratio.
> > Right, you can just treat the Scheme `Standard' as that common core,
> > nobody expects you to build any serious thing on top of that bare
> > standard. In this sense, the CL Standard is closer to something you
> > can actually work with,
>
> Then why do you use Scheme implementation X (and not Y)?
Because I like it, because I agree with it's design decisions,
whatever. Why do you use OS A and not B?
> People using CL are well aware of the limitations of the standard, but
> most of the time they can leverage the much greater power of the
> substrate to come up with truly portable solutions.
People using Scheme are well aware of the limitations of the standard.
What they do with this awareness is, as I said, different than
solutions that are portable to all Schemes.
Eli Barzilay
> A case in point. The vendor/implementor flamewars on CLL most of the
> time refer to the degree of adherence to the standard and (with one
> notable exception) are always minor.
>
> I do not recall any "major" flawar pitting one implementation against
> the other. The competition is about performance and usability, not
> about what CL feature that is not in R^nRS is being implemented or not
> in implementation X. :)
Well, if you read c.l.s, you will have to admit that _much_ less blood
is spilled in flamewars there. Examples not needed.
Eli Barzilay
> The key observation here is that Scheme implementations *cannot* and
> *must* diverge from the standard, simply because the standard is so
> restrictive that it is impossible to do anything with it.
There seem to be some sort of misunderstanding. Take a language is
with a complete standard that says: "programs in this language are
written in ASCII". You claim that this is restrictive to the point of
being able to do nothing with it, I claim that this is such a low
restriction that most programming languages on this planet can be
considered as valid extensions.
> In Common Lisp the number of "deviations" is actually circumscribed
> to pretty much defined "libraries" for which each implementation
> defines a specific interface.
Same in Scheme, different quantity.
> Given that the implementations are few, it is still possible to
> write portable programs.
True, but I never considered this any practical advantage for
everything I did in Lisp (not had to do, chose to do). I always used
a single implementation (well except for one huge project on that
Allegro 3 for Windows which is getting impossible to run).
> Scheme does not have modules. Remember, it ain't in R^nRS, it ain't
> in Scheme.
If it ain't in the standard, it ain't in the standard. That's all. I
don't program in "R^nRS".
> CL has packages, which can be used as modules and are,
Ugh... This is a different story.
> especially in conjunction with "community defined standard" or
> "specific vendor/implementation definitions": defsystem is one of
> these objects.
Given your own text above, I am tempted to do the same here, but I
won't.
> Note that here I am concerned about the "use" of the system. If you
> object that I cannot write a "library" (a .dll or a .so or a .a) in
> CL, I will respond with the request that you check what each CL
> vendor/implementor actually does. You can also check the old and
> not much used WACL in the AI.Repository.
No, I wasn't talking about these libraries. But forget it, it _is_ a
different story.
> The bottom line does not change. CL has DEFSTRUCT, Scheme does not.
Hmm... Must make people who program in _Scheme_ pretty stupid. Ever
seen one?
> > No, what I said is that Lisp people treat their spec in a very
> > different way than Scheme people. This is the constant source of
> > flamewars, for example, you attack the Scheme standard, when people
> > try to defend their Scheme implementation.
>
> Exactly. I agree on this. Now, the value of the standard is
> paramount.
But we've just agreed that it is treated very differently, therefore
even for similar values of value, it would still be taken differently.
> I just mplemented a non trivial piece of code and it runs
> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
> implementations at hand). On two OS's.
I did the same and it runs on every dialect of MzScheme. On six OS's.
> There is no way I could have not achieved the same level of
> portability using Scheme, simply because any two implementations
> just differ too much.
If you were using Scheme, you were probably using a single
implementation.
> What puzzles me is the strenght by which "Schemers" (I love that
> name!) refuse to acknowledge this key point.
What keypoint? Portability among Lisp implementations? I already
said I never used more than a single environment, so why would this
point be so important to become a key?
(I hate that name, I also hate Lispers and whatever. I prefer program
before my er.)
> I believe we agree on this here. The problem is the godzillion
> different Scheme implementations out there, all subtly incompatible
> and all trying to be different from CL.
I don't think that "being different than CL" is a major design goal.
> PS. As an aside on SICP. The fact that it uses Scheme, may be another
> historical quirk. CL was not available when SICP was being shaped
> at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> in the hands of freshmen. So, let's not confound history and
> market forces with technical merit. It should be obvious to many
> that they don't always mix well.
And you know that if it was then they'd use it?
Lieven Marchand
> Also see Henry Baker's paper "Critique of DIN Kernel Lisp Definition"
>
> <URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.html>
> <URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.ps.Z>
>
> ISO/DIN DKLisp was another attempt to start with a "small & clean" kernel,
> "a minimal language on top of which a larger language can be built."
> Baker makes some telling points against *both* Common Lisp & Scheme...
>
I think ANSI CL fulfills all but one of his demands, the exception
being the ridiculous one of size of specification. It would be an
enormous editorial effort for very little gain but it is perfectly
possible to separate CLTS into a small core and a large library. I
don't think this has any advantages for either students of the
language or for experienced programmers. A lot of functional
programming languages are defined like this with a small core that
usually gets a denotational definition and a standard prelude. It just
seems to confuse most students confronted with it.
Joe Marshall
> Joe Marshall <j...@content-integrity.com> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > >
> > > It ain't in R^nRS, it ain't in Scheme. End of the story.
> >
> > If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> > MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> > Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
> >
> > The larger Scheme implementations have quite a rich set of
> > `non-standard' features, and Jaffer's Scheme lib is portable to quite
> > a few of the other Schemes.
>
> Then why hasn't this set of features made it into the R^nRS?
It is difficult to get a R^nRS authors group together.
Even though Jaffer's library is reasonably portable, it isn't
necessarily what `everyone' wants as a standard.
Features are included in R^nRS by unanimous consent of its authors.
To use an example, virtually every `serious' Scheme implementation has
a DEFSTRUCT-like mechanism, and most, if not all, of the Scheme
authors would like to see some DEFSTRUCT standard within Scheme.
However, there are different opinions on how such a thing should be
implemented, what exact syntax and semantics it should have, how it
should interface into the type system, etc. etc.
These differences have in the past prevented structures from being put
in R^nRS. Nonetheless, it is possible to write Scheme code that uses
DEFSTRUCT, and reasonable to expect to be able to port it (with some
small amount of effort) to any of the `serious' Scheme implementations.
> Also, what is the content of Scheme Lib? (This is a rethorical question).
It's on the web, take a look. (A rhetorical answer.)
> > > Remember: the main design goal of Scheme is the shortness of the R^nRS.
> >
> > This isn't true. Scheme has evolved over the years and has been
> > influenced by many design goals. I think the main design goals of the
> > various implementations have been to satisfy a pragmatic need.
> >
> > The main goal of R^nRS has been to come up with a common set of core
> > elements that most or all Scheme implementations have, and most or all
> > Scheme implementors agree are `essential' to the language. R^nRS is
> > what everyone agrees is canonical, implementable, and pretty much `the
> > right thing'.
>
> CL is canonical, implementable and pretty much 'the right thing' as
> well.
I agree. I'm not trying to argue Scheme vs. Common Lisp. I'm just
pointing out that R^nRS is not the same sort of document as CLtL.
Joe Marshall
> > > | Also, IMO, because you can consider this thing an advantage of Lisp, then
> > > | people who use these two dialects of a great concept have such bitter
> > > | fights.
> > >
> > > Was that meant to be "advantage over Lisp"? I can't make sense of what
> > > you've written otherwise. Today, Scheme is nothing more than a dialect
> > > of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> > > for good measure. It used to be much more, but has been surpassed by
> > > almost everything.
> >
> > No, what I said is that Lisp people treat their spec in a very
> > different way than Scheme people. This is the constant source of
> > flamewars, for example, you attack the Scheme standard, when people
> > try to defend their Scheme implementation.
>
> Exactly. I agree on this. Now, the value of the standard is
> paramount. I just mplemented a non trivial piece of code and it runs
> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
> implementations at hand). On two OS's.
>
> There is no way I could have not achieved the same level of
> portability using Scheme, simply because any two implementations just
> differ too much.
>
> What puzzles me is the strenght by which "Schemers" (I love that
> name!) refuse to acknowledge this key point.
Huh? Any serious Schemer is all too familiar with this particularly
sore point.
> PS. As an aside on SICP. The fact that it uses Scheme, may be another
> historical quirk. CL was not available when SICP was being shaped
> at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> in the hands of freshmen. So, let's not confound history and
> market forces with technical merit. It should be obvious to many
> that they don't always mix well.
I wouldn't be so sure. Sussman and Abelson have had access to
CommonLisp for years, yet they still prefer to work with MIT Scheme.
Eli Barzilay
> [...] yet suppose it is possible to implement only the standard,
> doesn't that say the standard is good enough for real life
> implementations?
The CL one? Yes. For a lot. (And the Scheme one for 1000 times less).
> Is that _bad_ in any way?
Definitely not. I didn't claim that something is bad, only that it is
different..
> Is the occasional whining that something is not in the standard
> actually representative of anything?
No. (And I wouldn't be surprised if the number of such whiners is the
same in CL and in Scheme). Did I say it was?
> Your weird argument tells me one thing: Scheme the standard is
> useless and impractical,
Impractical yes. It is useful as a core language definitions.
> and the specification is of extremely low value in real life,
By the same argument it has a lot of value, not in the CL-value sense.
> while Common Lisp the standard is practically useful in real life.
> I _completely_ fail to see this as an argument in favor of Scheme.
What is supposed to be the argument in favor of Scheme? That the CL
std is useful in real life or that the Scheme one is much thinner?
For both I don't see any argument in favor of Scheme either. If it
sounded like I did, then there was a communication bug.
> | Again, I will not go into comparison of approaches (btw, CL does
> | not have any `modules' to begin with -- packages are not seperate
> | units of compilation), what I said is that when Lisp was developed
> | to have packages for symbols there were (a) not many alternatives
> | at that time, and (b) even if they were, since the language spec
> | contains much more you cannot play with ideas that damage the
> | language as a whole.
>
> OK, try and listen, now: Could you please _explain_ how your
> playing with new idea damages the language? I don't buy that line
> one bit, you see. It doesn't really help your case just to repeat
> it.
Take the idea in that Baker article that was posted on this thread:
cons cells are always immutable. It certainly qualifies for being a
"new idea". Now imagine adding it to Lisp and adding it to Scheme.
In the second case you don't break much because there is not much
there, but in the first case you have a *lot* of standard and a *lot*
to change, the not-so-great "damage as a whole" phrase I used is
existing things in your language that needs fixing after you add a
feature.
> | I think that there is nothing wrong in my logic: define your 2
> | properties of your language and it is possible to extend it in
> | many ways, define 2000 properties of your language and it becomes
> | harder to extend it in a consistent way.
>
> There is obviously something seriously wrong with your "logic".
See above example.
> You _actually_ argue that adding that new property _has_ to be
> done in an inconsistent way, otherwise 2 or 2000 properties
> wouldn't matter.
No, I argue that you have to think more before you add a property to a
pile of 2000 consistent ones trying to have the result consistent as
well.
> Ironically, I quite agree with you for a small set of properties,
> such as in Scheme, but it is obviously false for a large set of
> properties. [...]
If you're implying that it is hard in the small case according to the
same line of Scheme is kept ridiculously small, then this is
irrelevant. Scheme implementations add features. And because the
standard is so small they can do it in may ways, which portability go
with the wind. But see other post.
> | No, what I said is that Lisp people treat their spec in a very
> | different way than Scheme people. This is the constant source of
> | flamewars, for example, you attack the Scheme standard, when
> | people try to defend their Scheme implementation.
>
> And the difference is? [...]
The CL standard defines an almost complete language. The Scheme
standard defines a small core. (I'm sure I said this at least five
times.)
> Oh, just watch the Scheme people market themselves. They want the
> remaining goodwill that "Lisp" has, but only work to destroy it.
I did. A lot. Really a lot. I didn't see this.
> If so, I'd recruit you if I want to insult Scheme even more.
...
> | I think I have established a long history of no posts here...
>
> Why do you think everything I say in response to an article by you is
> _about_ you?
Please not the "_about_ you" trick... What I said wasn't about me, it
was about my posts.
> Don't you desire to communicate ideas that have a wider field of
> application that just yourself?
Are you sure that that I shouldn't me desire to communicate ideas that
have a wider field of application that just myself?
(said Emacs).
> | My only attempted point is to try to make people that it is not
> | Scheme that you should be talking about, but Scheme
> | implementation.
>
> So write up a specification for what those implementations
> implement, and I'll be happy to talk about those specifications.
It's all on-line.
> If you have a language that so prides itself [...] have nothing to
> show but a bunch of poorly documented implementations, the less I
> think of Scheme.
It's MzScheme. It's on-line.
And again, I wasn't saying anything about my implementation.
> Now, I used to think highly of Scheme. I have worked my way
> through SICP and used to like the book enough to start on SICP2,
> but as time has passed and I have had reason to evaluate things in
> more than the light of academic values, Scheme has become less and
> less attractive, to the point where I think I loathe the
> anti-specification stance that you and many other Scheme people so
> strongly favor.
As long as we're in the life story department, I also started with
SICP and admired it, then moved to Lisp and loved every second and now
I'm back to Scheme mainly because it fits best the stuff I do. If I
would do what you do for a living, I would chose Lisp too. Not that
there is anything wrong with trying to make money with Scheme, but the
power you get from a good compiler and the most important point: a
dynamic environment combined is really something special. (To make it
clear, I am talking about Lisp here.) Maybe in time Scheme
implementations will get to such a level, but why should I worry for
that now?
> Yet, it is pretty weird that a language with such a theoretical
> bent can attract so many anti-theoretical pragmatists.
Whew, at least I can get out alive from this one.
Jochen Schmidt
>> I just mplemented a non trivial piece of code and it runs
>> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
>> implementations at hand). On two OS's.
>
> I did the same and it runs on every dialect of MzScheme. On six OS's.
Oh *WOW* you've hit him to ground with this amazing defense - now you
have to take your dagger and cut out his heart before he is standing up
_gratulations_!
BTW: CLISP alone supports > 26 OS's so you should make sure your next
argument doesn't make such a nice boomerang like this.
How I hate this *#$% flamewars!!!
Regards,
Jochen
Eli Barzilay
> BTW: CLISP alone supports > 26 OS's so you should make sure your
> next argument doesn't make such a nice boomerang like this.
Wow, you really killed _me_ now. I am completely ashamed. I have
failed my heritage and my ancestors. Forgive me for my sins. I will
die now. (and I didn't even know how to count.)
Oh, _how_ do you hate this *#$% flamewars!!!
Marco Antoniotti
Joe Marshall <j...@content-integrity.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > ...
> > ...
>
> ...
Much deleted about the difficulties about changing the standard.
>
> These differences have in the past prevented structures from being put
> in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> DEFSTRUCT, and reasonable to expect to be able to port it (with some
> small amount of effort) to any of the `serious' Scheme
> implementations.
Why should I have to port it when I can use a language that ensures me
that *all* implementations will have DEFSTRUCT and that all
implementations of it will adhere to a standard?
>
> > Also, what is the content of Scheme Lib? (This is a rethorical question).
>
> It's on the web, take a look. (A rhetorical answer.)
I took a look. So what's in it? :) (The rethorical question stands).
...
> > > Scheme implementors agree are `essential' to the language. R^nRS is
> > > what everyone agrees is canonical, implementable, and pretty much `the
> > > right thing'.
> >
> > CL is canonical, implementable and pretty much 'the right thing' as
> > well.
>
> I agree. I'm not trying to argue Scheme vs. Common Lisp. I'm just
> pointing out that R^nRS is not the same sort of document as CLtL.
Fair enough.
I guess I just got up with the wrong foot this morning... :)
Marco Antoniotti
Joe Marshall <j...@content-integrity.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > PS. As an aside on SICP. The fact that it uses Scheme, may be another
> > historical quirk. CL was not available when SICP was being shaped
> > at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> > in the hands of freshmen. So, let's not confound history and
> > market forces with technical merit. It should be obvious to many
> > that they don't always mix well.
>
> I wouldn't be so sure. Sussman and Abelson have had access to
> CommonLisp for years, yet they still prefer to work with MIT Scheme.
That is their choice. Mine was a more general remark. And please
remember that I got up with the wrong foot this morning :)
Cheers
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
... much deleted.
>
> As long as we're in the life story department, I also started with
> SICP and admired it, then moved to Lisp and loved every second and now
> I'm back to Scheme mainly because it fits best the stuff I do. If I
> would do what you do for a living, I would chose Lisp too. Not that
> there is anything wrong with trying to make money with Scheme, but the
> power you get from a good compiler and the most important point: a
> dynamic environment combined is really something special. (To make it
> clear, I am talking about Lisp here.) Maybe in time Scheme
> implementations will get to such a level, but why should I worry for
> that now?
Maybe because eventually this will lead to a re-specification of CL? :)
Have you thought about this possibility? What arguments can you make
that this will not happen?
Eli Barzilay
> Maybe because eventually this will lead to a re-specification of CL? :)
> Have you thought about this possibility? What arguments can you make
> that this will not happen?
I also said that Lisp has a lot of ugly sides and I would like a
regrown cleaner version. We've passed that.
Joe Marshall
> Joe Marshall <j...@content-integrity.com> writes:
> >
> > These differences have in the past prevented structures from being put
> > in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> > DEFSTRUCT, and reasonable to expect to be able to port it (with some
> > small amount of effort) to any of the `serious' Scheme
> > implementations.
>
> Why should I have to port it when I can use a language that ensures me
> that *all* implementations will have DEFSTRUCT and that all
> implementations of it will adhere to a standard?
Er, um, you shouldn't --- you should use Common Lisp. I'm not by any
means suggesting that R^nRS gives you everything you could want in a
language! I was just saying that most serious Scheme implementations
give you a far more complete environment than barebones R^nRS. Scheme
is sort of in the state that Lisp was before Common Lisp.
> > > Also, what is the content of Scheme Lib? (This is a rethorical question).
> >
> > It's on the web, take a look. (A rhetorical answer.)
>
> I took a look. So what's in it? :) (The rethorical question stands).
I don't remember, and since you just looked, you are more informed
than I. (Rhetorical answer still stands, as well.)
cbbr...@hex.net
> > in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> > DEFSTRUCT, and reasonable to expect to be able to port it (with some
> > small amount of effort) to any of the `serious' Scheme
> > implementations.
>
> Why should I have to port it when I can use a language that ensures
> me that *all* implementations will have DEFSTRUCT and that all
> implementations of it will adhere to a standard?
I seem to recall some discussion a while back to the effect that
"CLOS's DEFCLASS makes DEFSTRUCT redundant, so DEFSTRUCT should really
be removed." :-)
>>> Also, what is the content of Scheme Lib? (This is a rethorical
>>> question).
>
>> It's on the web, take a look. (A rhetorical answer.)
>
> I took a look. So what's in it? :) (The rethorical question
> stands).
There has been somewhat wider surrounding the "SRFI" process;
admittedly that represents a process that should have begun 15 years
ago, but it does happen to be _reasonably_ active, and is _gradually_
address the issue of "beefing up" the libraries.
I would fully agree that SRFI isn't going anywhere towards providing:
- Some equivalent to DESTRUCTURING-BIND
- A close equivalent to CL "optional arguments"
- The magic of SETF
There's some ground in between the _both_ unreasonable positions of:
"They're working on something, so obviously everything's AOK" and
"They don't have a FULL answer to ALL my objections, so obviously
their process is utterly futile and the system is utterly useless."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
Rules of the Evil Overlord #100. "Finally, to keep my subjects
permanently locked in a mindless trance, I will provide each of them
with free unlimited Internet access. <http://www.eviloverlord.com/>
David Bakhash
> I really don't think that the original intent of Scheme was to have
> a language that is inherently less powerful than Lisp, just a core
> that is cleaner, that allows expansion, in a healthier way...
I would question anyone who looks at the bulk of Scheme code out there
which implements things that Common Lisp has, and would argue that
it's cleaner. Personally, having programmed and read lots of Scheme
code, to say that Scheme is in any way clean is a farce. Scheme code
is all over the place. It's mostly unreadable, overly complicated
because half of it is there just to reimplement the essentials that
Common Lisp has, where CL *also* has a superior API for that segment
of the Scheme language that gets re-implemented differently in almost
every different implementation of Scheme. The useful AND reasonably
learnable part of Scheme, to me, happens to be almost a proper subset
of Common Lisp, except where CL has superior semantics. The parts of
Scheme that are very powerful are overly complex for the average C
programmer to grasp. You take something like multiprocessing in
Common Lisp (as it is done almost identically in the different
implementations that support it), and it's got a simple interface that
most people would have no trouble with once they get functional
programming. Not so with continuations.
This newsgroup will always be frequented by Schemers, many of whom
prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
hashtables, vectors, structures (and DEFSTRUCT of course, among other
great macros), you want to just forget about every other language, not
just Scheme.
dave
Rainer Joswig
<ca...@alum.mit.edu> wrote:
> Eli Barzilay <e...@barzilay.org> writes:
>
> > I really don't think that the original intent of Scheme was to have
> > a language that is inherently less powerful than Lisp, just a core
> > that is cleaner, that allows expansion, in a healthier way...
>
> I would question anyone who looks at the bulk of Scheme code out there
> which implements things that Common Lisp has, and would argue that
> it's cleaner.
I think one language that wanted to be a competition is EuLisp.
Reading the EuLisp spec is still worth it. Scheme as a "competition"
does not make sense to me. It lacks some basic CL
mechanisms that are hard to add later (for a several reasons),
like for example keyword arguments.
Aesthetically, some of the Common Lisp code I have seen,
is extremely pleasing (the opposite is possible, too).
Just look at the AMOP book - everything just falls beautifully
into place - masters at work.
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Joe Marshall
> I would question anyone who looks at the bulk of Scheme code out there
> which implements things that Common Lisp has, and would argue that
> it's cleaner. Personally, having programmed and read lots of Scheme
> code, to say that Scheme is in any way clean is a farce.
You can write spaghetti code in any language, including CL.
Where Scheme is `clean' is in its formal semantics. This makes it
very useful when you are, for instance, trying to prove that a
particular compilation technique is semantically sound.
> Scheme code is all over the place. It's mostly unreadable, overly
> complicated because half of it is there just to reimplement the
> essentials that Common Lisp has...
I don't think this is a result of the language per se, but of the fact
that everyone and his brother writes a Scheme interpreter for an
undergraduate project.
> ..., where CL *also* has a superior API for that segment of the
> Scheme language that gets re-implemented differently in almost every
> different implementation of Scheme.
I wouldn't say the CL API is unconditionally superior, but I do agree
that there are too many gratuitous differences both between Scheme and
CL and each implementation of Scheme. There is a lot of utility in a
standard API, even if a `cleaner' or `better' one could be devised.
> This newsgroup will always be frequented by Schemers, many of whom
> prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> hashtables, vectors, structures (and DEFSTRUCT of course, among other
> great macros), you want to just forget about every other language, not
> just Scheme.
Do you want to work or do you want to play? If you want to play
around with language design and semantics, Scheme is a good starting
point. If you want to build an `industrial strength' application, CL
is a good starting point.
Eli Barzilay
> I would question anyone who looks at the bulk of Scheme code out
> there which implements things that Common Lisp has, and would argue
> that it's cleaner.
There is no connection between implementation of functionality which
is part of an implementation and the "cleanliness" of any language.
> Personally, having programmed and read lots of Scheme code, to say
> that Scheme is in any way clean is a farce. [...] The parts of
> Scheme that are very powerful are overly complex for the average C
> programmer to grasp.
Oh, tell that average C programmer I'm sorry. (Just being polite, I
couldn't care less for average-anything.)
> You take something like multiprocessing in Common Lisp (as it is
> done almost identically in the different implementations that
> support it), and it's got a simple interface that most people would
> have no trouble with once they get functional programming. Not so
> with continuations.
Of course. Using continuations for multiprocessing is a delicate
business to get right. But here's an example of code that I'd use:
(define (foo) (sleep 10) (printf "Hey!~%"))
(thread foo)
Was that hard? Unclear? Unclean?
> This newsgroup will always be frequented by Schemers, many of whom
> prefer Scheme to CL.
Yes, and Perl-ers and C-ers and maybe even VisualBasic-ers.
> But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> structures (and DEFSTRUCT of course, among other great macros), you
> want to just forget about every other language, not just Scheme.
So, if I have all of that in my Scheme implementation, shouldn't I be
happy?
David Bakhash
> > This newsgroup will always be frequented by Schemers, many of whom
> > prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> > hashtables, vectors, structures (and DEFSTRUCT of course, among other
> > great macros), you want to just forget about every other language, not
> > just Scheme.
>
> Do you want to work or do you want to play? If you want to play
> around with language design and semantics, Scheme is a good starting
> point. If you want to build an `industrial strength' application, CL
> is a good starting point.
Define play. Let me provide an example...
I would consider writing something like (say) a fortran-to-C translator
playing under your definition (insofar as it involves language design
and semantics). I think such a feat would be much easier to do in CL
than in Scheme.
Now consider fortran-to-cl vs. fortran-to-scheme. Which of those would
be easier? I'd still guess the former. Why? Because for all intents
and purposes, CL is a superset of Scheme, minus continuations.
Granted, scheme-to-fortran is easier than cl-to-fortran, and so you have
the following situation:
So in this example, cl is better for some uses, scheme for others. But
now suppose you wanted to write some middle-of-the-road, intermediate
turing-complete intermediate language (called `X') to describe a
program, and every translation from A->B actually goes from A->X->B.
Then Scheme would be easier, provided that it were X. However, if you
were _really_ playing, then you would be defining X yourself (i.e. it
wouldn't be Scheme), and in this case, writing code to deal with X would
probably be easier in CL than in Scheme. Writing code to translate from
A->X or from X->B (analyzers, generators) is also more likely easier in
CL than in Scheme.
So I've provided a real-world example of what the previous poster has
mentioned, and given my reasons for thinking that CL is better even for
play.
I do realize that continuations themselves are, in and of themselves,
very interesting and there's probably no single thing in CL that is as
interesting a concept as first-class Scheme continuations. Also, that
solutions using continuations are in general more interesting than other
solutions. For example, it would be nice to compare a non-deterministic
(choose/fail) sublanguage design and implementation in Scheme vs. CL.
dave
David Bakhash
> Of course. Using continuations for multiprocessing is a delicate
> business to get right. But here's an example of code that I'd use:
>
> (define (foo) (sleep 10) (printf "Hey!~%"))
> (thread foo)
>
> Was that hard? Unclear? Unclean?
no. good point.
> > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > structures (and DEFSTRUCT of course, among other great macros), you
> > want to just forget about every other language, not just Scheme.
>
> So, if I have all of that in my Scheme implementation, shouldn't I be
> happy?
No. Because they're not standard, and not even close to being
standardized for Scheme. And if you did have them in Scheme,
implemented in Scheme, then they would likely be untollerably slow.
Also, is this even feasible?
But then again, if you *did* build these CL ideas into Scheme, you
wouldn't be the first, and that's one of my points. If you find
yourself doing so because you need these tools, then why not just use CL
instead?
dave
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Of course. Using continuations for multiprocessing is a delicate
> business to get right. But here's an example of code that I'd use:
>
> (define (foo) (sleep 10) (printf "Hey!~%"))
^^^^^ ^^^^^^
Not in R^nRS! Ditto!
> (thread foo)
I'll grant you this :)
>
> Was that hard? Unclear? Unclean?
(defun foo () (sleep 10) (format t "Hey!~%"))
^^^^^
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_sleep.html
(mp:make-process #'foo)
^^^^^^^^^^^^^^^
Essentially the CLIM spec!
Was that hard? Unclear? Unclean?
...
> > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > structures (and DEFSTRUCT of course, among other great macros), you
> > want to just forget about every other language, not just Scheme.
>
> So, if I have all of that in my Scheme implementation, shouldn't I be
> happy?
No you should not! Because your program won't run on another Scheme
implementation. You just don't get it, do you? :)
Joe Marshall
> Using continuations for multiprocessing is a delicate business to
> get right.
That is because continuations are the *wrong tool* for
multiprocessing.
Joe Marshall
> > > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > > structures (and DEFSTRUCT of course, among other great macros), you
> > > want to just forget about every other language, not just Scheme.
> And if you did have them in Scheme, implemented in Scheme, then they
> would likely be intolerably slow. Also, is this even feasible?
That's ridiculous.
MIT Scheme has hash tables, and defstructs. There are vectors, not
only of scheme objects, but that may be specialized to hold just
characters, small numbers, or flonums. Vector-ref is open-coded by the
compiler, so it is no slower than svref in CL.
MIT Scheme also has an object system based on ``Tiny CLOS''. Now I'm
not going to argue that Tiny CLOS is `better' or even comparable to
CLOS, but it does provide classes, slots, multiple inheritaces,
generic functions, method combination, computed methods, etc.
There is not a MOP.
CL has a very rich standard library, and you are not going to find it
duplicated in Scheme, but the reasons for that are not because it
would be impossible to implement, or too slow to be useful.
Joe Marshall
> Joe Marshall <j...@content-integrity.com> writes:
>
> > > This newsgroup will always be frequented by Schemers, many of whom
> > > prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> > > hashtables, vectors, structures (and DEFSTRUCT of course, among other
> > > great macros), you want to just forget about every other language, not
> > > just Scheme.
> >
> > Do you want to work or do you want to play? If you want to play
> > around with language design and semantics, Scheme is a good starting
> > point. If you want to build an `industrial strength' application, CL
> > is a good starting point.
>
> Define play. Let me provide an example...
>
> I would consider writing something like (say) a fortran-to-C translator
> playing under your definition (insofar as it involves language design
> and semantics). I think such a feat would be much easier to do in CL
> than in Scheme.
I think you are right.
I was thinking of `playing' along the lines of investigating language
implementation via stratified monads, or seeing if converting to
A-normal form before compilation helps with dataflow analysis. Or
inventing `environment-passing-style' to model side effects, etc. etc.
These things are a bit easier in Scheme because there are fewer
special cases to consider.
> Because for all intents and purposes, CL is a superset of Scheme,
> minus continuations.
(and maybe tail recursion)
I pretty much agree. That is the reason that Scheme is used in a lot
of theoretical computer science. You can treat it as an `essential
subset'. If you can make it work in Scheme, it applies to much larger
systems, such as common lisp.
Tim Bradshaw
> That is because continuations are the *wrong tool* for
> multiprocessing.
But to be fair, so are stack groups -- both lisp systems and scheme
systems have historically made the mistake of exposing far too much of
the (uniprocessor-specific) implementation of multiprocessing. CL is
kind of better because systems typically do at least almost provide a
layer on which useful abstractions could be built (actually, as far as
I can see they get it wrong because of stuff like wait-functions, but
it's better than starting with call/cc, anyway).
--tim
Rob Warnock
+---------------
| This newsgroup will always be frequented by Schemers, many of whom
| prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
| hashtables, vectors, structures (and DEFSTRUCT of course, among other
| great macros), you want to just forget about every other language, not
| just Scheme.
MzScheme, the version I Scheme I use most often, has hashtables,
vectors, structures ("define-struct", with single-inheritance like CL
DEFSTRUCT's :INCLUDE), defmacro (in addition to syntax-rules). It also
has a thread system (well-integrated with I/O), a socket library (that
works well with threads), multiple namespaces, a sophisticated module
system ("units with signatures"), and a rich exception-handling system.
Oh, and boxes, weak boxes, & finalization ("will executors"). And regular
expressions, and the "awk" macro from Scsh. Add MrEd, and you get a
portable GUI application tookit (including a small web browser). Add
MysterX for COM/ActiveX (Windows only), and SrPersist (all platforms)
for OBDC connectivity.
Yes, it has only single-dimension arrays, and only a single-inheritance
object system with no MOP. When I need CL arrays or full CLOS, I use CL.
"But it's not Scheme", you say, "cuz that stuff's not in R5RS!" Herein
lies one of the big differences between the two communities: the Common
Lisp folk (at least, the ones in this newsgroup) get *much* more uptight
about Scheme extensions than the Scheme folks themselves do!! In the
Scheme community, if an implementation provides what's in R5RS, so that
R5RS-compliant programs run, then it *is* a "Scheme", no matter how much
(or what) extra stuff it has.
Also, at least as far as getting real work done, the Scheme folks tend
to pick an implementation and stick with it long enough to learn its
quirks & salient points, just as I've heard people say here they do
with CL, too.
Finally, as someone else pointed out, in actual practice neither the
CLTS nor R5RS is enough to get real work done, when "real work" includes
sockets, DBMS bindings, GUIs, and other trappings of modern life.
The really big difference is how *much* the standard "standardizes".
For Scheme, it's very little of the messy stuff; for CL it's much,
much more, but still not everything. In either case, porting a
significant application to a different implementation (of the "same"
language) is likely to be a bit of work -- but not a *huge* amount,
if your abstractions are reasonable.
I carry a Swiss Army Knife in my pocket, and I know where to go
when I need a well-appointed machine shop. I use both at various
times, for (mostly) different things. Why should I have to declare
exclusive allegiance to either of them?
-Rob
-----
Rob Warnock, 31-2-510 rp...@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Rob Warnock
+---------------
| Eli Barzilay <e...@barzilay.org> writes:
| > (define (foo) (sleep 10) (printf "Hey!~%"))
| ^^^^^ ^^^^^^
| Not in R^nRS! Ditto!
As I said in a previous message, "Scheme people" don't *care*!!!
It's only Common Lisp people that seem to get so bent out of shape
by the fact that the porduction implementations of Scheme are chock
full of stuff that's not in R5RS...
And where in CLHS, pray tell, are sockets, CLX/CLIM, threads, fork/exec,
FFI, and all the other stuff you need to add to CL to make *it* useful
in a production systems environment?
So enough already with this "not in R5RS" strawman, o.k.? The Scheme
standard is very, very small. The Common Lisp standard is very, very big.
We all know that. But neither standard is big enough to cover everything
most of us need for "real work". We all know that, too.
The solution in *both* cases is to pick an implementation that has
the things you need, and learn to live in/with that implementation
(and try *somewhat*, though don't be silly about it, to structure
your abtractions to if you *have* to change implementations it won't
be *too* painful). Since more of any "useful CL" is "standard", that
will almost always mean that the pain of moving between CL implementations
is less than the pain of moving between Schemes. So what? Big > little.
So please, let's stay away from the strawmen & cheap shots, o.k.?
There are probably plenty of serious issues we could talk about.
E.g., how about things where neither Scheme nor CL gets it quite right?
cbbr...@hex.net
> David Bakhash <ca...@alum.mit.edu> wrote:
> +---------------
> | This newsgroup will always be frequented by Schemers, many of whom
> | prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> | hashtables, vectors, structures (and DEFSTRUCT of course, among other
> | great macros), you want to just forget about every other language, not
> | just Scheme.
> +---------------
> MzScheme, the version I Scheme I use most often, has hashtables,
> vectors, structures ("define-struct", with single-inheritance like
> CL DEFSTRUCT's :INCLUDE), defmacro (in addition to syntax-rules). It
> also has a thread system (well-integrated with I/O), a socket
> library (that works well with threads), multiple namespaces, a
> sophisticated module system ("units with signatures"), and a rich
> exception-handling system. Oh, and boxes, weak boxes, &
> finalization ("will executors"). And regular expressions, and the
> "awk" macro from Scsh. Add MrEd, and you get a portable GUI
> application tookit (including a small web browser). Add MysterX for
> COM/ActiveX (Windows only), and SrPersist (all platforms) for OBDC
> connectivity.
> Yes, it has only single-dimension arrays, and only a
> single-inheritance object system with no MOP. When I need CL arrays
> or full CLOS, I use CL.
I've not used SCMOS <http://www.cs.rice.edu/~dorai/scmos.html> or
Meroon <http://youpou.lip6.fr/queinnec/WWW/Meroon.html>; neither
implements MOP, but are intended to resemble CLOS and claim to run
with MzScheme...
You've missed two _major_ missing things:
a) Keyword arguments. Scheme supports an equivalent to &rest, but not
to &key or &optional. As a result, you tend to need to implement
more functions in Scheme.
b) SETF expansion. Again, Scheme requires implementing additional
functions whereby rather than doing:
(setf (ref-interior-object-of thing) new-value)
you need to be explicit, via
(set-interior-object-of-whatever! thing new-value)
and define a bunch of "setters."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
You can lead a horse to water, but if you can get him to swim on his
back, you've got something.
Duane Rettig
> Marco Antoniotti <mar...@cs.nyu.edu> wrote:
> +---------------
> | Eli Barzilay <e...@barzilay.org> writes:
> | > (define (foo) (sleep 10) (printf "Hey!~%"))
> | ^^^^^ ^^^^^^
> | Not in R^nRS! Ditto!
> +---------------
>
> As I said in a previous message, "Scheme people" don't *care*!!!
Actually, I think this is not true. See below.
> It's only Common Lisp people that seem to get so bent out of shape
> by the fact that the porduction implementations of Scheme are chock
> full of stuff that's not in R5RS...
>
> And where in CLHS, pray tell, are sockets, CLX/CLIM, threads, fork/exec,
> FFI, and all the other stuff you need to add to CL to make *it* useful
> in a production systems environment?
CL people also tend to get bent out of shape for these, too. There is
no inconsistency here.
> So enough already with this "not in R5RS" strawman, o.k.? The Scheme
> standard is very, very small. The Common Lisp standard is very, very big.
> We all know that. But neither standard is big enough to cover everything
> most of us need for "real work". We all know that, too.
Both CL and Scheme have pseudo or de-facto standards, as well. I remember
seeing something like RTFs? (someone correct me on the name; I forgot) on
some site for Scheme, so at least some Schemers care about standardizing
non-standard pieces. And CLers are always worrying about this thing
called "portability".
Why is this? The answer is in an old term I haven't heard for a while,
but which is incredibly important in any industry: "second sourcing".
In any industry, if you have a product built on particular widgets but
can't guarantee your widget-vendor's viability, you must dig up a
second-source, a second vendor that you buy from to hedge your bet on
your widgets to build your product. Part of that second-sourcing
effort must be spent negotiating the interface to the second type of
widget. Sometimes it requires a retrofit. Ideally, there is a
standard interface so both brands of widgets are interchangable.
Now I suspect that the reason I don't hear this term anymore is
because it is mostly used to refer to hardware (and I'm completely out
of the hardware industry, now). However, the concept still exists in
software, only we tend to call it "portability". But because that
term is so overloaded, people sometimes miss the more subtle meaning
of portability that really means "easily second-sourced".
> The solution in *both* cases is to pick an implementation that has
> the things you need, and learn to live in/with that implementation
This is dangerous if the application is not portable.
> (and try *somewhat*, though don't be silly about it, to structure
> your abtractions to if you *have* to change implementations it won't
> be *too* painful).
A relative term. My experience as a vendor is that customers have a
very low tolerance for such pain, and rightly so. This applies to
version changes as well, which we also take very seriously. Any
"porting" that must be done for either a version change or a vendor
change is a negative, and lengthens the time it takes to release
your product.
> Since more of any "useful CL" is "standard", that
> will almost always mean that the pain of moving between CL implementations
> is less than the pain of moving between Schemes. So what? Big > little.
The difference may make or break your company in getting the new version
of your software out before your competitors.
> So please, let's stay away from the strawmen & cheap shots, o.k.?
> There are probably plenty of serious issues we could talk about.
> E.g., how about things where neither Scheme nor CL gets it quite right?
In this thread, I don't remember too many cheap shots (I regard the
example you quoted as an honest effort to show a difference in how
Schemers and CL standardize). And I think we really _are_ talking about
serious issues, although I don't think anyone had yet really explored
the portability issue (as it applies to second-sourcing).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Christophe Rhodes
> Both CL and Scheme have pseudo or de-facto standards, as well. I remember
> seeing something like RTFs? (someone correct me on the name; I forgot) on
> some site for Scheme, so at least some Schemers care about standardizing
> non-standard pieces.
SRFI (Scheme Request for Implementation);
<URL:http://srfi.schemers.org/>.
There are some very bright people involved in this process; I find it
interesting browsing the mailing list archives and the SRFIs
themselves; there are some good ideas, I think.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})")
cbbr...@hex.net
> Both CL and Scheme have pseudo or de-facto standards, as well. I
> remember seeing something like RTFs? (someone correct me on the
> name; I forgot) on some site for Scheme, so at least some Schemers
> care about standardizing non-standard pieces.
They're called SRFI's; <http://srfi.schemers.org/>, and a somewhat
fairer characterization than "standardizing non-standard piece" would
be their phrasing, namely "proposals for standardized feature sets for
Scheme implementations."
> In this thread, I don't remember too many cheap shots (I regard the
> example you quoted as an honest effort to show a difference in how
> Schemers and CL standardize). And I think we really _are_ talking
> about serious issues, although I don't think anyone had yet really
> explored the portability issue (as it applies to second-sourcing).
The problem, these days, is that CL community seems to be diverging
_away_ from generating standards for new things such as Internet
services. There's no longer a "Kent Pitman" to generate future
generations of HyperSpec [much appreciated both of those are!], and
there was the unfortunate "case conflict" last year implicating some
degree of noncooperativeness on the part of Franz.
The SRFI process is certainly limited in its power to improve Scheme;
it nonetheless has the merit that it's active, whilst CL
standardization efforts seem, um, less than terribly active these
days.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
"Options to reboot are: -n Avoids the sync. It can be used if a disk
or the processor is on fire." -- reboot(8)
Joe Marshall
> "In actual practice", Scheme is much, _much_ more messy than Common
> Lisp implementations will _ever_ get.
I don't know by what metric you are measuring messiness. Having done
both Scheme and Common Lisp implementations, I have found that
implementing full Common Lisp or a Scheme system with a library large
enough to be useful to be about the same amount of effort.
The code base ends up about the same size, and the amount of
`messiness' (as I see it), is about the same.
Joe Marshall
> * Joe Marshall wrote:
> > That is because continuations are the *wrong tool* for
> > multiprocessing.
>
> But to be fair, so are stack groups
Agreed!
> -- both lisp systems and scheme systems have historically made the
> mistake of exposing far too much of the (uniprocessor-specific)
> implementation of multiprocessing.
>
> CL is kind of better because systems typically do at least almost
> provide a layer on which useful abstractions could be built
> (actually, as far as I can see they get it wrong because of stuff
> like wait-functions,
Yes. Unfortunately, it seems that the `stack group' API is the
de-facto standard for multitasking among Common Lisp vendors, and I
have seen too many buggy implementations.
> but it's better than starting with call/cc, anyway).
It is the equivalent of trying to do multitasking with catch & throw.
T. Kurt Bond
> I think one language that wanted to be a competition is EuLisp.
> Reading the EuLisp spec is still worth it.
Reading the EuLisp papers is also still worth it. Some of them talk
about the different design decisions they made when designing the MOP for
it, and other things. There are also interesting, if fragmentary,
notes in the VIM and Denton work logs that talk about EuLisp and the
EuLisp implementations.
The EuLisp FAQ is at:
http://www.maths.bath.ac.uk/~jap/EuLisp/eulisp-faq.html
It points to the 0.99 version of the EuLisp definition (the .ps and
.dvi files) and the later partial revisions (an HTML document).
The EuLisp papers are available in subdirectories of:
ftp://ftp.bath.ac.uk/pub/eulisp/
The home page of the Youtoo Implementation of EuLisp is at:
http://www.maths.bath.ac.uk/~jap/ak1/youtoo/
As far as I can tell it's not being maintained right now, but with a
little bit of work this will still run under Linux. (With a little
more work it can be bootstrapped from the EuLisp sources; this
requires a couple of utility programs that were accidently left out of
the distribution, but I've got some crudely reverse-engineered
versions that seem to work, if anybody is interested.)
--
T. Kurt Bond, t...@tkb.mpl.com
Eli Barzilay
> * Rob Warnock
> | It's only Common Lisp people that seem to get so bent out of shape
> | by the fact that the porduction implementations of Scheme are chock
> | full of stuff that's not in R5RS...
>
> Only when you Scheme schmucks brag about the size of your language and
> try to knock Common Lisp for _having_ everything that you have to do on
> your own outside the standard. That's when the size of the standard is
> relevant. The size of penises or standards is not relevant otherwise.
When was exactly the last time someone came (or anywhere) where
someone bragged about the size of the Scheme standard?
> So can you insufferable Scheme freaks please just cut your crap
> here in comp.lang.lisp and take your silly Scheme propaganda to
> comp.lang.scheme where you can preach to your own goddamn choir?
No.
Eli Barzilay
> * Joe Marshall wrote:
> > That is because continuations are the *wrong tool* for
> > multiprocessing.
>
> But to be fair, so are stack groups -- [...]
Multiprocessing is delicate in any way you look at it. All these
tools are just for implementing it.
Eli Barzilay
> Not in R^nRS! Ditto!
Again??
> (defun foo () (sleep 10) (format t "Hey!~%"))
> [...]
> (mp:make-process #'foo)
> ^^^^^^^^^^^^^^^
> Essentially the CLIM spec!
>
> Was that hard? Unclear? Unclean?
No. No. No.
Was that my point?
> No you should not! Because your program won't run on another Scheme
> implementation. You just don't get it, do you? :)
No, *you* just don't get it. After every time I mention the fact that
I have `foo' available where `foo' is not in RnRS, you immediately go
for the "not in RnRS => not in Scheme" argument. You're trying to
argue with some imaginary _pure_ Scheme programmer, and not only have
I said pretty explicitly that I am not one, I also said that I would
be surprised to find one.
Tim Bradshaw
> Multiprocessing is delicate in any way you look at it. All these
> tools are just for implementing it.
Precisely, and the problem is that Lisp systems (and I presume scheme
systems too) expose far too much implementation detail, leading to
large bodies of code which make assumptions which either bind them to
an implementation, or mean that they will perform atrociously on other
implementations (consider the implications of WITHOUT-PREEMPTION as a
way of implementing critical sections on a multiprocessor, which is
perhaps the most egregious example although there are many others).
--tim
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | When was exactly the last time someone came (or anywhere) where
> | someone bragged about the size of the Scheme standard?
>
> Geez, I sure hope no Scheme pervert _comes_ where people brag
> about the size of the Scheme standard. That's just _too_ gross.
> Ick!
The question still stands - your main problem with "Scheme freaks" is
that they brag at the size of their standard, so, when did it last
happen?
> | No.
>
> That's the the Scheme attitude in a nutshell. It's nice to have
> you guys self-identify though. Thank you.
That's my own attitude in a nutshell. Drawing any conclusions on the
Scheme attitude is nonsensical (besides, I am using three different
"Lisp-related" languages on an almost daily basis, so you could draw
the same conclusion for the Lisp attitude).
> I fail to see the purpose that the Scheme trolls have in this
> newsgroup. Go create comp.lang.scheme.advocacy and go away from
> decent places, OK?
I fail to see the purpose of saying this in the current context,
especially since the way this discussion began was not Scheme
advocation - and it still doesn't contain any.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | The question still stands - your main problem with "Scheme freaks" is
> | that they brag at the size of their standard, so, when did it last
> | happen?
>
> Do you really expect an answer to this anal-retentive rhetorical
> question?
I don't see where this question is being either rhetoric, or anal retentive.
> You know perfectly well that language size is the big selling
> point for Scheme,
Only for the academic purpose, where, I think, Scheme wins and Lisp
suck. But this has _nothing_ to do with using either in the "real
world", where - if you compare the standards - Lisp wins and Scheme
suck. If real-world applications are what you're into (which is
pretty clear), then you hold, very unsurprisingly, the second opinion
and I _never_ that it is wrong. Again, I had no intentions to
advocate Scheme in any way - if, for some strange reason, you'll ask
me if you should switch to Scheme for what you are doing now, I would
most definitely not say that it is better.
> and you know equally perfectly well that Scheme freaks commonly
> attack Common Lisp based on the size of their standards documents.
If you talk about "academic attacks", then this is mostly true, but it
has no implications other than that. Your claims about Scheme being
an example of how Academia is treating the "real-world" in a bad way
are out of their context since, by definition, the academic world has
little to do with the "real-world", but very frequently it serves a
good purpose of starting new ideas that wouldn't have any chance
otherwise (and Lisp is a good example of _that_).
> Don't insult your own intelligence by requesting proof of the
> obvious, but feel free to tell me you have never seen it, and I'll
> point it out to the next time it happens. [...]
Please do.
> Again, but now in the spirit of your anal-retentiveness, my own
> question to you Scheme freaks still stands: Why do you come here
> to talk about Scheme? You already _have_ a newsgroup. [...]
Scheme suffers from some well-known misguided opinions here, a fact
that shows itself every once in a while. The reason I started talking
on this is only to try and make this issue a bit clearer. I had no
intention of having any Scheme discussion, including advocacy of any
kind. As I said, I have deep respect for Common Lisp, and I am using
it on a daily basis - so how could I even be suspected of advocating
Scheme over Lisp?
Kent M Pitman
> Erik Naggum <er...@naggum.net> writes:
>
> > * Eli Barzilay <e...@barzilay.org>
> > | The question still stands - your main problem with "Scheme freaks" is
> > | that they brag at the size of their standard, so, when did it last
> > | happen?
> >
> > Do you really expect an answer to this anal-retentive rhetorical
> > question?
>
> I don't see where this question is being either rhetoric, or anal retentive.
How about just "not productive"? Erik is right. It is routine for
Scheme people to cite the size of the ANSI CL standard as a negative,
and explicitly or implicitly to tout the small size of their document
as a model. Not all such encounters occur in referenceable fashion,
and it's useless/misleading and bordering on obnoxious and passive
aggressive to demand a reference as if the failure to reply with a
reference negated the claim.
Erik's dissection of this was on the mark: Even for as large as CL is,
no fan of CL would tell you there shouldn't be "more to come" if/when
we have the time to do so. By contrast, there are people who suggest
that Scheme's small size is a virtue, which works against the Scheme
community by failing to standardize common facilities that everyone needs
to use. The SRFI process somewhat helps to repair this, but it is not a
consensus body standard nor is it sanctioned by the original group of
authors. Scheme + other extensions is useful, but it's unfair to "hide"
the size of Scheme in this fashion at the same time as criticizing CL for
its size.
Eli Barzilay
> How about just "not productive"?
OK. (This hasn't been a "productive discussion" to begin with.)
> Erik is right. It is routine for Scheme people to cite the size of
> the ANSI CL standard as a negative, and explicitly or implicitly to
> tout the small size of their document as a model. [...]
I think that most "Scheme-posts" here have a similar general approach
to mine - they usually like Lisp but think that the two standards have
different goals. People who use Lisp exclusively tend to fight
imaginary Scheme purists that say that Lisp is a bad language because
it has a huge standard - and I think that such people do not exist, or
when they do, then they appear in an academic-only context.
> Erik's dissection of this was on the mark: Even for as large as CL
> is, no fan of CL would tell you there shouldn't be "more to come"
> if/when we have the time to do so.
Definitely - this is why it still might be possible to add things like
network, processes etc to it. That would probably be pretty hard to
get some consensus, but I think that Lisp has managed such issues
remarkably well so far. I'll even add that in this department, the
Scheme standard _does_ take the easy way out of not talking about
anything more than the absolute minimum needed, but this is not an
indication of laziness or academic pretentiousness, but as an
indication of a completely different goals for the standard. This is
why Scheme implementations face the problem of coming up with
solutions to such issues, and each implementation goes by what its
developers see as The Right Thing. The result is a philosophy which
is completely different than the Lisp one, which is also the usual
source of such flamewars. Going back to my starting point, I think
that once Lisp-ers admit this fundamental difference, a lot less
unproductive time will be spent. Continuations are one of the best
examples of this - they fit well with the Scheme goal, which does make
it hard for implementations to cope with, but it allows a lot of "cute
academic games". Shouting that this is an indication of why Scheme is
bad and Lisp is good is as useless as the opposite since both claims
are true when you view them under the two different goals. As a last
remark I'll just add that I think (only from personal experience here)
that Scheme-ers usually have good view/feel for the Lisp world since
they usually use both, where Lisp-ers tend to detest anything that
doesn't fit in the all-embracing-standard philosophy. (I guess all
this makes it even more similar to real religious wars (real as
Christians vs. Muslims etc)). Take Emacs-Lisp as an example of a
third camp - since these are usually people that just hack stuff for
their environment, wanting only to be _able_ to do it but don't really
care _how_, makes this a non existing side in this language wars - but
big wars begin as soon as people talk about whether the "next
generation" Emacs should use Common Lisp or Scheme as its language.
> By contrast, there are people who suggest that Scheme's small size
> is a virtue, which works against the Scheme community by failing to
> standardize common facilities that everyone needs to use.
As I said, I completely agree that such a claim, in a CL context (such
as this NG) would be bogus, and I think that most "Scheme-ers" that I
have seen posting it (where this instance of "ers" is anyone who
happen to be taking the Scheme side, not necessarily a real Scheme-er)
did not go for this argument either. The only reason I ever posted in
the first place is that I would be happy to see Lisp-ers understand
Scheme-ers a little better.
> The SRFI process somewhat helps to repair this, but it is not a
> consensus body standard nor is it sanctioned by the original group
> of authors.
And the reason it had taken so long to start something like this, and
that now it looses some of the initial interest, is that Scheme-ers
have a different view on the "standard" language definition.
> Scheme + other extensions is useful, but it's unfair to "hide" the
> size of Scheme in this fashion at the same time as criticizing CL
> for its size.
It is not hiding Scheme's size in anyway, just saying that this size,
interpreted as "the size of the standard" has no real meaning to
Scheme-ers since they really all just -ers of their actual
implementation.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | Scheme suffers from some well-known misguided opinions here, a
> | fact that shows itself every once in a while.
>
> Oh, but those should be corrected if they are indeed wrong, but do
> remember that one man's misguided opinion is easily another man's
> raison d'être or even religion. Can't mess with those, can we?
> :)
We can always try.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | OK. (This hasn't been a "productive discussion" to begin with.)
>
> That explains why you are hell bent on making is even less
> productive. I find such attitudes to be extremely snotty and very
> destructive.
Snotty? The thing with you is that you never give up - always the
last word, and I'm the one who's snotty because I dare post something
with no technical content? You really expect people at the position
of being labeled in any way, especially a negative one, to just shut
up? Maybe I should go low enough now in the hope that you will? From
my POV, you're the one who should alter your expectations. (Since I
said "you" so many times in the above, you'd probably have to go with
your twist of turning what I said back on me right?)
> | People who use Lisp exclusively tend to fight imaginary Scheme
> | purists that say that Lisp is a bad language because it has a huge
> | standard - and I think that such people do not exist, or when they
> | do, then they appear in an academic-only context.
>
> They aren't "imaginary Scheme purists", dude.
Until I see them (or their posts or whatever), they are.
> | Going back to my starting point, I think that once Lisp-ers admit
> | this fundamental difference, a lot less unproductive time will be
> | spent.
>
> But you're _wrong_! We can't "admit" to a "difference" where one
> party has clearly lost its good mind. I'm not joking about this.
> [...]
But when you define me as someone who lost his mind you make chances
of any kind of a discussion impossible, so why do you keep this on?
> | Continuations are one of the best examples of this - they fit well
> | with the Scheme goal, which does make it hard for implementations
> | to cope with, but it allows a lot of "cute academic games".
>
> Some of us are not even watching Big Brother, much less want to
> join. Games are for people who prefer not to deal with the real
> world.
If it weren't for games (my definition, not TV shows) in the computer
world, you wern't using Lisp today.
> | Shouting that this is an indication of why Scheme is bad and Lisp
> | is good is as useless as the opposite since both claims are true
> | when you view them under the two different goals.
>
> How about evaluating the goals? Suppose your goal is the
> extermination of mankind because you believe in the intrinsic evil
> of man in general, [...]
I have not said anything about goal evaluation. Certainly your
example is irrelevant to what I said.
> | As a last remark I'll just add that I think (only from personal
> | experience here) that Scheme-ers usually have good view/feel for
> | the Lisp world since they usually use both, where Lisp-ers tend to
> | detest anything that doesn't fit in the all-embracing-standard
> | philosophy.
>
> What an odd personal experience. I must assume that I'm part of
> that personal experience since I'm discussing this with you,
> albeit in what you have snottily and arrogantly and unilaterally
> decided is not a productive discussion, anyfuckingway, so let me
> just add that your ability to discern motives in other people is
> sorely lacking.
Whew, I'm lucky to be alive, aren't I?
> I'm usually a very tolerant guy,
[Wild laugh from the audience.]
> [...] incompetence and stupidity and dishonesty and ignorant
> arrogance, [...] some snotty asshole with an agenda that prohibits
> him from being honest and smart, I don't tolerate that.
And you really think that by this I will understand that you're the
one with The Truth and shut up in shame? How can you even be
surprised when people have these infinite threads with you?
> So you're missing the point, big time. It is the Scheme model of
> what is considered good and valuable that is rejected on its own
> terms, not its failure to measure up to some other model of what
> is considered good and valuable. I would _really_ have expected a
> snotty academic to grasp this, as it is the core of an
> intellectual approach to analysis, as opposed to the
> anti-intellectual pragmatist that looks at how useful something
> is, and which might have been guilty of your annoyingly snotty
> comment about what other people detest. Sheesh, dude, upgrade
> your brain.
Yeah, me and the three other guys who share my stupid opinions.
> I wonder how much you have looked at what you're talking about.
> You come here to dispell misguided opinions about Scheme, but you
> know nothing about the context into which you hope to inject your
> clarifications!
I know enough.
> How utterly _Scheming_ of you! And such Guile!
Oooh, now we're at the poetic stage...
> There are no wars, dude. You create them in your own mind because
> you think in war-like terms. [...] Wars are created by people
> who are intentionally irrational, and that includes people who
> come into a discussion without even the slightest pretense of
> wanting them to be productive.
Tsk tsk tsk, F-L-A-M-E W-A-R-S. You're confused again.
> | It is not hiding Scheme's size in anyway, just saying that this
> | size, interpreted as "the size of the standard" has no real
> | meaning to Scheme-ers since they really all just -ers of their
> | actual implementation.
>
> This cannot be true. If it were, they would embrace
> standardization of the common elements of their implementation,
> which they all resist.
Why would they? If they're happy with what they have, why would they
care to start the long effort of trying to get others to agree on what
both use?
> Performance is the last refuge of the miserable programmer.
Insults are the last refuge of the miserable writer.
Kent M Pitman
> > Erik is right. It is routine for Scheme people to cite the size of
> > the ANSI CL standard as a negative, and explicitly or implicitly to
> > tout the small size of their document as a model. [...]
>
> I think that most "Scheme-posts" here have a similar general approach
> to mine [...]
I did not mean to imply when I said it was "routine" that I was speaking
of this forum only. There are many venues, not all electronic and certainly
not all logged, in which Scheme is discussed.
I really have nothing more to say on the rest of this discussion. I really
don't care about this thread one iota, and consider it counterproductive.
MJ Ray
> This is the kind of stuff that would fit so well in an .advocacy group.
No, the following is the kind of stuff for c.l.lisp.advocacy:
> I happen to think that Scheme sucks universally, and especially so for
> academic purposes, where a serious, commercial Common Lisp _really_ wins.
Yeah, of course, let's teach them a language rather than concentrate
on the concepts and give them the simplest language which fits it.
For what it's worth, I started learning in BBC BASIC and it's not done
me any harm. ENDPROC.
> (I think it is a disservice to students to give them only "free" tools.)
Yeah, make 'em pay, huh?
Night!
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Not in R^nRS! Ditto!
>
> Again??
>
>
> > (defun foo () (sleep 10) (format t "Hey!~%"))
> > [...]
> > (mp:make-process #'foo)
> > ^^^^^^^^^^^^^^^
> > Essentially the CLIM spec!
> >
> > Was that hard? Unclear? Unclean?
>
> No. No. No.
>
> Was that my point?
>
>
> > No you should not! Because your program won't run on another Scheme
> > implementation. You just don't get it, do you? :)
>
> No, *you* just don't get it. After every time I mention the fact that
> I have `foo' available where `foo' is not in RnRS, you immediately go
> for the "not in RnRS => not in Scheme" argument. You're trying to
> argue with some imaginary _pure_ Scheme programmer, and not only have
> I said pretty explicitly that I am not one, I also said that I would
> be surprised to find one.
Then why don't you stop putting time into getting *a* Scheme up to par
with CL and don't come over to the Dark Side and spend your time in a
more productive way? There are a lot of things that need to be done
for CL.
Cheers
BTW. Don't even try to turn the question about me going over to the
Side of Light. :) Answer the question look into your soul and
listen to it. :)
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Eli Barzilay
> Then why don't you stop putting time into getting *a* Scheme up to
> par with CL and don't come over to the Dark Side and spend your time
> in a more productive way? There are a lot of things that need to be
> done for CL.
Why do you assume I'm not here in the Dark Side already? It _is_
possible to live in both places.
> BTW. Don't even try to turn the question about me going over to the
> Side of Light. :) Answer the question look into your soul and
> listen to it. :)
Again - converting anyone was really not my goal.
Eli Barzilay
> Eli Barzilay <e...@barzilay.org> writes:
>
> I did not mean to imply when I said it was "routine" that I was
> speaking of this forum only. There are many venues, not all
> electronic and certainly not all logged, in which Scheme is
> discussed.
And all come in some context - I have not seen in any other form
people bragging about the small size of RnRS as an advantage for doing
real-world systems.
> I really have nothing more to say on the rest of this discussion. I
> really don't care about this thread one iota, and consider it
> counterproductive.
It has been counterproductive for some time now.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | The thing with you is that you never give up - always the last word,
>
> Really? Well, what can I possibly say to this? Somewhere along
> the line, you decided it was OK to start talking about me. That's
> a good sign of a moron at work.
Oh, the moron stage... I guessed that you'll use "drivel" too but you
didn't, but most other parts were expected: using my name explicitly,
using the "_you_" thing, and BTW, I don't know who "Marcus G. Daniels"
is to take any courses from (although it is pretty clear he's a
character from one of your episodes that I missed).
> On the other hand, maybe it isn't so strange -- those who have
> such ability are generally smart enough to realize that they are
> fighting against their own daemons and create monsters out of
> their own prejudice.
Again, your posts at this stage are pretty predictable, including your
constant thing of twist-and-throw-back-at-his-face old tactic. You
create monsters, you provoke by using nice labels (moron etc) and when
the other side does get (very naturally) provoked you turn the whole
thing back. One thing _I_ am surprised at is that you keep
complaining about this at the same time as being blind to the fact
that you make it happen time after time.
> Now, you feel free to provide counter-evidence, of course.
Here's a good exercise in openness and tolerance: try to take your
post (or the previous one) and write the response that I should write
to satisfy you. (Resist your temptation to throw this back to me,
just try it.)
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Then why don't you stop putting time into getting *a* Scheme up to
> > par with CL and don't come over to the Dark Side and spend your time
> > in a more productive way? There are a lot of things that need to be
> > done for CL.
>
> Why do you assume I'm not here in the Dark Side already? It _is_
> possible to live in both places.
Yes. But on the Dark Side the work to do is less and more useful.
> > BTW. Don't even try to turn the question about me going over to the
> > Side of Light. :) Answer the question look into your soul and
> > listen to it. :)
>
> Again - converting anyone was really not my goal.
Why do you think I am not trying to convert you? :)
Cheers
David Bakhash
> David Bakhash <ca...@alum.mit.edu> writes:
>
> > > > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > > > structures (and DEFSTRUCT of course, among other great macros), you
> > > > want to just forget about every other language, not just Scheme.
>
> > And if you did have them in Scheme, implemented in Scheme, then they
^^^^^^^^^^^^^^^^^^^^^
> > would likely be intolerably slow. Also, is this even feasible?
>
> That's ridiculous.
Again, I was indicating that these things, implemented in Scheme
itself (noting that Scheme, as far as I can remember, lacks a file
compiler) would likely be slow.
dave
Eli Barzilay
> Yes. But on the Dark Side the work to do is less and more useful.
I'm judging which side to use depending on the task I need. I could
say that some things are better left for the other side but you
probably wouldn't believe that and I avoid getting into these
discussions. (At least I'm not going to the Perl side...)
> > > BTW. Don't even try to turn the question about me going over to the
> > > Side of Light. :) Answer the question look into your soul and
> > > listen to it. :)
> >
> > Again - converting anyone was really not my goal.
>
> Why do you think I am not trying to convert you? :)
Oh, you try to convert me? I'm converted enough, I wrote some Lisp
things that I would never dream of trying in Scheme. (I even use
ILisp.)
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | Oh, the moron stage...
>
> So you are not surprised to find out the truth about how you act?
> Good.
No, I am not surprised to see this thread degrade into your standard
drivel, as I have seen more times than I'd want to see.
> Yeah, sure, your behavior is my fault. That's the scary part,
> that you actually _believe_ that I have that much control over
> your life, that you are a marionette without the will-power to
> quit being counterproductive, and therefore have the most
> excellent reason to keep it up, and make it much worse. What is a
> moron, if not someone who behaves that way?
So now I can throw that back and say that every moron you have
encountered in your infinite fights here (which, I think, includes
pretty much everyone except those that you discourage from ever saying
anything), has received a very predictable reaction from you. In
other words, they have all been controlling you. If a moron is
someone that lets people control him like "a marionette without the
will-power to quit being counterproductive" then you are one of the
best examples of a moron in this NG and in any other.
> | Here's a good exercise in openness and tolerance: try to take your
> | post (or the previous one) and write the response that I should
> | write to satisfy you. (Resist your temptation to throw this back
> | to me, just try it.)
>
> Oh, that's very simple. Just produce a _thought_. Say something
> that _isn't_ yet more moronic flamebait. _You_ choose what _you_
> react to, and you get what you want. [...]
Oh, so I choose what to react to, and you claim that the only thing
that would satisfy you is that I get back on topic and not continue
this unproductive thread, right? (If not, then I'd really like to see
a rection post that would make you happy).
So considering the fact that I'm a moron that continues to reply to
your posts why wouldn't _you_ stop being a moron that gives me an
excuse to continue? Why wouldn't _you_ choose what you react to? If
in the collective experience of this NG, which you know very well,
(almost) every person that you have labeled as a moron did not shut up
but rather went directly on the unproductive track that we're on now,
then why haven't _you_ learned to just shut up when you see such
morons and avoid the whole moron talk? On a technical level you are
definitely not a moron, as you always like to note about others
(separating what you react to, their posts, rather than themselves),
but by the definition of a moron as a NG-moron, someone who posts
off-topic drivel and make other people join him, overall spending
people's time on reading it instead of doing productive work, then by
this definition you, Erik Naggum, is the super meta-moron of c.l.l.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | Oh, the moron stage...
>
> So you are not surprised to find out the truth about how you act?
> Good.
No, I am not surprised to see this thread degrade into your standard
drivel, as I have seen more times than I'd want to see.
> Yeah, sure, your behavior is my fault. That's the scary part,
> that you actually _believe_ that I have that much control over
> your life, that you are a marionette without the will-power to
> quit being counterproductive, and therefore have the most
> excellent reason to keep it up, and make it much worse. What is a
> moron, if not someone who behaves that way?
So now I can throw that back and say that every moron you have
encountered in your infinite fights here (which, I think, includes
pretty much everyone except those that you discourage from ever saying
anything), has received a very predictable reaction from you. In
other words, they have all been controlling you. If a moron is
someone that lets people control him like "a marionette without the
will-power to quit being counterproductive" then you are one of the
best examples of a moron in this NG and in any other.
> | Here's a good exercise in openness and tolerance: try to take your
> | post (or the previous one) and write the response that I should
> | write to satisfy you. (Resist your temptation to throw this back
> | to me, just try it.)
>
> Oh, that's very simple. Just produce a _thought_. Say something
> that _isn't_ yet more moronic flamebait. _You_ choose what _you_
> react to, and you get what you want. [...]
Oh, so I choose what to react to, and you claim that the only thing
that would satisfy you is that I get back on topic and not continue
this unproductive thread, right? (If not, then I'd really like to see
a reaction post that would make you happy).
So considering the fact that I'm a moron that continues to reply to
your posts why wouldn't _you_ stop being a moron that gives me an
excuse to continue? Why wouldn't _you_ choose what you react to? If
in the collective experience of this NG, which you know very well,
(almost) every person that you have labeled as a moron did not shut up
but rather went directly on the unproductive track that we're on now,
then why haven't _you_ learned to just shut up when you see such
morons and avoid the whole moron talk? On a technical level you are
definitely not a moron, as you always like to note about others
(separating what you react to, their posts, rather than themselves),
but by the definition of a moron as a NG-moron, someone who posts
off-topic drivel and make other people join him, overall spending
people's time on reading it instead of doing productive work, then by
this definition you, Erik Naggum, are the super meta-moron of c.l.l.
Thomas Francis Burdick
> (I think it is a disservice to students to give them only "free" tools.)
In the context of CL, you can't really mean that, can you? A student
sitting down to a unix workstation with Emacs, ILisp, and CMUCL all
properly configured hardly sounds disserved to me! (Emacs, g++, and gdb
on the other hand, was not a fun way to learn c++).
Joe Marshall
MIT Scheme, T, Stalin (of course), MzScheme, Bigloo, and others all
have file compilers.
The MIT Scheme compiler (the one I am most familiar with), produces
very good code when the right declarations are used.
Eli Barzilay
> * Eli Barzilay <e...@barzilay.org>
> | No, I am not surprised to see this thread degrade into your
> | standard drivel, as I have seen more times than I'd want to see.
>
> And your contributions are of course not of any relevance?
Sure they are, so your own definition of moronhood actually applies to
you whenever you use it. Nice to know.
> You know, that part, that you sick morons still think it's only my
> fault, still surprises me. How can you guys _possibly_ reach that
> conclusion? What kind of brain damage do you suffer from that
> causes you to think that you can go scot free from what _you_ do?
I could tell you again that I react to your posts in an obvious way,
and that way is obvious for enough people to make these episodes too
frequent, but I wouldn't since either you probably know that (at least
from past experience) or _you_ are insane, in both cases there is no
point.
> Or _are_ you criminally insane?
Since this is a legal term, and I can pretty much assume that if I
kill someone I will be found guilty for my actions, the answer is no.
> Because you're wrong. Most of the people who get a critical
> response get back on track.
Yes? So how come you can often see a huge Naggum/Other thread and
know what its content will look like?
> The real morons, including you, have to "win" first, [...]
I have to win? What do I have to win? You saying that you were wrong
and I was right? I don't think this will happen if only for the
reason that I have never said anything about something wrong or right.
I had a meta argument that you cannot say if it is wrong or right, so
what could I possibly win? This whole business of The Truth that you
so nicely claim did not exist is something that I used sarcastically.
> brain back in operation, [...] but you do, too, after a few weeks
> or months.
It's on track, thank you.
> Yet, you have to play your little games with me first, but I help
> identify your stupidity to yourself, and most of you guys realize
> it too late to make real use of it, but you come around,
> eventually. I'm not surprised that you pre-enlightened morons
> never see this. That's why you _stay_ morons and enjoy provoking
> me.
Yet you have to play your little games with us, but I help identify
your stupidity to yourself, and usually you realize it far too late to
make real use of it. I'm very surprised that you pre-enlightened
moron of all morons never see this. That's why you _stay_ moron of
morons and enjoy provoking the whole world.
> But talk more about yourself and your own reactions next time,
> will you? Oneself is the only person most of us know well enough
> to keep posting about for as long as some of you guys keep posting
> about me, and it shows: It isn't about me anymore after the first
> few stupid flames.
But you will talk again about yourself and your own reactions next
time, I'm sure. You seem to really know yourself well enough to keep
your drivel posts, and it shows: it isn't about anything after the
first few stupid flames, it's about Erik Naggum, spitting himself over
everyone's faces.
> Thanks for playing.
Actually, I wasn't playing now, I was running a Lisp program which
will finish soon. Time is not wated on this stupidity.
> You grab the last word, now.
Here I did.
Will Deakin
> Why do you assume I'm not here in the Dark Side already? It _is_
> possible to live in both places.
Ahhh but is it?
> Again - converting anyone was really not my goal.
...and talking about conversion I would refer you to Matthew 6:24...
;) will
Marco Antoniotti
Joe Marshall <j...@content-integrity.com> writes:
> MIT Scheme, T, Stalin (of course), MzScheme, Bigloo, and others all
> have file compilers.
>
> The MIT Scheme compiler (the one I am most familiar with), produces
> very good code when the right declarations are used.
Declarations?
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Yes. But on the Dark Side the work to do is less and more useful.
>
> I'm judging which side to use depending on the task I need. I could
> say that some things are better left for the other side but you
> probably wouldn't believe that and I avoid getting into these
> discussions. (At least I'm not going to the Perl side...)
Now, let's see what are the task you have at hand. When would you
choose *a* Scheme over Common Lisp and viceversa?
Eli Barzilay
> Now, let's see what are the task you have at hand. When would you
> choose *a* Scheme over Common Lisp and viceversa?
This will probably lead to an even worse discussion, so I'll avoid it.
Marco Antoniotti
Eli Barzilay <e...@barzilay.org> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Now, let's see what are the task you have at hand. When would you
> > choose *a* Scheme over Common Lisp and viceversa?
>
> This will probably lead to an even worse discussion, so I'll avoid it.
>
Come on, I am a nice guy :) What are the criteria by which you make the
choice? You should answer this question.
Christophe Rhodes
> Eli Barzilay <e...@barzilay.org> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > > Yes. But on the Dark Side the work to do is less and more useful.
> >
> > I'm judging which side to use depending on the task I need. I could
> > say that some things are better left for the other side but you
> > probably wouldn't believe that and I avoid getting into these
> > discussions. (At least I'm not going to the Perl side...)
>
> Now, let's see what are the task you have at hand. When would you
> choose *a* Scheme over Common Lisp and viceversa?
Ooo! Ooo! I can answer this one.
Consider the hobbyist programmer. Or consider the junior postgraduate
student who can't convince his group to shell out money for software
(OK, I haven't tried yet, I admit it). Then suppose there is a need
for a GUI.
Given these requirements, I would without a doubt choose DrScheme over
Common Lisp. There would no doubt be times when I would curse this
decision, probably firstly and foremostly because of the lack of
keyword arguments and the power this brings to things like FIND, but
at least I would be able to get the job done. And a programme written
with DrScheme at least has a chance of running on Unix, Windows,
MacOS, BeOS, and so on, if this is important (maybe for the hobbyist).
The alternative would be to write GUI bindings for one of the
freely-available Common Lisps. This would be possible for the
hobbyist, but not so much for the junior postgraduate physicist, I
fear. Getting the bindings to the state that they `feel' right within
CL is a hard task, as we discuss here periodically, and would without
doubt take quite a long time.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})")
Eli Barzilay
> Come on, I am a nice guy :) What are the criteria by which you make
> the choice? You should answer this question.
Oh well, since I'm deep in this anyway... These are my
considerations, personal ones - I am not saying for one second that
anyone else should follow them or not:
1. Big systems => Lisp
2. Performance => Lisp
3. Quick hacks and games => Scheme
4. Temporary hacks (code that you run very few times) => Emacs
5. Environment stuff (editing, mail, news, whatever) => Emacs
6. Script-like things => Scheme
7. Research ideas => Scheme
8. Research work => Lisp and some SML (our main system is in Lisp,
with ML (the one written in Lisp))
9. Other research work => OCaml (another system)
10. Portability => Scheme (MzScheme runs everywhere, even on Windows
and Macs, and we don't have Allegro for Windows)
11. Programs that I give other people => Scheme (since I can make a
small executable they can run)
12. Our cats starts singing French love songs => Perl (so I lied, not
even then).
Since I move a lot between the CL, ELisp and Scheme, I really
appreciate the good things in each one. The only exception is OCaml
(or SML) where I have learned to appreciate the advantages you get
from the type system, but after about two years of trying I am
convinced that there is no way I will ever like it more than I do now
(which is very little) but this is a different story.
BTW, the portability thing is interesting - our system can run on
different Lisp implementations, but we connected it with MzScheme for
a lightweight GUI front-end that can run everywhere (after an initial
attempt with TCL/TK (unrelated to me)).