1. Weirdly irregular syntax.
2. Java import statements and Java error backtraces anywhere you want to do real work.
3. Inexcusable renaming and name collisions on basic Lisp functions.
It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cases of using a Lisp or targeting the JVM with a more expressive language.
As an example I remember a presentation done some time ago where the presenter was showing code in F# and many non-technical people understood the code thinking it was a pseudo code at first (i.e. business stakeholders/BA types/etc). That was a win for them. If I showed F# and Clojure code side by side to an ex-coder manager as an example syntax I'm sure would matter and they often have a say in this decision. Buy-in is an important criteria in language selection for sure, as well as current skilled developers. If the pool of devs is small how easy it is to train people and get people wanting to be trained in it thinking it may be dead end skill with no jobs? I don't have that opinion personally but some dev's definitely do. Especially because jobs in these languages are scarce; if learning curve is small then it could be used even then.
My cynicism shows marketing and perception of a tech stack are equally if not more important than other factors in tech selection in many companies. No one got fired for picking IBM or in this day and age Java?
2. If you’re writing a wrapper to existing java lib maybe
3. Tough to be a particular lisp fanatic I guess.. Clojure helped me to get into lisp big time and all other lisps now feel clunky and inelegant.
For those of us who work for someone else - Clojure is a godsend. What's the alternative? No Lisp at all, and truly weirdly irregular syntax. Show me a single pragmatic and more or less popular language that's being used in the industry for building business apps that has nicer syntax than Clojure.
"Irregular syntax", as in not consistent with itself? Or, with historical LISPs? Some examples would be interesting.
>3. Inexcusable renaming and name collisions on basic Lisp functions.
Given that it isn't a version of common lisp that happens to target the jvm being more superficially similar while actually being substantially different wouldn't be a virtue. It would confuse more than it would illuminate.