An introduction to Reactive Programming • Hacker News Board

Re: An introduction to Reactive Programming

#11

Post by mpweiher » Thu, Feb 01, 2018, 10:24 PM UTC

seanmcdirmid wrote: post #9

doublerebel wrote: post #3

This is an interesting article, but I don't think it gives enough credit to Functional Programming. The article presents functional programming applied to push streams, which is part of FRP but only one way to look at Reactive Programming. Thinking in streams is a great exercise but is not a panacea. It's really easy to get started with streams in a toy example, but in real world applications backpressure and bufferi…

Most of those aren't FRP, at least in the Elliott/Hudak sense. Or if you mean anything that pushes streams around is FRP, then of course that existed long before FRP was even a word and happens in non-functional paradigms as well.

Voice of reason. Thank you!

Synchronous dataflow, Lucid, Esterel, Supercollider :-)

FP does not solve a problem for reactive programming, reactive programming solves a problem for FP.

Re: An introduction to Reactive Programming

#12

Post by quadcore » Thu, Feb 01, 2018, 10:24 PM UTC

While this may be technically sound, I think this is not the most fundamental way of explaining FRP. FRP is just a toy really. It's a useful toy that help to grasp and use an advanced programming concept. Let me explain.

That concept originates from a common programming mistake. A common mistake is to use compulsive caching. It's the tendency to store function results in a variable just because this result is gonna be re-used. The right way instead is to evaluate (or "re-evaluate") the function every time you need it unless you have a good reason not to (the only good reason is that the function is a bottleneck that affects the experience of the user). This is a better way of doing things because as everybody knows, invalidating caches is a hard thing to do (and variables, guess what, are just caches).

The added benefit (which really is not a benefit, but just good programming) is that things gonna now seem reactive.

Re: An introduction to Reactive Programming

#13

Post by mpweiher » Thu, Feb 01, 2018, 10:26 PM UTC

platz wrote: post #5

previous discussion https://news.ycombinator.com/item?id=7964873 There was a lot of talk on what FRP (Functional Reactive Programming) really meant, and if Rx is really FRP. My understanding these days is that Rx has distanced itself from the FRP term proper, while retaining the goals of programming with reactive streams.

Well, Conal has also distanced his work from the FRP term.

Re: An introduction to Reactive Programming

#14

Post by platz » Thu, Feb 01, 2018, 10:29 PM UTC

quadcore wrote: post #12

While this may be technically sound, I think this is not the most fundamental way of explaining FRP. FRP is just a toy really. It's a useful toy that help to grasp and use an advanced programming concept. Let me explain. That concept originates from a common programming mistake. A common mistake is to use compulsive caching . It's the tendency to store function results in a variable just because this result is gonna…

Your world does not address the difficulties of dealing with shared state and coordination, which is what FRP addresses in a principled way. FRP means you don't have data races on checking global variables and events littered all throughout the program, firing and mutating in an order that must be considered effectively random.

Re: An introduction to Reactive Programming

#15

Post by platz » Thu, Feb 01, 2018, 10:31 PM UTC

mpweiher wrote: post #13

platz wrote: post #5

previous discussion https://news.ycombinator.com/item?id=7964873 There was a lot of talk on what FRP (Functional Reactive Programming) really meant, and if Rx is really FRP. My understanding these days is that Rx has distanced itself from the FRP term proper, while retaining the goals of programming with reactive streams.

Well, Conal has also distanced his work from the FRP term.

My point still stands.

Re: An introduction to Reactive Programming

#16

Post by quadcore » Thu, Feb 01, 2018, 10:34 PM UTC

platz wrote: post #14

quadcore wrote: post #12

While this may be technically sound, I think this is not the most fundamental way of explaining FRP. FRP is just a toy really. It's a useful toy that help to grasp and use an advanced programming concept. Let me explain. That concept originates from a common programming mistake. A common mistake is to use compulsive caching . It's the tendency to store function results in a variable just because this result is gonna…

Your world does not address the difficulties of dealing with shared state and coordination, which is what FRP addresses in a principled way. FRP means you don't have data races on checking global variables and events littered all throughout the program, firing and mutating in an order that must be considered effectively random.

Function composition do most of that. Now, I said it was a fundamental explanation, not necessarily the whole story.

Re: An introduction to Reactive Programming

#17

Post by com2kid » Thu, Feb 01, 2018, 10:42 PM UTC

danharaj wrote: post #6

My shop specializes in multiplatform FRP applications via the reflex haskell library [0]. After many years of wrangling FRP my biggest learned lesson is certainly this: not everything is a stream! You need to be able to mix streams (also called events), which embody push semantics and behaviors (things you can sample), which embody pull semantics. This is important for performance and for the structure of large appli…

One of the teams I was on solved the pull behavior by having an "immediately publish last known value on subscription" parameter we could pass in when subscribing.

This solved most of our needs around pulling data.

We weren't doing a full FRP system, no composable streams, just building a system in which the only way to communicate was through subscriptions between components.

This worked really well in practice, for example to configure the rate at which the accelerator ran, a component would subscribe to the proper hz publisher, with different publishers existing for supported frequencies. A fancy bit of code handled doing the math needed to deliver all the different subscribers data at their requested rate.

Re: An introduction to Reactive Programming

#18

Post by platz » Thu, Feb 01, 2018, 10:46 PM UTC

quadcore wrote: post #16

platz wrote: post #14

Earlier quoted context omitted.

Your world does not address the difficulties of dealing with shared state and coordination, which is what FRP addresses in a principled way. FRP means you don't have data races on checking global variables and events littered all throughout the program, firing and mutating in an order that must be considered effectively random.

Function composition do most of that. Now, I said it was a fundamental explanation, not necessarily the whole story.

That is quite hand-wavy, and I don't think adequately addresses the issues.

Re: An introduction to Reactive Programming

#19

Post by [deleted] » Thu, Feb 01, 2018, 11:00 PM UTC

platz wrote: post #18

quadcore wrote: post #16

Earlier quoted context omitted.

Function composition do most of that. Now, I said it was a fundamental explanation, not necessarily the whole story.

That is quite hand-wavy, and I don't think adequately addresses the issues.

[deleted]

Re: An introduction to Reactive Programming

#20

Post by RobertRoberts » Thu, Feb 01, 2018, 11:41 PM UTC

Pardon my blunt question, but who is the heck is this for? Is this a sideways method of pushing React.js? Or is this for assembly programmers as well, and I just don't get it?