[burnthrow]

Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity.

There's some doublespeak going on here.

When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.

[pinchhit]

This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them.

Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.

[kazinator]

> it's actually convinced me on the virtue of regular OO/procedural languages over lisp.

This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure.

You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.

[thisiszilff]

To what extent do you think it is a clojure problem vs a people problem? Further up in the comment thread there was a post discussing how some orgs had problems because people would be writing java in clojure (or python or ruby, etc.). I can see there being problems with people no writing idiomatic clojure code in part because clojure is nwe and their experience is in OO/procedural languagees.