[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.

[jjwiseman]

That's right: The spec will never be revised, not because it already defines the ideal programming language (is that really your argument?), but because the effort and expense is so great.

[kennethtilton]

Maybe somewhere in between. The imperfections are so small that even a modest effort would never get undertaken. Something folks need to realize is that Lisp truly is a metalanguage: I think both Graham and Norvig knocked off quick and dirty OOP hacks when that (decent) fad came along. So it is hard to imagine what innovation might come along that would force us to get the Lisp hood up.

[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.

[weavejester]

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

I think you're mistaking the parent poster's argument. Immutability is at its most useful when it's the norm, rather than the exception. For this to work, the core language needs to very strongly encourage immutability, to the point where in-place mutability is considered something only useful for low-level performance tweaks.

It's not that Clojure is new - there are plenty of older languages that have a strong core of immutability. The point is that it needs to be at the core of the language in order to be pervasive.

> You just made that up. Clojure was designed to be able to run on the JVM.

No he didn't. The Clojure rationale page talks about separating languages from platforms, and this subject has come up often in talks and on the mailing list. Clojure has already been ported to Javascript, and there are various projects to implement Clojure in Python, Ruby, C and Lua - that I know of.

There's also a lot of current work going on in abstracting out the Clojure analyser and compiler, both to bootstrap the language, and to make it easier to derive ports.

[mrottenkolber]

> I think you're mistaking the parent poster's argument. Immutability is at its most useful when it's the norm, rather than the exception. For this to work, the core language needs to very strongly encourage immutability, to the point where in-place mutability is considered something only useful for low-level performance tweaks.

I don't think so. What you are saying is you can only program in way X if your language forces you to, which is obviously wrong? I think people just are not used to using a language that doesn't force you to do anything at all (e.g. lisp).

You can only program in way X if your language _allows_ you to. What language allows you to program in any way and even lets you easily modifiy the language to do whatever you want? Lisp.

> The Clojure rationale page talks about separating languages from platforms, and this subject has come up often in talks and on the mailing list.

Then they made that up. ClojureScript is not the same as Clojure. They did a pretty horrible job at seperating their language from their platform. I know because I get Java stack traces all day. I also have to use inferior language primitives dues to Clojure's Java-centrism every day.

[kennethtilton]

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