From: ccc31807
Subject: comparison of CL and Clojure
Date: 
Message-ID: <57361614-677d-4235-93e1-a0a4f459806b@y17g2000yqn.googlegroups.com>
Can anyone who has had experience with Common Lisp and Clojure be
willing to give an even-handed and non-prejudicial comparison of them:
similarities and differences, advantages and disadvantages.

I'm wondering whether it would be helpful to look at Clojure while in
the process of learning CL.

CC

From: vippstar
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <fdc4e922-8310-4572-8097-fe3894962bfa@j32g2000yqh.googlegroups.com>
On Jul 17, 11:45 pm, ccc31807 <········@gmail.com> wrote:
> Can anyone who has had experience with Common Lisp and Clojure be
> willing to give an even-handed and non-prejudicial comparison of them:
> similarities and differences, advantages and disadvantages.
>
> I'm wondering whether it would be helpful to look at Clojure while in
> the process of learning CL.

If you're learning CL, why would it be helpful to learn another
language? How would a comparison help you find out? You don't know
what it is that you need, do you? Don't learn two (or more)
programming languages at once, unless you are able to recognize &
categorize each feature of each language (ie you're stepping on stable
grounds).
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <97adc05d-b330-4cc8-8cbc-27ac3bac01c2@b15g2000yqd.googlegroups.com>
On Jul 17, 7:45 pm, vippstar <········@gmail.com> wrote:
> If you're learning CL, why would it be helpful to learn another
> language?

It wouldn't. I've found it helpful when learning a new language to
study several different resources in parallel, rather than rely on
just one resource completely. People like to say that Clojure is a
Lisp, and if this is the case, it would be simply another point of
view rather than another language. Actually, this was the question I
asked, rather than the answer I seek.

> How would a comparison help you find out? You don't know
> what it is that you need, do you? Don't learn two (or more)
> programming languages at once, unless you are able to recognize &
> categorize each feature of each language (ie you're stepping on stable
> grounds).

I constantly use multiple languages for projects, i.g. HTML, CSS, SQL,
JavaScript, Perl, PHP, etc. for a web based project. While in school,
I have sometimes had classes that used different languages, e.g.
assembly, Java, and C all in the same term. I agree that it's
confusing sometimes, but most of us have developed the ability to use
multiple technologies at the same time.

CC
From: Vsevolod Dyomkin
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <32130c97-3f77-4ee0-95c1-a50a2f7df206@d32g2000yqh.googlegroups.com>
On Jul 17, 11:45 pm, ccc31807 <········@gmail.com> wrote:
> Can anyone who has had experience with Common Lisp and Clojure be
> willing to give an even-handed and non-prejudicial comparison of them:
> similarities and differences, advantages and disadvantages.
>
> I'm wondering whether it would be helpful to look at Clojure while in
> the process of learning CL.
>
> CC

Clojure and Common Lisp have somewhat different philosophies.
While CL is a multi-paradigm language, whose main priorities are
flexibility and extensibility, Clojure is a more focused effort
strongly favoring functional programming over imperative, with an
accent on concurrency and intentional neglect of object-orientation.
In this regard, in my opinion, CL is more suited towards development
of large systems, while Clojure still has to show such ability. Both
are arguably very good languages for rapid prototyping, having an
excellent REPL and reflection. And Clojure should be a great choice
for a scripting language on the JVM.
Finally Clojure boasts, that it's an excellent language for
programming multicore systems.
Clojure is strongly influenced by CL, but it made some choices
explicitly different from CL. So Lars is right in this respect, that
it would be very easy to understand Clojure, knowing Common Lisp.
Well, vice versa should be correct as well (maybe just a little
harder).
The main differences are these:
1. Clojure is so-called Lisp-1 -- one common namespace language --
while CL is Lisp-n with multiple namespaces for variables, functions,
types etc.
2. Clojure is hosted solely on the JVM and has a single
implementation, while there are about 10 actively developed CL
implementations with either their own VMs, or residing on JVM and
such, or allowing compilation to native code.
3. Clojure uses different module/package management mechanism (the JVM
one).
4. Clojure uses the JVM calling convention, while CL uses it's own
(with multiple return values and keyword arguments).
5. Clojure provides built-in a lot of concurrency primitives, as well
as lazy evaluation, while in CL those are only available as libraries
or implementation-specific enhancements.
6. Clojure uses the JVM exception handling facilities, while CL has
it's own (much more advanced) signal protocol.
There are surely other differences, that I've forgot to mention.
Overall, my opinion is that both are very good programming languages,
actually, the best ones around now. For me CL is a much better one,
but that is, obviously, my personal preference.
It's a pity, that Clojure is often contrasted to CL as some more
`modern' language, because in CL there is still a lot of features,
that other `more modern' languages yet couldn't provide. And,
moreover, since modern is a very opportunistic (some would say, purely
`marketing') term.

Best regards,
Vsevolod Dyomkin
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <df25c26e-17e0-457f-8b79-ccf1ed9b203d@y7g2000yqa.googlegroups.com>
Thank you very much. Earlier this year, I purchased Joe Armstrong's
book 'Programming Erlang' and read through it. This helped me quite a
bit with recursion and modularity, and Erlang lacks built-in iteration
and the basic building blocks of apps are modules.

I've studied three CL books by now (Seibel, Wilensky, and am working
on W and H) and am to the point where I want to write apps that I can
deliver to clients, so having something that runs on the JVM looks
appealing to me.

If I may ask you to elaborate a little further: C, C++, and CLR-C++
(the MS version) are essentially the same language, as are the
different Java versions. Is the difference between CL and Clojure
comparable to this (identical syntax with added functionality) or
would it be closer to the difference between Perl and Python, or Perl
and Ruby?

Thanks, CC.

On Jul 18, 4:01 am, Vsevolod Dyomkin <········@gmail.com> wrote:
> On Jul 17, 11:45 pm, ccc31807 <········@gmail.com> wrote:
>
> > Can anyone who has had experience with Common Lisp and Clojure be
> > willing to give an even-handed and non-prejudicial comparison of them:
> > similarities and differences, advantages and disadvantages.
>
> > I'm wondering whether it would be helpful to look at Clojure while in
> > the process of learning CL.
>
> > CC
>
> Clojure and Common Lisp have somewhat different philosophies.
> While CL is a multi-paradigm language, whose main priorities are
> flexibility and extensibility, Clojure is a more focused effort
> strongly favoring functional programming over imperative, with an
> accent on concurrency and intentional neglect of object-orientation.
> In this regard, in my opinion, CL is more suited towards development
> of large systems, while Clojure still has to show such ability. Both
> are arguably very good languages for rapid prototyping, having an
> excellent REPL and reflection. And Clojure should be a great choice
> for a scripting language on the JVM.
> Finally Clojure boasts, that it's an excellent language for
> programming multicore systems.
> Clojure is strongly influenced by CL, but it made some choices
> explicitly different from CL. So Lars is right in this respect, that
> it would be very easy to understand Clojure, knowing Common Lisp.
> Well, vice versa should be correct as well (maybe just a little
> harder).
> The main differences are these:
> 1. Clojure is so-called Lisp-1 -- one common namespace language --
> while CL is Lisp-n with multiple namespaces for variables, functions,
> types etc.
> 2. Clojure is hosted solely on the JVM and has a single
> implementation, while there are about 10 actively developed CL
> implementations with either their own VMs, or residing on JVM and
> such, or allowing compilation to native code.
> 3. Clojure uses different module/package management mechanism (the JVM
> one).
> 4. Clojure uses the JVM calling convention, while CL uses it's own
> (with multiple return values and keyword arguments).
> 5. Clojure provides built-in a lot of concurrency primitives, as well
> as lazy evaluation, while in CL those are only available as libraries
> or implementation-specific enhancements.
> 6. Clojure uses the JVM exception handling facilities, while CL has
> it's own (much more advanced) signal protocol.
> There are surely other differences, that I've forgot to mention.
> Overall, my opinion is that both are very good programming languages,
> actually, the best ones around now. For me CL is a much better one,
> but that is, obviously, my personal preference.
> It's a pity, that Clojure is often contrasted to CL as some more
> `modern' language, because in CL there is still a lot of features,
> that other `more modern' languages yet couldn't provide. And,
> moreover, since modern is a very opportunistic (some would say, purely
> `marketing') term.
>
> Best regards,
> Vsevolod Dyomkin
From: Vsevolod Dyomkin
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <355cfd1a-2215-4e87-a3a0-122993e03399@y17g2000yqn.googlegroups.com>
On Jul 18, 5:27 pm, ccc31807 <········@gmail.com> wrote:
> I've studied three CL books by now (Seibel, Wilensky, and am working
> on W and H) and am to the point where I want to write apps that I can
> deliver to clients, so having something that runs on the JVM looks
> appealing to me.
There's also a Common Lisp implementation, running on the JVM: ABCL

> If I may ask you to elaborate a little further: C, C++, and CLR-C++
> (the MS version) are essentially the same language, as are the
> different Java versions. Is the difference between CL and Clojure
> comparable to this (identical syntax with added functionality) or
> would it be closer to the difference between Perl and Python, or Perl
> and Ruby?
First, I wouldn't say, that C and C++ are essentially the same
language, as C doesn't have exceptions, classes, STL and streams. But
in terms of syntax CL and Clojure have quite similar (but still
different) syntax, much like C and C++. In terms of semantics the
difference is even bigger, than between C and C++: CL and Clojure are
two distinct languages and not inter-operable the same as C and C++
are. Comparing to Python/Perl or Perl/Ruby I would say, that syntactic
difference is much smaller between Lisps, while semantic difference is
substantially greater (we are talking different underlying concepts
like: immutable data structures vs mutable, no OOP vs generic
functions based OOP, 1 namespace vs several namespaces), while Perl/
Python/Ruby are based on essentially one common set of concepts:
scripting/conventional OOP/single namespace/... But it's hard to draw
clear parallels here.

