There was an article posted here a few years back which visually shows how a git repo’s source code changes over time. Projects have varying degrees of downward slopes in the banding, which indicates the rate at which old code is overwritten.
One commenter (puredanger) ran the tool against the Clojure repo and remarked on its stability. After 2011, so past the time examined in the notes from this article, the banding is almost flat: new layers get added while very few changes are made to old code. The image stands out, and indicates how sound the language core library is. They keep adding new features, and don’t have to mess with the plumbing to make them work.
It's really neat to be able to empirically verify this. If you watch Rich Hickey's talks, especially Spec-ulation, you'll see this deep commitment to compatibility and progress through growth. This is exemplified by Clojure itself (which unlike many languages is famously "just a library") and many times in third party work. If you find a ten year old Python library, it's unlikely to work verbatim. A ten year old Clojure library is probably still idiomatic.
This also works in the other direction. People regularly run RCs and alphas for Clojure itself in production. Unless you're doing something pretty novel and experimental, like, say, GraalVM native images (where manually rejiggering is common in every environment, and Clojure is no exception), odds are everything Just Works.
Both are true, but usually that means the latter. Clojure was designed to make it as easy as possible to rub a little bit of parens on an existing (JVM, though now also other platforms) project. That means being a hosted language that embraces interop very closely, and shipping the language as just a jar.
I think this extends beyond the standard library. In my experience, once I've written a Clojure function, I rarely need to go back and edit it. The obvious, natural way to implement anything also tends to be correct, concise, generic, and efficient.
It certainly helps that the core library is stable, but that's not the only reason. Even when I'm not upgrading to a new version, Clojure code tends to be stable in a way that other languages are not. With languages like Python, Swift, or C#, I'll be constantly taking something I wrote, and modifying it to add a feature, and again to add another feature, and then re-architecting the whole thing to work in a fully generic way. Or I'm taking something obvious and simple, and changing it all around to make it more efficient.
It's not simply an attribute of Lisp. Common Lisp makes changes which are simple to describe also simple to implement. Clojure quite often makes them unnecessary.
One commenter (puredanger) ran the tool against the Clojure repo and remarked on its stability. After 2011, so past the time examined in the notes from this article, the banding is almost flat: new layers get added while very few changes are made to old code. The image stands out, and indicates how sound the language core library is. They keep adding new features, and don’t have to mess with the plumbing to make them work.
Code half-life: https://news.ycombinator.com/item?id=13112449
Clojure repo chart: https://m.imgur.com/a/rH8DC