Electric Clojure v3: Differential Dataflow for UI [video]
hyperfiddle-docs.notion.site
Electric Clojure v3: Differential Dataflow for UI [video]
1–10 of 53 posts
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#2I'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?
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#3What I’ve never understood about this approach is that it claims to be “network transparent,” but you need to add client and server annotations. So it’s very much network-aware.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#4I'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?
Try making comments that are relevant to the article.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#5I'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?
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, 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.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#6What I’ve never understood about this approach is that it claims to be “network transparent,” but you need to add client and server annotations. So it’s very much network-aware.
The author says somewhere that, paraphrasing, where something runs in a distributed system is essential complexity. I think the transparent part is where / when the communication between front and back end happen. The "transparency", whether or not it's the right term, it compared to having to do software development with awareness of the network interactions vs just calling out what runs where. No adding endpoints for everything, managing http calls or webhooks, etc.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#7What I’ve never understood about this approach is that it claims to be “network transparent,” but you need to add client and server annotations. So it’s very much network-aware.
The author says somewhere that, paraphrasing, where something runs in a distributed system is essential complexity. I think the transparent part is where / when the communication between front and back end happen. The "transparency", whether or not it's the right term, it compared to having to do software development with awareness of the network interactions vs just calling out what runs where. No adding endpoints f…
In the video Dustin also makes the point that in v3 all the client and server annotations can now be kept fully isolated from the parts of the code that model the essential complexity (i.e. any dynamic scoping or function parameters used by a 'pure' function are also network transparent), and this dramatically reduces the amount of global coupling across the codebase.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#8I'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?
Try making comments that are relevant to the article.
I've seen that the author of Electric Clojure is pretty involved in the startup scene and I was curious about how those folks perceive the changing world.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#9I'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?
Maybe because language models are mostly good at boilerplate and Clojure and lisps in general are mainly about eliminating it entirely. Clojure programs are very terse.
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#10I'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?
Claude 3.5 Sonnet is pretty good at writing Clojure, including Electric Clojure. The mistakes it makes (IME) tend to be the same kind of mistakes that human programmers make.