Best regards,
Vsevolod
From: A.L.
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <h4o365dlhsl14m9gvl5vlicvvo4vvkdlfk@4ax.com>
On Sat, 18 Jul 2009 07:27:40 -0700 (PDT), ccc31807
<········@gmail.com> wrote:

>Thank you very much. Earlier this year, I purchased Joe Armstrong's
>book 'Programming Erlang' and read through it. This helped me quite a
>bit with recursion and modularity, and Erlang lacks built-in iteration
>and the basic building blocks of apps are modules.

Buy and read book about Clojure

Programming Clojure (Pragmatic Programmers) 
by Stuart Halloway  

More books are expected.

>
>If I may ask you to elaborate a little further: C, C++, and CLR-C++
>(the MS version) are essentially the same language, as are the
>different Java versions.     

No, there are different Java vendors and supporters but Java is the
same. Java can be called "Java" only if it passes Sun's (now Oracle)
validation tests.

Closure is Lisp LIKE language that easily integrates with components
written in Java. This is NOT Lisp, or you can say that this is
stripped down and "decorated" Lisp.

This is same story like with Prolog and Visual Prolog. Although Visual
Prolog has "Prolog" in its name, and most constructs of real Prolog
are available in Visual Prolog, there are some critical pieces missing
(metaprogramming) and some critical extension made (strong typing).
Therefore, Visual Prolog is not Prolog. It is "prologish"

Ii is good that authors of Clojure named it "Clojure", but not "Java
Lisp". This is not Lisp. Maybe it is closer to Scheme, but I have no
opinion in this matter

However, it doesn't matter, really. There is HUGE interest in Clojure
and Scala among Java community, and definitely something is going on.
Jave people feel that with conventional programming style they are
hitting the wall, and something must be done to handle complexity.
Clojure and Scala come in right times... The same with F# in .NET
world.

A.L.
From: Robert Uhl
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <m3bpnhn0st.fsf@latakia.octopodial-chrome.com>
ccc31807 <········@gmail.com> writes:
>
> I've studied three CL books by now (Seibel, Wilensky, and am working
> on W and H) and am to the point where I want to write apps that I can
> deliver to clients, so having something that runs on the JVM looks
> appealing to me.

Not that you can deliver SBCL applications with
SB-EXT:SAVE-LISP-AND-DIE, and you can also deliver on the JVM with Armed
Bear Common Lisp <http://common-lisp.net/project/armedbear/>.

> If I may ask you to elaborate a little further: C, C++, and CLR-C++
> (the MS version) are essentially the same language, as are the
> different Java versions. Is the difference between CL and Clojure
> comparable to this (identical syntax with added functionality) or
> would it be closer to the difference between Perl and Python, or Perl
> and Ruby?

Very much the latter.

-- 
Robert A. Uhl
But it's more than that, of course; bad spelling just isn't respectable.
You may, perhaps, want to lament this fact.  You are free to do so.  The
fact remains.                                            --John Mitchell
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <0daa5c25-4464-41ac-9de1-a6b5ce548e4e@h31g2000yqd.googlegroups.com>
On Jul 18, 5:22 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> But it's more than that, of course; bad spelling just isn't respectable.
> You may, perhaps, want to lament this fact.  You are free to do so.  The
> fact remains.    

One of my favorite presidential quotes is by Andrew Jackson, who
purportedly said that he didn't have very much respect for any man who
knew only one way to spell a word.

Spelling is only a convention. Words are merely symbols. What counts
is the reality that words point to. IMO we as a culture are headed
toward exaltation of the symbol at the expense of reality, and
eventually it will bite us in the rear end.

Not Lisp related, sorry. CC.
From: Kenneth Tilton
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <4a62a8cf$0$22522$607ed4bc@cv.net>
ccc31807 wrote:
> On Jul 18, 5:22 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> But it's more than that, of course; bad spelling just isn't respectable.
>> You may, perhaps, want to lament this fact.  You are free to do so.  The
>> fact remains.    
> 
> One of my favorite presidential quotes is by Andrew Jackson, who
> purportedly said that he didn't have very much respect for any man who
> knew only one way to spell a word.
> 
> Spelling is only a convention. Words are merely symbols. What counts
> is the reality that words point to.

Words do not point to any one reality which is why natural language is 
useless for communication.

> IMO we as a culture are headed
> toward exaltation of the symbol at the expense of reality, and
> eventually it will bite us in the rear end.

So we should communicate without symbols? This should be intereswting.

kt
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <3e2ea078-2f97-4334-8dbf-9bb11cbee6c0@y19g2000yqy.googlegroups.com>
On Jul 19, 1:02 am, Kenneth Tilton <·········@gmail.com> wrote:
> > Spelling is only a convention. Words are merely symbols. What counts
> > is the reality that words point to.
>
> Words do not point to any one reality which is why natural language is
> useless for communication.

This gets into a discussion of what 'reality' consists of, and I don't
want to go there. I'm pretty much of an objectivist when it comes to
it, so this should tell you which side I will come down on.

There are at least two problems: First, people have different ideas of
the content of a symbol. 'Marriage' is an example -- some people think
it's a relationship between a husband and a wife, while others think
it's a relationship between to people not necessarily husband and
wife. Second, people have different ideas of the symbol itself. 'Hot'
is an example when used to describe a car. Is a 'hot car' one that
goes very fact, one that has been stolen, one that has been heated to
a high temperature, or one that many people are buying?

> > IMO we as a culture are headed
> > toward exaltation of the symbol at the expense of reality, and
> > eventually it will bite us in the rear end.
>
> So we should communicate without symbols? This should be intereswting.

No, no, no. What I mean is that we mistake the reality for the form,
and think that if we have the form we have the substance. For example,
consider 'happiness.' Many think that happiness is an end in itself --
consequently they attempt to 'be happy.' IMO, happiness is the by-
product that occurs when you are accomplishing some great end, doing
something you enjoy greatly, or in a period of significant
productivity. I think that a large part of the problem with drugs,
sexuality, alcohol, and the rest of our cultural dysfunctionality, is
that we as a society are focused too much on short term feelings
rather than long term accomplishments. A symptom of this is that we
have invested so much in the word itself rather than the content of
the word.

'The map is not the territory.' If you haven't heard this, Google it.

CC
From: Raffael Cavallaro
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <h3vect$srq$1@news.eternal-september.org>
On 2009-07-19 07:36:16 -0400, ccc31807 <········@gmail.com> said:

> 'The map is not the territory.' If you haven't heard this, Google it.

Wow. Just want to chime in here to say that this is one of the most 
condescending things I've ever seen on usenet. Just how deep and dark a 
cave do you think someone has to have been living in to never have 
heard this?

Your naive "objectivism" begs the question (in the original sense). 
Once you assume that there is a single "objective" reality it is a 
triviality that the linguistic problem reduces to what the chinese 
called "the rectification of names." I.e., simply matching the standard 
phraseology to the particular, well defined, objective phenomenon.

The whole philosphical issue (which Kenny correctly raised) is that 
there are a multitude of different ways to dice and slice the 
pheonomenal world (hell, even the greatest physicists on the planet are 
in fundamental disagreement as to whether there exist whole other 
parallel universes!).

"The map is not the territory" doesn't mean "your phraseology doesn't 
correspond to the one true conceptualization of the phenomenal world." 
"The map is not the territory" means "any map (i.e., conceptualization) 
you can come up with is just one of many possible maps becuase the 
territory (the phenomenal world) can never fully described by any 
single conceptual map ."
-- 
Raffael Cavallaro
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <1cb4a5b7-2dd3-4a26-8d5f-6b26333d66b5@o15g2000yqm.googlegroups.com>
On Jul 19, 11:33 am, Raffael Cavallaro
<················@pas.espam.s.il.vous.plait.mac.com> wrote:
> > 'The map is not the territory.' If you haven't heard this, Google it.
>
> Wow. Just want to chime in here to say that this is one of the most
> condescending things I've ever seen on usenet. Just how deep and dark a
> cave do you think someone has to have been living in to never have
> heard this?

Not at all meant to be condescending. Answering your question, plenty
of people have never heard this. I have a liberal arts academic
background and touched on general semantics a long time ago. Now I'm
mostly around technical types, and find that not only have most never
heard of it, most are not interested.

> Your naive "objectivism" begs the question (in the original sense).
> Once you assume that there is a single "objective" reality it is a
> triviality that the linguistic problem reduces to what the chinese
> called "the rectification of names." I.e., simply matching the standard
> phraseology to the particular, well defined, objective phenomenon.

The only thing I claim is that the objective world is 'real' in some
way independent of human cognizance. It would still 'exist' even if
humans didn't. This doesn't even attempt to consider the question of
epistemology, how we know the objective world.

> The whole philosphical issue (which Kenny correctly raised) is that
> there are a multitude of different ways to dice and slice the
> pheonomenal world (hell, even the greatest physicists on the planet are
> in fundamental disagreement as to whether there exist whole other
> parallel universes!).

I don't think it's philosophy as much as what used to be called
natural philosophy. That's the beauty of science -- we can engage in
empirical and observational practices without any preconceived notion
of what the stuff we are looking at consists of. In theory, anyway.

> "The map is not the territory" doesn't mean "your phraseology doesn't
> correspond to the one true conceptualization of the phenomenal world."

Of course not. What it means to me is that the word is not the thing.
We have this prescriptive notion running amok and people don't even
think about the descriptive nature of words. Case in point: marriage.
People think that 'changing the definition' of marriage will change
marriage in some way, not understanding that the <complex of events
and attributes> to which we have applied the symbol 'marriage' isn't
determined by the meaning we prescriptively attach to the word. This
is just one example of something that is widespread.

