@stevekrouse Is the Comprehensible FRP talk online somewhere?

Unfortunately it wasn't recorded live so all I have is the last practice talk I did https://www.loom.com/share/b636f469dcea42ce946b25dd5c0a75d3

Thanks. I have some questions about this stuff but I wanted to see the talk first. Btw, somewhere on your site gave me the impression the talk video was up. Idr which page but yeah

Apologies on the delay here! These are wonderful questions. I appreciate you taking the time to dig into my work. I hope to find time in the next couple days to reply 😬

no worries, just didn't know if notifications happen in threads. didn't want it to get lost

@Deklan Webster 1)

Thus we can expect Elm applications to grow entangled and stay that way

elm docs do recommend splitting up into modules when you have a type with a lot of helpers. Each module has its own update/view/model, I think. Although, I think Redux people, e.g., do keep a global store, so... idk Steve: I'm not sure where the question is.

In Reflex, you’d accomplish this by first describing a list of buttons of Dynamic length. This would emit a Dynamic list of Events, a higher-order stream. If you flattened the higher-order stream, counted all click Event occurrences, and added 1 for the original button, you’d get the desired length of the Dynamic list of buttons. Reflex would let you cyclically feed this Dynamic value back as the length of the list of buttons.

Does cyclical-ness always go with higher-orderness? Why? In other words, are there FRP libraries that use one but not the other? Steve: Higher-order streams are common, such as in Rx or xstream, both without cycles. Cyclic streams are quite rare, usually just in Conal-style original FRP. 3) This paragraph stuck out to me as needing more explanation (at least for me),

While Reflex enables understanding states via a single place in the code, Elm enables understanding messages via a single place in the code. If one wanted to understand the impact of a Reflex stream on downstream states, one would have to play the reverse of the Ctl-F game that we played in Elm. While this duality might seem equivalent, Reflex’s style is more comprehensible because understanding the behaviors of states is much more important than understanding the effects of messages.

Is the first part saying like, "Seeing all the effects of a 'command' is difficult with Reflex. But, tracking an individual piece of state is easy." Maybe like, a 'verb' vs 'noun' orientation? And, anyway, it's not obvious to me why one would be better than the other. Except for maybe.. see next point Steve: One analogy I make is the distinction between a dictionary or encyclopedia on one hand and an essay or piece of prose on the other. The Reflex approach is definitional like a dictionary or encyclopedia: each term is self-contained in a recursive way. The Elm approach is like imperative programming: you have to read through the entire text in order to piece the story together, even if you’re only curious about one or two characters. 4) Is it possible to autogenerate these cycle diagram thingies with this approach? Is that part of your goal? Let the editor make these diagrams for you? Steve: yes, one of the benefits of this definitional approach is that it better lens itself to comprehensibility through tools. As you noted those diagrams aren’t particularly helpful, but they point towards this sorts of visualizations that could be created. 5) Looking at the diagrams it occurred to me "Man, this is complicated". But, maybe, rightfully so: TodoMVC, despite appearances, IS that complicated. God help us with something more complicated. Steve: yes! This is essential to the point I’m trying to make. Software is really complicated but we mostly shove the complexity under the rug where it comes back to bite us twice as hard. I’m advocating that we be honest about the complexity we face, which might seem more difficult in the short run but pays dividends in the long run. 6) Are you still interested in all this, in particular Turbine? Yes and no. I really love the Turbine project, but it’s a bit too young to build tooling for because it’s API is changing so quickly. A couple of months ago I decided to put my FRP visualization projects on hold because they felt a bit too low level of a problem to work on.

Sorry if I bugged you too much about those questions! I appreciate that you answer long questions from random people online. Thank you. My point with 1) was just that if you minimize your 'global' store, and keep many smaller contained, local stores the problems you outline can be mitigated. I was asking if you agree. (This pattern is now being encouraged in React also: Context plus many useReducers) The dictionary vs essay metaphor is interesting. Thanks. Re: visualizations. I recently saw that other talk you gave on this with the different visualizations of the temperature converter. This makes more sense now. You see possibilities for many types of visualizations here. I've opened a few issues on Turbine about the documentation, or fixing up some of the examples. I saw you opened some issues complaining about the docs, and I hope to carry on in that tradition. Turbine is definitely intrinsically interesting enough to me, but it would be cool also to see it develop further. Although you dropped the FRP-viz work, are you still an FRP-believer, as it were? Is there other stuff here besides Turbine that one should keep their eye on? You've brought this OG FRP stuff to my attention, but now I'm disappointed I don't see more of it around!

My point with 1) was just that if you minimize your 'global' store, and keep many smaller contained, local stores the problems you outline can be mitigated. I was asking if you agree. (This pattern is now being encouraged in React also: Context plus many useReducers)

Possibly, but I don't think so. My gut says that we should only lump together that data which must be lumped together because pieces are dependent on each other. Any time we put data in the same store for convenience, we create a grouping where one doesn't need to exist. But my intuition on this is developing. I read a really great post recently that pushed forward my understanding on what I'm trying to get at here: https://blog.statebox.org/modularity-vs-compositionality-a-history-of-misunderstandings-be0150033568. I'm also going through the category theory for programmers course with #CKC6FM9DF which is really helping me get clearer on what I mean by compositionality. One key point: the IO Monad, while technically composible, isn't meaningfully composible because it doesn't have simple or precise semantics. Other monads are better at this, but if you use a monad to create global state, you're back to imperitive programming...

are you still an FRP-believer, as it were?

Glad you're pushing the Turbine guys still! Yes I'm a huge believer in FRP. At this point it seems so obviously right to me, but it still needs to be extended. I spent a little while in the past weeks brainstorming what an distributed, mixed-ownership FRP operating system for all our devices could look like. (You can find scattered notes on futureofcoding.org/log but I wouldn't recommend it.)

Is there other stuff here besides Turbine that one should keep their eye on?

I'm still trying to make sense of Conal's work. So you can always spend more time there. And #CKC6FM9DF if you haven't already. Seems almost like required reading for people looking to push the OG FRP paradigm

That blog post was interesting. I think I get it but it's still a little fuzzy. I'm def considering joining cat theory group. I watched some of those videos awhile back and found it helpful. I actually started learning category theory again from a more formal place. I think I'll recommend that resource over on the cat theory channel now. Unfortunately, the Turbine repo seems stalled. I wonder if they intend to keep up with it. Will check out the distributed FRP notes. Wrt IO monad, I've read Conal say that but I didn't really understand what an alternative could be. Now I've started learning about free monads and those seem like a possible answer. There's a new Haskell library called polysemy which (ostensibly) finally makes free monads workable in Haskell (boilerplate wise and performance wise). Does Conal address free monads?

Conal sketches the alternative here http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm

as far as I can tell free monads seem to fit what he's saying there

I don't see how free monads would solve the IO monad issue. It's not about coming up with a Haskell type to tape over writing/reading to filesystem/sockets, but to come up with a higher level of abstraction that doesn't read/write at all. The analogy is: any Haskell-to-JS library that allows me to mutate the DOM isn't what I'm looking for. I want something like FRP which allows me not to talk about DOM mutations at all.

Ah, I think I see. With ReactJS you can build a website without ever manipulating the DOM directly. You want to be able to, e.g., build a chat application without ever messing with a WebSocket (directly?). Or, persist a file without getting a handle or DB pool.