Rich Hickey once called TDD "guardrail programming", because it's like navigating to a location by first making contact with the guardrail and then just letting go of the steering wheel.
What they value is "hammock time", which is similar to what used to be called "Turinging" by the people working with Alan Turing, you just stare at the problem for hours and weeks and months, until a solution seems to magically manifest itself as obvious. Or in Richs' case, you just lay in a hammock with your books and a laptop, and think about your problem domain until the solution becomes easy.
Clojure itself is a tool that is meant to be refine- and hone-able by a skilled user, but can create a mess in the hands of a junior/AI.
Case in point, I've been working on the same 20k lines of code for the last 5 Years, and I don't mind it because I feel like I'm gaining another meaningful insight into my problem domain every few weeks. I'm not even working in Clojure anymore but the mindset is something that stuck to me.
The whole point of explorative REPL based programming is that it allows you to further your understanding of the problem. And the value is in the understanding, and not the code.
I feel like this is best captured by a story that my father (an artist/designer) once told me.
The Shogun and the Artist
Once, a young shogun visited Mount Fuji and was so captivated by its beauty that he commissioned a renowned local artist to create an ink wash painting of the mountain. The shogun instructed the artist to complete the painting by the time he returned from his travels.
Years passed, and the shogun finally returned, eager to see the painting. However, the artist apologized, explaining that he had not yet finished. The shogun, though disappointed, granted the artist more time.
More years went by, and the shogun returned again, only to find the painting still unfinished. Yet again, the shogun, moved by the mountain's beauty, granted another extension.
This pattern repeated for many years, until both the shogun and the artist had grown old. Finally, the shogun, tired of waiting, demanded the artist finish the painting.
“We are both old and frail,” the shogun said. “I may not live to see the day you finish. I want to visit Mount Fuji through your painting, even if I can no longer travel. Finish it now—I demand it.”
“Very well,” the artist replied. He took up his brush and, in just a few strokes, perfectly captured the essence of Mount Fuji.
The shogun was astonished. “This captures the essence perfectly,” he said. “But if it took only moments, why did you make me wait a lifetime? Do you think so little of me?”
The artist smiled and replied, “On the contrary, my lord. I have painted Mount Fuji every day since you first made your request. But it took a lifetime of learning, experimentation, and experience to capture its essence like this.”
Understanding at last, the shogun rewarded the artist for his lifetime of dedication.I believe there is a macro for that.
The most optimistic outlook I've heard on AI+Clojure is that AI is not magical and still benefits from good abstractions. So hopefully as models get better at reasoning, using something like Electric Clojure will help them write clean, maintainable code.
I think Clojure (or any lisp) applications tend to lean towards mini-DSLs that don’t lend themselves to generalization very well. There’s also not much agreement in the community on any single problem or way of doing anything (one of the best and worst parts about the language)
Like try finding YC job posting without TS and/or Python in the requirements :-/
- locally reasoned about (pure functions that compose)
- static type checking (so that nonsense is discovered at compile time)
Weirdly this makes Python a worse choice and Haskell a better one. Clojure benefits a little bit.
I don’t think people are choosing language stacks based on what is best for the problem. The main factor is “what do I already know?”
Copilot and other ai powered autocompletes mostly amount to large boilerplate generators. macros in lisp and elxiir are strictly better in terms of long term maintenence in the cases that warrant that. But autogenerated code with a junior checking it in under "trust me bro" does not instill confidence in me.
I'm reminded of a situation a few months ago with my (nontechnical) cofounder. He had been discussing our recent funding round and strategies for growth with another CTO friend he knew. The approach he was a proponent of was hiring a bunch of gifted juniors and watching them like hawks. The idea is that they would produce lots of code for all the upcoming features. The problem here is obvious. Juniors make messes and more code != better code. These new AI powered pushes seem to basicly be this strategy on steroids. I can certainly see the strength of it if you're trying to build fast, get traction and get acquired before the house of cards falls apart.
Personally, I don't see it as a optimal strategy when you're trying to build a viable long term business. Platform matters. Ergonomics matter and most importantly, Human intelligence matters. We hired another senior engineer instead and we're doing fine. If I had to do it over again, I would still stick with elixir.