My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic.
At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time?
I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so.
Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make.
That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there.
I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.
Over and over again, they have been perfecting the art of "building things fast." The problem [with the most] programming languages today, that although they provide frameworks, command-line tools, code generators, etc. to build things quickly, the codebases very quickly become difficult to maintain and scale.
So many times, I have seen it myself. I quit jobs simply because I exhausted my mental and cognitive capacity to deal with the code that I wrote myself several months ago.
While Clojure codebases, no matter how messy they can get, they feel very much like gardens - you can slowly and organically keep growing them.
Some may say: "You're talking about Haskell, or Scala, (or some other language)" And in my experience, although you can do pretty cool things in those languages, sometimes simple, dumbed-down solutions are better. Some may argue: "Now you're talking about Python, or Go...". I think Clojure has a perfect balance between "sophisticated, ultrasmart" PLs and Pls with the books titled "X for complete idiots."
I think Clojure is an ideal language for writing business apps and more and more companies starting to see that.
I don't disagree with anything you've said, and might be myself one of those grumpy programmers :)
But that isn't at odds with the view that Clojure is more fit in some environments than others, depending on existing knowledge, deadlines, budget etc.
Maybe I'd introduce Clojure in ~6 out of 10 projects. I want that N to be 9.
Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully.
I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
My background is freelancing/consulting where it's not uncommon to gather diverse individuals to work on a greenfield project.
There's an implicit assumption that all participants know a thing or two about programming, and accordingly are apt learners.
So yes, on day 3 the code won't be perfect, neither on day 6 but after a few code reviews one can get stuff done.
Personally I wouldn't be comfortable prescribing Clojure for such a project, in contrast to other languages which I've never coded in, but that I know that socially, today, work better.
Your test is basically asking “is it similar to something popular”, there will always be a learning curve when changing to a new, different from what you’re used to, tool. In my personal experience, I’ve seen people go from no Clojure or functional programming knowledge to productive in a few weeks, that’s quicker than I’ve seen some people go from non-OO to OO (although I imagine it has more to do with the people than with the paradigms)
I think it's a problem loop. No one wants to use Clojure because it's hard to impossible finding Clojure Devs. Also no one wants to learn it for the same reasons. The demand is less to non-existent to a point any time spent learning Clojure is unlikely to give any substantial returns.
I would say Clojure more than substantial returns of invested time. Not just the language itself, but also the wider approach to software composition, feature accretion vs backward compatibility, schema'd dynamic typing seem benefictial no matter what your development tools you use. Maybe check out the talks below and see if they don't enRich you as software engineer.
If anyone reading this is in this situation: hi! I've been working in Clojure(&script) for eight years, and I'm looking for full-time work. Email is in my profile.
At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time?
I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so.
Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make.
That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there.
I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.