> "The map is not the territory" means "any map (i.e., conceptualization)
> you can come up with is just one of many possible maps becuase the
> territory (the phenomenal world) can never fully described by any
> single conceptual map ."

I never bought into General Semantics in a big way. I like the
practice of e-prime and actually practice it from time to time, but
that's about the extent of it. (Whenever I make a formal presentation,
I use e-prime, and have since about 1970, but I'm certainly not
fanatic about it, as you can tell from this sentence.)

CC
From: Pascal J. Bourguignon
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <87ab30dc3l.fsf@galatea.local>
ccc31807 <········@gmail.com> writes:
> There are at least two problems: First, people have different ideas of
> the content of a symbol. 'Marriage' is an example -- some people think
> it's a relationship between a husband and a wife, while others think
> it's a relationship between to people not necessarily husband and
> wife. Second, people have different ideas of the symbol itself. 'Hot'
> is an example when used to describe a car. Is a 'hot car' one that
> goes very fact, one that has been stolen, one that has been heated to
> a high temperature, or one that many people are buying?

You're confusing words and symbols.
There is one word, "hot", and several symbols:
FAST, STOLEN, HOT, SEXY, UNDER-TENSION, etc..

The work of NLP is to map the words to the right symbols.

Notice that you may be lazy, and name your symbols the same, #1=#:HOT
and #2=#:HOT but they will have different properties, and still be
different symbols meaning something else.


-- 
__Pascal Bourguignon__
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <9fedd0e5-54b6-4007-8280-c83e2bcdab22@a7g2000yqk.googlegroups.com>
On 19 Jul., 13:36, ccc31807 <········@gmail.com> wrote:

> consider 'happiness.' Many think that happiness is an end in itself --
> consequently they attempt to 'be happy.' IMO, happiness is the by-
> product that occurs when you are accomplishing some great end, doing
> something you enjoy greatly, or in a period of significant
> productivity. I think that a large part of the problem with drugs,
> sexuality, alcohol, and the rest of our cultural dysfunctionality, is
> that we as a society are focused too much on short term feelings
> rather than long term accomplishments. A symptom of this is that we
> have invested so much in the word itself rather than the content of
> the word.

Yesterday I was happy while seeing a grey heron sitting on a fence
at a pond where he was waiting for some unwary frog to appear.
From: Tetrahedral Quartz
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <h41hj9$kn8$1@aioe.org>
Rainer Joswig wrote:
> On 19 Jul., 13:36, ccc31807 <········@gmail.com> wrote:
> 
>> consider 'happiness.' Many think that happiness is an end in itself --
>> consequently they attempt to 'be happy.' IMO, happiness is the by-
>> product that occurs when you are accomplishing some great end, doing
>> something you enjoy greatly, or in a period of significant
>> productivity. I think that a large part of the problem with drugs,
>> sexuality, alcohol, and the rest of our cultural dysfunctionality, is
>> that we as a society are focused too much on short term feelings
>> rather than long term accomplishments. A symptom of this is that we
>> have invested so much in the word itself rather than the content of
>> the word.
> 
> Yesterday I was happy while seeing a grey heron sitting on a fence
> at a pond where he was waiting for some unwary frog to appear.

The pigeons roost in the clock tower at midnight.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009072018384375249-tfb@cleycom>
On 2009-07-20 11:40:32 +0100, Tetrahedral Quartz <········@gmail.com> said:

> The pigeons roost in the clock tower at midnight.

The helicopters have been dispatched
From: Slobodan Blazeski
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <b5d87da9-5827-426e-8135-05612c559dec@k1g2000yqf.googlegroups.com>
On Jul 20, 11:17 am, Rainer Joswig <······@lisp.de> wrote:
>
> Yesterday I was happy while seeing a grey heron sitting on a fence
> at a pond where he was waiting for some unwary frog to appear.

Please send him to c.l.l. we have one frog too many

bobi
From: Giorgos Keramidas
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <87k52583mr.fsf@kobe.laptop>
On Sun, 19 Jul 2009 01:02:05 -0400, Kenneth Tilton <·········@gmail.com> wrote:
>> IMO we as a culture are headed toward exaltation of the symbol at the
>> expense of reality, and eventually it will bite us in the rear end.
>
> So we should communicate without symbols? This should be intereswting.

I believe this has been described in Gulliver's Travels.  Quoting from
the online copy at Project Gutenberg[1]:

    "We crossed a walk to the other part of the academy, where, as I
    have already said, the projectors in speculative learning resided.
    ...

    The other project was, a scheme for entirely abolishing all words
    whatsoever; and this was urged as a great advantage in point of
    health, as well as brevity.  For it is plain, that every word we
    speak is, in some degree, a diminution of our lunge by corrosion,
    and, consequently, contributes to the shortening of our lives.  An
    expedient was therefore offered, "that since words are only names
    for things, it would be more convenient for all men to carry about
    them such things as were necessary to express a particular business
    they are to discourse on."
    ...
    I have often beheld two of those sages almost sinking under the
    weight of their packs, like pedlars among us, who, when they met in
    the street, would lay down their loads, open their sacks, and hold
    conversation for an hour together; then put up their implements,
    help each other to resume their burdens, and take their leave.

This should be interesting indeed.  I imagine a similar scheme would
have a deep, lasting and profound effect on the talks given by, oh, say,
politicians and news-casters, to name just a few.

[1] http://www.gutenberg.org/etext/829

PS: Just to bring things a bit back on topic, did anyone else notice
that the F# spammer posts in *support* of a Lisp language now?  It's
about Clojure instead of CL, but that's also an interesting change :-)
From: Kenneth Tilton
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <4a63dc0a$0$22521$607ed4bc@cv.net>
> PS: Just to bring things a bit back on topic, did anyone else notice
> that the F# spammer posts in *support* of a Lisp language now?

Yep. Says it all about the superiority of CL, the inferiority of F#, and 
the mediocrity of His Frogginess.

kt
From: Pascal J. Bourguignon
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <87iqhpc7j4.fsf@galatea.local>
ccc31807 <········@gmail.com> writes:

> On Jul 18, 5:22 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
>> But it's more than that, of course; bad spelling just isn't respectable.
>> You may, perhaps, want to lament this fact.  You are free to do so.  The
>> fact remains.    
>
> One of my favorite presidential quotes is by Andrew Jackson, who
> purportedly said that he didn't have very much respect for any man who
> knew only one way to spell a word.
>
> Spelling is only a convention. Words are merely symbols. What counts
> is the reality that words point to. IMO we as a culture are headed
> toward exaltation of the symbol at the expense of reality, and
> eventually it will bite us in the rear end.
>
> Not Lisp related, sorry. CC.

On the contrary, it's perfectly well related to lisp and all computer matters.

But we have a problem of terminology here.



You say that word = symbol and that there's a mapping from the set of
words (your "symbols") to the set of realities.

In Lisp, what represents the reality (and IS a reality inside the lisp
system), is the SYMBOL.  Which has only one name, which is a STRING.
We could introduce the notion of word in lisp, implementing it as a
string, and we could design a mapping from words to symbols.  We could
have several words mapping to the same symbol.

For example:  "rain"   -> RAIN
              "pluie"  -> RAIN
              "lluvia" -> RAIN

And indeed, there could be an exaltation of the words at the expense
of symbols (denoting the reality).  But for this we will have to wait
for an increased diffusion of NLP systems.


However, Jackson's quote means something different.  You can spell
only phonetic occurences.  So what he calls "word" is actually a
sound.  (This is to be expected, orality of the culture varies along
time, inversely proportional to the degree of civilisation).  And
notice how strongly he defends the spellings, that is the written
forms (what you call "words") against what he considers, in his oral
culture mindset, the primary representant, the phonetic word.  The
point of these different written forms is that they map to different
(lisp) symbols or realities.  He is saying that different realities
may be denoted by the same phonems, as can be detected when you write
the words, from their different spelling.  Therefore he takes the
point of view of Lisp, with clear distinguished "written words" = lisp
symbols denoting disintinguished realities.

        pēs  --> "peace" --> PAX
             --> "piece" --> CHUNK

Spelling is not only a convention, it is what allows you to
distinguish the meaning of the phonems.  The written forms (at least
in civilized languages) are more precise than the oral forms, they
convey more sense, and indicate more precisely what reality is
denoted.



Finally, and this is not mentionned directly by Jackson, remains the
problem of the context.  You could speak smurf, and still associate a
correct meaning to meaningless words (even with several spellings),
given a context.  Personnaly, I don't find that very interesting,
because this only shows that the amount of information transmited is
close to 0.  I'd rather not speak, like native americans...  But
nonetheless, such a feature is useful as an error correction code in
language parsers.  So if that highly regarded person by our Jackson
writes: "Israel and Palesitine agreed to make piece next week", you
could correct it into  "Israel and Palesitine agreed to make peace
next week" (personnally, I don't agree with Jackson, I'd tend to
qualify that guy of sloppy at least).  And vice versa if he wrote
"Nikolaus and Rudolf agreed to make peace next week.", you could guess
that he really means "Nikolaus and Rudolf agreed to make a piece next
week.", assuming Nioklaus August Otto and Rudolf Diesel worked
together on some car part.  In any case, in this respect the ability
to find different spelling of a same phonem is of no use if you cannot
find the RIGHT spelling!  But what can you expect from presidents of
the USA (or any other democracy for that matter).



Unfortunately, with the advent of the audio-visual media, people can't
spell anymore: they're losing the precision of language embedded in
the spelling, we're returning to a kind of oral culture, or even
worse, we're falling back to the emotionality imposed by the televised
images without any higher thinking.  Technology is not a guarantee of
civilization...


-- 
__Pascal Bourguignon__
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <7a81610a-312b-4189-9c13-5a72d4f3b64b@n11g2000yqb.googlegroups.com>
Forgive me for not responding to most of what you said. I'll revisit
this tomorrow.

