Maintainability. If you're the only person who can edit the library, you've just created a bus factor that would be unacceptable to most project managers.

As a complement to my other reply to you, I'll note that I developed a simulation system in Java (a very common language), and strove to keep it small, avoid complexity, and generally make it approachable -- but for a long time I remained the only one who understood how the system worked, because you simply had to understand the business domain in order to understand why things worked the way they did.

This is my personal opinion, but I think that domain expertise is a much stronger component of bus factor than language choice is. You can write unmaintainable code in any language. But good code often still has prerequisites to understanding. Meanwhile, if you have the domain expertise, you can get quite far in understanding semi-bad code just by pattern matching on manifestations of your domain.

I mean, that specific library isn't really all that hard to work with. It's not doing anything completely crazy, just somewhat unusual. But in general I think it's probably better to keep the crazy custom environment to personal projects- at least for awful utility macro libraries like mine.

Narrowing down on a single library is one thing. Maybe case by case it's ok. In general if someone showed up and said "I will prototype everything in lisp and you can take it from there" I'd say they are a bit egotistical and not being much of a help to the org. Prototypes are 1% of the work.

And I say this as someone whose full time job was to do research prototypes of robotics libraries for a while.

not only project managers. i love lisp but i dont use it for hobby projects partially because i don’t want to maintain libraries in a small ecosystem where they are often abandoned

The fact that you adapted the famous Heinlein quote for programming just goes to show me a problem with that quote. Recall that the original quote mentioned programming itself as one of the many things that a human should know how to do. But your adaptation illustrates that programming alone is deep enough to merit its own specializations. So just as, IMO, specialization is not just for insects but also for humans living in a functioning, populous civilization, specialization is also fine and expected for programmers, particularly since our numbers have grown over the decades. And to bring this back to my original point, yes, this means that we shouldn't all be writing lowest-common-denominator code in mainstream languages. But I still think it's a good idea to avoid needless fragmentation.

Fair enough; I think I'm describing the horizontal bar of the "T" and you're pointing out the vertical, and we differ on the amount of fragmentation ergolib represents. (Despite not using CL on the daily, upon perusing ergolib's source I found it a relatively straightforward mod-con library, so I don't think it necessarily fragments)

(But I was pretty serious about that list: I would hope a programmer just out of school would have heard of all of them, and expect anyone experienced to have done most of them, if not necessarily in the languages that make each one easy. Similarly, from Heinlein's original list, I currently lack only practical experience in planning invasions [though I have theoretic hex-board experience], butchering hogs [though I have a friend who has offered to teach me], and dying gallantly [though I have "I am just going outside and may be some time" as an example to follow should the occasion arise])