DEV Community

Discussion on: What the hell is Reactive Programming anyway?

Collapse
 
taikedz profile image
Tai Kedzierski • Edited

I've never had to delve into "reactive programming" or any such higher paradigms to describe a style or principle.... but the title caught my eye as to how I could understand this. I feel none-the-wiser alas, but here's what I'm getting out of it...

If I borrow clumisly a notation from logic/mathematics, I am seeing your statement as

f(b,c) => a
Enter fullscreen mode Exit fullscreen mode

That is, whatever b and c, their processing engenders a. We could even claim them to be states. And then, the question is, what to do with a, how to respond, or react to it, when either component changes the value, or state a. Which dovetails neatly into the assertion, "(Real-time) programs are usually reactive", since we depend on knowing what happened to a to further proceed...

But then, I recently discovered the existence of "real time operating systems" and am confused as to the nature of those as opposed to more "usual" operating systems. What is meant by "real-time"?

I feel to a certain extent there is a problem of terminology - in the desire to re-use words for the benefit of succinctness (or marketability), the fast breakdown of analogy seems to just muddy the ability to understand what was actually meant.

So... what is reactive programming? I am still confused.

Collapse
 
ryansolid profile image
Ryan Carniato

Sorry I was trying to end on an ambiguous note because even if I am fairly content where I landed it feels not like it is a worthwhile distinction. This started in the article I mentioned in the introduction where it has become common to call the JS Framework React not reactive. And from every encompassing definition, I could find it was in fact reactive.

I was looking for some sort of commonality for why these things are called reactive programming. And while there is a lot of reactivity around especially in UX design, monitoring real-time systems, etc..., I wanted to focus on the programming paradigm. Unfortunately, it ended up being that the commonality still boiled down to something very generic. So much that even the first paper that coined the term wasn't any clearer.

I realize throwing that at the end only serves to muddle everything. I'm content enough with my definitions up to that point. It was just that it is likely some other definition exists that loosely fits. That paper considered reactive programming to be about a program that ran at the pace of the outside inputs rather than its internal environment. By that definition pretty much any browser UI programming driven off DOM events fits this.

I still like my definitions and differentiate reactive programming the paradigm, from reactive programs, or systems. But arguably a pretty arbitrary position to be taking.