[mrottenkolber]

Like I said its an experiment. CL is a great piece of work forged by decades of engineering _consensus_. Feel free to take a look at ABCL if you want to know where the man hours of clojure should have went into.

Its just like ruby, a trend that a lot of effort is wasted on, because the fundamentals are plain wrong.

[rolandukor]

Unfortunately, you haven't told me anything. I will leave it at that.

[mrottenkolber]

To sum it up:

CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time.

Clojure: An opinionated experiment with a single implementation that might just as well have been a library for CL (we do have STM libraries though, so there isn't really a point).

ABCL is a CL implementation for the JVM.

[_delirium]

> CL: Extensible, industry proven language with many implementations on many platforms. Big standards body which still only defines what is proven to be good by the test of time.

This was once true, but CL's standards body last made a significant revision twenty years ago, and no longer exists. It petered into inactivity by the late '90s, formally lost its voting privileges due to lack of quorum by the early 2000s, and was dissolved in 2004 (http://mailman.rose-hulman.edu/pipermail/ncits/2004-August/0...).

Nowadays the consensus process is more community driven, more of a messy "modern-style" language evolution, and doesn't involve a formal standards body or any kind of centralized process. Implementations add proprietary extensions to experiment, and then compatibility libraries layer over those extensions, slowly becoming de-facto standards. For example multithreading can't be implemented in standard CL, and various CLs instead expose their own private threading APIs. Bordeaux-threads then arises as a compatibility layer and attempt at achieving consensus around a portable threading API.

Perhaps that isn't a problem, but it simply isn't the case that CL has a big standards body that defines what has been proven to be good: it has no standard body, which as a result defines nothing post-1994; the base language is frozen in time.

[agentultra]

> Perhaps that isn't a problem

It really isn't a problem. AFAIK there isn't a run-time performance to using cross-implementation libraries. If you're building an application you probably don't even need to worry about supporting multiple implementations and can write to the available extensions directly. Fortunately the spec left us with a highly-extensible "programmable programming language." Libraries fill the gaps between implementations which push the gap as technology changes. The core is just the bedrock to build upon.

[mrottenkolber]

> This was once true, but CL's standards body last made a significant revision twenty years ago, and no longer exists.

It is STILL true that we have a great standard which only includes the "definitely right" things. And if you ask me, its just so good that we haven't needed a revision in 20 years.

[JeanPierre]

    And if you ask me, its just so good that we haven't needed a revision in 20 years.

What about threading and/or concurrency? CLTL doesn't mention it, yet it is something which is now considered a requirement for real, general purpose programming languages.

[mrottenkolber]

We do have BORDEAUX-THREADS (defacto standard for OSS implementations). The commercial vendors supply various high perfomace concurrency frameworks.

[jjwiseman]

> its just so good that we haven't needed a revision in 20 years

This is part of why I no longer use Common Lisp (after using it professionally for about 10 years). There are clear bugs in the spec, but it will never change. If your language is not progressing, it is dead.

[kennethtilton]

Nonsense. The standards process is a beast, so no one is going to kick it off for anything other than a good solid rethink. As others have noted, the language and spec are done, aka pretty much ideal. Go write some code, people.

ps. Love elsewhere a mention of "modern-style" language development. Sounds like "make it up as we go", what Lisp was doing in the sixties.

[hga]

That library couldn't enforce Clojure's functional nature.

CL (Common Lisp) is "multiparadigm", and shows warts going all the way back to the original mainline LISP. I should note that I'm someone who prefers Scheme to mainline LISP, modulo library availability ... which is one place Clojure it really winning, CL is an abject disaster, and Scheme is very very late to the game (still a work in progress last time I checked, R7RS-small being ratified less than 3 months ago).

I also see value in making vectors, maps etc. first class syntactically (although I would have been happier keeping vectors out of special form and function syntax), the collection and sequence unifications, etc. etc.

To finish, Clojure was first released 6 years ago, I'd say it's getting past the experiment stage. E.g. I don't know how you count implementations, but the ones that run on top of the CLR and JavaScript mean something, especially the latter, and what I gather it's bringing to the party.

[kennethtilton]

"CL is an abject disaster"? I need a red card over here.

[mtrimpe]

And what about using persistent data structures by default and having JavaScript as a compilation target?

I also haven't heard much about how easy CL's host language inter-op is to work with...

Another big thing of course is that the community is much more vibrant and welcoming than Common Lisp's.

[mrottenkolber]

> And what about using persistent data structures by default

You can do that in CL if you like to.

> and having JavaScript as a compilation target?

See ParenScript.

> I also haven't heard much about how easy CL's host language inter-op is to work with...

CL doesn't have a host language. And look at ABCL please.

> Another big thing of course is that the community is much more vibrant and welcoming than Common Lisp's.

The community is more skiddish and therefore newbie friendly. CL's community may feel arrogant at first, but with time you will notice it was justified because you were wrong and ignorant about it.

[mtrimpe]

> > And what about using persistent data structures by default

> You can do that in CL if you like to.

When you do this by default you do get a completely different ecosystem of libraries though, which is one of Clojure's key advantages over CL.

> CL doesn't have a host language.

Another one of Clojure's key features is that it's designed to be easy to implement on a host language.

That choice has some disadvantages such as forgoing the elegant condition system of CL in favor of plain old exceptions, but it also enables the practical use of Clojure and it's persistent data structures on a varied collection of host languages.

> CL's community may feel arrogant at first, but with time you will notice it was justified

We all know the Smug Lisp Weeny stereotype. I had the pleasure of talking with the original smug lisp weeny (smuglispweeny.blogspot.com) a couple of years ago about his OpenCells library which I still love as one of the most elegant solutions in computing.

OpenCells never went anywhere serious though but the Clojure ecosystem is starting to develop it's own version of the concept which runs on the browser right away and is already driving demo iOS and Android apps.

So yes, Clojure might not have the history of CL behind it and has less of a history of drawing bright minds into an ivory tower which contains infinite beauty but which rarely, if ever, makes down to earth.

You could say that makes it a toy, but if I had to place a bet on which language will have the biggest impact from now on then I'm pretty sure which language I would put my money on.

[mrottenkolber]

> When you do this by default you do get a completely different ecosystem of libraries though, which is one of Clojure's key advantages over CL.

This isn't even an argument. "Because its new."

> Another one of Clojure's key features is that it's designed to be easy to implement on a host language.

You just made that up. Clojure was designed to be able to run on the JVM. When implementing Clojure from scratch you will have to emulate the JVM. So the guys who will maybe (I don't think anybody will remeber Clojure in 10 years) do that in ten years will curse rich hickey.

I am not comment on the rest, because it has no content.

[kennethtilton]

Exactly. We Common Lispers created Clojure as a firewall when we realized The Great Unwashed were headed our way. Seems to be working.

[agentultra]

A rather comprehensive summary of why you might want to look into Common Lisp: http://www.lispworks.com/products/myths_and_legends.html

Although be warned that the article starts to pitch a particular implementation (LispWorks) near the end it is worth reading.