But, looking at the examples (picked the Wordle one since I know that game): https://github.com/HumbleUI/HumbleUI/blob/main/dev/examples/...
I find it extremely hard to read. Even small snippets, say line 56 to 74 which define this "color", "merge-colors" and "colors"... then the "field" one lines 76 to 117 is even harder.
is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)
I wonder what the same Wordle example would look like in, say pure Flutter.
Also wonder how would that code look with external dependencies (say hitting a server to get the word of the day), and navigation (with maintaining state in between those pages)
I avoided Clojure for nearly 15 years because I thought so too.
Turned out I spoke English and couldn't read Russian. But that didn't mean Russian was unreadable—I just didn't know how. It had nothing to do with whether or not it was "readable" or not, it was easy to read (and understand) once I learned how.
After about two weeks, I found reading Clojure to be just as easy as any other code. I did that at 46, so I don't think age is a major barrier. (I've written read and written code my entire life.)
I'm now writing Clojure code every day and am much happier as a developer. (That's why I made the effort initially, and it definitely paid off.)
One thing that really helped was asking ChatGPT or Claude to explain a piece of Clojure code to me, when I had questions. Especially early on, that was invaluable.
Also, learning structured code editing made a big difference—I consider it to be essential. It was extremely frustrating until I spent an afternoon doing that.
Clojure code is "read" differently than, say, Python or JavaScript or C and that's reflected in how you navigate and edit the code.
YMMV
Once you learn the basic structural editing commands, writing code becomes like composing poetry out of haiku pieces. Instead of thinking like: "how do I grab these vars used inside this function and refactor it to be them in their own unit?...", you'd just grab some expressions and move them around, like bricks or lego pieces. It is extremely satisfying way of writing programs. The only drawback of that approach is that later it becomes harder to work with "more traditional" PLs, you just can't easily manipulate code the same way in Python, JS/TS, Kotlin, Java, C++, etc. - you need a "structured", homoiconic, lispy language for that trick to work. Treesitter makes an effort to improve the process, but it still not on the same level of simplicity.