Watching the video about FRP and Elm considering that I'm thinking about some reactive GUI design stuff https://www.youtube.com/watch?v=Agu6jipKfYw
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
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?
@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.
@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.
@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.
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.
@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.