My Scheme heartache
Gonzo
This is my first post to this group. I am not a troll and these are
all honest doubts and ruminations (it is a sad thing that this is
nowadays a necessary introduction). Also, apologies in advance for the
length of this post.
I love Lisp (as a generic programming philosophy, not a particular
implementation). I have known about Lisp since my college days
(roughly twenty years ago). It has never left my mind as a powerful,
cool and "mysterious" language. I remember I used to say that if I
ever had to participate in a contest about writing any kind of
"intelligent game", I would do it in Lisp, but I was never quite able
to answer the question "why".
I work at a company where all current development is conducted in Java
(and there is some COBOL kicking around). I have been doing Java for
about ten years, after a long stint at C++ programming. As with Lisp,
there was always in my mind a lingering question about Java: it didn't
quite cut it for me, but I couldn't really sit down and reason about
it convincingly.
Our productivity at work is not stellar, and this got me thinking
about the way we handle things. Due to recent surgery in my back, I
had a long time to ponder, and ponder I did. I ran into Paul Graham's
articles and realized I needed to take a look into Lisp again. Oh, I
also learned from Paul's articles the reason why Lisp was so high in
my appraisals: it sits at the top of the language pyramid. No doubts
about that.
So I have been reading a lot about Lisp, (re)learning much and finding
myself wondering about many things. I have tried to search for my own
answers but I decided that I need a little dialog at this point. Hence
my visit to this Usenet group. (Usenet was also part of my upbringing
way back when). Again, I really am not looking for any flame wars or
rants. From now on I will use more specific terms rather than "Lisp".
1. Scheme or CL? Personally, I automatically prefer "leaner and
simpler" than "comprehensive and complex" (perhaps my Java scars are
showing here). So I have chosen Scheme for my personal trail blazing;
as an implementation, PLT Scheme seems to be very good and thorough.
Anybody can comment on my two choices?
2. I am ready to really buy into the whole Scheme philosophy. I think
I have finally understood the power of continuations and am even more
convinced about the breadth of the language. But I also have no
illusions about the real world needs for the projects I have to
tackle. So I am wondering how I can use Scheme together with a lot of
third party libraries; I will just name a few from the top of my mind:
2.1 A generic interface to RDBMS systems, that will allow me to use
MySQL for development and SQLite / PostgreSQL for deployment
(switching between them effortlessly).
2.2 An MCV framework that allows me to easily use #2.1 to implement
the model but also provides facilities for the controller and view.
2.3 Support for AJAX in my controller.
2.4 Support for some kind of messaging; at least being able to send
and receive text/binary data over TCP/IP.
3. As an extension to question #2: where are the frameworks? What is
everyone using / contributing to, so that wheels are not reinvented?
What is the preferred way to develop a web application with an RDBMS
back-end? To develop a console application? To develop a traditional
GUI application? Can all this be done portably across operating
systems? Is this being done anywhere currently?
4. In an almost feverish state of mind, I have come to a rather
extreme conviction. Since Scheme is all powerful and sits above all
languages, it should allow me to write in Scheme EVERYTHING I need for
a project, and later generate code in any other language as needed.
For example, I picture a web application where I write in Scheme not
only my business logic, but also the queries to the DB (to generate
proper SQL according to the RDBMS I decide to use), the page
descriptions (using SXML to generate HTML), the behavior in those
pages (to generate Javascript and to support AJAX), the styling in
those pages (to generate CSS), the configuration in my application (to
generate XML / property files / INI files / whatever), the
documentation for the application (to generate... whatever), etc. In a
bold move, I have unified all development into a single, powerful
language that is (to me) a joy to use. The world is mine!
Am I crazy? Or does something like this already exist? Perhaps some of
the people who are reading this post may be thinking "oops, he's onto
us, he needs to be eliminated"... But don't you agree that, being
Scheme so powerful, you could use it as a super-language to program
all aspects of your application in?
I will shut up now, with the high hopes that somebody more
knowledgeable than I am (which is not a very tall call) will answer my
questions. Thanks to everyone who has read this far.
Andrew Reilly
I think that your questions are fairly representative of those of a large
fraction of experienced hands who try lisp or scheme at some stage. Not
too far from mine, for a time, so I'll briefly post my personal answers.
Your mileage will almost certainly vary (different problem domains, etc.)
On Thu, 02 Jul 2009 12:58:47 -0700, Gonzo wrote:
> 1. Scheme or CL? Personally, I automatically prefer "leaner and simpler"
> than "comprehensive and complex" (perhaps my Java scars are showing
> here). So I have chosen Scheme for my personal trail blazing; as an
> implementation, PLT Scheme seems to be very good and thorough. Anybody
> can comment on my two choices?
That's exactly how I went. I note, from reading c.l.l that there are
quite a few who started down exactly this path and subsequently switched
to Common Lisp, and don't regret the move, so I don't discount the
possibility that I'll go that way myself, eventually. On the other hand,
I don't believe that scheme can be considered a "toy" language in any
significant sense now, if that was ever an apt description, so perhaps I
won't.
> 2. I am ready to really buy into the whole Scheme philosophy. I think I
> have finally understood the power of continuations and am even more
> convinced about the breadth of the language. But I also have no
> illusions about the real world needs for the projects I have to tackle.
> So I am wondering how I can use Scheme together with a lot of third
> party libraries; I will just name a few from the top of my mind:
>
> 2.1 A generic interface to RDBMS systems, that will allow me to use
> MySQL for development and SQLite / PostgreSQL for deployment (switching
> between them effortlessly). 2.2 An MCV framework that allows me to
> easily use #2.1 to implement the model but also provides facilities for
> the controller and view. 2.3 Support for AJAX in my controller. 2.4
> Support for some kind of messaging; at least being able to send and
> receive text/binary data over TCP/IP.
My use of scheme has, so far, not required the use of any third-party
libraries, apart from those that are "natively" supplied with PLT (and
those are many.) In particular, PLT gives me all of the GUI, networking,
web/xml processing capabilities that I need, in the box. I don't do
databases, but I believe that many of the things that you're looking for
are available in the "PLaneT" repository, which is sort of like PLT's
CPAN. On the other hand, PLT and many other schemes have well-developed
FFI (foreign function interface) libraries, so it ought to be possible to
make what you need if you can't find it.
If, on the other hand, you find yourself intricately wedded to the Java
universe, there are several scheme variants (Kawa, bigloo for starters)
that run on/in the JVM, and can access java classes natively. Another
interesting recent entrant into the field is Clojure, which you might
want to investigate.
> 3. As an extension to question #2: where are the frameworks? What is
> everyone using / contributing to, so that wheels are not reinvented?
> What is the preferred way to develop a web application with an RDBMS
> back-end? To develop a console application? To develop a traditional GUI
> application? Can all this be done portably across operating systems? Is
> this being done anywhere currently?
There are several. Historically implementation-dependent, and so not
particularly portable. The R6RS movement is an attempt to allow greater
portability, and there are several code repositories (SNOW, SLIB) that
cater to multiple implementations. There are rumours of a new,
distributed repository scheme about to be introduced, too...
As I said for 2, I have found that PLT gives me what I need in the box,
so I haven't needed to play with these repositories yet, but I dare say
that I will should deployment issues or whatever prompt me to use one of
the other schemes.
> 4. In an almost feverish state of mind, I have come to a rather extreme
> conviction. Since Scheme is all powerful and sits above all languages,
> it should allow me to write in Scheme EVERYTHING I need for a project,
> and later generate code in any other language as needed. For example, I
> picture a web application where I write in Scheme not only my business
> logic, but also the queries to the DB (to generate proper SQL according
> to the RDBMS I decide to use), the page descriptions (using SXML to
> generate HTML), the behavior in those pages (to generate Javascript and
> to support AJAX), the styling in those pages (to generate CSS), the
> configuration in my application (to generate XML / property files / INI
> files / whatever), the documentation for the application (to generate...
> whatever), etc. In a bold move, I have unified all development into a
> single, powerful language that is (to me) a joy to use. The world is
> mine!
You might want to have a look at Hop, which seems to be the Manuel
Serrano's adventures in scheme->javascript inter-operation. There are
other such projects around, I think. The Hop demos are pretty
interesting, though.
> Am I crazy? Or does something like this already exist? Perhaps some of
> the people who are reading this post may be thinking "oops, he's onto
> us, he needs to be eliminated"... But don't you agree that, being Scheme
> so powerful, you could use it as a super-language to program all aspects
> of your application in?
Why not? Why worry about being crazy? Just have a go at doing some
small part of the things that you want to do, and see how it goes?
Having a good problem to solve is much more important than idly wondering
about the details ahead of time, IMO.
> I will shut up now, with the high hopes that somebody more knowledgeable
> than I am (which is not a very tall call) will answer my questions.
> Thanks to everyone who has read this far.
I'm by no means knowledgeable about the world of scheme. But I'm happy
with the way it's handled the things I've asked it to do so far, and
that's good enough to prompt me to reply to your message. Hope it helps.
Cheers,
--
Andrew
Pascal J. Bourguignon
> Hello everyone,
>
> This is my first post to this group. I am not a troll and these are
> all honest doubts and ruminations (it is a sad thing that this is
> nowadays a necessary introduction). Also, apologies in advance for the
> length of this post.
>
> I love Lisp (as a generic programming philosophy, not a particular
> implementation). I have known about Lisp since my college days
> (roughly twenty years ago). It has never left my mind as a powerful,
> cool and "mysterious" language. I remember I used to say that if I
> ever had to participate in a contest about writing any kind of
> "intelligent game", I would do it in Lisp, but I was never quite able
> to answer the question "why".
Have you read SICP?
Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
http://eli.thegreenplace.net/category/programming/lisp/sicp/
http://www.neilvandyke.org/sicp-plt/
I would say it answers nicely the question "why".
--
__Pascal Bourguignon__
Gonzo
Hi Andrew, thanks for responding. A few comments:
> That's exactly how I went. I note, from reading c.l.l that there are
> quite a few who started down exactly this path and subsequently switched
> to Common Lisp, and don't regret the move, so I don't discount the
> possibility that I'll go that way myself, eventually. On the other hand,
> I don't believe that scheme can be considered a "toy" language in any
> significant sense now, if that was ever an apt description, so perhaps I
> won't.
I don't discount ever moving to CL, but at this point it certainly
looks like, with Scheme, I can have my cake and eat it too.
> My use of scheme has, so far, not required the use of any third-party
> libraries, apart from those that are "natively" supplied with PLT (and
> those are many.) In particular, PLT gives me all of the GUI, networking,
> web/xml processing capabilities that I need, in the box. I don't do
> databases, but I believe that many of the things that you're looking for
> are available in the "PLaneT" repository, which is sort of like PLT's
> CPAN. On the other hand, PLT and many other schemes have well-developed
> FFI (foreign function interface) libraries, so it ought to be possible to
> make what you need if you can't find it.
OK, so PLT seems to be a good choice. Thanks for the encouragement.
> If, on the other hand, you find yourself intricately wedded to the Java
> universe, there are several scheme variants (Kawa, bigloo for starters)
> that run on/in the JVM, and can access java classes natively. Another
> interesting recent entrant into the field is Clojure, which you might
> want to investigate.
I don't really want to stick close to the Java world. I did read on
Clojure but it didn't look as clean as Scheme.
> > 3. As an extension to question #2: where are the frameworks?
>
> There are several. Historically implementation-dependent, and so not
> particularly portable. The R6RS movement is an attempt to allow greater
> portability, and there are several code repositories (SNOW, SLIB) that
> cater to multiple implementations. There are rumours of a new,
> distributed repository scheme about to be introduced, too...
Could you provide more details about SNOW, SLIB and this mysterious
Scheme repository?
> You might want to have a look at Hop, which seems to be the Manuel
> Serrano's adventures in scheme->javascript inter-operation. There are
> other such projects around, I think. The Hop demos are pretty
> interesting, though.
OK, thanks for the pointer, I will look into Hop.
> Why not? Why worry about being crazy? Just have a go at doing some
> small part of the things that you want to do, and see how it goes?
> Having a good problem to solve is much more important than idly wondering
> about the details ahead of time, IMO.
I don't really think I am crazy... ;-) I just wanted to elicit some
comments about this idea; Scheme being the powerful language that it
is, I would find it hard to believe nobody has thought along the same
lines before.
> I'm by no means knowledgeable about the world of scheme. But I'm happy
> with the way it's handled the things I've asked it to do so far, and
> that's good enough to prompt me to reply to your message. Hope it helps.
Experience is what I was after. Thanks for sharing it.
> Andrew
Gonzo
Gonzo
> Have you read SICP?
>
> Structure and Interpretation of Computer Programs
> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
> http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
> http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_...
> http://eli.thegreenplace.net/category/programming/lisp/sicp/
> http://www.neilvandyke.org/sicp-plt/
I did read the whole book, but that was during a previous incarnation
(maybe 15 years ago)... It took me to the point where I would say
"Lisp (Scheme) is a really great language" without allowing me to put
my finger on the "why".
> I would say it answers nicely the question "why".
The "why" is answered now, it is what made me post to begin with.
Right now I am going over a couple of other Scheme books (and some
tenths of papers), but I do intend to re-read SICP. In fact, I own a
really nice 1st edition hardcover which I love to handle.
> __Pascal Bourguignon__
Gonzo
Gonzo
> tenths of papers), but I do intend to re-read SICP. In fact, I own a
> really nice 1st edition hardcover which I love to handle.
Of course, I meant "tens of papers"... I do read them thoroughly!
Aaron W. Hsu
wrote:
> this mysterious Scheme repository?
Let me shed some light on the "soon to be introduced" distributed
repository scheme. It is called Descot (Decentralized Scheme Code
Tracker), and it is designed to permit the sharing and transmission of
code and library metadata between systems in a language and implementation
independent way. It has a few goals that are further out on the timeline,
but the first goal is to make it easier to find, grab, and use libraries
within a dispersed community like Scheme where code could be sitting
anywhere (not just in a CPAN archive), and may be available for many
implementation. It is currently in Alpha status, while I try to get all
the features written and published in an useful manner. That won't help
you much right now, since no one is currently using it, but later, when
you write your own code, or when other repositories start using
Descot-compatible interfaces, it will make it possible for you to more
easily publish and find libraries within the community, and hopefully
reduce the redundancy of re-implementation that can happen quite easily
right now.
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
Aaron W. Hsu
wrote:
> nice 1st edition hardcover which I love to handle
The second edition has a number of updates that you should examine.
Gonzo
I was afraid someone would say that... Isn't the second edition around
$100? Bugger!
Aaron W. Hsu
wrote:
> Isn't the second edition around
> $100? Bugger!
It is also freely available online. So, you can keep your comfortable book
form for the one, and read the online one, or, as I would prefer, print
them out -- it is so much easier on the eyes. On the other hand, you can
usually find the book cheaply (thought not that cheaply) somewhere.
Michele Simionato
users.org> wrote:
> If, on the other hand, you find yourself intricately wedded to the Java
> universe, there are several scheme variants (Kawa, bigloo for starters)
> that run on/in the JVM, and can access java classes natively. Another
> interesting recent entrant into the field is Clojure, which you might
> want to investigate.
I second that. Clojure seems to be perfect for your use case.
Apparently it
has an extremely active community (the newsgroup has already more
subscribers
than comp.lang.scheme) and a lot of potential for becoming the most
popular
Lisp ever (actually I think it will).
As soon as I find the time I will try to write a real life project
(which means database and web programming) with it, to see how it
fares in
practice. I have not done that yet, simply because I am totally
ignorant about
Java. You do not have that handicap, though.
Michele Simionato
Benjamin L. Russell
<gonzalo....@gmail.com> wrote:
>[...]
>
>1. Scheme or CL? Personally, I automatically prefer "leaner and
>simpler" than "comprehensive and complex" (perhaps my Java scars are
>showing here). So I have chosen Scheme for my personal trail blazing;
>as an implementation, PLT Scheme seems to be very good and thorough.
>Anybody can comment on my two choices?
These are not the only two viable options in Lisp-land. As Andrew
Reilly and Michele Simionato have also suggested, Clojure (see
http://clojure.org/) also seems to be a good choice for creating an
application. Clojure is a Lisp-1 dialect of Lisp with a functional
approach to programming, for which an Emacs SLIME-based development
environment called "Clojure Box" (http://clojure.bighugh.com/) is
available.
Personally, I actually prefer the IDE of Clojure to that of PLT Scheme
(see http://plt-scheme.org/) (DrScheme). Although DrScheme has an
excellent debugger and support for multiple sub-languages of Scheme (a
pedagogically very useful feature), it does not offer all the editing
conveniences of Emacs, and certain users have experienced bugs in
using DrScheme on certain other OS's.
In particular, DrScheme exhibits certain bugs when running on certain
other-language versions of Windows XP, such as the Japanese version of
Windows XP Professional, Service Packs 2 and 3, in which it the
DrScheme file explorer therein intermittently hangs for about 5
seconds every 10 seconds or so. (I have described this bug in detail,
and even submitted a trace obtained using StraceNT, to Eli Barzilay of
PLT [1] (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033638.html),
who replied that he would forward the information to "Matthew"
(presumably Matthew Flatt) [2] (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033644.html),
but as of June 18, I hadn't heard back from Eli, and since then, I
have tentively switched over to Gauche Scheme (see
http://practical-scheme.net/gauche/index.html), which is an R5RS
scripting implementation of Scheme with good Unicode support, because
of this bug.) When I discussed this bug on the plt-scheme mailing
list, Eli replied, in part, as follows [3] (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033639.html):
>Unfortunately, we are far from having the kind of resources for
>testing and/or debugging problems that are specific to an OS/language.
>In the department of "exotic languages" there are active people on the
>group who might use German, Thai, Chinese, and Hebrew -- yet I don't
>believe that anyone have seen the problem you're talking about. (I'm
>saying "might" because even if I'm in Israel, I'm likely to use
>machines that have an English OS installed, since many developers
>prefer it.)
(My job requires me to work with the Japanese version of Windows XP,
Service Pack 2 or 3, so I have no choice in which OS to use at work,
and therefore hardly consider my language-version "exotic"; however,
your mileage may vary.)
If you're not going to be using DrScheme with an "exotic"-language
version of Windows XP, then you should be fine; this problem
apparently only manifests itself on the Japanese version of Windows
XP. (Just don't use any of the other "exotic"-language variants of
Windows XP mentioned above with DrScheme.)
Clojure Box, on the other hand, works fine on my OS, and reportedly
has good Unicode support as well (although, to give fair credit, PLT
Scheme also has Unicode support (although this is not the same as
universal-language support)).
Just to be fair, PLT Scheme does have certain advantages over Clojure.
In particular, Clojure lacks support for first-class continuations and
tail-call optimization (see "Clojure from SICP? Good idea? - Clojure"
[4], dated "Wed, 26 Mar 2008 07:53:05 -0700 (PDT)," by Rich Hickey at
http://groups.google.com/group/clojure/msg/be43ec191cd69869), and so
cannot be considered truly a proper "Scheme"; it is, as described
above, rather, a Scheme-like Lisp-1 dialect of Lisp based on the JVM
with good library support (again, to give fair credit, PLT Scheme also
has fairly good library support) and Unicode support. Also, although
the Clojure mailing list is friendly and helpful, it is
application-focused, and so does not focus so much as the plt-scheme
mailing list on theoretical and pedagogical topics.
In short, in choosing between PLT Scheme and Clojure, to summarize:
1. PLT Scheme:
Advantages:
* supports first-class continuations and tail-call
optimization
* has Unicode support
* has relatively good library support
* supports various sub-languages of Scheme, each with its
own separate set of features
* has an active mailing list with significant discussion of
pedagogical and some theoretical issues in addition to application
development-oriented issues
Disadvantages:
* DrScheme does not always run bug-free in non-English
versions of Windows XP Professional, Service Packs 2 and 3
* some members of PLT consider certain non-English languages
to be "exotic languages," and apparently lack resources for
testing/debugging issues specific to such "exotic languages"
See the paper "The Structure and Interpretation of the Computer
Science Curriculum" [5], by Matthias Felleisen, Robert Bruce Findler,
Matthew Flatt, and Shriram Krishnamurthi (see
http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/),
for a description of the design philosophy behind the book _How to
Design Programs_ (see http://www.htdp.org/), which uses PLT Scheme.
2. Clojure:
Advantages:
* can be developed in Clojure Box, an Emacs SLIME-based IDE
* because it runs on the JVM, applications developed using
it can be platform-independent
* compiles directly to JVM bytecode, yet is completely
dynamic
* provides easy access to Java frameworks
* has Unicode support
* has relatively good library support
* has a mailing list focusing on application development
* (at least to my knowledge) is relatively polished,
bug-free, and easy to use
Disadvantages:
* lacks support for first-class continuations and tail-call
optimization
* lacks direct support for mutual recursion, instead using
trampolines (see "Clojure - api: [definition of] (trampoline f),
(trampoline f & args)" [6] at http://clojure.org/api#trampoline),
which, if a function is to be returned as a final value, require
wrapping the function in a data structure and unpacking it after the
trampoline returns
* is not a proper Scheme, but rather a Scheme-like Lisp-1
dialect based on the JVM
* mailing list thereof does not focus much on theoretical
and pedagogical topics (is application-development-focused)
Again, you may wish to refer to the above-mentioned post "Clojure from
SICP? Good idea? - Clojure" [4] (see
http://groups.google.com/group/clojure/msg/be43ec191cd69869) on
Clojure's approach to "atomic programming" a la SICP (see
http://mitpress.mit.edu/sicp/) (which he apparently discounts).
>2. I am ready to really buy into the whole Scheme philosophy. I think
>I have finally understood the power of continuations and am even more
>convinced about the breadth of the language.
Congratulations! Just for reference, I should probably give credit to
one book [7] which explained continuations relatively clearly for me:
Programming Languages: Application and Interpretation
by Shriram Krishnamurthi
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/
In particular, Part VII: Continuations of the above-mentioned title
described the use of continuations in preserving information across
multiple interactions in a stateless protocol used on the Web: HTTP.
-- Benjamin L. Russell
References
[1] Russell, Benjamin L. "[plt-scheme] some progress in identifying
cause of DrScheme file explorer intermittent freezing problem on
Japanese version of Windows XP Pro, Service Pack 3." The plt-scheme
Archives. Brown University. 4 June 2009. 3 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033638.html>.
[2] Barzilay, Eli. "[plt-scheme] Re: some progress in identifying
cause of DrScheme file explorer intermittent freezing problem on
Japanese version of Windows XP Pro, Service Pack 3." The plt-scheme
Archives. Brown University. 4 June 2009. 03 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033644.html>.
[3] Barzilay, Eli. "[plt-scheme] some progress in identifying cause of
DrScheme file explorer intermittent freezing problem on Japanese
version of Windows XP Pro, Service Pack 3." The plt-scheme Archives.
Brown University. 4 June 2009. 3 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033639.html>.
[4] Hickey, Rich. "Re: Clojure from SICP? Good idea?." Clojure Google
Group. Google Groups. 26 March 2008. 3 July 2009.
<http://groups.google.com/group/clojure/msg/be43ec191cd69869>.
[5] Felleisen, Matthias, Findler, Robert Bruce, Flatt, Matthew, and
Krishnamurthi, Shriram. "The Structure and Interpretation of the
Computer Science Curriculum." Cambridge: _Journal of Functional
Programming_ 14:4 (2004): 365-378.
<http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/>.
[6] Hickey, Rich. "Clojure - api: [definition of] (trampoline f),
(trampoline f & args)." Clojure - home. 2009. 3 July 2009.
<http://clojure.org/api#trampoline>.
[7] Krishnamurthi, Shriram. _Programming Languages: Application and
Interpretation._ Shriram Krishnamurthi, 2003.
<http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/>.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Michele Simionato
wrote:
> In particular, DrScheme exhibits certain bugs when running on certain
> other-language versions of Windows XP, such as the Japanese version of
> have tentively switched over to Gauche Scheme (seehttp://practical-scheme.net/gauche/index.html)
I fail to see the cause-effect relation. Even if DrScheme does not
work in the Japanese
version of XP you are using, you can always use mzscheme with Emacs:
there is not point
in switching to another Scheme implementation, unless you want to use
Gauche for some other reason. The emacs mode quack.el has even
specific features to interact with PLT.
M.S.
Pascal Costanza
> Hi there,
>
> I think that your questions are fairly representative of those of a large
> fraction of experienced hands who try lisp or scheme at some stage. Not
> too far from mine, for a time, so I'll briefly post my personal answers.
> Your mileage will almost certainly vary (different problem domains, etc.)
>
> On Thu, 02 Jul 2009 12:58:47 -0700, Gonzo wrote:
>> 1. Scheme or CL? Personally, I automatically prefer "leaner and simpler"
>> than "comprehensive and complex" (perhaps my Java scars are showing
>> here). So I have chosen Scheme for my personal trail blazing; as an
>> implementation, PLT Scheme seems to be very good and thorough. Anybody
>> can comment on my two choices?
>
> That's exactly how I went. I note, from reading c.l.l that there are
> quite a few who started down exactly this path and subsequently switched
> to Common Lisp, and don't regret the move, so I don't discount the
> possibility that I'll go that way myself, eventually. On the other hand,
> I don't believe that scheme can be considered a "toy" language in any
> significant sense now, if that was ever an apt description, so perhaps I
> won't.
I think it's important to look at both Scheme and Common Lisp. Lisp is
indeed not so much a language, but rather a family of principles for
designing languages, and it's important, IMHO, to have an idea of the
design space of Lisp. Scheme and Common Lisp can be regarded as
representatives of two different local optima in that design space, and
together they give you a good idea what the possibilities are. Although
the coverage of the design space is certainly far from complete by then,
it also certainly gives you a good starting point to then also look at
other Lisp dialects (like Dylan, ISLISP, Arc, Clojure, etc., etc.). Even
if you eventually choose to stick with Scheme, you then better know why.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza
> On Jul 2, 11:29 pm, Andrew Reilly <andrew-newsp...@areilly.bpc-
> users.org> wrote:
>> If, on the other hand, you find yourself intricately wedded to the Java
>> universe, there are several scheme variants (Kawa, bigloo for starters)
>> that run on/in the JVM, and can access java classes natively. Another
>> interesting recent entrant into the field is Clojure, which you might
>> want to investigate.
>
> I second that. Clojure seems to be perfect for your use case.
> Apparently it has an extremely active community (the newsgroup has
> already more subscribers than comp.lang.scheme) and a lot of
> potential for becoming the most popular Lisp ever (actually I think
> it will).
Note, though, that the size of a user community is far less important
for Lisp dialects than for other languages, because with Lisp/Scheme,
it's a lot easier to get off the ground than with other languages. In
other words, you shouldn't base your decision what Lisp dialect you
choose based on criteria you developed for other, less powerful languages.
Grant Rettke
wrote:
> I second that. Clojure seems to be perfect for your use case.
> Apparently it
> has an extremely active community (the newsgroup has already more
> subscribers
> than comp.lang.scheme)
How does that make it better for the OP?
Grant Rettke
> Two years back I found myself in the same situation. I needed a Scheme
> that I can use in my daily work, with built-in support for GUIs,
> networking, GUI and ability to talk to ODBC compliant databases. I
> extended and molded MzScheme into just that. You can find my Scheme
> distribution here:http://spark-scheme.wikispot.org/. Probably Gonzo
> will find it useful!
Just wondering, why didn't you use PLT for that, or if it didn't have
the features, just add them?
Grant Rettke
> and certain users have experienced bugs in
> using DrScheme on certain other OS's.
mzscheme can still be used, with EMACS as an editor perhaps.
Eli Barzilay
> Personally, I actually prefer the IDE of Clojure to that of PLT
> Scheme (see http://plt-scheme.org/) (DrScheme). Although DrScheme
> has an excellent debugger and support for multiple sub-languages of
> Scheme (a pedagogically very useful feature), it does not offer all
> the editing conveniences of Emacs, and certain users have
> experienced bugs in using DrScheme on certain other OS's.
Just to put things straight and in perspective, the bug that Benjamin
is talking about is one that *only* *he* has reported.
> In particular, DrScheme exhibits certain bugs when running on
> certain other-language versions of Windows XP, such as the Japanese
> version of Windows XP Professional, Service Packs 2 and 3, [...]
And if you look at the thread that Benjamin referred to, you'll see
that the problem is related to slow memory access. For all I know,
the problem might be specific to his computer or his set of installed
drivers, or in some Japanese version of a Windows driver. (Note: the
problem happens when DrScheme opens a file dialog, something that is
actually done by the OS.)
> (My job requires me to work with the Japanese version of Windows XP,
> Service Pack 2 or 3, so I have no choice in which OS to use at work,
> and therefore hardly consider my language-version "exotic"; however,
> your mileage may vary.)
> [...]
> * some members of PLT consider certain non-English
> languages to be "exotic languages," and apparently lack resources
> for testing/debugging issues specific to such "exotic languages"
My use of "exotic" was in absolutely no way negative in any way, which
is why I put it in scare-quotes. When I speak it, I obviously don't
consider Hebrew to be exotic; but if I want DrScheme to run on Hebrew
OSs, with all translations and with right-to-left editing, then I
would need to either do the work myself, or find people who are
willing to help me. Given that there are much less people who I'll be
able to find, and given the related fact that much less people want
this to happen, Hebrew is much more "exotic" than English. (The
choice of "exotic" might have confused you, being an "exotic language"
speaker, I tend to make such mistakes.)
> Just to be fair, PLT Scheme does have certain advantages over
> Clojure. In particular, Clojure lacks support for first-class
> continuations and tail-call optimization [...], and so cannot be
> considered truly a proper "Scheme"; [...]
This kind of comparison that lumps together very high-level language
feature, very low-level bugs, and "social features" is bogus.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Michele Simionato
Bigger community == more libraries. Also the OP had a Java background
and (apparently) an enterprise mindset. Clojure seems to be more
enterprise-oriented than PLT. That could be a plus or a minus
depending on what one wants.
Pascal Costanza
What does that mean that something is "more enterprise-oriented" than
something else?!?
Aaron W. Hsu
<michele....@gmail.com> wrote:
> Bigger community == more libraries. Also the OP had a Java background
> and (apparently) an enterprise mindset. Clojure seems to be more
> enterprise-oriented than PLT. That could be a plus or a minus
> depending on what one wants.
Clojure also lacks maturity, stability, long standing methods of
operation, and doesn't have some of the features Schemers have come to
expect. It is largely functional programming oriented, rather than
paradigm flexible.
I do not mean that Clojure is not something that someone may find
interesting, but if one wishes to look at enterprise solutions (where
stability matters), I wouldn't invest my money into Clojure at the moment.
There are a number of Scheme solutions out there, each with their
strengths, and porting between them isn't so hard that if one doesn't work
out the way the OP wants, he can't move to another, and there is at least
one Scheme which provides superb standards support and strong commercial
end-user support.
As for libraries, PLT certainly has a lot, and there is a lot of Scheme
code floating out there. Chicken also has a good set of libraries, there
are the SRFIs, and other Schemes have bindings for all manner of
applications as well. Some initial effort may be required to port them to
other systems, but my point is that you have choice, and lots of it, and
if you want enterprise level stability and support, you can get it in
Scheme.
Others define enterprise differenlty than I do, so if those definitions
match more closely to Clojure, well then, by all means, use the right tool
for the right job. I'm not sure that the above statements lead to a
Clojure conclusion, however.
Gonzo
> Hi everyone,
>
> Two years back I found myself in the same situation. I needed a Scheme
> that I can use in my daily work, with built-in support for GUIs,
> networking, GUI and ability to talk to ODBC compliant databases. I
> extended and molded MzScheme into just that. You can find my Scheme
> distribution here:http://spark-scheme.wikispot.org/. Probably Gonzo
> will find it useful!
>
>
> -- Vijay
Thanks for the information, I will take a look at it. How is Spark
different from, say, PLT?
Gonzo
> Disadvantages:
> * lacks support for first-class continuations and tail-call
> optimization
> * lacks direct support for mutual recursion, instead using
> trampolines
Thanks for the information. I did read on Clojure, but the lack of
first-class continuations (now that I really understand them) is a
deal breaker for me.
> >2. I am ready to really buy into the whole Scheme philosophy. I think
> >I have finally understood the power of continuations and am even more
> >convinced about the breadth of the language.
>
> Congratulations!
Thanks! It wasn't easy to wrap my mind around them.
> Just for reference, I should probably give credit to
> one book [7] which explained continuations relatively clearly for me:
>
> Programming Languages: Application and Interpretation
> by Shriram Krishnamurthihttp://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-04-26/
>
> In particular, Part VII: Continuations of the above-mentioned title
> described the use of continuations in preserving information across
> multiple interactions in a stateless protocol used on the Web: HTTP.
I'll make sure I check that reference.
Gonzo
Thanks for your reply. If it were possible (and this doesn't unleash a
holy war), could you summarize a few advantages I might find in CL
over Scheme?
Gonzo
> > and (apparently) an enterprise mindset. Clojure seems to be more
> > enterprise-oriented than PLT. That could be a plus or a minus
> > depending on what one wants.
>
> What does that mean that something is "more enterprise-oriented" than
> something else?!?
I guess this refers to my questions about support for libraries (RDBMS
access, AJAX, etc.) and frameworks (Web applications, GUI
applications, etc.). I can see how Clojure could be perceived as
closer to fitting those requirements, because of its capabilities to
mesh with Java. But I do not want to compromise my decision of going
with Scheme (and all it entails, such as continuations) to favor
library abundance. Of course, this is only MY opinion on this issue.
Gonzo
> operation, and doesn't have some of the features Schemers have come to
> expect. It is largely functional programming oriented, rather than
> paradigm flexible.
This, as I said, is a deal breaker for me (in reference to Clojure's
lack of support for continuations).
> There are a number of Scheme solutions out there, each with their
> strengths, and porting between them isn't so hard that if one doesn't work
> out the way the OP wants, he can't move to another, and there is at least
> one Scheme which provides superb standards support and strong commercial
> end-user support.
Which Scheme would this be?
Aaron W. Hsu
wrote:
> Thanks! It wasn't easy to wrap my mind around [continuations].
I always find it funny that other people don't think they are useful for
general programming.
Aaron W. Hsu
wrote:
> Thanks for your reply. If it were possible (and this doesn't unleash a
> holy war), could you summarize a few advantages I might find in CL
> over Scheme?
Unfortunately, I don't think one can really list the advantages and
disadvantages *as* advantages or disadvantages without starting a holy
war. They're different. Whether those differences constitute advantages
for one and disadvantages for the other is up for grabs.
Gonzo
>
> I always find it funny that other people don't think they are useful for
> general programming.
I totally agree. The examples on web application development using
continuations (just to mention one real world case) are mind blowing.
Gonzo
> > holy war), could you summarize a few advantages I might find in CL
> > over Scheme?
>
> Unfortunately, I don't think one can really list the advantages and
> disadvantages *as* advantages or disadvantages without starting a holy
> war. They're different. Whether those differences constitute advantages
> for one and disadvantages for the other is up for grabs.
I agree. We best leave this thread as it is, with the civil tone it
has had until now.
Aaron W. Hsu
wrote:
> I guess this refers to my questions about support for libraries (RDBMS
> access, AJAX, etc.) and frameworks (Web applications, GUI
> applications, etc.). I can see how Clojure could be perceived as
> closer to fitting those requirements, because of its capabilities to
> mesh with Java. But I do not want to compromise my decision of going
> with Scheme (and all it entails, such as continuations) to favor
> library abundance. Of course, this is only MY opinion on this issue.
If you are interested in lots of libraries, make sure you know about the
SRFIs, PLT's PLaneT, Chicken's Eggs, and keep in touch with the Scheme
community as a whole to make sure you know what other libraries are out
there.
I find that if you choose the Scheme you most like for its core values,
you can get lot's of other libraries over to that Scheme if you so choose.
Sometimes it takes a little extra work, though. For example, I converted
over S-expression based SQL libraries from PLT to Chez, but it wasn't the
easiest port I have ever done. If not having ready access to a complete
set of libraries without doing a little porting work (minor or major), you
are probably well off with Chicken or PLT (though I am sure there are some
others).
As for the libraries you mentioned here:
RDBMS -- You'll find many bigger Schemes (MIT, Chicken, PLT, Chez, &c.)
have RDBMS interfaces.
AJAX -- You can find portable code for converting S-expressions to JSON
pretty easily, and the rest is just a little server side scripting in your
Web Framework of choice. Magic has a JSON thing, and there are others.
Web Framework -- Magic, Mod_lisp, http servers, servlets, ... take your
pick. I use mod_lisp, and there are librarise for a few Schemes that work
with it. It has the benefit of being remarkably easy to implement if you
ever need to go to another Scheme for some reason, or another language.
GUIs -- I use GUI Editors to generate C Stub files which I link in with
Chez Scheme, but PLT has a GUI framework, and Java Based Schemes can
interact with Java toolkits. I think there are also some Xlib bindings
around among others. It shouldn't be too hard to make bindings for other
lightweight toolkits either.
Aaron W. Hsu
wrote:
>> There are a number of Scheme solutions out there, each with their
>> strengths, and porting between them isn't so hard that if one doesn't
>> work out the way the OP wants, he can't move to another, and there is
>> at least one Scheme which provides superb standards support and strong
>> commercial end-user support.
>Which Scheme would this be?
Chez Scheme is one of the few commercial Scheme implementations. It
provides support contracts, site licenses, and so forth. It is also very
good about supporting the standards (I think R6RS support is not too far
away), but it also doesn't pack a huge built-in library repository from
which to draw automatically. I maintain a set of libraries that I use for
web programming and I try to make them generally usable for other
Schemers. I'm in the process of reworking them (in coordination with my
Descot endeavor), but if you would like more details, please let me know.
There is also Wraith Scheme, but as I understand it, that is more of a
Shareware program without a specific support contract going for it.
On the other hand, there is something to be said for community support,
and there are many other Schemes that have substantial user-base support
through mailing lists and the like.
Gonzo
reply to my original post.
> 4. In an almost feverish state of mind, I have come to a rather
> extreme conviction. Since Scheme is all powerful and sits above all
> languages, it should allow me to write in Scheme EVERYTHING I need for
> a project, and later generate code in any other language as needed.
> For example, I picture a web application where I write in Scheme not
> only my business logic, but also the queries to the DB (to generate
> proper SQL according to the RDBMS I decide to use), the page
> descriptions (using SXML to generate HTML), the behavior in those
> pages (to generate Javascript and to support AJAX), the styling in
> those pages (to generate CSS), the configuration in my application (to
> generate XML / property files / INI files / whatever), the
> documentation for the application (to generate... whatever), etc. In a
> bold move, I have unified all development into a single, powerful
> language that is (to me) a joy to use. The world is mine!
I have been thinking more about this. SXML shows how easily you can,
bidirectionally, turn XML into Scheme. And since XML has been used and
abused beyond belief, I am pretty sure mostly anything you wish to
represent (SQL queries, configuration files, source code, you name it)
can be (and, unluckily, has been) represented as XML. Therefore, it is
clear that you could also represent all of those things as Scheme
code, right?
So in my master plan (and best Dr. Evil impersonation) I envision a
web application stored in a directory structure were every single
thing is ultimately Scheme code. The application server could piece
everything together dynamically after receiving a request, even
detecting when it would become necessary to regenerate something
because the Scheme source has been updated. The directory structure
could be fashioned after a well-designed web framework, so that you
could piece your HTML pages together from small Scheme templates or
pieces. The business logic could access data in RDBMSs without
concerns about SQL dialects, because the queries would be internally
represented in a single "language" that could generate proper SQL
according to the specific DB. Etc.
> Am I crazy? Or does something like this already exist? Perhaps some of
> the people who are reading this post may be thinking "oops, he's onto
> us, he needs to be eliminated"... But don't you agree that, being
> Scheme so powerful, you could use it as a super-language to program
> all aspects of your application in?
Come on, someone here become a traitor and spill the beans! Where can
I find such a beast? What great web sites exist today that use this
wonderful technology?
Wait a minute; perhaps this is Paul Graham's best kept secret? Does he
frequent this newsgroup?
I'll calm down now. Thanks and best regards.
Aaron W. Hsu
wrote:
> I have been thinking more about this. SXML shows how easily you can,
> bidirectionally, turn XML into Scheme. And since XML has been used and
> abused beyond belief, I am pretty sure mostly anything you wish to
> represent (SQL queries, configuration files, source code, you name it)
> can be (and, unluckily, has been) represented as XML. Therefore, it is
> clear that you could also represent all of those things as Scheme
> code, right?
Yes, but the question remains, should you?
> So in my master plan (and best Dr. Evil impersonation) I envision a
> web application stored in a directory structure were every single
> thing is ultimately Scheme code. The application server could piece
> everything together dynamically after receiving a request, even
> detecting when it would become necessary to regenerate something
> because the Scheme source has been updated. The directory structure
> could be fashioned after a well-designed web framework, so that you
> could piece your HTML pages together from small Scheme templates or
> pieces. The business logic could access data in RDBMSs without
> concerns about SQL dialects, because the queries would be internally
> represented in a single "language" that could generate proper SQL
> according to the specific DB. Etc.
I actually do something like this already. The idea of serving pages
dynamically using this sort of thing has been done by some others as well,
where their pages are just SXML and they are loaded into a specific
sandbox for evaluation. It's really not hard to do, and doesn't require
anything special.
However, there are a few things that might make you stop to think.
Firstly, do you really want to have code sitting all over the place to be
run? Maybe. Do you really want data to be represented as code? Maybe.
However, if it is likely that you will parse external data sources, you
might rather want to use s-expressions or some other syntax and create a
minimal parser for handling this data, rather than to evaluate the data
directly. This is what I do for my RDF based Descot Repostory protocol
implementation. Sometimes it is better to represent you data in the
application using meaningful disjoint datatypes like xml-element and the
like, as you can get more reliable checking built-in.
SQL has been S-expressionized, but I don't see much movement on the effort
lately. I ported this code to Chez Scheme a while ago, but I didn't have
the opportunity to really put it through its paces.
My web application (implementing Descot specificed features) uses a file
hierarchy at the moment to store information about library metadata. The
data can be stored in an s-expression based format which is then trivially
loaded and parsed into an record based RDF datatype. I can then perform
operations on this store. Incoming requests are served from Apache to a
Scheme server over the mod_lisp protocol, where the Scheme system grabs
the appropriate data and returns it after the data has been massaged into
the correct output format.
If you use something like mod_lisp you may want to have your dynamic pages
spread out in the relative hierarchy in which you want them served. Then,
you can walk this hierarchy and use the paths at which a particular file
is found to bind the page generator therein to a specific URL. It would
the be easy to track time stamps on the pages and reload whenever
necessary.
Peter Keller
> What does that mean that something is "more enterprise-oriented" than
> something else?!?
It means someone actually wrote the code to check for error conditions.
If you log the error, it moves you up to "enterprise ready".
If you actually do behavior based upon the error you get the the rarified
echelon of "enterprise class".
You think I'm kidding?
Later,
-pete
Nick Keighley
> Michele Simionato wrote:
> > Bigger community == more libraries. Also the OP had a Java background
> > and (apparently) an enterprise mindset. Clojure seems to be more
> > enterprise-oriented than PLT. That could be a plus or a minus
> > depending on what one wants.
>
> What does that mean that something is "more enterprise-oriented" than
> something else?!?
bigger marketing budget
Grant Rettke
wrote:
Some corporate entity about which you can say "Nobody ever go fired
for choosing <said entity>"?
Grant Rettke
> Come on, someone here become a traitor and spill the beans! Where can
> I find such a beast? What great web sites exist today that use this
> wonderful technology?
You can do anything with Scheme.
You should try out whatever you like and see what works the best, and
also what you might learn and enjoy. Then decide how much you want to
invest.
You might find that a mix of Scheme, XML, and C work best for you,
too.
Do what works for you. That is the spirit of Scheme.
Pascal Costanza
Clojure is not the only Lisp dialect/implementation that meshes well
with Java. There are a couple of Scheme implementations running on the
JVM, and there is a CL implementation running on the JVM as well
(although I have the impression that the Scheme implementations are more
mature in that regard). Furthermore, there are options to have Common
Lisp implementations interoperate with a JVM without having them run on
the JVM, typically for the commercial CL implementations (like Allegro
Common Lisp and LispWorks). I don't know enough about Scheme support in
that regard.
Pascal Costanza
> On Fri, 03 Jul 2009 18:05:23 -0400, Gonzo <gonzalo....@gmail.com>
> wrote:
>
>> Thanks for your reply. If it were possible (and this doesn't unleash a
>> holy war), could you summarize a few advantages I might find in CL
>> over Scheme?
>
> Unfortunately, I don't think one can really list the advantages and
> disadvantages *as* advantages or disadvantages without starting a holy
> war. They're different. Whether those differences constitute advantages
> for one and disadvantages for the other is up for grabs.
The best comparison I am aware of, which is also considerably neutral,
is this: http://community.schemewiki.org/?scheme-vs-common-lisp
It doesn't reflect R6RS yet, especially wrt a standardized module
system, but apart from that it still seems to be pretty accurate. (R6RS
is not accepted throughout the Scheme community, so there are still
issues in that regard.)
Aaron W. Hsu
> (R6RS is not accepted throughout the Scheme community, so there are
> still issues in that regard.)
Of course, R5RS was never accepted throughout the community either. :-)
Pascal Costanza
> On Sat, 04 Jul 2009 11:32:10 -0400, Pascal Costanza <p...@p-cos.net> wrote:
>
>> (R6RS is not accepted throughout the Scheme community, so there are
>> still issues in that regard.)
>
> Of course, R5RS was never accepted throughout the community either. :-)
Neither was Common Lisp. ;-)
Aaron W. Hsu
> Aaron W. Hsu wrote:
>> On Sat, 04 Jul 2009 11:32:10 -0400, Pascal Costanza <p...@p-cos.net>
>> wrote:
>>
>>> (R6RS is not accepted throughout the Scheme community, so there are
>>> still issues in that regard.)
>> Of course, R5RS was never accepted throughout the community either. :-)
>
> Neither was Common Lisp. ;-)
And that's what we love about Lisp.
Benjamin L. Russell
wrote:
>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>
>[...]
>
>> Just to be fair, PLT Scheme does have certain advantages over
>> Clojure. In particular, Clojure lacks support for first-class
>> continuations and tail-call optimization [...], and so cannot be
>> considered truly a proper "Scheme"; [...]
>
>This kind of comparison that lumps together very high-level language
>feature, very low-level bugs, and "social features" is bogus.
Unusual, perhaps, but "bogus?" As in, "not genuine" (see
http://www.merriam-webster.com/dictionary/bogus)? How so?
To the contrary, I was being quite "genuine," albeit subjective, in my
assessment. But then, Gonzo had asked for "comments," which do not
necessarily preclude personal opinion. My focus was on usability as a
tool for comparative programming language study, and in that regard,
while PLT Scheme bundles many useful features in one convenient
package, certain low-level bugs can keep DrScheme from being
convenient on the particular language version of the OS that I am
using.
Some people in this thread have suggested using MzScheme, but MzScheme
does not always receive the same level of support as DrScheme in the
PLT Scheme community. As a example, recently Neil Van Dyke released a
package for SICP support for DrScheme, but when I asked him whether he
had any plans for a GNU Emacs equivalent of the package (to avoid the
file explorer hanging problems that I am experiencing), he replied as
follows [1] (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033086.html):
>Benjamin L.Russell wrote at 05/13/2009 03:29 AM:
>> Do you have any plans for a GNU Emacs equivalent of this package?
>
>[...]
>
>For this SICP support project, my main goal is to let SICP students use
>DrScheme, which should be smoother and less intimidating than anything
>Emacs-like.
>
>Note that I suspect you can actually be able to use this package with
>"mzscheme" or "mred" in an Emacs REPL with Quack. However, for someone
>wanting to do SICP with something Emacs-like, even though it would be
>nice to bring them into the PLT camp, they might be just as well off by
>using MIT Scheme and Edwin.
(Just for the record, using MIT Scheme and Edwin would not make me
"just as well off" as using PLT Scheme in Emacs. In particular, I
have numerous customizations to my .emacs file which are difficult to
migrate to Edwin, and Edwin's fonts are not so easy to read as those
of Emacs. Also, I would like to use Emacs Lisp to write macros when
working with PLT Scheme, and Edwin, being Scheme-based, does not work
with Emacs Lisp macros.)
In response, I then tried to pursue Emacs + MzScheme for SICP support
for PLT Scheme further (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033088.html),
as follows [2]:
>On Wed, 13 May 2009 04:01:20 -0400, Neil Van Dyke
><neil at neilvandyke.org> wrote:
>
>>[...]
>>
>>That said, if anyone swear up and down that they will use PLT Scheme in
>>a GNU Emacs REPL for SICP, :) then I'll look at tweaking the REPL so it
>>behaves more like MIT Scheme and Edwin.
>
>I wouldn't mind using PLT Scheme in a GNU Emacs REPL for SICP ;).
Unfortunately, Neil Van Dyke then replied as follows [3] (see
http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033109.html):
>Really, it's about DrScheme. I like to think that the majority of
>people are quietly buzzing about on SICP in DrScheme, and I'm only
>hearing from Emacs people because the package is not intended for that.
So this package is "not intended" for "Emacs people." Great. I
wanted to use PLT Scheme + Emacs to study SICP, but the SICP Package
for PLT Scheme is simply "not intended" for "Emacs people."
This is the reason that MzScheme is not the same as DrScheme for using
PLT Scheme.
And this is the reason that PLT Scheme is not always convenient for my
purposes.
-- Benjamin L. Russell
[1] Van Dyke, Neil. "[plt-scheme] Re: SICP Support in PLT Scheme (now
available for testing)" The plt-scheme
Archives. Brown University. 13 May 2009. 6 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033086.html>.
[2] Russell, Benjamin L. "[plt-scheme] Re: SICP Support in PLT Scheme
(now available for testing)" The plt-scheme
Archives. Brown University. 13 May 2009. 6 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033088.html>.
[3] Van Dyke, Neil. "[plt-scheme] Re: SICP Support in PLT Scheme (now
available for testing)" The plt-scheme Archives.
Brown University. 13 May 2009. 6 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033109.html>.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Eli Barzilay
> On Fri, 03 Jul 2009 11:27:12 -0400, Eli Barzilay <e...@barzilay.org>
> wrote:
>
>>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>>
>>[...]
>>
>>> Just to be fair, PLT Scheme does have certain advantages over
>>> Clojure. In particular, Clojure lacks support for first-class
>>> continuations and tail-call optimization [...], and so cannot be
>>> considered truly a proper "Scheme"; [...]
>>
>>This kind of comparison that lumps together very high-level language
>>feature, very low-level bugs, and "social features" is bogus.
>
> Unusual, perhaps, but "bogus?" As in, "not genuine" (see
> http://www.merriam-webster.com/dictionary/bogus)? How so?
http://www.jargonwiki.com/wiki/Bogus
Specifically, your comparison lumped a low level bug (that only you
have reported), high level features like continuations and TCO, and
social features like mailing lists.
> Some people in this thread have suggested using MzScheme, but
> MzScheme does not always receive the same level of support as
> DrScheme in the PLT Scheme community.
That's false by definition, given that DrScheme is running *in*
MzScheme.
> As a example, recently Neil Van Dyke released a package for SICP
> support for DrScheme, but when I asked him whether he had any plans
> for a GNU Emacs equivalent of the package
Yes, DrScheme has certain advantages over a raw REPL interface, and
Neil chose to advocate that. That is not any kind of a lower level of
"support for MzScheme".
> [...] he replied as follows [...]:
>>Note that I suspect you can actually be able to use this package
>>with "mzscheme" or "mred" in an Emacs REPL with Quack. [...]
And ... did you *try* it? (Here's a thick hint: using `mred-text' as
your executable, it works fine from Emacs.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Benjamin L. Russell
wrote:
>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>
>> On Fri, 03 Jul 2009 11:27:12 -0400, Eli Barzilay <e...@barzilay.org>
>> wrote:
>>
>>>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>>>
>>>[...]
>>>
>>>> Just to be fair, PLT Scheme does have certain advantages over
>>>> Clojure. In particular, Clojure lacks support for first-class
>>>> continuations and tail-call optimization [...], and so cannot be
>>>> considered truly a proper "Scheme"; [...]
>>>
>>>This kind of comparison that lumps together very high-level language
>>>feature, very low-level bugs, and "social features" is bogus.
>>
>> Unusual, perhaps, but "bogus?" As in, "not genuine" (see
>> http://www.merriam-webster.com/dictionary/bogus)? How so?
>
>http://www.jargonwiki.com/wiki/Bogus
>
>Specifically, your comparison lumped a low level bug (that only you
>have reported), high level features like continuations and TCO, and
>social features like mailing lists.
Let's go through each of the definitions that you referred to in [1]
and see whether they stand up:
>bogus: adj.
>
> 1. Non-functional. "Your patches are bogus."
Since the topic of this discussion is a comparison, not a program,
this does not apply.
> 2. Useless. "OPCON is a bogus program."
Comparisons listing bugs in a program are not useless, so this does
not fit.
> 3. False. "Your arguments are bogus."
My comparison was based on genuine results obtained, so it is not
false, so this does not fit, either.
> 4. Incorrect. "That algorithm is bogus."
Again, since my comparison was based on genuine results obtained, it
is not incorrect, so this does not fit, either.
> 5. Unbelievable. "You claim to have solved the halting problem for Turing Machines? That's totally bogus."
Perhaps, but since I have given specific examples, you would need to
give a reason as to why not to believe those examples if you use this
definition.
> 6. Silly. "Stop writing those bogus sagas."
Silly? Hardly so. A comparison discussing a bug is not silly if that
bug keeps me from using the program conveniently, whether or not it
applies to other users, so this does not fit, either.
Hence, your usage is bogus. ;-)
>> Some people in this thread have suggested using MzScheme, but
>> MzScheme does not always receive the same level of support as
>> DrScheme in the PLT Scheme community.
>
>That's false by definition, given that DrScheme is running *in*
>MzScheme.
Perhaps I did not clarify what I meant by "MzScheme" sufficiently. By
"MzScheme," I specifically meant the REPL that comes up when I type
"mzscheme" at the Windows cmd.exe window, as opposed to the IDE that
comes up when I click on the Start Menu icon labelled "DrScheme";
_viz._:
>Microsoft Windows XP [Version 5.1.2600]
>(C) Copyright 1985-2001 Microsoft Corp.
>
>C:\Documents and Settings\Benjamin>mzscheme
>Welcome to MzScheme v4.2 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
>>
It says "MzScheme," doesn't it? That's what I meant. This is what I
invoke interactively in Emacs. This is what I use; in fact, this is
what I need to use to avoid the file explorer bug previously
discussed, which has occurred on both this computer and on the
previous laptop which I used at my previous job, both of which were
running the Japanese version of Windows XP (this bug apparently does
not occur on the English version of Windows XP).
>> As a example, recently Neil Van Dyke released a package for SICP
>> support for DrScheme, but when I asked him whether he had any plans
>> for a GNU Emacs equivalent of the package
>
>Yes, DrScheme has certain advantages over a raw REPL interface, and
>Neil chose to advocate that. That is not any kind of a lower level of
>"support for MzScheme".
I did not say "lower level"; I simply said "support" (see [2]
(http://www.merriam-webster.com/dictionary/support%5B2%5D)):
>Main Entry:
> support
>Function:
> noun
>Date:
> 14th century
>
>1 [...] b: assistance provided by a company to users of its products <customer support>
By replying as follows (see [3]
(http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033109.html)),
>Really, it's about DrScheme.
Neil Van Dyke indicated that the user support he intended to provide
for SICP in DrScheme was focused on the DrScheme IDE, and not on the
MzScheme REPL prompt that comes up at the cmd.exe command prompt, and
which I invoke interactively in Emacs. The bug I mentioned earlier
does not occur at the REPL; it occurs only in the IDE, apparently only
on the Japanese version of Windows XP (and not the English one), and
only if a specific kind of action (opening the file explorer and
navigating through directories using it for a few seconds) is
performed. Hence, this distinction of the MzScheme REPL vs. the
DrScheme IDE is necessary.
>> [...] he replied as follows [...]:
>>>Note that I suspect you can actually be able to use this package
>>>with "mzscheme" or "mred" in an Emacs REPL with Quack. [...]
>
>And ... did you *try* it? (Here's a thick hint: using `mred-text' as
>your executable, it works fine from Emacs.)
Indeed; it does, using either `mred-text -i sicp -l errortrace' or
`mzscheme -i sicp -l errortrace.'
It's interesting that neither of these usages is documented on the
relevant Web site (see [4] ("SICP Support in PLT Scheme" at
http://www.neilvandyke.org/sicp-plt/)). Neither is the non-DrScheme
installation method. This is what I mean by lack of "support."
-- Benjamin L. Russell
[1] "Bogus - JargonWiki." _The Jargon Wiki._ 23 Sept. 2008. 7 July
2009. <http://www.jargonwiki.com/wiki/Bogus>. Based in part on the
entry for "bogus" in _The Jargon File (version 4.4.7)._ Eric Raymond.
29 Dec. 2003. 7 July 2009. <http://catb.org/jargon/html/B/bogus.html>.
[2] "support - Definition from the Merriam-Webster Online Dictionary."
_Merriam-Webster Online Dictionary._ _MERRIAM-WEBSTER ONLINE._ 2009. 7
July 2009. <http://www.merriam-webster.com/dictionary/support%5B2%5D>.
[3] Van Dyke, Neil. "[plt-scheme] Re: SICP Support in PLT Scheme (now
available for testing)" The plt-scheme Archives.
Brown University. 13 May 2009. 7 July 2009.
<http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033109.html>.
[4] Van Dyke, Neil. "SICP Support in PLT Scheme." _Neil Van Dyke's
(im)personal site._ 30 June 2009. 7 July 2009.
<http://www.neilvandyke.org/sicp-plt/>.
(P.S. Eli, please stop sending me personal e-mail messages asking me
to stop discussions like these. I replied, asking you to stop telling
me what to say, and yet you still wrote back, so I have created a
special folder and filter in my e-mail account just for you. Please
respond in this thread, and not in personal e-mail. As I have already
mentioned, there is nothing wrong with posting results obtained and
opinions concerning a Scheme implementation on an open Scheme
discussion forum.)
Eli Barzilay
> On Mon, 06 Jul 2009 11:58:05 -0400, Eli Barzilay <e...@barzilay.org>
> wrote:
>
>>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>>
>>> On Fri, 03 Jul 2009 11:27:12 -0400, Eli Barzilay <e...@barzilay.org>
>>> wrote:
>>>
>>>>Benjamin L. Russell <DekuDe...@Yahoo.com> writes:
>>>>
>>>>[...]
>>>>
>>>>> Just to be fair, PLT Scheme does have certain advantages over
>>>>> Clojure. In particular, Clojure lacks support for first-class
>>>>> continuations and tail-call optimization [...], and so cannot be
>>>>> considered truly a proper "Scheme"; [...]
>>>>
>>>>This kind of comparison that lumps together very high-level language
>>>>feature, very low-level bugs, and "social features" is bogus.
>>>
>>> Unusual, perhaps, but "bogus?" As in, "not genuine" (see
>>> http://www.merriam-webster.com/dictionary/bogus)? How so?
>>
>>http://www.jargonwiki.com/wiki/Bogus
>>
>>Specifically, your comparison lumped a low level bug (that only you
>>have reported), high level features like continuations and TCO, and
>>social features like mailing lists.
>
> Let's go through each of the definitions that you referred to in [1]
> and see whether they stand up:
>[...]
If you really insist on getting to this ridiculous level -- your
comparison was:
* Non-functional; as in "not fit for most people to choose a
language".
* Silly; as in "since people expect a coherent comparison, yours will
utterly confuse them".
>>> Some people in this thread have suggested using MzScheme, but
>>> MzScheme does not always receive the same level of support as
>>> DrScheme in the PLT Scheme community.
>>
>>That's false by definition, given that DrScheme is running *in*
>>MzScheme.
>
> Perhaps I did not clarify what I meant by "MzScheme" sufficiently.
> By "MzScheme," I specifically meant the REPL that comes up when I
> type "mzscheme" at the Windows cmd.exe window, as opposed to the IDE
> that comes up when I click on the Start Menu icon labelled
> "DrScheme"; _viz._:
>
>>Microsoft Windows XP [Version 5.1.2600]
>>(C) Copyright 1985-2001 Microsoft Corp.
>>
>>C:\Documents and Settings\Benjamin>mzscheme
>>Welcome to MzScheme v4.2 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
>>>
>
> It says "MzScheme," doesn't it?
Yes. It also says "Copyright".
Anyway, the mzscheme *repl* is most certainly and very much supported.
> That's what I meant. This is what I invoke interactively in Emacs.
> This is what I use; in fact, this is what I need to use to avoid the
> file explorer bug previously discussed, which has occurred on both
> this computer and on the previous laptop which I used at my previous
> job, both of which were running the Japanese version of Windows XP
> (this bug apparently does not occur on the English version of
> Windows XP).
... and both of which are *your* computers, therefore if there is a
problem in some driver that you're using, it is likely to persist in
all of your machines.
>>> As a example, recently Neil Van Dyke released a package for SICP
>>> support for DrScheme, but when I asked him whether he had any plans
>>> for a GNU Emacs equivalent of the package
>>
>>Yes, DrScheme has certain advantages over a raw REPL interface, and
>>Neil chose to advocate that. That is not any kind of a lower level of
>>"support for MzScheme".
>
> I did not say "lower level"; I simply said "support" [...]
Yes, it *is* supported, period.
> By replying as follows (see [3]
> (http://list.cs.brown.edu/pipermail/plt-scheme/2009-May/033109.html)),
>
>>Really, it's about DrScheme.
>
> Neil Van Dyke indicated that the user support he intended to provide
> for SICP in DrScheme was focused on the DrScheme IDE, [...]
He also indicated that it should work with mred (the mzscheme+gui
equivalent). And it does.
> apparently only on the Japanese version of Windows XP [...],
s/the/my/
> Indeed; it does, using either `mred-text -i sicp -l errortrace' or
> `mzscheme -i sicp -l errortrace.'
>
> It's interesting that neither of these usages is documented on the
> relevant Web site (see [4] ("SICP Support in PLT Scheme" at
> http://www.neilvandyke.org/sicp-plt/)). Neither is the non-DrScheme
> installation method. This is what I mean by lack of "support."
Did you *try* to tell Neil about it?
Better yet, did you consider offering to help him in "implementing"
this kind of support yourself? Given that the only thing that is
needed is some paragraph with instructions on how to use it in Emacs,
it would be very easy.
The bottom line is that Neil is not working for PLT -- he just
volunteered to make this package possible. You can claim that in
general, this indicates a lack of interest in using Emacs and SICP
code -- and like any open source project, it is the people who set
their own preferences to the effect of what work they're willing to
contribute. Taking Neil's decision and extrapolating generalizations
on the "PLT Scheme community" is as bogus as this conclusion:
The PLT Scheme community is divided into a group that supports PLT
Scheme -- either via DrScheme or Emacs, and a group that whines
about the lack of support for Emacs and is not willing to make any
real investment.
(This conclusion is an accurate extrapolation based on a sample of you
and Neil, and the fact that Neil has considerable contributions that
are related to both Emacs and DrScheme whereas you have none.)
----------------
[Note: there is no reason for anyone except for Benjamin to read the
following. The only possible value would be some kind of a
voyeuristic entertainment, and there are certainly many places to get
much higher-quality entertainment (of any kind) on the web.]
> (P.S. Eli, please stop sending me personal e-mail messages asking me
> to stop discussions like these.
Since you insist on violating common netiquette and drag personal
emails into a public form, I have no choice but repeat my
clarification in the public forum: what I wrote was
Please stop making such wild and misleading claims about me or about
PLT.
and later clarified that:
* Of course, I cannot *tell* you what to say, hence I started my
request with "Please". If you don't respect it, all I can (and
will) do is defend myself against such insults, and put any sweeping
generalizations about PLT Scheme in their place.
* In "some members of PLT consider certain non-English languages ..."
you made it sound like I'm some american redneck who doesn't care
about any languages other than english, whereas I actually said that
we just don't have the human and computing resources to try all
languages. This was more than just an opinion -- it was an outright
insult.
* You made it sounds (for the second time now) like this is some
common problem of DrScheme, where in reality you are the *single*
person on earth who complained about this. (I don't remember the
exact numbers, but PLT is downloaded and installed about a 1000
times each day -- that's a *lot* of people who *don't* have that
bug.)
* In addition you chose Neil as the example of lack of support (or
interest or whatever) in any non-DrScheme work -- where the reality
is that Neil wrote a popular Emacs package that mainly targets PLT
Scheme. Given that you have zero Emacs packages (or at least zero
Emacs packages that target PLT Scheme and are publicly available),
this makes Neil have invested infinitely more time than you did
supporting the PLT+Emacs combination.
> As I have already mentioned, there is nothing wrong with posting
> results obtained and opinions concerning a Scheme implementation on
> an open Scheme discussion forum.
I apologize for that email. In case this is not clear -- I consider
my reply above as potentially embarassing for you, which is why I
tried, for your sake, to avoid doing so in public. If you don't care
about this, or if you don't see how this can be perceived then so be
it. In fact, I would still not have written the above if you hadn't
mentioned explicitly filtering out my emails.
[But more than that, I need to personally apologize for anyone
unfortunate enough to have read the above.]
Xah Lee
> Hello everyone,
> ...
>
> 4. In an almost feverish state of mind, I have come to a rather
> extreme conviction. Since Scheme is all powerful and sits above all
> languages, it should allow me to write in Scheme EVERYTHING I need for
> a project, and later generate code in any other language as needed.
> For example, I picture a web application where I write in Scheme not
> only my business logic, but also the queries to the DB (to generate
> proper SQL according to the RDBMS I decide to use), the page
> descriptions (using SXML to generate HTML), the behavior in those
> pages (to generate Javascript and to support AJAX), the styling in
> those pages (to generate CSS), the configuration in my application (to
> generate XML / property files / INI files / whatever), the
> documentation for the application (to generate... whatever), etc. In a
> bold move, I have unified all development into a single, powerful
> language that is (to me) a joy to use. The world is mine!
>
> the people who are reading this post may be thinking "oops, he's onto
> us, he needs to be eliminated"... But don't you agree that, being
> Scheme so powerful, you could use it as a super-language to program
> all aspects of your application in?
A few of my essays might change your view, roughly ordered from most
revelant to your query to less.
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
• Xah Lee's Computing Experience Bio
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html
one thing i'm surprised about your post is that, of your 10 to 20
years of industrial programing experience as implied in your post,
that you still have the thought of one language to rule them all. I
know of no one, after 10+ years of industrial coding, still remotely
fancy the prospect of using one lang to do all tasks.
Xah
∑ http://xahlee.org/
☄
Elena
In the end, I chose PLT Scheme because:
- Scheme guarantees tail call optimization, therefore allowing you to
learn functional programming which seems to be the next big thing;
- you are very likely to find a Scheme interpreter or compiler on any
platform;
- Scheme's core is thin, CL seems to have a lot of cruft because of
historical reasons;
- PLT Scheme has lots of very easy to install libraries and a
centralized repository;
- PLT Scheme has cohomprensive and readily available HTML
documentation (performing live search as you type!);
- DrScheme is a friendly and effective multiplatform IDE;
- currently, PLT Scheme only lacks native threads, but a mantainer
answered previously to a question of mine that they are going to be
added.
Pascal Costanza
> I started like you, comparing CL and Scheme.
>
> In the end, I chose PLT Scheme because:
> - Scheme guarantees tail call optimization, therefore allowing you to
> learn functional programming which seems to be the next big thing;
Most Common Lisp implementations allow you to enable this as well. It
would be better if this were more portable across Common Lisp
implementations though, but it's not as bad as you seem to think.
> - you are very likely to find a Scheme interpreter or compiler on any
> platform;
Same for Common Lisp.
> - Scheme's core is thin, CL seems to have a lot of cruft because of
> historical reasons;
Most of what's in Common Lisp gets reimplemented for Scheme, so it
doesn't seem to be cruft after all.
> - PLT Scheme has lots of very easy to install libraries and a
> centralized repository;
There are library repositories for Common Lisp as well. I don't have
serious problems with installing Common Lisp libraries, but it could
indeed be better. Again, it's not as bad as you seem to think.
> - PLT Scheme has cohomprensive and readily available HTML
> documentation (performing live search as you type!);
Same for Common Lisp - see the HyperSpec. I use LispWorks most of the
time, the documentation that comes with it is excellent, and easy to
search as well.
> - DrScheme is a friendly and effective multiplatform IDE;
Same for LispWorks.
> - currently, PLT Scheme only lacks native threads, but a mantainer
> answered previously to a question of mine that they are going to be
> added.
Clozure Common Lisp and SBCL already provide symmetric multiprocessing,
and LispWorks and Allegro Common Lisp will add this in their new releases.
rotty
> Elena wrote:
> > - PLT Scheme has cohomprensive and readily available HTML
> > documentation (performing live search as you type!);
>
> Same for Common Lisp - see the HyperSpec.
>
on
the Web? The (admittedly few) times I needed it, I was always put off
by
the (at least compared to the PLT docs) bad rendering of the copy at
http://www.lispworks.com/documentation/lw50/CLHS/ -- the content is
broken into way too many pages, requiring a lot more clicking to
navigate than what would be necessary.
> I use LispWorks most of the
> time, the documentation that comes with it is excellent, and easy to
> search as well.
>
The PLT online docs are searchable with just a web browser, which is a
huge plus IMHO -- I don't use DrScheme, and only seldomly mzscheme,
but
I use the PLT docs all the time (they provide search/index for R5RS,
R6RS and most SRFIs).
> > - DrScheme is a friendly and effective multiplatform IDE;
>
> Same for LispWorks.
>
One advantage of DrScheme/PLT is that it's free software, while
LispWorks is
proprietary.
--Rotty
Elena
On 24 Lug, 18:37, Pascal Costanza <p...@p-cos.net> wrote:
> Elena wrote:
> > I started like you, comparing CL and Scheme.
>
> > In the end, I chose PLT Scheme because:
> > - Scheme guarantees tail call optimization, therefore allowing you to
> > learn functional programming which seems to be the next big thing;
>
> Most Common Lisp implementations allow you to enable this as well. It
> would be better if this were more portable across Common Lisp
> implementations though, but it's not as bad as you seem to think.
Well, it seems you can't always count on that. Maybe TCO is available
from the compiler but not from the interpreter, and so on.
>
> > - you are very likely to find a Scheme interpreter or compiler on any
> > platform;
>
> Same for Common Lisp.
I have not been clear enough: I was not talking just about mainstream
operating systems, but also about virtual machines (JVM, .NET, etc.),
small devices (PDA, etc) and so on.
>
> > - Scheme's core is thin, CL seems to have a lot of cruft because of
> > historical reasons;
>
> Most of what's in Common Lisp gets reimplemented for Scheme, so it
> doesn't seem to be cruft after all.
I'm taking your word for that.
>
> > - PLT Scheme has lots of very easy to install libraries and a
> > centralized repository;
>
> There are library repositories for Common Lisp as well. I don't have
> serious problems with installing Common Lisp libraries, but it could
> indeed be better. Again, it's not as bad as you seem to think.
That's what I've understood by reading around. It seemed that for more
complex libraries, you'd have to track down dependencies by hand,
whilst PLT Scheme "require" takes care of everything.
>
> > - PLT Scheme has cohomprensive and readily available HTML
> > documentation (performing live search as you type!);
>
> Same for Common Lisp - see the HyperSpec. I use LispWorks most of the
> time, the documentation that comes with it is excellent, and easy to
> search as well.
It seems to me that PLT Scheme's documentation system is more
cohomprensive than HyperSpec, but maybe that's just a newbie
perspective.
>
> > - DrScheme is a friendly and effective multiplatform IDE;
>
> Same for LispWorks.
I'm taking your word for that.
>
> > - currently, PLT Scheme only lacks native threads, but a mantainer
> > answered previously to a question of mine that they are going to be
> > added.
>
> Clozure Common Lisp and SBCL already provide symmetric multiprocessing,
> and LispWorks and Allegro Common Lisp will add this in their new releases.
Well, that's more advanced than what I was talking about... I meant
just native multithreading.
Thanks again.
Elena
> The PLT online docs are searchable with just a web browser, which is a
> huge plus IMHO -- I don't use DrScheme, and only seldomly mzscheme,
> but
> I use the PLT docs all the time (they provide search/index for R5RS,
> R6RS and most SRFIs).
+1
I'm amazed at how quickly you can navigate PLT Scheme's cohomprensive
documentation.
Pascal Costanza
> On Jul 24, 6:37 pm, Pascal Costanza <p...@p-cos.net> wrote:
>> Elena wrote:
>>> - PLT Scheme has cohomprensive and readily available HTML
>>> documentation (performing live search as you type!);
>> Same for Common Lisp - see the HyperSpec.
>>
> Is there a reasonably "beautiful" version of the HyperSpec available
> on
> the Web? The (admittedly few) times I needed it, I was always put off
> by
> the (at least compared to the PLT docs) bad rendering of the copy at
> http://www.lispworks.com/documentation/lw50/CLHS/ -- the content is
> broken into way too many pages, requiring a lot more clicking to
> navigate than what would be necessary.
That link is incorrect (or better, a bad starting point). Try this
instead: http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
Yes, it takes a little bit getting used to, but by now I'm very fast
using it. Especially, pay attention to the Chapter index, the Symbol
index, and the Selected Highlights. (The indexes are the most important.)
>> I use LispWorks most of the
>> time, the documentation that comes with it is excellent, and easy to
>> search as well.
>>
> The PLT online docs are searchable with just a web browser, which is a
> huge plus IMHO -- I don't use DrScheme, and only seldomly mzscheme,
> but
> I use the PLT docs all the time (they provide search/index for R5RS,
> R6RS and most SRFIs).
I can't compare directly to the PLT online doc, because I have never
used it. However, I use the LispWorks IDE, from within which it is a
breeze to use the HyperSpec, and all the other LispWorks documentation.
Of course, you could also use Google. (OK, that wasn't too serious... ;)
>>> - DrScheme is a friendly and effective multiplatform IDE;
>> Same for LispWorks.
>>
> One advantage of DrScheme/PLT is that it's free software, while
> LispWorks is proprietary.
Whether that's an advantage is debatable, and a topic for a different
discussion. However, there is also the free Personal Edition of
LispWorks, which works very well for many purposes. So if you insist on
free (for some definition of free), you can get it for free. [1]
Pascal
[1] For example, you could develop in LispWorks, and then deploy with
one of the open source Common Lisp implementations.
Pascal Costanza
> Thank you, Pascal, for your rebuttal :-)
>
> On 24 Lug, 18:37, Pascal Costanza <p...@p-cos.net> wrote:
>> Elena wrote:
>>> I started like you, comparing CL and Scheme.
>>> In the end, I chose PLT Scheme because:
>>> - Scheme guarantees tail call optimization, therefore allowing you to
>>> learn functional programming which seems to be the next big thing;
>> Most Common Lisp implementations allow you to enable this as well. It
>> would be better if this were more portable across Common Lisp
>> implementations though, but it's not as bad as you seem to think.
>
> Well, it seems you can't always count on that. Maybe TCO is available
> from the compiler but not from the interpreter, and so on.
Yes, that's what I mean that it should be more portable (and it should
also be clearer what guarantees you get). But it seems to me that this
issue is a bit overrated (but maybe it's better not to get into this too
much on comp.lang.scheme... ;)
>>> - you are very likely to find a Scheme interpreter or compiler on any
>>> platform;
>> Same for Common Lisp.
>
> I have not been clear enough: I was not talking just about mainstream
> operating systems, but also about virtual machines (JVM, .NET, etc.),
> small devices (PDA, etc) and so on.
The JVM seems pretty well covered, due to ABCL (and also some interop
solutions). You are right with regard to .NET and certain small devices.
>>> - PLT Scheme has lots of very easy to install libraries and a
>>> centralized repository;
>> There are library repositories for Common Lisp as well. I don't have
>> serious problems with installing Common Lisp libraries, but it could
>> indeed be better. Again, it's not as bad as you seem to think.
>
> That's what I've understood by reading around. It seemed that for more
> complex libraries, you'd have to track down dependencies by hand,
> whilst PLT Scheme "require" takes care of everything.
That's not quite true anymore, due to asdf-install and other projects
that improve handling of library dependencies.
>>> - PLT Scheme has cohomprensive and readily available HTML
>>> documentation (performing live search as you type!);
>> Same for Common Lisp - see the HyperSpec. I use LispWorks most of the
>> time, the documentation that comes with it is excellent, and easy to
>> search as well.
>
> It seems to me that PLT Scheme's documentation system is more
> cohomprensive than HyperSpec, but maybe that's just a newbie
> perspective.
Take a look at the documentation that comes with LispWorks. It's very
complete indeed. (True also for other commercial Common Lisp
implementations, and for many libraries as well, especially those by Edi
Weitz.)
>>> - currently, PLT Scheme only lacks native threads, but a mantainer
>>> answered previously to a question of mine that they are going to be
>>> added.
>> Clozure Common Lisp and SBCL already provide symmetric multiprocessing,
>> and LispWorks and Allegro Common Lisp will add this in their new releases.
>
> Well, that's more advanced than what I was talking about... I meant
> just native multithreading.
I'm fine with that. ;)
Elena
> I can't compare directly to the PLT online doc, because I have never
> used it.
Have a look to the live search, then:
http://docs.plt-scheme.org/search/index.html
And you are not limited to APIs and standards.
Outstanding, isn't it? :-)
Pascal Costanza
Yes, this looks indeed very impressive!
Here is what the search dialog looks like in LispWorks (as of version
5.1.1): http://p-cos.net/lw-search/search-dialog.jpg
...and this is what a result window looks like:
http://p-cos.net/lw-search/search-results.html [*]
It's obviously not as impressive as the PLT online doc, but certainly
very usable as well.
Pascal
[*] The links on that page don't work, because they are links to files
on my private machine.
Grant Rettke
> Elena wrote:
> > Well, it seems you can't always count on that. Maybe TCO is available
> > from the compiler but not from the interpreter, and so on.
>
> Yes, that's what I mean that it should be more portable (and it should
> also be clearer what guarantees you get). But it seems to me that this
> issue is a bit overrated (but maybe it's better not to get into this too
> much on comp.lang.scheme... ;)
Botox is overrated. TCO doesn't really fall into the same category.
Read LAMBDA: The Ultimate Imperative.
Pascal Costanza
I did read the lambda papers.
Please read my statement in context.
Thanks,
Pascal Costanza
> Grant Rettke wrote:
>> On Jul 24, 5:16 pm, Pascal Costanza <p...@p-cos.net> wrote:
>>> Elena wrote:
>>>> Well, it seems you can't always count on that. Maybe TCO is available
>>>> from the compiler but not from the interpreter, and so on.
>>> Yes, that's what I mean that it should be more portable (and it should
>>> also be clearer what guarantees you get). But it seems to me that this
>>> issue is a bit overrated (but maybe it's better not to get into this too
>>> much on comp.lang.scheme... ;)
>>
>> Botox is overrated. TCO doesn't really fall into the same category.
>>
>> Read LAMBDA: The Ultimate Imperative.
>
> I did read the lambda papers.
>
> Please read my statement in context.
To clarify a bit: I can understand why some people prefer the guarantee
of proper tail recursion, especially when they want to program in a
certain programming style. It was actually the case that recently, we
ran into a problem in some Common Lisp code because of the lack of
proper tail recursion. However, it turned out that we could easily solve
it, using the idioms described in this posting:
http://groups.google.com/group/comp.lang.lisp/msg/8f9dcf58a00aca27
The result is not as elegant as if we had used Scheme, but it is also
not as ugly as you may think it is.
My statement about proper tail recursion being overrated has to be seen
in context: Other features that Common Lisp has, but Scheme doesn't, are
just more important to me, including in that project where the lack of
guaranteed proper tail recursion was a problem. In the end, Common Lisp
was still the better choice. YMMV.
Rainer Joswig
> Elena wrote:
> > On 25 Lug, 00:09, Pascal Costanza <p...@p-cos.net> wrote:
> >> I can't compare directly to the PLT online doc, because I have never
> >> used it.
>
> > Have a look to the live search, then:
>
> >http://docs.plt-scheme.org/search/index.html
>
> > And you are not limited to APIs and standards.
>
> > Outstanding, isn't it? :-)
>
> Yes, this looks indeed very impressive!
>
> Here is what the search dialog looks like in LispWorks (as of version
> 5.1.1):http://p-cos.net/lw-search/search-dialog.jpg
>
> ...and this is what a result window looks like:http://p-cos.net/lw-search/search-results.html[*]
>
> It's obviously not as impressive as the PLT online doc, but certainly
> very usable as well.
>
> Pascal
>
> [*] The links on that page don't work, because they are links to files
> on my private machine.
>
> --
> My website:http://p-cos.net
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
Elena
Also: http://lispdoc.com/
w_a_x_man
"an unwieldy, overweight beast"
"A monstrosity"
"sucks"
"an aberration"
"incomprehensible"
"a nightmare"
"no future"
"a significantly ugly language"
"hacks"
"bad"
In context:
Brooks and Gabriel 1984, "A Critique of Common Lisp":
Every decision of the committee can be locally rationalized
as the right thing. We believe that the sum of these
decisions, however, has produced something greater than its
parts; an unwieldy, overweight beast, with significant costs
(especially on other than micro-codable personal Lisp
engines) in compiler size and speed, in runtime performance,
in programmer overhead needed to produce efficient programs,
and in intellectual overload for a programmer wishing to be
a proficient COMMON LISP programmer.
-----
Bernard Lang:
Common Lisp did kill Lisp. Period. (just languages take a
long time dying ...) It is to Lisp what C++ is to C. A
monstrosity that totally ignores the basics of language
design, simplicity and orthogonality to begin with.
-----
Gilles Kahn:
To this day I have not forgotten that Common Lisp killed
Lisp, and forced us to abandon a perfectly good system,
LeLisp.
-----
Paul Graham, May 2001:
A hacker's language is terse and hackable. Common Lisp is not.
The good news is, it's not Lisp that sucks, but Common Lisp.
Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.
A really good language should be both clean and dirty:
cleanly designed, with a small core of well understood and
highly orthogonal operators, but dirty in the sense that it
lets hackers have their way with it. C is like this. So were
the early Lisps. A real hacker's language will always have a
slightly raffish character.
Organic growth seems to yield better technology and richer
founders than the big bang method. If you look at the
dominant technologies today, you'll find that most of them
grew organically. This pattern doesn't only apply to
companies. You see it in sponsored research too. Multics and
Common Lisp were big-bang projects, and Unix and MacLisp
were organic growth projects.
-----
Jeffrey M. Jacobs:
Common LISP is the PL/I of Lisps. Too big and too
incomprehensible, with no examiniation of the real world of
software engineering.
... The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and
then we'll all go down the tubes". Everybody had vested
interests, both financial and emotional.
CL is a nightmare; it has effectively killed LISP
development in this country. It is not commercially viable
and has virtually no future outside of the traditional
academic/defense/research arena.
-----
Dick Gabriel:
Common Lisp is a significantly ugly language. If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.
-----
Paul Graham:
Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?
-----
Daniel Weinreb, 24 Feb 2003:
Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortuanate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.
-----
Daniel Weinreb, 28 Feb 2003:
Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself.