2020/02/15 2:10:34 AM UTC

Watching the video about FRP and Elm considering that I'm thinking about some reactive GUI design stuff

But... he's making a bunch of claims about benefits you get that I'm not sure come from those places:
- He shows off changing a function and having a live change to the system and this being a benefit of the static graph... but I've had that kind of stuff in Guile which definitely doesn't have a static graph
- Similarly, time travel debugger, I've got that in Goblins

2020/02/15 2:11:20 AM UTC

I think reactive, declarative programming makes sense for certain portions of your programs, but sometimes I get thrown by claims about "this is where X kind of property flows out of your system" when... is it?

2020/02/15 2:42:10 AM UTC

@cwebber You get those things because you've been careful about where you allow side effects though, no? It seems like you're probably doing an ad hoc sort of FRP already.

2020/02/15 2:47:12 AM UTC

@freakazoid Goblins is really more actor model than FRP, though I think the two can be composed. It's the use of "become" for state changes that allows time traveling in Goblins.

2020/02/15 3:09:37 AM UTC

@cwebber @freakazoid What's the difference between this concept of "subscriptions" in contrast to FRP?

Reading that announcement I'm not seeing what's changed.

2020/02/15 3:14:44 AM UTC

@alcinnz @cwebber @freakazoid subscriptions are usually just the notifier chain.

FRP tends to include a more functional flair where you can put filters/maps on event streams themselves and chain some common pre-defined behaviors together to get the events you want.

2020/02/15 3:15:57 AM UTC

@icedquinn @cwebber @freakazoid That's what I thought FRP was, and in which case Elm never really struck me as using it.

2020/02/15 3:16:39 AM UTC

@alcinnz @cwebber @freakazoid didn't elm walk away from all that in more recent versions?

2020/02/15 5:44:22 AM UTC

@alcinnz @cwebber It seems like the main difference between Czaplicki's "concurrent FRP" and the actor model is that with concurrent FRP you're still writing pure functions, whereas with the actor model you are explicitly sending and receiving messages, which are side effects.

I believe that in FRP "signals" generally always have a value, and changes in the value are like messages in the actor model. I believe you also need to implement all state as signals.

2020/02/15 5:48:36 AM UTC

@alcinnz @cwebber Now that I'm thinking about this, it reminds me a lot of "views" in CouchDB, since they're a memoized transformation applied to the database.

Ther's also the Observer pattern, which is very useful for creating GUIs. Observers subscribe to values and get notified when they change. This sounds a lot like Elm's subscriptions. So perhaps it's really just a mapping from FRP to something more actor-like.

2020/02/15 5:59:08 AM UTC

@alcinnz @cwebber It seems like a major issue with (non-concurrent) FRP is that unlike the actor model it's deterministic, which is significant overkill most of the time. I suspect this is why its proponents don't realize that it's not that much of an advantage. With FRP you only need to record the inputs, but the total volume of messages in an equivalent actor system should only be larger by a small multiple. Which anyone who's watched a Starcraft replay can tell you.