On Jul 19, 6:05 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> ccc31807 <········@gmail.com> writes:
> > On Jul 18, 5:22 pm, Robert Uhl <·········@NOSPAMgmail.com> wrote:
> >> But it's more than that, of course; bad spelling just isn't respectable.
> >> You may, perhaps, want to lament this fact.  You are free to do so.  The
> >> fact remains.    
>
> > One of my favorite presidential quotes is by Andrew Jackson, who
> > purportedly said that he didn't have very much respect for any man who
> > knew only one way to spell a word.
<snip />

> However, Jackson's quote means something different.  You can spell
> only phonetic occurences.  So what he calls "word" is actually a
> sound.  (This is to be expected, orality of the culture varies along
> time, inversely proportional to the degree of civilisation).  And
> notice how strongly he defends the spellings, that is the written
> forms (what you call "words") against what he considers, in his oral
> culture mindset, the primary representant, the phonetic word.  The
> point of these different written forms is that they map to different
> (lisp) symbols or realities.  He is saying that different realities
> may be denoted by the same phonems, as can be detected when you write
> the words, from their different spelling.  Therefore he takes the
> point of view of Lisp, with clear distinguished "written words" = lisp
> symbols denoting disintinguished realities.

You are putting way too much importance into my little joke. I agree
that meaning in many cases depends upon the exact written
representation of a word. However, there is a legal doctrine of long
standing called 'idem sonans' which conveys the idea that like
sounding names are the same name, thus 'Stewart' and 'Stuart' are the
same person, as are 'Jonson', 'Johnson', 'Johnston',' and 'Johnstone'.
My larger point, if there is one, is that formal education isn't
essential to either life or success, and it carries its own burdens
and deficiencies.


<snip />

> Finally, and this is not mentionned directly by Jackson, remains the
> problem of the context.  You could speak smurf, and still associate a
> correct meaning to meaningless words (even with several spellings),
> given a context.  Personnaly, I don't find that very interesting,
> because this only shows that the amount of information transmited is
> close to 0.  I'd rather not speak, like native americans...  But
> nonetheless, such a feature is useful as an error correction code in
> language parsers.  So if that highly regarded person by our Jackson
> writes: "Israel and Palesitine agreed to make piece next week", you
> could correct it into  "Israel and Palesitine agreed to make peace
> next week" (personnally, I don't agree with Jackson, I'd tend to
> qualify that guy of sloppy at least).

It was meant as a joke. Don't you see the humor in it? Also, it has an
element of truth, like all jokes.

> And vice versa if he wrote
> "Nikolaus and Rudolf agreed to make peace next week.", you could guess
> that he really means "Nikolaus and Rudolf agreed to make a piece next
> week.", assuming Nioklaus August Otto and Rudolf Diesel worked
> together on some car part.  In any case, in this respect the ability
> to find different spelling of a same phonem is of no use if you cannot
> find the RIGHT spelling!  But what can you expect from presidents of
> the USA (or any other democracy for that matter).

See above. In older legal documents, names tend to be variable,
including names of more formal legal entities like corporations.
Sloppy? Yes, but that's simply the way it is. People call me, both
orally and in writing, Chuck, Charles, and Charlie. I'm the same
person, even if someone calls me Doofas.

> Unfortunately, with the advent of the audio-visual media, people can't
> spell anymore: they're losing the precision of language embedded in
> the spelling, we're returning to a kind of oral culture, or even
> worse, we're falling back to the emotionality imposed by the televised
> images without any higher thinking.  Technology is not a guarantee of
> civilization...

And I disagree very strongly with this, and think it's just the
opposite. Compare Shakespeare's plays where he seems to make up
spellings as he goes along. Technology means that we have become more
dependent on the written form of words, not less. I don't think we are
returning to a more oral culture, I think that we are losing what
little oral culture remains.

CC
From: w_a_x_man
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <b825bb63-d6dd-46e2-9f30-0eda259da168@a7g2000yqk.googlegroups.com>
On Jul 18, 8:30 pm, ccc31807 <········@gmail.com> wrote:

> One of my favorite presidential quotes is by Andrew Jackson, who
> purportedly said that he didn't have very much respect for any man who
> knew only one way to spell a word.
>
> Spelling is only a convention. Words are merely symbols. What counts
> is the reality that words point to.

Unto the right high mighti and doubtid Prynsace the Quen of
Implande, one that was your Servaunt but now beinge both a
Traitor and a manifald parjured Traitor, which Heaven above doth
abhorre, the erth below detest, the sun moone and starres be
eschamed of, and all Creatures doo curse and ajudge unworthy of
breth and life, do wish onelie to die your Penytent. In hevye
sorrowe doo send you these advisoes which I requyre your Mageste
in umblest manner to pondur wel, seeinge ells your manyfest
Overthrowe and Rwyn att hand. And albeit in Carcee you reste in
securitie, it is serten you are there as saife as he that
hingeth by the Leves of a Tree in the end of Autumpne when as
the Leves begin to fall. For in this late Battaile in
Mellicafhaz Sea hath the whole powre of Wychlande on the sea
been beat downe and ruwyned, and the highe Admirall of our whole
Navie loste and ded and the names of the great men of accownte
that were slayen at the battaile I may not numbre nor the common
sorte much lesse by reaisoun that the more part were dround in
the sea which came not to Syght. But of Daemounlande not ij
schips companies were lossit, but with great puissaunce they doo
buske them for Carsee. Havinge with them this Gowldri Bleusco,
strangely reskewed from his preassoun-house beyond the toombe,
and a great Armey of the moste strangg and fell folke that ever
I saw or herd speke of. Such is the Die of Warre.

E. R. Eddison, _The Worm OUroboros_, 1922
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <DLmdnVjiyf-8j_zXnZ2dnUVZ8hOdnZ2d@brightview.co.uk>
ccc31807 wrote:
> Can anyone who has had experience with Common Lisp and Clojure be
> willing to give an even-handed and non-prejudicial comparison of them:
> similarities and differences, advantages and disadvantages.
> 
> I'm wondering whether it would be helpful to look at Clojure while in
> the process of learning CL.

Clojure sheds a lot of CL's baggage to make for a much cleaner language and
incorporates many modern features like decent interop and concurrent GC.
Consequently, it is one of the only Lisp-related technologies that is not
in decline:

  http://www.google.com/trends?q=clojure%2Ccommon+lisp

I recommend learning Clojure and Scheme and forgetting about CL.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Lars Rune Nøstdal
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <8b2983bd-7eab-4d45-a887-8731c2a59002@k1g2000yqf.googlegroups.com>
On Jul 18, 3:16 am, Jon Harrop <····@ffconsultancy.com> wrote:
> ccc31807 wrote:
> > Can anyone who has had experience with Common Lisp and Clojure be
> > willing to give an even-handed and non-prejudicial comparison of them:
> > similarities and differences, advantages and disadvantages.
>
> > I'm wondering whether it would be helpful to look at Clojure while in
> > the process of learning CL.

Learning, understanding and comparing CL with Clojure yourself is easy
once you know CL. You'll have enough trouble learning Lisp (the common
stuff) anyway.

I do not see myself switching to something running on the JVM easily
as I got everything I need; a good compiler, threads, sockets,
database access and libraries.


On Jul 18, 3:16 am, Jon Harrop <····@ffconsultancy.com> wrote:
> concurrent GC.

Someone is working on concurrent GC for SBCL.
From: Lars Rune Nøstdal
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <40fc0c9e-d06c-4f36-869c-85c287a3fabb@g31g2000yqc.googlegroups.com>
On Jul 18, 4:53 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Jul 18, 3:16 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > ccc31807 wrote:
> > > Can anyone who has had experience with Common Lisp and Clojure be
> > > willing to give an even-handed and non-prejudicial comparison of them:
> > > similarities and differences, advantages and disadvantages.
>
> > > I'm wondering whether it would be helpful to look at Clojure while in
> > > the process of learning CL.
>
> Learning, understanding and comparing CL with Clojure yourself is easy
> once you know CL. You'll have enough trouble learning Lisp (the common
> stuff) anyway.

Uh, "Comparing CL with Clojure yourself is ...."

..anyway, don't pay too much attention to the infamous JH; make up
your own opinions.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071810263816807-tfb@cleycom>
On 2009-07-18 02:16:28 +0100, Jon Harrop <···@ffconsultancy.com> said:

> Clojure sheds a lot of CL's baggage to make for a much cleaner language and
> incorporates many modern features like decent interop and concurrent GC.

Is there some reason CL implementations could not have concurrent GC?
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <G_qdnVVI79poMfzXnZ2dnUVZ8u6dnZ2d@brightview.co.uk>
Tim Bradshaw wrote:
> On 2009-07-18 02:16:28 +0100, Jon Harrop <···@ffconsultancy.com> said:
>> Clojure sheds a lot of CL's baggage to make for a much cleaner language
>> and incorporates many modern features like decent interop and concurrent
>> GC.
> 
> Is there some reason CL implementations could not have concurrent GC?

No theoretical reason.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: ok
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <e8015a70-41f8-450b-983b-7ab403ab1028@s31g2000yqs.googlegroups.com>
In 3rd millennium of human enlightenment, JH wrote:
> > Is there some reason CL implementations could not have concurrent GC?
>
> No theoretical reason.

And how did you spot that?
Did you infer solid practice from hypothetical theory?
Or did you make up your theory from never happened practice?

Or both?
Or nothing?
Or all?
From: John Thingstad
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <op.uw9k4mxvut4oq5@pandora>
På Sat, 18 Jul 2009 11:26:38 +0200, skrev Tim Bradshaw <···@cley.com>:

