5 ms·

Can someone explain the synergy of using reactive with functional? Reactive is great and functional is great but I don't see what they have to do with each oth

by mchahn 8y ago

Can someone explain the synergy of using reactive with functional? Reactive is great and functional is great but I don't see what they have to do with each other.

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 ago
  Is 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 ago
    I met an Elm dev once, who even after two years, had not used it or even knew how.
  - pcstl 8y ago
    It's been sort of left behind as Elm has de-emphasized FRP. I used it a lot, though.
  - fpoling 8y ago
    From 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 ago
    No 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 ago
    Well, 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.
mpweiher 8y ago
You are correct, there isn't really any synergy, and it's just a re-framing of synchronous dataflow programming using somewhat convoluted terminology and technology. In fact, what "reactive programming" does is solve the problem that FP has with reactive systems[1], in that it isn't suited for them at all. FP, pretty much by definition, is suitable for transformational systems, i.e. systems that map some inputs to some outputs and are then done. With just FP, there really isn't any way to build reactive systems, that is systems that continuously react to external and internal stimuli, whereas reacting (responding) to stimuli (messages) is pretty much the definition of OO. By treating input as (infinite) streams of data and applying collection processing to those, you can sort of map this to the aforementioned dataflow programming and solve your problem. Of course, just using dataflow programming directly is both simpler and faster, but hey... [1] https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...
- fpoling 8y ago
  Elm is pure function and reactive but it is not FRP especially with its latest Elm architecture. The language does not use anything like Haskell's IO or State monad, yet is perfectly capable of building complex applications. It shows that one can have pure functional language for reactive systems with relatively simple type system. One just needs to provide thoughtful architecture and libraries.
- mchahn 8y ago
  > just using dataflow programming directly is both simpler and faster, But a good reactive system is simpler to write, understand, and debug. At least that is what I found in my latest project.
  - mpweiher 8y ago
    What dataflow system/language did you use to compare?
    - mchahn 8y ago
dakom 8y ago
The fundamental building block of FRP is something called a Behavior, which is a container for a value that changes over time. More specifically, it's not just any container - but rather one which follows laws that make it a candidate for passing into pure functions that expect certain typeclasses (specifically it's a Functor, Applicative, and some others) The result is that you can do the same things with a Behavior as you can with other Functors and Applicatives and things - for example you can `map` it with a function that operates on that inner value (whatever it may be) and you'll get a new Behavior which contains that transformed inner value.

by mchahn 8y ago

Can someone explain the synergy of using reactive with functional? Reactive is great and functional is great but I don't see what they have to do with each other.

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 ago
Is 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 ago
  I met an Elm dev once, who even after two years, had not used it or even knew how.
- pcstl 8y ago
  It's been sort of left behind as Elm has de-emphasized FRP. I used it a lot, though.
- fpoling 8y ago
  From 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 ago
  No 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 ago
  Well, 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.

mpweiher 8y ago

You are correct, there isn't really any synergy, and it's just a re-framing of synchronous dataflow programming using somewhat convoluted terminology and technology. In fact, what "reactive programming" does is solve the problem that FP has with reactive systems[1], in that it isn't suited for them at all. FP, pretty much by definition, is suitable for transformational systems, i.e. systems that map some inputs to some outputs and are then done. With just FP, there really isn't any way to build reactive systems, that is systems that continuously react to external and internal stimuli, whereas reacting (responding) to stimuli (messages) is pretty much the definition of OO. By treating input as (infinite) streams of data and applying collection processing to those, you can sort of map this to the aforementioned dataflow programming and solve your problem. Of course, just using dataflow programming directly is both simpler and faster, but hey... [1] https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res...

fpoling 8y ago
Elm is pure function and reactive but it is not FRP especially with its latest Elm architecture. The language does not use anything like Haskell's IO or State monad, yet is perfectly capable of building complex applications. It shows that one can have pure functional language for reactive systems with relatively simple type system. One just needs to provide thoughtful architecture and libraries.
mchahn 8y ago
> just using dataflow programming directly is both simpler and faster, But a good reactive system is simpler to write, understand, and debug. At least that is what I found in my latest project.
- mpweiher 8y ago
  What dataflow system/language did you use to compare?
  - mchahn 8y ago

dakom 8y ago

The fundamental building block of FRP is something called a Behavior, which is a container for a value that changes over time. More specifically, it's not just any container - but rather one which follows laws that make it a candidate for passing into pure functions that expect certain typeclasses (specifically it's a Functor, Applicative, and some others) The result is that you can do the same things with a Behavior as you can with other Functors and Applicatives and things - for example you can `map` it with a function that operates on that inner value (whatever it may be) and you'll get a new Behavior which contains that transformed inner value.