Scheme is heavily academic?
Griff
A common remark I find on websites is that "Scheme is a heavily
academic language by nature while Common Lisp is geared more for real
world development". I've read this more than a few times, actually.
Why do people seem to frequently make this remark?
Regards,
Grant
Pascal Costanza
...because it easily starts useless flame wars.
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/
Cor Gest
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Why do people seem to frequently make this remark?
Because it is so much easier to get people wasting time on triviality
urging them to do something usefull takes more.
Cor
--
The biggest problem LISP has is that it does not apeal to dumb people
If this failed to satisfy you try reading the HyperSpec or woman frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read the policy before mailing http://www.clsnet.nl/mail.html
Bruce Lewis
> A common remark I find on websites is that "Scheme is a heavily
> academic language by nature while Common Lisp is geared more for real
> world development". I've read this more than a few times, actually.
Scheme is frequently applied to secondary- and university-level
teaching. Common Lisp is frequently applied in industry. It is a truth
universally acknowledged that if a computer language is frequently used
in a given area, then that area is what the language is geared for.
Ray Dillinger
[Since this topic is historically flamebait and I'm going
to express actual opinions, I'd like to take this moment to
ask everyone to respond calmly if at all. I'm trying to be
fair to both languages]
Scheme has historically striven to be a minimal, complete,
consistent, multiparadigm language. That means the standards
have been very short relative to other languages, covering
relatively few concepts and structures but making sure that
the semantics of each concept are mathematically as simple
as possible, and that those concepts and structures are
sufficient to synthesize pretty much anything and lend themselves
to programming in pretty much any style.
As a result, it's been ideal for teaching computer science - and
I want to emphasize the word 'science', as opposed to 'trade'.
'engineering' is somewhere inbetween. The trade of programming
means studying individual languages and systems and tools and
libraries and coding standards and protocols and gaining some
proficiency in using them. The science of programming is about
how each of these things are designed, the math behind them, and
what kind of design and mathematical tradeoffs are involved in
different ways of doing things.
When you're studying computer science, you don't want to waste
too much time teaching the students a language. So you want a
language that smart students accustomed to rigorous thought can
literally pick up in a couple of days. And scheme has been
that language. When you're studying object orientation and
how OO systems should be designed, you want a base language
that contains the facilities necessary to roll your own object
orientation extensions, so you can try out several different
types of OO in the course of a single semester. And scheme
has served that need as well. When you want to talk about
functional, OO, and procedural programming (and if you're
completist, even unification programming) you need a language
that easily or with the addition of a library or two lends
itself to all three. Scheme works great for that.
The fact is that Scheme doesn't have a lot of readymade things
that other languages have. Instead, it has the facilities to
easily build them. And that means it lets you freely experiment
with different designs or different *ways* of building them,
or even design individual programs using different facilities
depending on what fits the individual problem best.
But this extreme flexibility tends to play bloody hell with
interoperability. Typical scheme programs contain
infrastructure code that virtually everything "interesting"
about the program depends on. If you want to reuse code,
you have to do some serious work to make sure it can get
the kind of object-oriented functionality it wants, and
the version of the TCP stack code that has the particular
functions and argument orders that it requires, and the version
of the CGI library that provides CGI variables with the variable
names it expects in the scope it expects, the particular module
system that it depends on, the "wrappers" for common functions
that it expects, etc, etc, and etc.
And if you attempt to reuse code from several different projects,
as is typically the case with opensource programming, you learn
the true name of pain. Many of these extensions conflict with
each other, requiring namespace control. But many of the
module systems granting namespace control also conflict with
one another. And you start by trying to sort it out, and
if you're like me, end by throwing a bunch of stuff out the
window and coding it from scratch - again. Because scheme makes
it very easy to code from scratch and very hard to integrate
code that diverse people relying on diverse libraries wrote.
Such systemic conflict is also in the heritage of Common Lisp,
but Common Lisp took a different route. Where scheme did not
standardize that which was controversial or multiply-defined
and instead included sufficient "good stuff" to build it whichever
way you wanted from scratch, Common Lisp undertook standardization
with the express purpose of supporting (or at least easily porting
to the new standard) and permitting interoperability of a vast
body of legacy code, and actively locked a lot of the "good stuff"
up (such that you now have to jump through serious hoops if you
want to redefine any standardized function, and rolling your own
control constructs with general reified continuations is simply out
of the question) to prevent people from re-creating the quagmire.
The result is that the Common Lisp standard adopted wholesale
the structures and designs of several different lisp systems
which no longer really exist in the wild. There is duplication
of purpose in many standard functions, with subtle differences
and variations made necessary by different design decisions in
the ancestral lisp systems. On the plus side, this gives you
a "standard" function that's a drop-in replacement for nearly
any function in the ancestral lisp systems, standardizes an exact
semantics for each, and saves you having to implement such
things yourself. On the minus side, Common Lisp is a relatively
huge language, and most students are not going to pick it up
in a couple of days. Also, because its design is relatively
fixed, you have a single object system and that means it's
extra painful to experiment with multiple different other object
systems. Likewise module systems, etc. Also, the mathematics
and semantics of Common Lisp are more complex and sometimes
opaque, with subtleties about referencing the "data" value or
the "function" value in expected and unexpected ways seriously
getting in your way if you try to do (or analyze rigorously)
pure functional programming.
Like all larger structures, it has to be more rigid. Thus there
is far less room in Common Lisp to experiment than there is in
Scheme, and so while it has served the needs of software engineers
and tradesmen rather well, it hasn't been as kind for designers
and scientists, who need to experiment. One of the things that
makes scheme *hugely* flexible, and which computer scientists
love to use in experiments, is general reified continuations. The
facility simply can't exist in Common Lisp because it would
enable code that would actively subvert the semantics of, or
unexpectedly expose implementation details of, a lot of common
libraries and implementation strategies.
But CL has largely achieved its goal of providing interoperability
for a vast quantity of old lisp code and providing a stable
platform for writing new code. And the duplication of purpose
in many of its functions has translated into the ability to
express certain kinds of subtle differences simply and precisely.
And because those different versions of functions exist with
standardized names, first you don't have to implement the
particular version of them your code requires, and second you
won't usually get subtle name conflicts when porting or
integrating code. Both of these greatly lower the mental overhead
of integrating code from diverse sources into a single program.
Bear
(Who's been studying the "ancestral" lisps recently....)
Griff
Thank you so much for your answer!
Pascal Costanza
> Griff wrote:
>> Hi folks,
>>
>> A common remark I find on websites is that "Scheme is a heavily
>> academic language by nature while Common Lisp is geared more for real
>> world development". I've read this more than a few times, actually.
>>
>> Why do people seem to frequently make this remark?
>>
>> Regards,
>>
>> Grant
>
> [Since this topic is historically flamebait and I'm going
> to express actual opinions, I'd like to take this moment to
> ask everyone to respond calmly if at all. I'm trying to be
> fair to both languages]
[I feel I have to respond to a few issues here, but I will try to stay
as calm as you. ;)]
> Also, because [Common Lisp's] design is relatively
> fixed, you have a single object system and that means it's
> extra painful to experiment with multiple different other object
> systems.
This is, to the best of my knowledge, incorrect. The Common Lisp Object
System has been designed with the flexibility in mind to adapt it to
different kinds of object systems. So for certain styles of object
systems, it is especially easy to experiment with variations thereof.
Especially, it is relatively painless to make non-trivial modifications
and still get reasonable efficiency such that such modifications can
actually be used in practice. (You're correct that the latter is not
necessarily an important requirement, but can be interesting nonetheless
in some cases.)
> Like all larger structures, it has to be more rigid. Thus there
> is far less room in Common Lisp to experiment than there is in
> Scheme, and so while it has served the needs of software engineers
> and tradesmen rather well, it hasn't been as kind for designers
> and scientists, who need to experiment.
It's relatively painless to get rid of all the baggage that you don't
need in your concrete experiments due to the ability to shadow almost
anything with Common Lisp's package system. (Module systems for Scheme
give you a similar degree of flexibility. Some people find it hard to
get used to Common Lisp packages, though.)
> One of the things that
> makes scheme *hugely* flexible, and which computer scientists
> love to use in experiments, is general reified continuations. The
> facility simply can't exist in Common Lisp because it would
> enable code that would actively subvert the semantics of, or
> unexpectedly expose implementation details of, a lot of common
> libraries and implementation strategies.
This danger exists for any library, no matter whether implemented in
Scheme or Common Lisp for that matter. The possibility to reify
continuations is one of many possible ways to do reflection on the
computational state of a program. Both Scheme and Common Lisp are
lacking other reflective facilities, and Common Lisp provides some that
Scheme doesn't have. [1]
I mostly agree with your other remarks.
Pascal
[1] It would be nice if either dialect would provide a more complete set
of reflective facilities, and would integrate them in cleaner ways, but
that's of course not an easy task.
gavino
LOL, come off it!
Hows BRL doing?
have you tried scsh at all?
I am on arch linux now and it comes with a scsh package!!
I remember trying BRL but I never went to MIT so the book talking
about MIT's email system and its programability confused me. More
time perhaps would have helped me...
BRL!!!
gavino
HI I saw your scsh.
Do I need to read sicp before attacking the scsh manual if I am new to
programming? or can I use scsh with sicp?
I want to get a scheme environment going on arch linux. to learn
gavino
Paul Graham on his site mentions how he would choose common lisp over
scheme because it has real macros. Do they (if they are still
superior in 2007) make clisp a better choice for building web based e
commerce apps today?
Pascal Costanza
I am not involved in scsh. You probably mean someone else.
Pascal Costanza
> Paul Graham on his site mentions how he would choose common lisp over
> scheme because it has real macros. Do they (if they are still
> superior in 2007) make clisp a better choice for building web based e
> commerce apps today?
I don't know what you mean by "real" macros, but the specific
characteristics of a macro system are completely unrelated to the
possibility to develop web applications with the underlying language.
Pascal
joe nada
>
> When you're studying computer science, you don't want to waste
> too much time teaching the students a language.
Hi Ray --
It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java
and Python have a simple language syntax. Now, it may be that, in this
day and age, when programmers are asked to learn so many things, a
language with a simplified syntax is actually on that has a higher
"adoption factor."
Oh, that sounbds really bad! But I thought the whole point of Scheme
being a small language that wants to have libraries was a way to prevent
this sad state of affairs. From what I've read from R6RS it seems these
issues are addressed in this new standard. Wanna commoent on that?
> things yourself. On the minus side, Common Lisp is a relatively
> huge language, and most students are not going to pick it up
> in a couple of days.
Common Lisp is huge and there are obscure corners. When a language is
huge, you get "gurus" (a bad sign).
Jens Axel Søgaard
> Paul Graham on his site mentions how he would choose common lisp over
> scheme because it has real macros. Do they (if they are still
> superior in 2007) make clisp a better choice for building web based e
> commerce apps today?
Graham's book is old.
--
Jens Axel Søgaard
Thant Tessman
> Ray Dillinger wrote:
>> Griff wrote:
>>> Hi folks,
>>>
>>> A common remark I find on websites is that "Scheme is a heavily
>>> academic language by nature while Common Lisp is geared more for real
>>> world development". I've read this more than a few times, actually.
>>>
>>> Why do people seem to frequently make this remark?
>>>
>>> Regards,
>>>
>>> Grant
>>
>> [Since this topic is historically flamebait and I'm going
>> to express actual opinions, I'd like to take this moment to
>> ask everyone to respond calmly if at all. I'm trying to be
>> fair to both languages]
>
> [I feel I have to respond to a few issues here, but I will try to stay
> as calm as you. ;)]
>
>> Also, because [Common Lisp's] design is relatively
>> fixed, you have a single object system and that means it's
>> extra painful to experiment with multiple different other object
>> systems.
>
> This is, to the best of my knowledge, incorrect. The Common Lisp Object
> System has been designed with the flexibility in mind to adapt it to
> different kinds of object systems. So for certain styles of object
> systems, it is especially easy to experiment with variations thereof.
No, Bear is right. CLOS is a single object system. Yes, you are right.
It is a particularly flexible object system.
[...]
>> One of the things that
>> makes scheme *hugely* flexible, and which computer scientists
>> love to use in experiments, is general reified continuations. The
>> facility simply can't exist in Common Lisp because it would
>> enable code that would actively subvert the semantics of, or
>> unexpectedly expose implementation details of, a lot of common
>> libraries and implementation strategies.
>
> This danger exists for any library, no matter whether implemented in
> Scheme or Common Lisp for that matter. [...]
Support of continuations is more profound than that. That's why he also
said "implementation strategies."
-thant
Thant Tessman
> In <45c0f093$0$68952$742e...@news.sonic.net> Ray Dillinger wrote:
>> When you're studying computer science, you don't want to waste
>> too much time teaching the students a language.
>
> Hi Ray --
>
> It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java
> and Python have a simple language syntax. Now, it may be that, in this
> day and age, when programmers are asked to learn so many things, a
> language with a simplified syntax is actually on that has a higher
> "adoption factor."
Scheme simply can't be beat in the syntax department. But I don't think
that's what he was talking about. The real problem with all those
languages is that they all heavily impose a programming methodology
specific to their design. When you learn Java, you learn Java.
[...]
-thant
Pascal Costanza
> Pascal Costanza wrote:
>> Ray Dillinger wrote:
>>> Also, because [Common Lisp's] design is relatively
>>> fixed, you have a single object system and that means it's
>>> extra painful to experiment with multiple different other object
>>> systems.
>>
>> This is, to the best of my knowledge, incorrect. The Common Lisp
>> Object System has been designed with the flexibility in mind to adapt
>> it to different kinds of object systems. So for certain styles of
>> object systems, it is especially easy to experiment with variations
>> thereof.
>
> No, Bear is right. CLOS is a single object system. Yes, you are right.
> It is a particularly flexible object system.
CLOS together with its metaobject protocol actually defines a family of
object systems, not just one. That's what I was getting at.
>>> One of the things that
>>> makes scheme *hugely* flexible, and which computer scientists
>>> love to use in experiments, is general reified continuations. The
>>> facility simply can't exist in Common Lisp because it would
>>> enable code that would actively subvert the semantics of, or
>>> unexpectedly expose implementation details of, a lot of common
>>> libraries and implementation strategies.
>>
>> This danger exists for any library, no matter whether implemented in
>> Scheme or Common Lisp for that matter. [...]
>
> Support of continuations is more profound than that. That's why he also
> said "implementation strategies."
Sure, but it's still the case that the danger exists in both languages.
For example, see http://www.r6rs.org/formal-comments/comment-36.txt
Pascal
Rob Thorpe
Just because it's there though doesn't mean you have to use it. If you
like you can create your own object system using functions, macros
etc. This is what was done in the Garnet toolkit for example.
You can do fairly much the same things possible in scheme, but for the
some extra things call/cc may allow.
Cor Gest
Some entity, AKA "gavino" <gavc...@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Do I need to read sicp before attacking the scsh manual if I am new to
> programming? or can I use scsh with sicp?
> I want to get a scheme environment going on arch linux. to learn
The MIT SICP web-site has all the tools and the paticular
scheme-implementation for use on linux to do the 6.001 courseware stuff.
Ray Dillinger
> In <45c0f093$0$68952$742e...@news.sonic.net> Ray Dillinger wrote:
>
>>When you're studying computer science, you don't want to waste
>>too much time teaching the students a language.
>
>
> Hi Ray --
>
> It's not just Scheme that takes this approach: Eiffel, Smalltalk, Java
> and Python have a simple language syntax. Now, it may be that, in this
> day and age, when programmers are asked to learn so many things, a
> language with a simplified syntax is actually on that has a higher
> "adoption factor."
It's true that those languages have simple syntax.
But they simply are not as flexible as scheme. You
cannot compare different OO systems, for example, in
smalltalk or Java. Nor can you compare side-effecting
and non-side-effecting implementations of things in
Haskell. etc. Each of those languages are exactly
what they are, and don't provide *any* "good stuff"
for experimenting with different types of languages.
Scheme, on the other hand, is easily made into any
language you want to talk or think about.
>>one another. And you start by trying to sort it out, and
>>if you're like me, end by throwing a bunch of stuff out the
>>window and coding it from scratch - again.
>
>
> Oh, that sounbds really bad! But I thought the whole point of Scheme
> being a small language that wants to have libraries was a way to prevent
> this sad state of affairs. From what I've read from R6RS it seems these
> issues are addressed in this new standard. Wanna commoent on that?
Indeed, the new standard under consideration does seem to
be trying to address this. I was careful to mention that
I was talking about the history of scheme, not it's future.
But whether the standard does what people hope it does,
remains to be seen.
Bear
Ray Dillinger
In fairness, I haven't masterd the CLOS MOOP. I may be underestimating
the flexibility of the object system available.
> [1] It would be nice if either dialect would provide a more complete set
> of reflective facilities, and would integrate them in cleaner ways, but
> that's of course not an easy task.
It is difficult to imagine how a truly complete set of reflective
facilities could be, um, "clean".
Bear
Pascal Costanza
>> [1] It would be nice if either dialect would provide a more complete
>> set of reflective facilities, and would integrate them in cleaner
>> ways, but that's of course not an easy task.
>
> It is difficult to imagine how a truly complete set of reflective
> facilities could be, um, "clean".
ROTFL. OK, that round is for you. ;)
Pascal
Pascal Costanza
> Pascal Costanza wrote:
>> The Common Lisp
>> Object System has been designed with the flexibility in mind to adapt
>> it to different kinds of object systems. So for certain styles of
>> object systems, it is especially easy to experiment with variations
>> thereof. Especially, it is relatively painless to make non-trivial
>> modifications and still get reasonable efficiency such that such
>> modifications can actually be used in practice. (You're correct that
>> the latter is not necessarily an important requirement, but can be
>> interesting nonetheless in some cases.)
>
> the flexibility of the object system available.
If you want to learn more about it but want to avoid learning the rest
of Common Lisp, Tiny CLOS for Scheme is a pretty good starting point.
Eli Barzilay's Swindle is based on this (part of PLT Scheme), as is
STklos. The latter two seem to be pretty good approximations of full CLOS.
However, none of the CLOS derivatives for Scheme I have seen so far are
as complete as CLOS itself.
The paper "User-Level Language Crafting" by Andreas Paepcke gives an
excellent introduction to the CLOS MOP (and it should be relatively
straightforward to see how this maps to Tiny CLOS). You can find it on
his homepage.
There is, however, no substitute for reading The Art of the Metaobject
Protocol sooner or later. ;)
Pascal
just...@gmail.com
Whilst CLOS is very flexible, incredibly so compared to C++ for
example, there's nothing stopping you from completely ignoring that it
is there if you want to use some completely different OOP style. It's
pretty much the same as Scheme from that point of view, except that it
has a standard OOP system there if you want it.
Justin
George Neuner
>In <45c0f093$0$68952$742e...@news.sonic.net> Ray Dillinger wrote:
>>
>> And if you attempt to reuse code from several different projects,
>> as is typically the case with opensource programming, you learn
>> the true name of pain. Many of these extensions conflict with
>> each other, requiring namespace control. But many of the
>> module systems granting namespace control also conflict with
>> one another. And you start by trying to sort it out, and
>> if you're like me, end by throwing a bunch of stuff out the
>> window and coding it from scratch - again.
>
>Oh, that sounds really bad! But I thought the whole point of Scheme
>being a small language that wants to have libraries was a way to prevent
>this sad state of affairs. From what I've read from R6RS it seems these
>issues are addressed in this new standard. Wanna commoent on that?
>
It's not quite all that bleak. Writing portable code is an issue in
Scheme because of the large number of different implementations and
the fact that many aspects of the programming environment are not
standardized. But CL isn't really that much better - things like
GUIs, networking, conditions/exceptions[1], FFI, etc. are
implementation dependent in both languages.
CL's standard package and object system mean that more CL code is more
easily portable among implementations - but code which is not portable
in CL deals largely with same issues as code which is not portable in
Scheme.
Heavy-weight Scheme and CL implementations come with built-in
libraries for many common programming tasks. The solution for either
language is to pick one of these implementations and stick with it as
much as possible. Open source libraries usually try to support the
popular implementations, and when you must port something, the
heavy-weights generally have better documentation and more user
support available.
WRT R6RS, we'll have to wait until we have implementations and people
get some experience with it. The library system is similar enough to
CL's package system that it should provide many of the same benefits.
The exception system also appears inspired by CL's condition system -
and I predeict it will have the same portability problems (see [1]).
Regardless, if people use it, it will be an improvement over the
complete anarchy we have now.
George
[1] The CL standard defines the portable functions/macros and
semantics of the condition system. However there are only a few
conditions defined which all CL implementations must respect. Because
conditions are user definable, each implementation has defined its own
unique hierarchy.
--
for email reply remove "/" from address
joe nada
>
> It's not quite all that bleak. Writing portable code is an issue in
> Scheme because of the large number of different implementations and
> the fact that many aspects of the programming environment are not
> standardized. But CL isn't really that much better - things like
> GUIs, networking, conditions/exceptions[1], FFI, etc. are
> implementation dependent in both languages.
>
Yes, I've seen that. There's code for Franz Lisp, code for LispWorks,
code for MCL.
Code that runs on CMUCL, but that won't run on SBCL or CLisp.
Additionally, there's the problem of the platform you're on.
In the end, it's my impression that Common Lisoers stick to the
implementation they love, but they seem to be getting better at crossing
over to each other's implementations.
JN.
joe nada
> It's true that those languages have simple syntax.
> But they simply are not as flexible as scheme. You
> cannot compare different OO systems, for example, in
> smalltalk or Java. Nor can you compare side-effecting
> and non-side-effecting implementations of things in
> Haskell. etc. Each of those languages are exactly
> what they are, and don't provide *any* "good stuff"
> for experimenting with different types of languages.
> Scheme, on the other hand, is easily made into any
> language you want to talk or think about.
>
And then you built on top of that, instead of starting out with code
that looks esoteric because you need to get your head wrapped around a
1000 page manual.
This seems to be a winning strategy, syntax-wise, if we look at how the
community of programmers at large picked up their favorite languages (
Perl, when it was uncomplicated and immature, etc.)
On the other hand, after a certain point, it maybe a non-issue. In
languages like Perl or Ruby, you also get visual marks (visual cues -
Fortress will be sort of like that, too).
JN.
Bruce Lewis
> I remember trying BRL but I never went to MIT so the book talking
> about MIT's email system and its programability confused me. More
> time perhaps would have helped me...
> BRL!!!
You could have ignored the cgiemail references and moved forward, or you
can read http://web.mit.edu/wwwdev/cgiemail/user.html
Once you know what a cgiemail template is all the references make sense.
joe nada
> Paul Graham on his site mentions how he would choose common lisp over
> scheme because it has real macros. Do they (if they are still
> superior in 2007) make clisp a better choice for building web based e
> commerce apps today?
>
about porting Scheme to Common Lisp.
(Some panel he was on, with Guy Steele, too).
JN.
Ray Dillinger
> gavino wrote:
>
>> Paul Graham on his site mentions how he would choose common lisp over
>> scheme because it has real macros. Do they (if they are still
>> superior in 2007) make clisp a better choice for building web based e
>> commerce apps today?
>
>
> I don't know what you mean by "real" macros, but the specific
> characteristics of a macro system are completely unrelated to the
> possibility to develop web applications with the underlying language.
He means defmacro macrology as opposed to define-syntax
macrology. He doesn't want to be protected from variable
name capture, because sometimes he uses macros where such
capture is important and necessary to the purpose of the
macro.
Neither system is really "superior" as a programming tool,
IMO. defmacro macros can do some types of things that
define-syntax macros can't (affecting variables that don't
appear in their argument lists, behaving differently if
one of their arguments is named something different, etc).
But on the downside you have to be careful, and often even
add extra code, to avoid doing some of those things
accidentally. define-syntax macros (scheme's standard
macro system as of the time graham was writing his opinion)
won't ever have any captures, let alone accidental captures,
and so they are referentially transparent. That definitely
makes them easier to prove things about mathematically,
and more reliable when used in code whose programmer
isn't familiar with their exact implementation.
Anyway, Scheme is adopting a more general macro system
in R6RS, so the distinction is less urgent than it was.
Bear
Pascal Costanza
> Pascal Costanza wrote:
>> gavino wrote:
>>
>>> Paul Graham on his site mentions how he would choose common lisp over
>>> scheme because it has real macros. Do they (if they are still
>>> superior in 2007) make clisp a better choice for building web based e
>>> commerce apps today?
>>
>> I don't know what you mean by "real" macros, but the specific
>> characteristics of a macro system are completely unrelated to the
>> possibility to develop web applications with the underlying language.
>
> He means defmacro macrology as opposed to define-syntax
> macrology. He doesn't want to be protected from variable
> name capture, because sometimes he uses macros where such
> capture is important and necessary to the purpose of the
> macro.
Maybe, but I still don't see the relationship to "web based e commerce
apps".
Ray Dillinger
> Maybe, but I still don't see the relationship to "web based e commerce
> apps".
Yeah, me either. I ignore questions like that because
there's just really nothing interesting about the
applications that indicates one language over another,
and even if there was it would only mean that someone
needed to write a library.
Bear
prhlava
"gavino" <gavc...@gmail.com> wrote:
> I want to get a scheme environment going on arch linux. to learn
pacman -S drscheme
then start drscheme .
vlad