I love Clojure's Flowstorm, it makes it easy to verify code is doing what you think — all the data is exposed programmatically so you can also create your own GUIS from it or feed it to LLMs so they can have a deep understanding of program behaviour (or you can browse it yourself)
> A bigger problem is the tedious necessity of having to reconstruct the desired state every single run. When you have something small with limited functionality, that is fine, but as your application grows, rebuilding the state can take a significant effort.
This is what tests are for. There should be no buildup of internal state that can't be arrived at with a simple invocation in a unit test.
Tests help to a point, but anybody who's worked on a large project knows that unit tests miss a lot of stuff because they don't focus on end-to-end relationships in code. There's a whole genre of memes about having unit tests and lack of integration tests for example. Of course you can add, integration tests, and regression tests, and so on. And you should, but doing that in the middle of you figuring how to best implement a particular feature is a lot of drag.
Often, when you're building something new, you're not sure what the best approach is. So, you need room to experiment and try different things to see what works best. Writing tests boxes you into an approach out of the gate.
Sure but do coding agents need this? They can create fixtures or scripts very quickly. No offence, but this article reads like a list of reasons you like Clojure.
I like many of the ideas in Clojure, but I never learned it, so it doesn't matter to me what advantages it provides to an agent if I can't understand the code its creating. This year I've done a lot of work modifying open source applications I use with agents, some in languages I don't know. One is Metabase, which is written in Clojure. Another is Forgejo, written in Go. I had no real experience with either language.
Go was much, much easier to understand in that context. I could review the agents changes and follow data flow, follow tests etc.
And no, its not because I'm more familiar with similar imperative languages. The last 14 years I've written the most code in Elixir and Haskell. Lots of Javascript, C++ and Python as well. Admittedly no Lisp other than a bit of emacs but semantically Elixir is probably closer to Clojure than most Lisps are.
In my experience they do. I use LLMs a lot, and one of the most common failure modes I see is that they implement stuff, but fail to wire it up end to end, or don't consider the broader context. The features of Clojure I outline in the post directly addressed the failure modes I've experienced using most other languages.
In fact, I've actually tried using Python and Js with LLMs initially because my logic was that these languages are more widely used and there's more training data. It's been a miserable experience for me, and I'm having a much better time with Clojure. I'm sharing my own experience here having actually used both types of languages, and the benefits I see in my workflow.
The fact that you're unable to learn Clojure is very much a you problem. I worked at a Clojure shop a while back where we hired university students regularly. They were able to pick up Clojure within a week or two and write useful code with it. The fact that somebody with over 14 years experience can't learn this language is absolutely surreal.
My point is for someone who hasn’t learned the language, Clojure is one of the most inscrutable languages you could choose to use with an agent, and I doubt people who don’t know it will put the time in at this point. I’d expect exactly the same is true of Haskell. I know it well, so sure I can use it with AI, but I wouldn’t expect many will learn it now.
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.
I love Clojure's Flowstorm, it makes it easy to verify code is doing what you think — all the data is exposed programmatically so you can also create your own GUIS from it or feed it to LLMs so they can have a deep understanding of program behaviour (or you can browse it yourself)
Making GUIs with Clojure watching it render in real time is quite an experience.
> A bigger problem is the tedious necessity of having to reconstruct the desired state every single run. When you have something small with limited functionality, that is fine, but as your application grows, rebuilding the state can take a significant effort.
This is what tests are for. There should be no buildup of internal state that can't be arrived at with a simple invocation in a unit test.
Tests help to a point, but anybody who's worked on a large project knows that unit tests miss a lot of stuff because they don't focus on end-to-end relationships in code. There's a whole genre of memes about having unit tests and lack of integration tests for example. Of course you can add, integration tests, and regression tests, and so on. And you should, but doing that in the middle of you figuring how to best implement a particular feature is a lot of drag.
Often, when you're building something new, you're not sure what the best approach is. So, you need room to experiment and try different things to see what works best. Writing tests boxes you into an approach out of the gate.
Sure but do coding agents need this? They can create fixtures or scripts very quickly. No offence, but this article reads like a list of reasons you like Clojure.
I like many of the ideas in Clojure, but I never learned it, so it doesn't matter to me what advantages it provides to an agent if I can't understand the code its creating. This year I've done a lot of work modifying open source applications I use with agents, some in languages I don't know. One is Metabase, which is written in Clojure. Another is Forgejo, written in Go. I had no real experience with either language.
Go was much, much easier to understand in that context. I could review the agents changes and follow data flow, follow tests etc.
And no, its not because I'm more familiar with similar imperative languages. The last 14 years I've written the most code in Elixir and Haskell. Lots of Javascript, C++ and Python as well. Admittedly no Lisp other than a bit of emacs but semantically Elixir is probably closer to Clojure than most Lisps are.
In my experience they do. I use LLMs a lot, and one of the most common failure modes I see is that they implement stuff, but fail to wire it up end to end, or don't consider the broader context. The features of Clojure I outline in the post directly addressed the failure modes I've experienced using most other languages.
In fact, I've actually tried using Python and Js with LLMs initially because my logic was that these languages are more widely used and there's more training data. It's been a miserable experience for me, and I'm having a much better time with Clojure. I'm sharing my own experience here having actually used both types of languages, and the benefits I see in my workflow.
The fact that you're unable to learn Clojure is very much a you problem. I worked at a Clojure shop a while back where we hired university students regularly. They were able to pick up Clojure within a week or two and write useful code with it. The fact that somebody with over 14 years experience can't learn this language is absolutely surreal.
I never said I can’t learn it. I said I haven’t.
My point is for someone who hasn’t learned the language, Clojure is one of the most inscrutable languages you could choose to use with an agent, and I doubt people who don’t know it will put the time in at this point. I’d expect exactly the same is true of Haskell. I know it well, so sure I can use it with AI, but I wouldn’t expect many will learn it now.
I haven't written Clojure in a while.
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.