> https://github.com/dustingetz/missionary-quickstart/blob/main/src/quickstart.cljs#L141-L145 I've seen the claim of "flows as referentially transparent" in the missionary docs before and struggled to understand it for a long time. I think it's because I am both not used to thinking of an expression as a process, and because I am not used to thinking of a process as a value. I think it would be useful to drive home the fact that flows can be thought of as values and can therefore be referentially transparent. I also think a couple of functional counterexamples that break composition due to their non-referentially-transparent nature would go a long way.

keep reading lmk if your q is resolved

https://github.com/dustingetz/missionary-quickstart/blob/main/src/quickstart.cljs#L271 is helpful. The term "recipe" is helpful, too. On this https://github.com/dustingetz/missionary-quickstart/blob/main/src/quickstart.cljs#L124C42-L124C47, I ask myself "but what about returning a new promise from a function each time?" And then I wonder "hm, maybe reuse means share work here, not run a process twice."

(Not sure that I'm explaining myself well here.)

I dunno, for me the key to understanding what you mean by "referentially transparent" (to the extent that I do understand) is to remind myself 1) that we're talking about recipes here, and 2) that a recipe can be a value.

generally really like the quickstart though, nice job

I suppose it can be considered good prep for today’s talk?

re work sharing, the way you'd reuse the result of running a flow, is through m/signal or m/stream which are recipes that allocate a memo buffer

if you did that, in the N <input example, you'd get one input in the DOM and it's latest value would be repeated 3 times. So compare "reuse the recipe 3 times" vs "run the recipe once and buffer the result, reusing the buffered result 3 times"

i will add a new example for that, or even you can add it and send PR!

The test results do not show up in the Calva output window. Is that on purpose? (I find them in the dev console of the app).

My brain confuses rcf/tap (which referred becomes just tap) with tap>. Might be worth a comment both in the rcf docs and in this starter file?

Calva (well, clojure-lsp/clj-kondo) complains about missionary.Cancelled. But the REPL is happy about it. Can we make clj-kondo happy too in some way?

Is nil not expected here?

cannot reproduce nil, invoking task main returns cancellation callback

> The test results do not show up in the Calva output window. Is that on purpose? (I find them in the dev console of the app). This also tripped me. Screenshot of first time I evaled the first test form.

there is a video in the readme, did you both miss it?

Oh, between the time I decided I’d do it and now, I forgot to go back to check it out!

Well, didn’t miss it, but I’m used to see the results in the output window. I’m using a single screen and it’s a bit of a bother to have both browser and vscode side by side, so I mostly have them covering each other.

Yeah, all is right.

I sometimes get the test results in the output window, actually.

Yeah, I’m more used to have RCF in my backend’s clojure process, not in a frontend’s clojurescript process. 🙂

I will look into tweaking the RCF test reporter to report with something other than console.log. There was a reason we chose this that I dont currently recall

I do not understand editor stdout / nrepl integrations for any editor (not just calva)

My last job’s DevUX involvement did involve taming these things in various contexts. Not always evident.

DM please, @U0514DPR7 😃

Here it wasn’t apparent to me why we repeat inc on L29,31 since it’s already part of the flow mapping above on L13. (Subtle highlights)

I was able to follow it just reading through! I think of m/observe as "useeffect minus the rules of hooks", and it's shocking how much that opens up. it's scalable metaprogramming, all the power of lisp without the ball of mud!

should I say that? I kinda avoid talking about useEffect because my react experience is very dated and I dont want to say wrong things

not sure, but in my experience you kind of just accept the constraints that react puts on your without too much thinking about the opportunity costs, and that's not obvious until you really dig into electric a bit. the composition across network thing is only a small part of what makes the paradigm interesting but I think most of your marketing has been around that. it's an easy exciting demo but really undersells the potential

so maybe "what if you could use hooks without the rules of hooks" is an accessible/intriguing enough pitch that can't misleadingly undersell what electric is about

at least for the lisp crowd "what if you didn't have to be scared of macros/dynamic scope" is pretty intriguing I feel. a lot of wasted potential around not using macros because "only pure functions compose" -- well now we have ergonomic managed effects in a language with real metaprogramming

Continuing where I left off yesterday… Nice, very inspiring language, and it does raise my hopes a lot.

Here, it did feel weird that you kept relying on broken-watch till the end. I understand how you relieved it in the next line, “unbreaking” it, though. So it’s just a very minor quibble. The broken-watch name was, I thought, hinting me that you’d later provide a fixed impl. But instead, you decided to fix its uses. And there’s value in seeing that we can indeed rearrange the dynamics of producers.

Yes really appreciated the presentation. Very enlightening.

It’s always funny to see Dustin react like this. Missionary isn’t the regular “fabric”, it’s full of surprises. 😄