> On 2009-07-18 02:16:28 +0100, Jon Harrop <···@ffconsultancy.com> said:
>
>> Clojure sheds a lot of CL's baggage to make for a much cleaner language  
>> and
>> incorporates many modern features like decent interop and concurrent GC.
>
> Is there some reason CL implementations could not have concurrent GC?
>

No. Sceineer has one and LispWorks has one under development.
Franz is working on one and I have heard (unverified) that SBCL is too.
So this should be viewed and a temporary state of things. Lisp companies  
have fewer employees than java has so things take a bit longer. Withing a  
couple of years I would think most Lispers will be working with a 64 bit  
lisp with concurrent processing.

---------------
John Thingstad
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <f69af3b6-612c-4a01-b722-380ab212022e@d4g2000yqa.googlegroups.com>
On 18 Jul., 15:01, "John Thingstad" <·······@online.no> wrote:
> På Sat, 18 Jul 2009 11:26:38 +0200, skrev Tim Bradshaw <····@cley.com>:
>
> > On 2009-07-18 02:16:28 +0100, Jon Harrop <····@ffconsultancy.com> said:
>
> >> Clojure sheds a lot of CL's baggage to make for a much cleaner language  
> >> and
> >> incorporates many modern features like decent interop and concurrent GC.
>
> > Is there some reason CL implementations could not have concurrent GC?
>
> No. Sceineer has one and LispWorks has one under development.
> Franz is working on one and I have heard (unverified) that SBCL is too.
> So this should be viewed and a temporary state of things. Lisp companies  
> have fewer employees than java has so things take a bit longer. Withing a  
> couple of years I would think most Lispers will be working with a 64 bit  
> lisp with concurrent processing.
>
> ---------------
> John Thingstad

Concurrent GC and concurrent execution are not the same.

I don't know any current Common Lisp implementation with a concurrent
GC -
with the possible exception of ABCL, which might use the JVM
GC in concurrent mode. Is there even a parallel GC?

The concurrent GC runs concurrently to the user code.
The parallel GC does its work on more than one core, but may stop user
code.

So what one might want is a concurrent and parallel GC. But there is
no free lunch.
It comes with a cost. Note though that on the JVM you have to enable
the concurrent GC
and that SUN warns that it decreases 'application throughput'.

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#available_collectors

   'It is designed for applications with medium- to large-sized data
sets for which response time is more important than overall
throughput, since the techniques used to minimize pauses can reduce
application performance.'

You can imagine that for a lot of larger Lisp applications response
time is less important than overall throughput and thus the concurrent
GC is useless anyway.

Harrop uses it only to mention something that CL implementations don't
provide, but other products have. A marketing trick.
He has no idea if any Lisp application actually needs it, because he
never has written any.
From: Alex Mizrahi
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <4a62d423$0$48232$14726298@news.sunsite.dk>
 RJ> You can imagine that for a lot of larger Lisp applications response
 RJ> time is less important than overall throughput and thus the concurrent
 RJ> GC is useless anyway.

If your algorithm is inherently single-threaded, but you have dual-core CPU,
there might be some benefit for having concurrent GC -- it will do most of 
its
work running alongside the computation.

 RJ> Harrop uses it only to mention something that CL implementations don't
 RJ> provide, but other products have. A marketing trick.
 RJ> He has no idea if any Lisp application actually needs it, because he
 RJ> never has written any.

I believe many applications -- like interactive ones -- will benefit a lot 
from
a concurrent GC (or just better GC).

Particularly, I often deal with web applications. It is usually a case that 
applications
is quite fast -- say, it has 20ms response time, thus handling 50 requests 
per second.
It works fine for a minute or so, and then BAM -- you have a GC which takes 
something
on scale of 1 second, or perhaps more. It is already unpleasant at this 
point -- 1 second
delay is already noticeable and is percieved as application being somewhat 
slow.
Another problem is that whole application is totally stalled during GC and 
requests
 get queued by OS. If you have 40 requests per second, you will get 40 of 
them queued
while it does GC. If you did not configure big enough backlog, some requests 
will get lost
 -- people will see that site did not work for them. Then app needs to 
process queued
requests before it comes to new ones, and it takes some time...
So it is quite unpleasant when GC pause is 1 second, but it can be longer 
then that
 -- more memory you use, larger is GC pause. If one uses swap file, GC can 
take
as long as minute (even if you're not short on RAM, but simply OS decided 
that
file cache is more important that Lisp or Java heap), so I avoid having swap 
at all
where I use Lisp or Java.

I've tried Java's concurrent GC when working with ABCL, and it appeared to 
be
better than default one, and seemed better than SBCL's GC (although it was 
not
direct comparison with SBCL). It offers lower pause times and makes pauses
more predictable. 
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <deef32b8-1e00-4eb5-b34f-fa7468cdaad8@n11g2000yqb.googlegroups.com>
On 19 Jul., 10:06, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
>  RJ> You can imagine that for a lot of larger Lisp applications response
>  RJ> time is less important than overall throughput and thus the concurrent
>  RJ> GC is useless anyway.
>
> If your algorithm is inherently single-threaded, but you have dual-core CPU,
> there might be some benefit for having concurrent GC -- it will do most of
> its
> work running alongside the computation.

Could be. You could also stop the app and do a parallel GC using both
cores.
That could be even faster. It would not run concurrently, but
parallel.

But a single threaded app and a concurrent GC, sounds a bit
constructed.
That does not look like applications run and not like a future model.

>
>  RJ> Harrop uses it only to mention something that CL implementations don't
>  RJ> provide, but other products have. A marketing trick.
>  RJ> He has no idea if any Lisp application actually needs it, because he
>  RJ> never has written any.
>
> I believe many applications -- like interactive ones -- will benefit a lot
> from
> a concurrent GC (or just better GC).

Sure, better GCs are welcome. But I doubt that the concurrent GC is
the better
one. By default the JVM gc does NOT run concurrently, last I looked.
You had to turn it on and SUN warns that it reduces application
throughput.
Plus, I would expect the concurrent GC to be less robust. SUN for
example works on a new GC, which seems to be getting better, but warns
that it may not be robust enough for some applications. Running
an application with a not sufficiently debugged GC is no fun. Lisp
applications tend to fall over very fast when the GC is faulty (my
experience).
Lisp applications need tagged data and when the data is corrupted,
it just won't work.

> Particularly, I often deal with web applications. It is usually a case that
> applications
> is quite fast -- say, it has 20ms response time, thus handling 50 requests
> per second.

Sure, Web servers, etc. all kinds of apps that need fast interactive
response times with relatively little work per 'unit' will benefit.

But up until a few years ago that was not the market of Lisp
applications
and I doubt it is even now. The model is more that you have
a longer running unit of work and doing computing on complex data
with complex computations: expert systems, rule systems, compilers,
theorem provers, algebra systems, etc. For many of those the
response time is in the range above 20ms.

Now you can say that applications may do both, doing serving the web
while
computing complex, say financial, calculations. But that is not how
you write apps for the enterprise. Those are layered to handle load
and for other reasons
(security, ...).
There are layers of load balancers, web servers, application servers
and
database servers. Enterprise applications don't do calculations inside
apache.
At least not the one I saw. The business logic is run in J2EE
application
servers, something that can be replaced by a Lisp application server.

So, yes, concurrent GC may decrease response time and make it more
predictable. Adding that capability to Lisp would be fine. But I doubt
that it is applicable in too many cases of actual Lisp applications.
Last I looked Lisp did not compete in companies for web servers
and databases with Apache or Oracle.

Another interesting, related, but hard to get GC variant is support
for hard or soft real-time responses. There is a market in expert
systems
(or what it is called to day) for process control. Often Lisp
runs without GC in those applications.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071911124916807-tfb@cleycom>
On 2009-07-19 09:50:02 +0100, Rainer Joswig <······@lisp.de> said:

> Sure, better GCs are welcome. But I doubt that the concurrent GC is
> the better
> one

I think an important point here (which relates to my earlier 
obsessing-about-the-tools article) is that most of us have used an 
application which needs to have good interactive response at the 
keystroke level, largely written in a garbage-collected language, which 
for much of its life (and probably still) has a really pretty 
rudimentary GC system.  Some of us have run that application on systems 
with performance under one VAX MIPS. Yet somehow the performance has 
been OK both then and for most of the 25 years since then.  So perhaps 
flashy GC technology is not quite as critical as one might think.

--tim
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <9d9cbe40-7a5d-4f8a-8924-fb845d895d47@26g2000yqk.googlegroups.com>
On 19 Jul., 12:12, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-19 09:50:02 +0100, Rainer Joswig <······@lisp.de> said:
>
> > Sure, better GCs are welcome. But I doubt that the concurrent GC is
> > the better
> > one
>
> I think an important point here (which relates to my earlier
> obsessing-about-the-tools article) is that most of us have used an
> application which needs to have good interactive response at the
> keystroke level, largely written in a garbage-collected language, which
> for much of its life (and probably still) has a really pretty
> rudimentary GC system.  Some of us have run that application on systems
> with performance under one VAX MIPS. Yet somehow the performance has
> been OK both then and for most of the 25 years since then.  So perhaps
> flashy GC technology is not quite as critical as one might think.
>
> --tim

I have this five MIPS Lisp Machine next to, display is on a Mac with
X11.
For my purposes the interactive response is okay. It is just generally
a bit slow. ;-)

If you use CCL with its ephemeral GC on a 3Ghz machine,
the interactive response is just great.
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <ePidnbAXN-PyZ__XnZ2dnUVZ8tSdnZ2d@brightview.co.uk>
Rainer Joswig wrote:
> On 19 Jul., 10:06, "Alex Mizrahi" <········@users.sourceforge.net>
> wrote:
>> RJ> You can imagine that for a lot of larger Lisp applications response
>> RJ> time is less important than overall throughput and thus the
>> concurrent RJ> GC is useless anyway.
>>
>> If your algorithm is inherently single-threaded, but you have dual-core
>> CPU, there might be some benefit for having concurrent GC -- it will do
>> most of its
>> work running alongside the computation.
> 
> Could be. You could also stop the app and do a parallel GC using both
> cores.
> That could be even faster. It would not run concurrently, but
> parallel.

