Live data from Hacker News

Electric Clojure v3: Differential Dataflow for UI [video]

hyperfiddle-docs.notion.site

31–40 of 53 posts

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

#31

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 amoun…

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.

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 :)

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

#32

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…

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

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

#33

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…

Re. performance - Electric v2 is already faster than alternatives for many kinds of apps (not all). We expect v3 to be so fast that it can express apps that are outright impossible with alternatives. The robotics observability IDE in the talk, for example, as well as Hyperfiddle itself.

Re. server caching – Electric (being reactive) auto memoizes all scopes, even on the server. (The essence of reactive programming is a time/space tradeoff - cache more things to minimize recomputation later.) For example, in the virtual scroll demo from the talk, the database query runs once and is retained in memory, so that scrolling simply indexes over the memoized collection:

    (defn window [xs offset limit]
      (subvec (vec xs) ; fast cast
        (Math/max offset 0)
        (Math/min (+ offset limit) (count xs))))

    (e/defn Window [query! offset limit]
      (e/server
        (let [xs ($ e/Offload #(query!))] ; retain and reuse xs as offset changes
          [(count xs) (e/diff-by identity (window xs offset limit))])))
Regarding client caching - it's basically the same. Hoist the value you want to save to be above the conditional that is disposing it. If that doesn't work, use an atom.

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

#34
I hate stuff like this.

It's so incredibly brilliant that it spoils me for mainstream tech, but it's never actually "done enough" for mgmt to feel comfortable adopting it in any capacity. (See also: Unison https://www.unison-lang.org/)

Or, you can get them to adopt, but then you hit hiring limitations.

I say this as someone who built a large team of Clojure developers in a Fortune 100 company, and lived to regret it.

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

#35
post #34

I hate stuff like this. It's so incredibly brilliant that it spoils me for mainstream tech, but it's never actually "done enough" for mgmt to feel comfortable adopting it in any capacity. (See also: Unison https://www.unison-lang.org/ ) Or, you can get them to adopt, but then you hit hiring limitations. I say this as someone who built a large team of Clojure developers in a Fortune 100 company, and lived to regret it…

> Or, you can get them to adopt, but then you hit hiring limitations.

Depends on how flexible your "hiring principles" are. You mention you did this at a Fortune 100 company, so obviously you didn't have any flexibility at all. But for the (good) places that allow people to learn on the job, you just need to find a sufficiently smart person who likes to learn, and they'll get up to speed with Clojure relatively quickly, as long as their first reaction when seeing parenthesis isn't "eww".

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

#36
post #34

I hate stuff like this. It's so incredibly brilliant that it spoils me for mainstream tech, but it's never actually "done enough" for mgmt to feel comfortable adopting it in any capacity. (See also: Unison https://www.unison-lang.org/ ) Or, you can get them to adopt, but then you hit hiring limitations. I say this as someone who built a large team of Clojure developers in a Fortune 100 company, and lived to regret it…

Could you share more about your experience?

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

#37
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)…

How does this implicit, "bottom up" definition of the network boundary between client and server cope with version incompatibilities? You, as the developer, control what version of your code is running on the server, but you don't have direct control over what version is running in the browser.

In approaches with an explicit API, you can explicitly maintain backward compatibility for a period of time until you believe that enough browsers have "caught up" to newer versions of the software running on the server to allow you to retire that backward compatibility.

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

#38
A short story from the pre-development of Electric/Hyperfiddle. I was sitting at a table with Rich and Dustin after Conj in Philly. Dustin was trying to explain some of these (still hypothetical) ideas to Rich, and Rich was just too tired from the keynote to really follow along. He wasn't dismissive, but just didn't seem to get the Big Idea. Many people would have taken that as a sign and possibly dropped the idea.

Not Dustin though, if anything he seems to have doubled down and sought to prove the ideas with working libraries. Here we are years later with a growing community and excitement about this real working software.

Bravo Dustin for having the strength to stay the course. You knew you were on to something way back then, and haven't lost sight of it.

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

#39

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”

I think you mean “AEI”: Artificial Enlightened Intelligence

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

#40

A short story from the pre-development of Electric/Hyperfiddle. I was sitting at a table with Rich and Dustin after Conj in Philly. Dustin was trying to explain some of these (still hypothetical) ideas to Rich, and Rich was just too tired from the keynote to really follow along. He wasn't dismissive, but just didn't seem to get the Big Idea. Many people would have taken that as a sign and possibly dropped the idea. N…

ha nooo i think he said: “i am looking for something more flexible” than the immutable REST payload POC we were playing with at the time (this was 8 years ago). He was right!
Post reply on HN