5 ms·
It's easier to reason about highly asynchronous code if all you can do is transform and compose streams, and all side-effecting work happens at the "ends of the
by pcstl 8y ago
It's easier to reason about highly asynchronous code if all you can do is transform and compose streams, and all side-effecting work happens at the "ends of the pipe", so to say.
Arbitrary side-effects coupled with asynchronicity are a recipe for Heisenbugs.
Additionally, if you add in the constraint that you can't change signal routing at runtime and you only use pure functions on stream, you can actually debug by moving streams to any point in their history and figuring out what the system is doing with them. That's a very common debugging technique in the Elm programming language, for instance, as shown here: https://www.youtube.com/watch?v=RUeLd7T7Xi4 https://www.youtube.com/watch?v=RUeLd7T7Xi4.
- seanmcdirmid 8y agoIs that really common among Elm programmers? As far as I can tell, it was a nice one off demo but it hasn't been advanced as Elm has.
- hellofunk 8y agoI met an Elm dev once, who even after two years, had not used it or even knew how.
- pcstl 8y agoIt's been sort of left behind as Elm has de-emphasized FRP. I used it a lot, though.
- fpoling 8y agoFrom my small experience with following Elm tutorials and implementing simple apps is that such debugging is not necessary. Elm strongly encourages to use a serializable state with no things like long-lived lambdas or closures capturing arbitrary stack frames. In turns it makes reasoning about the code very easy. In my cases just by observing the bug for the first time I could almost immediately find the code triggering the misfeature. This was absolutely not the case with pages with relatively small JS that I dealt occasionally in past.
- mjaniczek 8y agoNo it's not. Elm doesn't have signals anymore since, I think, version 0.17.
- mchahn 8y ago> Arbitrary side-effects coupled with asynchronicity are a recipe for Heisenbugs. I find it easy to avoid side-effects in imperative reactive code. With side-effects I wouldn't call it reactive. > , if you add in the constraint that you can't change signal routing at runtime Once again, this is easy in imperative code. I am not complaining about functional code. It definitely has its place (just not for me). I just finished an awesome product with imperative reactive code and I thought maybe I was missing something.
- pcstl 8y agoWell, sure, you can program imperatively without side-effects, but you can also use side-effects within asynchronous streams. The point of using functional programming with reactive programming is that you have a guarantee that you won't get non-deterministic behavior.