That can be faster but it is usually slower and, in particular, is a lot
slower as the number of cores increases. That is actually why Haskell
doesn't scale well beyond 4 cores.

>> I believe many applications -- like interactive ones -- will benefit a
>> lot from
>> a concurrent GC (or just better GC).
> 
> Sure, better GCs are welcome. But I doubt that the concurrent GC is
> the better
> one. By default the JVM gc does NOT run concurrently, last I looked.

That is wrong. Sun just replaced their old CMS GC with the G1 GC. Both are
concurrent.

> You had to turn it on and SUN warns that it reduces application
> throughput.

Can reduce throughput.

> Plus, I would expect the concurrent GC to be less robust. SUN for
> example works on a new GC, which seems to be getting better, but warns
> that it may not be robust enough for some applications. Running
> an application with a not sufficiently debugged GC is no fun. Lisp
> applications tend to fall over very fast when the GC is faulty (my
> experience).

That is why Lisp is screwed: they can no longer Greenspun essential core
features like a robust concurrent GC.

> But up until a few years ago that was not the market of Lisp
> applications
> and I doubt it is even now. The model is more that you have
> a longer running unit of work and doing computing on complex data
> with complex computations: expert systems, rule systems, compilers,
> theorem provers, algebra systems, etc. For many of those the
> response time is in the range above 20ms.

All of those applications would benefit from scalable parallelism and that
means a concurrent GC instead of a stop-the-world GC.

> So, yes, concurrent GC may decrease response time and make it more
> predictable. Adding that capability to Lisp would be fine. But I doubt
> that it is applicable in too many cases of actual Lisp applications.
> Last I looked Lisp did not compete in companies for web servers
> and databases with Apache or Oracle.

Lisp does not compete anywhere. Lack of decent GC in any implementation is
just another nail in Lisp's coffin.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <62a38370-7a25-4476-8adc-0309216aff94@d32g2000yqh.googlegroups.com>
On 19 Jul., 13:59, Jon Harrop <····@ffconsultancy.com> wrote:
> Rainer Joswig wrote:
> > On 19 Jul., 10:06, "Alex Mizrahi" <········@users.sourceforge.net>
> > wrote:
> >> RJ> You can imagine that for a lot of larger Lisp applications response
> >> RJ> time is less important than overall throughput and thus the
> >> concurrent RJ> GC is useless anyway.
>
> >> If your algorithm is inherently single-threaded, but you have dual-core
> >> CPU, there might be some benefit for having concurrent GC -- it will do
> >> most of its
> >> work running alongside the computation.
>
> > Could be. You could also stop the app and do a parallel GC using both
> > cores.
> > That could be even faster. It would not run concurrently, but
> > parallel.
>
> That can be faster but it is usually slower and, in particular, is a lot
> slower as the number of cores increases. That is actually why Haskell
> doesn't scale well beyond 4 cores.
>
> >> I believe many applications -- like interactive ones -- will benefit a
> >> lot from
> >> a concurrent GC (or just better GC).
>
> > Sure, better GCs are welcome. But I doubt that the concurrent GC is
> > the better
> > one. By default the JVM gc does NOT run concurrently, last I looked.
>
> That is wrong. Sun just replaced their old CMS GC with the G1 GC. Both are
> concurrent.

No, if you start the JVM the concurrent GC does nothing. You have
to turn it on. I wrote 'be default it does not run concurrently'.
Because the concurrent GC is DISABLED by default.

http://java.sun.com/javase/technologies/hotspot/gc/g1_intro.jsp

  Finally, to run G1 at its full potential, try setting these two
parameters which are currently disabled by default because they may
uncover a rare race condition: -XX:+G1ParallelRSetUpdatingEnabled -XX:
+G1ParallelRSetScanningEnabled

and more.

You haven't used it, right? Good luck.
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <IIednTEhV7CaqP7XnZ2dnUVZ8lydnZ2d@brightview.co.uk>
Rainer Joswig wrote:
> On 19 Jul., 13:59, Jon Harrop <····@ffconsultancy.com> wrote:
> No, if you start the JVM the concurrent GC does nothing. You have
> to turn it on. I wrote 'be default it does not run concurrently'.
> Because the concurrent GC is DISABLED by default.
> 
> http://java.sun.com/javase/technologies/hotspot/gc/g1_intro.jsp

Your citation states:

  "Like CMS, G1 periodically performs a concurrent marking phase."

>   Finally, to run G1 at its full potential, try setting these two
> parameters which are currently disabled by default because they may
> uncover a rare race condition: -XX:+G1ParallelRSetUpdatingEnabled -XX:
> +G1ParallelRSetScanningEnabled

You are referring to tweaks that make other phases concurrent as well but,
AFAICT, the major mark phase is always concurrent by default on both the
old and new JVM GCs.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <479c7a88-8850-4f35-954c-c185542e492a@k6g2000yqn.googlegroups.com>
On 19 Jul., 18:09, Jon Harrop <····@ffconsultancy.com> wrote:
> Rainer Joswig wrote:
> > On 19 Jul., 13:59, Jon Harrop <····@ffconsultancy.com> wrote:
> > No, if you start the JVM the concurrent GC does nothing. You have
> > to turn it on. I wrote 'be default it does not run concurrently'.
> > Because the concurrent GC is DISABLED by default.
>
> >http://java.sun.com/javase/technologies/hotspot/gc/g1_intro.jsp
>
> Your citation states:
>
>   "Like CMS, G1 periodically performs a concurrent marking phase."
>
> >   Finally, to run G1 at its full potential, try setting these two
> > parameters which are currently disabled by default because they may
> > uncover a rare race condition: -XX:+G1ParallelRSetUpdatingEnabled -XX:
> > +G1ParallelRSetScanningEnabled
>
> You are referring to tweaks that make other phases concurrent as well but,
> AFAICT, the major mark phase is always concurrent by default on both the
> old and new JVM GCs.

What is so hard to understand? Just read the documentation.

  'G1 is still considered experimental and can be enabled with the
following two parameters: -XX:+UnlockExperimentalVMOptions -XX:
+UseG1GC'

G1 is DISABLED by default. There is no concurrent GC by default. You
are dreaming.

The older concurrent GC is also DISABLED by default.

SUN tells you how to start Java using it:

   java -XX:+UseConcMarkSweepGC

Drawback: the concurrent GC does not compact objects and fragmentation
can occur, unless another GC stops the app and does a GC.
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <_uadnYQADZ0XmPnXnZ2dnUVZ8uadnZ2d@brightview.co.uk>
Rainer Joswig wrote:
> On 19 Jul., 18:09, Jon Harrop <····@ffconsultancy.com> wrote:
>> You are referring to tweaks that make other phases concurrent as well
>> but, AFAICT, the major mark phase is always concurrent by default on both
>> the old and new JVM GCs.
> 
> What is so hard to understand? Just read the documentation.

The page you cited only says that the new G1 GC is disabled by default.

> SUN tells you how to start Java using it:
> 
>    java -XX:+UseConcMarkSweepGC
> 
> Drawback: the concurrent GC does not compact objects and fragmentation
> can occur, unless another GC stops the app and does a GC.

Yes. I have found other pages that state that.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Andrew Reilly
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <7cg3j8F27ccbvU1@mid.individual.net>
On Sun, 19 Jul 2009 11:06:44 +0300, Alex Mizrahi wrote:

> Particularly, I often deal with web applications. It is usually a case
> that applications
> is quite fast -- say, it has 20ms response time, thus handling 50
> requests per second.
> It works fine for a minute or so, and then BAM -- you have a GC which
> takes something
> on scale of 1 second, or perhaps more. It is already unpleasant at this
> point -- 1 second
> delay is already noticeable and is percieved as application being
> somewhat slow.

I don't want to diminish the issue: and I've read some interesting papers 
from both Sun and IBM about techniques to make "rate-aware" garbage 
collectors for real-time control and embedded applications that seem 
quite interesting and promising.

This does seem like the sort of issue that can be solved, or at least 
ameliorated at the system level.  If you have multiple processors, any 
one of which might have stopped for garbage collection, then you might be 
able to run multiple, parallel server instances, all sitting behind a 
dispatching reverse-cache.  Then the load just goes up a bit on the 
instances that aren't actively collecting garbage.

Cheers,

-- 
Andrew
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <ePidnbMXN-N7Z__XnZ2dnUVZ8tQAAAAA@brightview.co.uk>
Andrew Reilly wrote:
> This does seem like the sort of issue that can be solved, or at least
> ameliorated at the system level.  If you have multiple processors, any
> one of which might have stopped for garbage collection, then you might be
> able to run multiple, parallel server instances, all sitting behind a
> dispatching reverse-cache.  Then the load just goes up a bit on the
> instances that aren't actively collecting garbage.

You are essentially describing a concurrent GC.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Andrew Reilly
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <7chr9mF262hm8U1@mid.individual.net>
On Sun, 19 Jul 2009 13:01:56 +0100, Jon Harrop wrote:

> Andrew Reilly wrote:
>> This does seem like the sort of issue that can be solved, or at least
>> ameliorated at the system level.  If you have multiple processors, any
>> one of which might have stopped for garbage collection, then you might
>> be able to run multiple, parallel server instances, all sitting behind
>> a dispatching reverse-cache.  Then the load just goes up a bit on the
>> instances that aren't actively collecting garbage.
> 
> You are essentially describing a concurrent GC.

So those only work in situations where you can isolate dependent actions 
to individual processors, "embarrasingly-parallel" style?  That would 
seem to be a bit limiting...

