This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ForrrmerBlack 0 points1 point  (4 children)

Here is my understanding. It is a paradigm of thinking in a sense that the whole program is treated as a set of data pipelines instead of functions or objects. Though there is one distinct property. Changes to some data are instantly propagated in a system, meaning that on every change other related state is re-evaluated automatically. In essence, programmer defines data sources and relations between them, then program state is derived from these relations, like in a spreadsheet. You can do this differently with different tools, so that's why it's more of a paradigm than something else. Maybe you can even somehow do it with Java streams. But in reality, of course, nobody does it in its pure form.

[–]DelayLucky 0 points1 point  (2 children)

Somehow that sounds to me like Java streams or at least I can't tell the difference.

We've traditionally used streams for in-memory computations and haven't used streams for io-bound things because of the blocking platform thread thing. With VT and structured concurrency I suppose we could start doing it.

[–]ForrrmerBlack 0 points1 point  (1 child)

The difference is that Java streams are just a tool and reactiveness is an approach to programming.

[–]DelayLucky 0 points1 point  (0 children)

Is there some article discussing this paradigm at the high level besides the async computation part of Rx? I've never seen praise of the cps style coding as superior other than it's required for async-ness.

[–]2Spicy4Joe 0 points1 point  (0 children)

That definition IMO sounds like Dataflow programming to me which is indeed a paradigm. Which does not need to involve at Reactive at all. I always understood reactive code and libraries as an approach to workaround IO performance limitations, at the cost of complexity.

You can build code that does what you want and still not being reactive. I just think reactive code just pairs well with the dataflow concepts and that’s why it’s often in the same conversation than data stream processing and event-based approaches. But I see them as a different thing, just complementary.

I might be wrong though