I've found that the gap between generative AI's ability to generate code for mainstream languages and niche languages such as Clojure is growing. It is getting much better at generating code for the former, and continuing to flounder for the latter. How do Clojure folks feel about that? Do you disagree, or maybe see it as a non-issue?
Electric Clojure v3: Differential Dataflow for UI [video]
21–30 of 53 posts
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#22Earlier quoted context omitted.
Clojure people are probably THE community with a philosophy diametrically opposed to AI generated code. 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,…
By a similar argument, the Clojure people could be said to be diametrically opposed to human-generated code. Which is also true-ish, but not that meaningful an observation. At some point code needs to be written by someone or something.
I believe there is a macro for that.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#23Earlier quoted context omitted.
Clojure people are probably THE community with a philosophy diametrically opposed to AI generated code. 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,…
By a similar argument, the Clojure people could be said to be diametrically opposed to human-generated code. Which is also true-ish, but not that meaningful an observation. At some point code needs to be written by someone or something.
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.Re: Electric Clojure v3: Differential Dataflow for UI [video]
#24On the other hand, there is a ridiculous amount of power in Lisps. Operating at a higher level of abstraction is like having magical powers. When you go back to programming in Go, you feel like someone chopped off one of your arms or legs.
On the other hand, to be fair to Go, when you are an immigrant in a Go codebase, everything is very easy. Turn this way ... oh I've seen this a thousand times before its an XYZ. Turn that way, oh, I don't even have to read that, I know what that is. Oh what is that ... oh its my greencard to this codebase, I can now fix bugs with confidence.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#25This feels over engineered to me. The classic cool factor influencing the “if we could vs if we should”, bolstered by developing it as a software engineer on a performant dev box with impeccable internet connection; hell, maybe even a local dev db clone.
I suppose you could argue server side caching would alleviate some of the pains of a design like this, but you’re still performing redundant server round trips for the stream when a piece of data goes in and out of view.
Does the tech have any local caching options to make this a little more sane for a worst case an end user?
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#26I've found that the gap between generative AI's ability to generate code for mainstream languages and niche languages such as Clojure is growing. It is getting much better at generating code for the former, and continuing to flounder for the latter. How do Clojure folks feel about that? Do you disagree, or maybe see it as a non-issue?
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.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#27Love Clojure, but am repulsed by the idea of a “responsive DOM network stream”. This feels over engineered to me. The classic cool factor influencing the “if we could vs if we should”, bolstered by developing it as a software engineer on a performant dev box with impeccable internet connection; hell, maybe even a local dev db clone. I suppose you could argue server side caching would alleviate some of the pains of a…
This is not the way how Electric apps work, this was just a demonstration of how easily you can orchestrate complex network-transparent client-server interactions _when_ you need them.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#28Love Clojure, but am repulsed by the idea of a “responsive DOM network stream”. This feels over engineered to me. The classic cool factor influencing the “if we could vs if we should”, bolstered by developing it as a software engineer on a performant dev box with impeccable internet connection; hell, maybe even a local dev db clone. I suppose you could argue server side caching would alleviate some of the pains of a…
> Does the tech have any local caching options to make this a little more sane for a worst case an end user?
This is trivially solved in Electric- as long as you hold onto a client-side handle of the data, it won't be unmounted.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#29You can do absolutely magical interactive apps with Electric. However, I think, the catch is that the learning curve of Missionary and Electric is _very_ steep, and you have to understand the concepts pretty deeply in order to successfully debug (hence, to make) your code. And it is worth it, in my opinion — the concepts used are beautiful in a mathematical way and fit together pretty well.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#30As much as I love lisps, and I've written a fair bit of code in Scheme, Racket, and Clojure, I have to admit, when you are an immigrant in another person or organization's code, their specific abstractions, DSLs (macros), etc., can be very (VERY) burdensome to get up to speed on to even begin to start contributing to the codebase (much less debugging complicated issues). On the other hand, there is a ridiculous amoun…