but I think clojure is well suited for the age of llm's. token efficient .everything is data even the code is data is easy to deal with verification. pure functions etc.
however one will still need to know how to write / read clojure. when the industry is trending towards not reading code e.g the shit dhh has been parroting lately about not reading code and likewise many people in the industry.
Just today I got some project discussion related to Alokai (https://alokai.com/).
With platforms like this one, the whole programming is done in natural language, and the same attention given to the generated code, as most folks look into the Assembly output of their compilers.
This is now the trend across all SaaS products with extension points, the old SDKs are now legacy, or specific MCP tools, the new way is "agentic".
What I expect will happen is that we'll move more towards creating specs and contracts as developers that the LLMs will fill. And this works great with Clojure.
For example, I've been working on this library which lets you specify the state graph and constraints https://github.com/jlt-commons/writ
And I used it to formally encode Erlang OTP specs in a machine verifiable way here https://github.com/jlt-commons/ensemble/tree/main/test/ensem...
All I can say is best of luck to anybody trying to do something like that using natural language.