An introduction to Reactive Programming
gist.github.com
An introduction to Reactive Programming
1–10 of 78 posts
Re: An introduction to Reactive Programming
#2> If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article
Thanks for actually writing. Written information can be parsed non-linearly, which is super important for learning and reference. For whatever reason, a lot of people don't seem to understand that, and just put out videos, which are like lectures: helpful, but frustrating.
Re: An introduction to Reactive Programming
#3This 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 buffering are a concern. The consideration of backpressure also opens the push/pull stream discussion. If you are interested in applying more from this article, the API is very similar in Godot2 (Node) [0], which is based on Riemann (Ruby) [1]. (Node streams have configurable backpressure/buffering [2].)
Complex interconnected events can cause a runaway snowball effect if not carefully constructed or bound by limits:
* Elm's "time-travel" debugger is so valuable because it allows introspection through an event chain that may not be linear.
* Node takes a common approach, which is to push data/events through the stream but handle errors by bubbling up the stream processing chain. This Node approach maintains a hierarchy that is relatively easy to reason about.
* React is popular because it effectively is FRP applied to the data model: the JSX view is the function, and the change in data model is the event. Since data model changes are limited, atomic, and one-way this makes React easier to reason about than other frameworks (Angular, I'm looking at you). This concept pre-dates React, I've used it since years ago with SpineJS and Knockout.
Last but not least, when using streams there is an important tradeoff between speed/latency and delivery/processing guarantees, which is enough for its own discussion...
[0]: https://github.com/nextorigin/godot2
[1]: http://riemann.io/concepts.html
[2]: https://nodejs.org/en/docs/guides/backpressuring-in-streams/
Re: An introduction to Reactive Programming
#4> If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article Thanks for actually writing. Written information can be parsed non-linearly, which is super important for learning and reference. For whatever reason, a lot of people don't seem to understand that, and just put out videos, which are like lectures: helpful, but frustrating.
Lectures, for me, are a great touchpoint, and, in the context of academia, a great way to set (and maintain) a rhythm. But they (almost always) require me to actively take notes (something I can't always do) to really take anything of value away from them.
(All of that is to say, I agree with you.)
Re: An introduction to Reactive Programming
#5previous 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.
Re: An introduction to Reactive Programming
#6My 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 applications.
Coming up with a set of primitives to efficiently combine events and behaviors in expressive ways is really difficult but worth it.
Re: An introduction to Reactive Programming
#7> "this new thing called Reactive Programming"
Let's take an age-old paradigm and present it as something new... why, I don't know, maybe so we can come across as an expert on something "new" and high-tech for fame and fortune...
...at least until someone who has been around the block comes along and figures out you're at best a bullshit artist and at worst completely ignorant and unqualified to be presenting...
Re: An introduction to Reactive Programming
#8This 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…
when talking about 'backpressure' it is essential to distinguish whether we are talking about pull streams or push streams, and if the backpressure mechanism is in-band or out-of-band.
usually when we talk about a 'reactive stream' we are only talking about push streams, because if you are truly reactionary the consumer doesn't control the flow like a pull-based iterator does.
Re: An introduction to Reactive Programming
#9This 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.
Re: An introduction to Reactive Programming
#10This 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.
I agree. I intended to make it clear with my first sentence that Streams as described in the article is just a subset of Reactive Programming.
My point is that Functional, Reactive, and Streams programming have common concepts that are important programming tools, when used appropriately. However, Reactive Programming is neither exclusively Functional nor Streams-based, although the article implies it.