Sure. So I've spent a lot of time working with FRP things, e.g. with https://hackage.haskell.org/package/reflex with the github.com/obsidiansystems/obelisk/ web framework. While FRP was sort of deemed to hard / a dead end in the early 2020s, it works well for me, and I still consider it viable.
I dislike effects because superficially they are about similar problems ("My whole-program needs side effects") but no amount of effects system stuff is going to ever get you to anything like FRP. In particular, the eeffects mind seems to be pretty narrow, something like:
"I have a bunch of regular-seeming code that does some 'extra stuff', and I need to manage those extra capabilities in a modular way that respects the principle of least authority."
By contrast, the FRP approach rejects the premise that:
- The programs basically look more or less "normal", but with (good) restrictions on what you can do
- The effects are something "side" or "extra".
It's hard to say exactly what it is about instead, but some guidelines might be:
- Don't just decompose a program into terminating parts (like terminating callbacks + magic event look). Embrase non-termination (well, co-termination), and think of new ways to be modular that don't carry over from terminating whole programs.
- Think in terms of "flows", be like a plumber. Try to directory program the steady state in terms of the large scale architecture, and not a regular functional--imperative program that "carries out" out the flows as a spec.
- - Actor-model-type stuff is wrong for focusing on the "nodes not edges". We should have simple components but rich networks.
- Try to find structure not in the effects themselves, but how you intended to use them. If the effects form sinks/sources, then have them be pipeline end pieces that compose just like the the pure middle pieces.
- Calculus is good for programming, after all. Time derivatives / time integrals are at very least good metaphors. We should all go learn more Control Theory for more things than "memory pressure".
Reflex in fact has a bunch of MTL-style classes, and while I recognize the ways which that workflow isn't ideal, it simply has not been a large problem for me in practice. Effect systems are not useless, just low priority to me -- they become more important if one turns all their problems into questions of side effects -- but per the above I don't think that is a fruitful way to reduce all ones problems to one.
I see what you mean, but "embracing" effects also means, in a way, shifting the frame of reference so they are pure (from the new frame). That's a really hard requirement, and so in some sense it's more constrained. Certainly the difficulty relates to why FRP has been abandoned in so many places.
