A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..."

The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure.

What I mean by this:

I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need of being more productive and writing more robust code.

Yes, you can write functional, immutable, dynamic, code in Java and do meta-programming in Java!

It's just somewhat cumbersome and prickly.

Enter: Clojure.

I've seen many an 'unwise' programmer make just as much a mess of Java systems as people are suggesting they've seen in Clojure projects. It may be simply that Java slows you/your team down enough so that the messes of unwise programmers are just made more slowly.

But one wonders if this is really a win: you're probably also delivering your business value more slowly, as well.

:thinking-face:

I use Clojure because I am not a particularly wise programmer (I have been fortunate to work with many actually wise programmers).

I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantics, or concurrency issues), dynamic (no pre-definition or ceremony required), concise (thanks to a literal representation that does not even require commas between elements), and have a generic access api (no custom functions/accessors/etc).

Because I use the exact same transformation functions on EVERY PROBLEM, there is an enormous amount of reuse of generic operations both within and across Clojure code (even Clojure code that manipulates Clojure code, which is after all, just data).

Because the center of our code is open data, coupled with generic functions open to later extension (multimethods, protocols), Clojure is notably good at handling information systems that evolve over time in requirements (a feature of essentially all of them).

The core constructs are not hard, certainly they are easier to learn and use than complicated things like mutable classes and locking. The unlearning from other languages is often bigger than the learning. Nubank for example is certainly not hiring 100s of Clojure developers - in most cases they are hiring good people and teaching them Clojure. There are other successful companies doing the same.

Large Clojure programs can be hard to reason about because large programs are hard to reason about. One benefit of Clojure programs is that they are often 100x smaller than the equivalent program in a popular OO language. They are also trivial to interact with live in your REPL so that you can inspect the data flowing through them. I will happily take live data and interactive function execution over 1000 classes with custom methods. Both require time to learn but I'm much happier changing the smaller, simpler one.

The idea that "Clojure requires wise developers" is completely backwards. Enormous modern class/annotation based OO programs are the ones that require the smartest developers because that's what it takes to understand them. Clojure is accessible to all.

[0] https://github.com/redplanetlabs/specter

Data driven languages need simple & powerful transformation libraries. `get-in` is repetitive and tiresome to use.

Specter and it's ilk make transformations clear and simple.

No amount of planning or foresight negates the need for data transformation libraries.