Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An introduction to Reactive Programming

gist.github.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: An introduction to Reactive Programming

#61

Post by ivanhoe »

thomastjeffery wrote: post #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.

Both can be useful - especially if video is with live coding. Texts often omit the small details that are perhaps obvious to the author, but you are not aware of them. IMHO every installation instruction out there that takes more than copy&pasting 2 lines of text should be in a form of a video, because there's always that one step that is not in the text...

Re: An introduction to Reactive Programming

#62

Post by fnayr »

thomastjeffery wrote: post #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.

> For whatever reason

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.

Re: An introduction to Reactive Programming

#63

Post by klibertp »

seriousluoldmof wrote: post #32
rhapsodic wrote: post #25

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.

Back when I was a kid, we called this rapid application development - but then again, we didn't create cults around dev methodologies...

> Back when I was a kid, we called this rapid application development

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?)

Re: An introduction to Reactive Programming

#64

Post by naasking »

isoos wrote: post #49
naasking wrote: post #35

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…

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…

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

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.

Re: An introduction to Reactive Programming

#65

Post by naasking »

zachrose wrote: post #43
naasking wrote: post #35

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.

To elaborate a little on the other poster, the data types you're used to are finite values built incrementally, ie. build this, then build this, then build that.

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.

Re: An introduction to Reactive Programming

#66

Post by naasking »

omginternets wrote: post #60
naasking wrote: post #35

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…

>codata I'm not familiar with the term. Could you please elaborate?

See other replies to my comment for more details.

Re: An introduction to Reactive Programming

#67

Post by rhapsodic »

parmesan wrote: post #41
rhapsodic wrote: post #25

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.

>It's turned out to become a standard for mobile developers due to the concurrent and async nature of the platform.

A "standard for mobile developers"? Not that I can see.

Re: An introduction to Reactive Programming

#68

Post by jcelerier »

adamnemecek wrote: post #34
fnord77 wrote: 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?

In languages such as Esterel, Lustre, and Signal, in the late 80s

Re: An introduction to Reactive Programming

#70

Post by kitd »

rhapsodic wrote: post #25

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.

On the contrary, it ties in neatly with platforms & programming models that can't just rely on being able to summon up an OS thread at will, but have to self-schedule over a small number of owned threads.

In just about every event-loop-driven, there exists an implementation of Rx (or something like that anyway)

Post reply on HN