So where I'm coming from really, though I didn't emphasize this in the stackexchange post, is more like in terms of organizing the code- not so much the benefits of avoiding errors (though that's icing on the cake!)
From the small little ball bounce demo, it really seems like making functions the thing that changes leads to just nice code. It feels elegant to me that we can look up some formula for motion and make that the thing we're changing, rather than messing around with accumulating and compensating for errors.
The answers there were pretty surprising and kinda awesome for me to see - esp. that it turns out this is the ideal and used in top-tier space simulations where possible(!) The fact that this is imho the more organic way of thinking in FRP is fascinating to me...
Maybe, simply by hooking the objects up declaratively, a lot of the scariness of inter-dependencies goes away and we can use this approach more often... I mean I can't see that far ahead yet, but on a gut feeling level it just seems like "check for all collisions against all objects and update their functions" is indeed scary... but when the objects are actually defined in terms of eachother, it's not so bad... maybe... if that makes sense.
That line of thinking might be a total dead-end... so far I've just got one bouncing ball to show for it, and that was mostly derived from @the-real-blackh and @huanhulan's examples... I think this does deserve more experimentation!
I might finally get around to pong!
