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

31–40 of 78 posts

Re: An introduction to Reactive Programming

#31

Post by danharaj »

michaelsbradley wrote: post #30
danharaj wrote: 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…

Flapjax had behaviors , as you describe, as a key facility in a JavaScript FRP implementation, dating back to 2008: 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!

Sounds about right, FRP was originally formulated around events and behaviors all the way back in 1997! Great credit to Conal Elliott and the late Paul Hudak for that.

Re: An introduction to Reactive Programming

#32

Post by seriousluoldmof »

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

Re: An introduction to Reactive Programming

#34

Post by adamnemecek »

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?

Re: An introduction to Reactive Programming

#35

Post by naasking »

danharaj wrote: 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 what they are, our languages just don't have codata as first-class citizens, and so we shoehorn it into stream abstractions.

Re: An introduction to Reactive Programming

#36

Post by hudbuddy »

Since no one has mentioned it yet, and it respectably isn't mentioned in the article, the author of this is the creator of the cycle.js (cycle.js.org).

It is a really cool way of looking at DOM state as a flow of: -> user interaction -> application reaction ->

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.

Re: An introduction to Reactive Programming

#37

Post by naasking »

raquo wrote: post #22
quadcore wrote: post #12

While this may be technically sound, I think this is not the most fundamental way of explaining FRP. FRP is just a toy really. It's a useful toy that help to grasp and use an advanced programming concept. Let me explain. 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…

This "assignment is caching is bad" analogy does not hold any water. 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…

> 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, sounds like exactly what he's arguing for.

Re: An introduction to Reactive Programming

#38

Post by naasking »

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

> but then again, we didn't create cults around dev methodologies...

You sure about that? I certainly recall plenty of holy wars over object oriented programming.

Re: An introduction to Reactive Programming

#39

Post by jfoutz »

hudbuddy wrote: post #36

Since no one has mentioned it yet, and it respectably isn't mentioned in the article, the author of this is the creator of the cycle.js (cycle.js.org). It is a really cool way of looking at DOM state as a flow of: -> user interaction -> application reaction -> 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 entir…

IMHO, you run into the same problem as journaling. User interaction is basically a stream of deltas. If everything is perfect, it’s awesome. But really, you want checkpoints from time to 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.

Re: An introduction to Reactive Programming

#40

Post by raquo »

naasking wrote: post #37
raquo wrote: post #22

Earlier quoted context omitted.

This "assignment is caching is bad" analogy does not hold any water. 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…

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

Post reply on HN