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

On Jul 17, 11:45 pm, ccc31807 <carte> 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).

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.

On Jul 18, 3:16 am, Jon Harrop <j> 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 <j> wrote:
> concurrent GC.

Someone is working on concurrent GC for SBCL.

On Jul 18, 4:53 am, Lars Rune Nøstdal <larsnost> wrote:
> On Jul 18, 3:16 am, Jon Harrop <j> 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.

On Jul 17, 11:45 pm, ccc31807 <carte> 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

On 2009-07-18 02:16:28 +0100, Jon Harrop <jon> 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?

Tim Bradshaw wrote:
> On 2009-07-18 02:16:28 +0100, Jon Harrop <jon> 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.

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?

Jon Harrop wrote:
> ccc31807 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:
>
> [..]
>
> I recommend learning Clojure and Scheme and forgetting about CL.

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


Pascal

På Sat, 18 Jul 2009 11:26:38 +0200, skrev Tim Bradshaw <tfb>:

> On 2009-07-18 02:16:28 +0100, Jon Harrop <jon> 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

On 2009-07-18 14:01:24 +0100, "John Thingstad" <jpthing> 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).

On 18 Jul., 15:01, "John Thingstad" <jpth> wrote:
> På Sat, 18 Jul 2009 11:26:38 +0200, skrev Tim Bradshaw <t>:
>>
>
> 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/technolog...ble_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.

On 18 Jul., 15:28, Tim Bradshaw <t> wrote:
> On 2009-07-18 14:01:24 +0100, "John Thingstad" <jpth> 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.

On 18 Lug, 15:01, "John Thingstad" <jpth> 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.)