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