An introduction to Reactive Programming
gist.github.com
gist.github.com
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.
(All of that is to say, I agree with you.)
The problem with doing that, however, is that you are doing something a specific way, on a specific platform, using specific tools. That can make it frustrating or even impossible for viewers/readers to break out of your specific workflow/tools/platform, which is usually what they want to do.
Just a wild guess, but that reason could be that ad monetization works way better on videos than static pages and are more likely to garner subscribers to build a following.
Reasons are dependencies. Excuses are orthogonal.
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.
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.
We were running on an embedded micro with 256KB of RAM, so just making everything async and callback based was already pushing the boundaries of the industry. Vendors we worked with got extremely confused when we said they needed to hand us async code, that they had a few milliseconds to run in before they relinquished control, and that busy loops were verboten.
I really miss working in a code base where every component can be trivially subscribed to.
On the flip side, I've seen subscriptions taken too far, as people make every single value on a form a separate subscription. Seriously, it is A-OK to give the First and Last names together when the user hits submit.
https://github.com/brownplt/flapjax/blob/f92e99ea25a4533c4ab...
I "discovered" FRP in 2011, when I stumbled upon Flapjax — spent a month pouring over the source code, learned a lot, my brain has never been the same since!
I have a creeping suspicion that after a few more years, "push" is just going to be viewed as codata, and "pull" will just be "data". I mean, that's kind of what they are, our languages just don't have codata as first-class citizens, and so we shoehorn it into stream abstractions.
Codata is the inverse, in that you can see it as a finite set of observations of some already built infinite data structure, ie. unpack this value at the head, then unpack that, etc. For instance, the stream of values observed from a process that runs forever.
We usually encode codata using inductive data types, but this is awkward for all of the reasons that come up in FRP and other reactive systems.
In a "push" model you provide a callback that will receive events and it has no way of influencing their frequency or timing. There is no mandatory buffering here.
In the "pull" model, you have a handle, that you can call to receive the next event, which is essentially an iteration over async events. It is up to you to decide the frequency or the timing, and it is up to the backing library to buffer events if needed to be.
I'm linking to the Dart API pages here, but the same concept applies to every language/library out there. Stream.listen [0] is straightforward and similar to many other libs out there. The interesting part is that Dart has a StreamIterator[1], which allows you to "pull" events form the stream at your own pace.
[0] https://api.dartlang.org/stable/1.24.3/dart-async/Stream-cla... [1] https://api.dartlang.org/stable/1.24.3/dart-async/StreamIter...
It is also easy to use Stream Iterator to loop over the values unconditionally:
Stream<Event> stream = whatever();
var iter = new StreamIterator<Event>(stream);
while (await iter.moveNext()) {
// process the iter.current value at whatever pace you'd like
}But this is exactly one of the important distinctions between data and codata. If your language supported first-class codata, you wouldn't need to encode push evaluation via a stream data type. Codata already has the required push-like semantics, and your language's evaluation model would handle the necessary plumbing for you.
I'm not familiar with the term. Could you please elaborate?
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.
You get a result from a call to `foo(bar)`. You have to _do something_ with that result. One common thing you'd need to do is to call another function: _baz(foo(bar))_. But then you're just hiding the assignment inside a baz function call (the result of _foo(bar)_ will be available as a variable/constant inside of _baz_).
That doesn't so bad if you only need to do one thing with with the result of `foo(bar)`. Now what if you have to do something with that result twice. In this case all you've done is reduce the scope of a constant to be smaller than it needs to be, requiring you to make a duplicate `foo(bar)` call.
Now you're repeating yourself and you don't know anymore if you're conceptually dealing with the same result or if foo(bar) might produce a different result on second call. You removed philosophical/semantic meaning from your code and did not gain anything from it.
If you find yourself wanting/needing to "expire" variables that you define before you run out of scope, then the answer is a combination of:
1) use constants of immutable data structures, not variables or mutable structures 2) better name such constants so that you know what they represent 3) better manage scope and function size
In practice, the above is much easier to achieve than what you're proposing, and makes the code easier to read and maintain.
> 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)
That does not scale to using the coding paradigm that you're proposing application-wide. Your whole app will be one big bottleneck because it's doing a multiple of the computations that it needs to be doing, with no easy way out. I guess you can get away with that by throwing more money at your backend infra, but you can't do that on mobile or for web frontends or desktop apps.
Unless the OP is arguing for call-by-name evaluation, which when you take his words literally, sounds like exactly what he's arguing for.
But more importantly, the whole premise is wrong. "Cache invalidation" for data that has an average lifespan of 30 lines of code in a single function is not a hard problem. Real cache invalidation is hard for reasons that don't translate to the case of ephemeral constants with properly limited scope.
No, it's not. It defines different evaluation semantics.
"this will be re-evaluated every time you access it"
The whole point being, FRP, while having some cool features, is mostly fixing bad programming practices.
It is a really cool way of looking at DOM state as a flow of: <interface> -> user interaction -> application reaction -> <interface>
The general idea being that the state of an application can be represented by a timeline of events throughout the lifetime of an application. Since it is entirely time and event driven/stateless, it gives way to some pretty cool "time travel" concepts.
The philosophy is this:
If you know how something begins, and you know the exact times at which anything happens to it, then you can assume its state at any given period in time.
It’s a cool idea. It’s cooler if your organization has the chops to rarely introduce defects. Replaying on refresh works ok ish. The really cool part is making every interaction with the system uniform. State comes in, small tweak, state goes out.
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/
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.
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.
Synchronous dataflow, Lucid, Esterel, Supercollider :-)
FP does not solve a problem for reactive programming, reactive programming solves a problem for FP.
docs.racket-lang.org/frtime
This was how I was introduced to reactive programming 5 or so years ago.
[1]: https://github.com/kriskowal/gtor/blob/master/README.md
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.
Good stuff!
This is for javascript programmers who enjoy functional programming and want an introduction into Rx.js library. It may also be of interest for programmers in other languages (because rx has been implemented in many of them).
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...
Data base triggers is also "Reactive", and materialized views are also "reactive".
Are there some novel aspects to "FRP", sure.
"Reactive programming is programming with asynchronous data streams.
In a way, this isn't anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. [..]"
Is it different?
You sure about that? I certainly recall plenty of holy wars over object oriented programming.
What do you mean by "this"? RAD tools like Visual Basic, Delphi or Cincom Smalltalk were event-based - which is also true with most native GUI frameworks, BTW - but they did not provide any abstraction above the level of events. Reactive programming takes events and stuffs them down a set of pipelines, where previously you had this giant switch statement for dispatch and the logic for actually doing something was split among some of the branches of that switch. Now you can group your logic around a certain pipe, which allows you to see a complete description of complex processes at a glance, without the need to guess "which event is used as a next step of this process?"
So Reactive is actually a quite convenient interface to event-driven systems and it wasn't available in RAD tools of the nineties (if memory serves, might be wrong on this?)
My bet it's here to stay.
A "standard for mobile developers"? Not that I can see.
In just about every event-loop-driven, there exists an implementation of Rx (or something like that anyway)