I think this is the most treacherous assumption people tend to make about programming languages, for a few reasons. One of them is that we really don't have any way to measure software that we actually use day to day.

Think about the software controlling your local water treatment plant, traffic lights, the software your local power company relies on, the software running the servers you connect to, and all the servers those things connect to. All the infrastructure in between and the infrastructure's own infrastructure. Allegro Lisp's customers are shotgun spread in industries like healthcare, finance and manufacturing. They're paying for it, so we can infer they're using it, but can anybody actually name what software is written in it?

If we play six degrees of separation, accounting for the full gamut of every single computer that does something relevant to your life no matter how distant, how much of that software are you actually familiar with? The fact of the matter is that we genuinely have no broad picture. There is no introspective method to find out what software you are relying on in your day to day life, almost all of it is completely opaque and implicit. To ask "what software do I use?" is to ask an unanswerable question. So to then synthesize an answer is to work with an unsound, unsupported, incomplete conclusion, which is exactly how you end up assuming you don't use software written in Lisp, while directly using software written in Lisp (HN)

Of course, even accounting for the epistemic issue, the premise is still flawed. ATS is a language with 'useful ideas, but...', Haskell is an aging pragmatic kitchen sink. Positioning the latter as the former is almost comedic.

Like I said: Clojure runs significant chunks of Walmart's infrastructure, Nubank's entire banking stack serving several hundred million customers - for a second, Nubank is the biggest digital bank in the world; Apple uses it; Cisco uses it. Emacs Lisp runs one of the most enduring pieces of software in computing history. You you ever used Grammarly - it's powered on Lisp; This very site runs on Lisp.

"I don't encounter Lisp in my work and that feels meaningful to me" (there's no other way to interpret your words) is just another, personal opinion that has no practical, objective angle. "The Curse of Lisp" opinion, at least back in the day had some objective relevance that no longer holds true.

Let's walk through your examples:

SQL libraries: Korma is dead, YeSQL is dead, HugSQL is in maintenance mode. The community converged on next.jdbc + HoneySQL. That's not fragmentation - that's exploration followed by selection.

Build tools: Boot had its moment, it's essentially gone. Leiningen is still around but new projects overwhelmingly use deps.edn. That's not fragmentation either - it's a transition, and a remarkably clean one.

Spec vs. Schema vs. Malli is the most interesting case because the convergence is still in progress. Schema is effectively in maintenance mode. Spec has stalled (spec2 never really shipped). Malli is clearly gaining momentum as the community choice for new work, largely because it treats schemas as data — which is very Clojure. But even here, these aren't competing implementations of the same thing the way, say, Javascript build tools are. They have meaningfully different design philosophies, and the community is converging on the one that best fits Clojure's values.

Compare it to JS, where we have Webpack, Vite, esbuild, Parcel, Rollup, Turbopack, and the "winner" changes every 18 months. Or Python's packaging story - pip, pipenv, poetry, conda, PDM, uv - which is still a mess after decades with a vastly larger community. Fragmentation in large ecosystems often doesn't self-correct because there's enough mass to sustain competing approaches indefinitely.

The small community size that you frame as a weakness is actually why the self-correction works. There aren't enough people to sustain five competing SQL libraries, so the best one wins and everyone moves on. The tight community, the shared values around simplicity and data orientation, and the fact that people actually talk to each other - these create selection pressure that larger, more diffuse ecosystems lack.

The productivity gains aren't speculatory - from the most pragmatic angles, I see time and again - they are real and palpable.