[coldtea]

>btw, your question assumes that Common Lisp is not evolving. This is not correct at all. Which improvements Clojure evolving consists of?

Traction for one.

>Transducers? Cl got them too

Pointing to some random libs that implement the same concept doesn't mean it's part of a languages culture/ecosystem/common practice as transducers are to closure.

E.g. I could say "Rails? Well, language X has a rails like framework too", but that wouldn't mean you get the same benefits of using that framework over rails, when you include language adoption, community vibrancy, availability of programmers to hire, tooling, books, etc.

[adrusi]

The whole point of common lisp, the reason it has survived since the beginning of time, is that the language was designed so that language innovation happened by people developing libraries for it. Complaining that common lisp hasn't evolved is like complaining that free-software posix systems haven't evolved. True, the posix standard hasn't evolved much, but its not meant to, it's meant to be evolved by the userspace programs and libraries that people write.

Yes, this approach is not the best approach to getting mass adoption, and there are benefits to mass adoption — people can help you, there's a bigger pool of people to hire, etc (I think its much more important to companies than individuals). But mass adoption isn't always the goal. I suppose you can consider Ruby analogous to Ubuntu while common lisp is like a *bsd distribution (or arch, gentoo, slack...). Ubuntu is great, all Ubuntu installations start from the same starting point, and the potential for customization is limited (try changing Ubuntu's init system), so you can just ask a question on stack overflow and get an answer with instructions specific to how your system works. And companies are more likely to pick Ubuntu than gentoo, because its better supported and supposedly more stable. That doesn't mean that people consider the distributions where the user can pick and choose exactly what their system does (like a common lisp programmer does by picking out libraries of macros) to be any worse of a distribution. Quite the contrary, the mythos seems to consider these distributions better in some way, like they're a better tool for a more skilled practitioner, a sentiment which has also found its place around common lisp.

[coldtea]

>The whole point of common lisp, the reason it has survived since the beginning of time, is that the language was designed so that language innovation happened by people developing libraries for it.

And that "whole point" hasn't worked very well as to the availability of a rich library ecosystem and/or adoption. So, while it's a nice trait to have, it's perhaps too much of a burden.

>But mass adoption isn't always the goal.

True, but it's not like CL was designed like some researchy or experimental project that doesn't care about mass adoption.

[mapcars]

They should not be a part of language, what for?

Everything else you mentioned is about community only, and doesn't apply directly to the language.

E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway.

If you have a bad language with great community - it doesn't reduce your suffering from the language itself.

[coldtea]

>E.g. if you have a good language without a community, community can eventually grow, but you can use the language anyway. If you have a bad language with great community - it doesn't reduce your suffering from the language itself.

My experience has been the inverse.

I'd rather use a bad, or usually mediocre language WITH community, tooling, libs, books, programmers etc, than a better one where I'll be burdened by the lack of all of these.

So, in a sense, community tramps inherent language qualities.

After all that's the very basic message from Lisp and Smalltalk.

[catnaroek]

Agreed. Clojure isn't overall a bad language, but it has annoying quirks in a lot of places, presumably because it needs to be compatible with Java. The ones that annoy me the most are (0) `nil` and `false` being different, and (1) wonky arithmetic that uses Java's numeric types under the hood, unless you explicitly ask it not to.