Live data from Hacker News

An introduction to Reactive Programming

gist.github.com

41–50 of 78 posts

Re: An introduction to Reactive Programming

#41

I'm going to go out on a limb here with a prediction. Reactive Programming will not catch on in any big way. Maybe in 10 years I'll look foolish for having said this, but I'm willing to take the chance.

It's turned out to become a standard for mobile developers due to the concurrent and async nature of the platform. As a side note, I've been working through ~10 different code bases during the last 4 years - every single one has included an Rx library. Scala, Java, Swift, Kotlin, C++.

My bet it's here to stay.

Re: An introduction to Reactive Programming

#43
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…

> 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. 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 w…

Could you unpack this a bit for the relative layperson? I once heard a guy at a Haskell meetup say that “codata is the categorical dual of data” but I didn’t know what that means then and I still don’t know.

Re: An introduction to Reactive Programming

#46
post #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...

Ok where did you write reactive back in the day?

I don't think it was called reactive back in the day, but the ideas are old to some degree. If you drop the functional aspects, then "Reactive" programming goes back to Lotus 123 (for the those too young, think Excel).

Data base triggers is also "Reactive", and materialized views are also "reactive".

Are there some novel aspects to "FRP", sure.

Re: An introduction to Reactive Programming

#47

Earlier quoted context omitted.

> 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. 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 w…

Could you unpack this a bit for the relative layperson? I once heard a guy at a Haskell meetup say that “codata is the categorical dual of data” but I didn’t know what that means then and I still don’t know.

Data is finite data structures, while Codata is infinite data structures (like streams.) They are duals because you can generate and process data using induction, while you can use coinduction to generate and process codata. One is "built up" naturally, and the other is "torn down" naturally.

Re: An introduction to Reactive Programming

#48

Earlier quoted context omitted.

Ok where did you write reactive back in the day?

I don't think it was called reactive back in the day, but the ideas are old to some degree. If you drop the functional aspects, then "Reactive" programming goes back to Lotus 123 (for the those too young, think Excel). Data base triggers is also "Reactive", and materialized views are also "reactive". Are there some novel aspects to "FRP", sure.

And OS interrupts are also reactive?

Re: An introduction to Reactive Programming

#49
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…

> 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. 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 w…

I believe that the distinguishing property is not what the event/data/codata is, rather how you are accessing it and when you process it.

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 stream = whatever();
    var iter = new StreamIterator(stream);
    while (await iter.moveNext()) {
      // process the iter.current value at whatever pace you'd like
    }

Re: An introduction to Reactive Programming

#50
post #40

Earlier quoted context omitted.

> 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_). Unless the OP is arguing for call-by-name evaluation, which when you take his words literally,…

Call-by-name is just syntactic sugar for anonymous functions. It has all the same problems. 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.

> Call-by-name is just syntactic sugar for anonymous functions.

No, it's not. It defines different evaluation semantics.

Post reply on HN