[HN Gopher] Electric Clojure v3: Differential Dataflow for UI [v...
___________________________________________________________________
Electric Clojure v3: Differential Dataflow for UI [video]
Author : refset
Score : 83 points
Date : 2024-08-22 11:24 UTC (5 hours ago)
(HTM) web link (hyperfiddle-docs.notion.site)
(TXT) w3m dump (hyperfiddle-docs.notion.site)
| BaculumMeumEst wrote:
| 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?
| amw-zero wrote:
| Try making comments that are relevant to the article.
| BaculumMeumEst wrote:
| 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.
| jraines wrote:
| 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 :-/
| BaculumMeumEst wrote:
| Figured I wasn't the only one.
| j-pb wrote:
| 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.
| roenxi wrote:
| 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.
| riwsky wrote:
| It's a lisp, so arguably you can abstract away "actually
| writing the code" too, behind macros
| nanomonkey wrote:
| > At some point code needs to be written by someone or
| something.
|
| I believe there is a macro for that.
| j-pb wrote:
| But code as the formalisation of the problem is not
| seperatable from the understanding of its domain.
|
| 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.
| lambdaba wrote:
| 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.
| pgt wrote:
| 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.
| pgt wrote:
| 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.
| sesm wrote:
| 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.
| manishsharan wrote:
| 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.
| barrell wrote:
| 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)
| sabbaticaldev wrote:
| when AI can code clojure it'll be called "AGI"
| KingMob wrote:
| Agreed, this mirrors what I've found using LLMs with Clojure
| and Python. Any large language with lots of training data is
| going to get good results from LLMs.
| yayitswei wrote:
| I largely agree with the comments here, that LLMs struggle with
| Clojure but Claude does it best at the moment. I also use it
| mainly for writing individual functions, though it occasionally
| correctly generates a simple Electric app with my desired
| functionality (Projects help, along with giving it lots of
| examples).
|
| 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.
| amw-zero wrote:
| 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.
| ojw wrote:
| 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.
| refset wrote:
| 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.
| dustingetz wrote:
| 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.
| TheMagicHorsey wrote:
| As 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 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.
| lispisok wrote:
| Your comments about Go make sense since it was no secret Go was
| designed to get junior engineers at Google up to speed being
| productive as fast as possible.
| diggan wrote:
| And on the opposite side, Clojure was made with a full focus
| on getting professional developers with lots of experience to
| be able to use Lisp in places they normally couldn't
| (initially Java shops), with no compromises to make it easier
| for beginner programmers.
|
| And that's OK, not every language needs to cater to everyone
| :)
| teoingdri wrote:
| Love 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 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?
| nlitened wrote:
| > you're still performing redundant server round trips for the
| stream when a piece of data goes in and out of view
|
| 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.
| yayitswei wrote:
| Have you tried it? I was skeptical too until I built a few apps
| with it. The learning curve is easier than it seems (I started
| by modifying the examples) and it really does cut down on
| development time - turns out much of modern web programming
| revolves around network management and its associated
| complexities.
|
| > 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.
| nlitened wrote:
| Dustin, Leo, and the rest of Electric team are brilliant,
| borderline geniuses.
|
| You 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.
| dustingetz wrote:
| Thanks! We hope the v3 learning curve will be a lot better; v2
| has a bunch of non-obvious semantics that you just had to learn
| (as described in [1]) - which are now fixed in v3. But you're
| right, Electric is for experts. We built it for ourselves in
| order to meet the performance and scalability requirements of
| our upcoming product Hyperfiddle - low-code declarative
| infrastructure for UI--or more simply, a CRUD Spreadsheet.
| https://www.hyperfiddle.net/
|
| [1] https://hyperfiddle-docs.notion.site/Electric-
| Clojure-v3-tea...
___________________________________________________________________
(page generated 2024-08-22 17:00 UTC)