I thought that the point was that you put processor-specific-GC locks 
around all of the state mutation operators so that you can ensure that 
the processor-specific GC gets to operate on a stationary memory image.  
That's a lot more complicated, not guaranteed to keep all threads happy 
(they might all depend on a lock held by a thread on the stopped 
processor) and certain to make the average performance worse.  I can 
understand why Sun might advise against it, even if they've implemented 
it.

I think that rate-aware collection-time-limited collectors of the sort 
that I've seen discussed in the real-time literature are more likely to 
be the right answer in the long run.  And sure: you'll probably want to 
have one of those guarding its own pool per processor, but you still need 
to keep a lid on the worst-case collection time.

Cheers,

-- 
Andrew
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <X7KdnaLY7NTfZP_XnZ2dnUVZ8kWdnZ2d@brightview.co.uk>
Rainer Joswig wrote:
> So what one might want is a concurrent and parallel GC. But there is
> no free lunch.
> It comes with a cost. Note though that on the JVM you have to enable
> the concurrent GC
> and that SUN warns that it decreases 'application throughput'.
> 
>
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#available_collectors
> 
>    'It is designed for applications with medium- to large-sized data
> sets for which response time is more important than overall
> throughput, since the techniques used to minimize pauses can reduce
> application performance.'
> 
> You can imagine that for a lot of larger Lisp applications response
> time is less important than overall throughput and thus the concurrent
> GC is useless anyway.

Lisp has very different requirements of a GC compared to Java so such
extrapolations are not likely to be correct.

> Harrop uses it only to mention something that CL implementations don't
> provide, but other products have. A marketing trick.
> He has no idea if any Lisp application actually needs it, because he
> never has written any.

Microsoft and Sun implemented concurrent GCs for a reason.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: ok
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <e70fd95a-bfc9-4bc3-b4ee-43b663cfce55@y7g2000yqa.googlegroups.com>
On 18 Lug, 15:01, "John Thingstad" <·······@online.no> wrote:
> No. Sceineer has one and LispWorks has one under development.
> Franz is working on one and I have heard (unverified) that SBCL is too.
> So this should be viewed and a temporary state of things. Lisp companies  
> have fewer employees than java has so things take a bit longer. Withing a  
> couple of years I would think most Lispers will be working with a 64 bit  
> lisp with concurrent processing.
>
> ---------------
> John Thingstad

Just to remember:

Real revolutions in programming language theory rarely happen once in
50 years, so CL implementation developers don't see any need for
hurry...

(It's not enough to sharpen up existing damages, so to say.)
From: Jeff M.
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2297627b-4115-41e6-81d7-8db1a52f8922@k30g2000yqf.googlegroups.com>
On Jul 18, 8:41 am, ok <········@gmail.com> wrote:
>
> Just to remember:
>
> Real revolutions in programming language theory rarely happen once in
> 50 years, ...
>

How can anyone even suggest that with a straight face? Programming as
we know it has really only been around - at most - for what? 60, maybe
70 years? Even if your statement was true, there's not even 2 data
points to begin seeing a pattern to confirm it.

Second, I don't believe there's anywhere close to a definition of a
"revolution in programming language theory." What would someone
consider that to be? The jump to a compiler? The addition of
conditionals? GC? Functional? Coroutines? Lazy evaluation? First class
functions? Quantum computing?

Finally, knowledge breeds more knowledge, understanding, and
experimentation. Having one leads to another, which leads to another,
and yet another... There's no possible historical data to make one
believe that programming should just stagnate on some linear, flat
line of advancements. As opposed to being an exponential curve like
all other sciences throughout history.

As for the original topic of concurrent GC: as others have stated, the
answer is "no." But this should be one of those things where the
question "who cares?" really does matter. You don't care how a CONS
cell is stored internally whether value tagging uses 2, 3 or 4 bits,
or if your particular Lisp implementation was written in C, C++,
Assembler, or even Brainf*ck. All you should care about is whether or
not it does what you need within some acceptable parameters (like
execution speed or memory requirements).

Now, here may be some assumption that a concurrent GC is "faster"
somehow than a non-concurrent GC. But that isn't implicitly true. In
fact, the exact opposite may end up being the case. If you are making
an application that has many execution threads sharing a single memory
heap. Or if the end application is running on a machine with a single
HW thread. These are things Lisp implementors may be taking into
consideration as they know who the majority of their [paying]
customers are.

Just food for thought.

Jeff M.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071816140975249-tfb@cleycom>
On 2009-07-18 15:41:41 +0100, "Jeff M." <·······@gmail.com> said:

> As for the original topic of concurrent GC: as others have stated, the
> answer is "no." But this should be one of those things where the
> question "who cares?" really does matter. You don't care how a CONS
> cell is stored internally whether value tagging uses 2, 3 or 4 bits,
> or if your particular Lisp implementation was written in C, C++,
> Assembler, or even Brainf*ck. All you should care about is whether or
> not it does what you need within some acceptable parameters (like
> execution speed or memory requirements).
> 
> Now, here may be some assumption that a concurrent GC is "faster"
> somehow than a non-concurrent GC. But that isn't implicitly true. In
> fact, the exact opposite may end up being the case. If you are making
> an application that has many execution threads sharing a single memory
> heap. Or if the end application is running on a machine with a single
> HW thread. These are things Lisp implementors may be taking into
> consideration as they know who the majority of their [paying]
> customers are.

You have fallen into a common trap, and will now be eaten by the 
creatures that lurk at the bottom of the pit in which you now find 
yourself. This particular trap is called "assuming people want to get 
things done".  Here is how it works.

Obviously, for someone whose aim is to *get something done*, what they 
care about is whether or not the tool they are using will work 
adequately to achieve their ends.  Thus, someone who wants, say, to 
process telemetry information from a spacecraft might be interested in 
how well the system he's using will interface to whatever is acquiring 
this information, and how good it is at real-time processing.  They 
probably don't care about whether the system they are using can be used 
as a plugin in Firefox.

In other words, people like this treat the tools they use as, well, 
tools: they are good in so far as they are useful to the task at hand, 
and different tools are useful for different tasks.

Now, pause for a minute and consider whether people are actually like 
this. On the whole they are not.  In fact, for most people, most of the 
time, the aim is to put as many obstacles in the way of *getting stuff 
done* as possible.  Even worse, many people want to put obstacles in 
the way of letting anyone *else* get stuff done.

How might someone like this behave?  Well, one obvious thing is to 
become obsessed about the tools, and in particular to become obsessed 
about all sorts of features of these tools which *do not matter*.  Here 
are three examples.

Common Lisp does not specify an interface to systems written in C.  So, 
clearly it can't be used, even though many *implementations* do have 
such an interface, because programs written in such implementations 
will not be portable CL, and it Will Not Do to write programs which are 
not purely portable CL.  Further, it is important to spend many hours 
complaining about this in newsgroups, rather than using some other 
language or writing programs which are not fully portable.

Unix Bourne shell scripts have certain well-known issues with argument 
parsing and whitespace.  So, even for cases where these problems will 
not matter, it is important to avoid getting anything done, but instead 
spend time installing Python across an estate of thousands of machines. 
 Since a new version of Python will have appeared by the time this task 
is completed, this process never ends, thus neatly avoiding the 
possibility of *ever* having to get anything done.

There are small but detectable differences between 
supposedly-equivalent camera lenses.  So it is important to spend all 
your time and money on lenses (and often on the camera system to go 
with them) to find the "best" one, rather than deciding that what you 
have is clearly good enough and just going out and taking pictures.  
While doing this, fill discussion fora with endless flame wars about 
the merits or otherwise of your currently favoured system.
From: Jeff M.
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <9817f443-8d7b-46b5-9e94-6818c3b0fac1@g31g2000yqc.googlegroups.com>
On Jul 18, 10:14 am, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-18 15:41:41 +0100, "Jeff M." <·······@gmail.com> said:
>
>
>
> > As for the original topic of concurrent GC: as others have stated, the
> > answer is "no." But this should be one of those things where the
> > question "who cares?" really does matter. You don't care how a CONS
> > cell is stored internally whether value tagging uses 2, 3 or 4 bits,
> > or if your particular Lisp implementation was written in C, C++,
> > Assembler, or even Brainf*ck. All you should care about is whether or
> > not it does what you need within some acceptable parameters (like
> > execution speed or memory requirements).
>
> > Now, here may be some assumption that a concurrent GC is "faster"
> > somehow than a non-concurrent GC. But that isn't implicitly true. In
> > fact, the exact opposite may end up being the case. If you are making
> > an application that has many execution threads sharing a single memory
> > heap. Or if the end application is running on a machine with a single
> > HW thread. These are things Lisp implementors may be taking into
> > consideration as they know who the majority of their [paying]
> > customers are.
>
> You have fallen into a common trap, and will now be eaten by the
> creatures that lurk at the bottom of the pit in which you now find
> yourself. This particular trap is called "assuming people want to get
> things done". [...]

LOL. Well said. ;-)

Jeff M.
From: A.L.
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <tur365d8ksu2sgo8sglpcijlj8hqe9dgkp@4ax.com>
On Sat, 18 Jul 2009 16:14:09 +0100, Tim Bradshaw <···@cley.com> wrote:

>On 2009-07-18 15:41:41 +0100, "Jeff M." <·······@gmail.com> said:
> 
>In other words, people like this treat the tools they use as, well, 
>tools: they are good in so far as they are useful to the task at hand, 
>and different tools are useful for different tasks.
>
>Now, pause for a minute and consider whether people are actually like 
>this. On the whole they are not.  

If they are not, they get fired and company hires replacement that
does the job effectively,  without emotions and without having sesual
attachment to programming language editor.

>
>How might someone like this behave?  Well, one obvious thing is to 
>become obsessed about the tools, and in particular to become obsessed 
>about all sorts of features of these tools which *do not matter*.  Here 
>are three examples.
  

