Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electric Clojure v3: Differential Dataflow for UI [video]

hyperfiddle-docs.notion.site

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#11

Post by pgt »

BaculumMeumEst wrote: post #2

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?

The advent of competent LLMs has increased the viability of using more powerful "esoteric" languages like Clojure because it solves The Hiring Problem: I can ask it to rewrite my application in another language, or it can help junior programmers write better code.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#12

Post by sesm »

BaculumMeumEst wrote: post #2

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?

Recently I was writing Pedestal code (for the first time in my life) and ChatGPT was ok at generating boilerplate for it. If the nature of the code is boilerplate like and there is online documentation that ranks high in Google search, I suppose ChatGPT will do ok for any language.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#13

Post by barrell »

BaculumMeumEst wrote: post #2

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?

Been working with a Clojure, Python, and Elixir codebase since the advent of LLMs. It’s shockingly bad at Clojure still, but can get halfway decent with Elixir. Claude has always been better than OpenAI at Clojure, but that’s not really saying much.

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)

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#14

Post by jraines »

BaculumMeumEst wrote: post #8
amw-zero wrote: post #4

Earlier quoted context omitted.

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.

It’s honestly top of mind question for someone like me, who loves Clojure but doesn’t want to be disadvantaged for this reason. Like I wonder if the “Blub paradox” is still real or if we’re in a world where “if Blub isn’t the answer you aren’t using enough of it (spat from an LLM)”.

Like try finding YC job posting without TS and/or Python in the requirements :-/

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#15

Post by manishsharan »

sesm wrote: post #12
BaculumMeumEst wrote: post #2

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?

Recently I was writing Pedestal code (for the first time in my life) and ChatGPT was ok at generating boilerplate for it. If the nature of the code is boilerplate like and there is online documentation that ranks high in Google search, I suppose ChatGPT will do ok for any language.

I have found chatgpt to be shockingly good for writing functions. I decompose my problem domain into a series of functions and I have chatgpt generate code for each those functions. My greatest fear is that I am losing my memory when in comes to clojure's built in functions as ChatGPT has been taking care of those for me for close to over a year.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#16

Post by sabbaticaldev »

BaculumMeumEst wrote: post #2

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?

when AI can code clojure it’ll be called “AGI”

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#17

Post by dustingetz »

amw-zero wrote: post #3

What 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 site macros (e/client & e/server) let the programmer declare what site an effect must run on. The network is not explicit, only implied. For example, platform calls like (query-database) or (.createTextNode js/document) or (check-password) are inherently sited. Siting is essential complexity (arguably the essence of a distributed system), and consequently we as programmers are hyper-aware of where (at which site) our effects must run, and we require perfect control over their placement.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#18

Post by roenxi »

j-pb wrote: post #5
BaculumMeumEst wrote: post #2

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?

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.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#19

Post by BaculumMeumEst »

jraines wrote: post #14
BaculumMeumEst wrote: post #8

Earlier quoted context omitted.

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.

It’s honestly top of mind question for someone like me, who loves Clojure but doesn’t want to be disadvantaged for this reason. Like I wonder if the “Blub paradox” is still real or if we’re in a world where “if Blub isn’t the answer you aren’t using enough of it (spat from an LLM)”. Like try finding YC job posting without TS and/or Python in the requirements :-/

Figured I wasn't the only one.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#20

Post by riwsky »

roenxi wrote: post #18
j-pb wrote: post #5

Earlier 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.

It’s a lisp, so arguably you can abstract away “actually writing the code” too, behind macros
Post reply on HN