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.
Right, hence my pitch is that people should actually learn Clojure. You still need to understand what the code is doing, but there's a much bigger case for using a high level language that's concise and expressive with LLMs around.
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".
I think this kind of stuff will work for certain domains, but there are limitations of what you can do in terms of defining complex behaviors using natural language. I expect there are still going to be plenty of software problems where you do need to be far more hands on. A formal description will always be more precise at the end of the day.
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.
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.