"Lisp community"?...

A.L.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071817162316807-tfb@cleycom>
On 2009-07-18 16:55:24 +0100, A.L. <········@aol.com> said:

> If they are not, they get fired and company hires replacement that
> does the job effectively,  without emotions and without having sesual
> attachment to programming language editor.

Yes.  That always happens.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071814280016807-tfb@cleycom>
On 2009-07-18 14:01:24 +0100, "John Thingstad" <·······@online.no> said:

> No. Sceineer has one and LispWorks has one under development.

That's interesting.  My question was rhetorical though (sorry, I have a 
weakness for troll-baiting).
From: Rainer Joswig
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <70e7a159-a15f-48d8-bb8e-5b72575600cc@h21g2000yqa.googlegroups.com>
On 18 Jul., 15:28, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-18 14:01:24 +0100, "John Thingstad" <·······@online.no> said:
>
> > No. Sceineer has one and LispWorks has one under development.
>
> That's interesting.  My question was rhetorical though (sorry, I have a
> weakness for troll-baiting).

No, Scieneer CL has a concurrent Lisp. I don't think its GC is
concurrent.
LispWorks has not said if their upcoming LispWorks 6 has a concurrent
GC.
It will have concurrent Lisp execution, though.

Let's not mix concurrent GC and concurrent execution of Lisp code.
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071815425616807-tfb@cleycom>
On 2009-07-18 14:32:33 +0100, Rainer Joswig <······@lisp.de> said:

> Let's not mix concurrent GC and concurrent execution of Lisp code.

Indeed not.  It depends on what you mean by "concurrent" of course, but 
Clozure CL has native threads and (observationally) can use multiple 
cores, but does not have a concurrent GC as far as I know.
From: Christoph Senjak
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2818f26b-1b0b-42e2-bcd3-0bdc3831d846@b14g2000yqd.googlegroups.com>
On Jul 18, 3:16 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Clojure sheds a lot of CL's baggage to make for a much cleaner language and
> incorporates many modern features like decent interop and concurrent GC.
> Consequently, it is one of the only Lisp-related technologies that is not
> in decline:
>
>  http://www.google.com/trends?q=clojure%2Ccommon+lisp
>
> I recommend learning Clojure and Scheme and forgetting about CL.

CL is solid, well-developed, and has a lot of code that runs on any
major implementation. Scheme is small and more suitable for academical
purposes. Working with Scheme, you will mostly have to decide for
which implementation your code should be. And clojure is new, and
still under development. That is why there are so many new sites and
posts about clojure, while in CL, there are none (which explains your
Google Link).

So I wouldnt recommend "forgetting about CL". Actually, to get a
deeper understanding for Lisp, I wouldnt recommend to begin with
Clojure. Depending on what exactly you want to do, maybe Scheme or
maybe Common Lisp is the better choice, and of course, in the
beginning, you should only learn one of both, until you think you have
a deeper understanding. And then you can try the other one or Clojure
and use what fits you best.
From: Lars Rune Nøstdal
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <f1f52a80-6b0e-4f3d-a942-d15b14096604@h18g2000yqj.googlegroups.com>
On Jul 18, 8:13 pm, Christoph Senjak <················@googlemail.com>
wrote:
> On Jul 18, 3:16 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Clojure sheds a lot of CL's baggage to make for a much cleaner language and
> > incorporates many modern features like decent interop and concurrent GC.
> > Consequently, it is one of the only Lisp-related technologies that is not
> > in decline:
>
> >  http://www.google.com/trends?q=clojure%2Ccommon+lisp
>
> > I recommend learning Clojure and Scheme and forgetting about CL.
>
> CL is solid, well-developed, and has a lot of code that runs on any
> major implementation. Scheme is small and more suitable for academical
> purposes. Working with Scheme, you will mostly have to decide for
> which implementation your code should be. And clojure is new, and
> still under development. That is why there are so many new sites and
> posts about clojure, while in CL, there are none (which explains your
> Google Link).

Adding to this; I do not think CL'ers Google much seeing as the
Hyperspec is available at a well-known location and also available for
off-line browsing. Docs for libraries and implementations tend to be
included on installation or with the source in addition to being
available online:

* http://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm

* http://www.lisp.org/mop/index.html

* http://www.sbcl.org/manual/

* http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation

* http://common-lisp.net/project/postmodern/postmodern.html and
http://common-lisp.net/project/postmodern/s-sql.html

* http://common-lisp.net/project/cxml/

* http://common-lisp.net/project/asdf/manual.html

* http://weitz.de/hunchentoot/

* http://weitz.de/cl-who/

* http://weitz.de/cl-ppcre/

* http://common-lisp.net/project/cffi/manual/html_node/index.html


....etc.!

Also, let's quote some Naggum:

http://groups.google.com/group/comp.lang.lisp/msg/d671a424235e9f18

> Also I was also surprised at the minimal quantity of internet resources
> related to Lisp.  Being one of the oldest language, maybe I expected a
> little more.

  I can easily see how this is disappointing.  However, there is at
least
  one somewhat surprising reason for this: It is so easy to do things
in
  Common Lisp that people have no personal need to advertise it and
make a
  public nuisance of themselves.  While Archimedes may have made the
first
  serious connection between nudity and marketing scientific
discovery, I
  think today's Common Lisp hacker goes "yeah!" and just smiles.  In
sharp
  contrast, today's young punks go "HOLY SHIT!  IT WORKS!  GUYS!
GUYS!  IT
  WORKS!" and rush off to get another cool domain name.  That "yeah!"
is
  also probably worth a thousand times more money than the other Cool
Hack,
  which is why it is _not_ marketed -- the reward was right there to
begin
  with, with no need to attract attention from the crowds just to feel
good
  about your own work.  Remember, Common Lisp people are about 10
years
  older than Java people.
From: Jon Harrop
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <DOOdndjt3tRE6v_XnZ2dnUVZ8h-dnZ2d@brightview.co.uk>
Christoph Senjak wrote:
> Scheme is small and more suitable for academical purposes.

Then why do Scheme's recent industrial success stories (e.g. FFTW, Cilk)
dwarf anything done with Common Lisp?

And why do the user bases of open source software written in Scheme (e.g.
Festival) dwarf those of anything written in Common Lisp?

> Working with Scheme, you will mostly have to decide for 
> which implementation your code should be. And clojure is new, and
> still under development.

Scheme and Clojure are not dead languages.

> That is why there are so many new sites and posts about clojure, while in
> CL, there are none (which explains your Google Link).

Nobody is searching for Common Lisp because it is an (un)dead language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
From: Tim Bradshaw
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <2009071911240675249-tfb@cleycom>
On 2009-07-19 03:42:45 +0100, Jon Harrop <···@ffconsultancy.com> said:

> And why do the user bases of open source software written in Scheme (e.g.
> Festival) dwarf those of anything written in Common Lisp?

Festival was not written in Scheme.  It uses SIOD as its scripting 
language because it was easy to attach it to C/C++ and because 
Festival's author had a good deal of familiarity with Lisp.  All the 
guts of Festival is in C/C++.

I can't speak for the person who wrote Festival but from (now fairly 
distant) memory I think that he'd probably have preferred CL but there 
really were no practical free embeddable CLs ((a)kcl was probably 
basically it and it was not really usable) at that time, while there 
were several scheme-based systems (SIOD and ELK Scheme at least).

Finally I imagine the success of Festival has just a little bit more to 
do with it being a good-quality, free, speech synthesis system than 
with its choice of scripting language.
From: Pascal Costanza
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <7cdtffF26t58sU1@mid.individual.net>
Jon Harrop wrote:
> ccc31807 wrote:
>> Can anyone who has had experience with Common Lisp and Clojure be
>> willing to give an even-handed and non-prejudicial comparison of them:
>> similarities and differences, advantages and disadvantages.
>>
>> I'm wondering whether it would be helpful to look at Clojure while in
>> the process of learning CL.
> 
> Clojure sheds a lot of CL's baggage to make for a much cleaner language and
> incorporates many modern features like decent interop and concurrent GC.
> Consequently, it is one of the only Lisp-related technologies that is not
> in decline:
> 
>   http://www.google.com/trends?q=clojure%2Ccommon+lisp
> 
> I recommend learning Clojure and Scheme and forgetting about CL.

Hey, the guy clearly wanted "non-prejudicial"... ;)


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/
From: Slobodan Blazeski
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <ff01379a-ff7f-4c69-885b-257190854607@o7g2000yqb.googlegroups.com>
On Jul 17, 10:45 pm, ccc31807 <········@gmail.com> wrote:
> Can anyone who has had experience with Common Lisp and Clojure be
> willing to give an even-handed and non-prejudicial comparison of them:
> similarities and differences, advantages and disadvantages.
>
> I'm wondering whether it would be helpful to look at Clojure while in
> the process of learning CL.
>
> CC

http://tourdelisp.blogspot.com/2009/02/what-kind-of-lisp-should-i-learn.html

Bobi
From: ccc31807
Subject: Re: comparison of CL and Clojure
Date: 
Message-ID: <d40813dc-938b-40c6-b7c7-2f1003f21d5b@s15g2000yqs.googlegroups.com>
On Jul 21, 10:57 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Jul 17, 10:45 pm, ccc31807 <········@gmail.com> wrote:
>
> > Can anyone who has had experience with Common Lisp and Clojure be
> > willing to give an even-handed and non-prejudicial comparison of them:
> > similarities and differences, advantages and disadvantages.
>
> > I'm wondering whether it would be helpful to look at Clojure while in
> > the process of learning CL.
>
> > CC
>
> http://tourdelisp.blogspot.com/2009/02/what-kind-of-lisp-should-i-lea...
>
> Bobi

Thank you, CC.