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

51–60 of 78 posts

Re: An introduction to Reactive Programming

#51

Post by raquo »

forkerenok wrote: post #50
raquo wrote: post #40

Earlier quoted context omitted.

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.

Which are exactly equivalent to a function call, just with a different type, and a syntax without parens.

"this will be re-evaluated every time you access it"

Re: An introduction to Reactive Programming

#53

Post by barbersturgeon »

ak39 wrote: post #45

Can traditional languages like C, C++ and even Object Pascal support reactive programming? Or this is only implementable in functional languages?

They absolutely can. Take a look at http://reactivex.io for implementations in lots of imperative/oo languages. Functional reactive programming can also be done in these languages but may lack some of the convenince of a functional oriented language

Re: An introduction to Reactive Programming

#54

Post by didibus »

doublerebel wrote: post #3

This is an interesting article, but I don't think it gives enough credit to Functional Programming. The article presents functional programming applied to push streams, which is part of FRP but only one way to look at Reactive Programming. Thinking in streams is a great exercise but is not a panacea. It's really easy to get started with streams in a toy example, but in real world applications backpressure and bufferi…

Correction, Riemann is implemented in Clojure, not Ruby.

Re: An introduction to Reactive Programming

#55

Post by forkerenok »

raquo wrote: post #51
forkerenok wrote: post #50

Earlier quoted context omitted.

> Call-by-name is just syntactic sugar for anonymous functions. No, it's not. It defines different evaluation semantics.

Which are exactly equivalent to a function call, just with a different type, and a syntax without parens. "this will be re-evaluated every time you access it"

I see what you meant now. Though it seems you are mixing notions of anonymous function and function as an argument of higher order functions (it doesn't have to be anonymous).

Re: An introduction to Reactive Programming

#56

Post by suprfnk »

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

I think that line is aimed towards people new to all this stuff, hearing "functional reactive programming" being thrown around. The author does seem to know the 'roots', if you can call it that:

"Reactive programming is programming with asynchronous data streams.

In a way, this isn't anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. [..]"

Re: An introduction to Reactive Programming

#57

Post by quadcore »

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…

Good point. It's not really relevant for local variables I guess, because those caches are invalidated quite elegantly (you'll still find cases Im sure where the programmer took that too far). I dont have all the cases in mind but, for example, storing results in object members is common and more often than not, detrimental. Also, there is the events. Events are a caching mechanism as well. They are an optimisation and they are evil. Now don't get me wrong, if you have a bottleneck, events can be a great optimisation.

The whole point being, FRP, while having some cool features, is mostly fixing bad programming practices.

Re: An introduction to Reactive Programming

#58

Post by mhd »

naasking wrote: post #38
seriousluoldmof wrote: post #32

Earlier quoted context omitted.

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.

And the 4GL bubble.

Re: An introduction to Reactive Programming

#59

Post by TuringTest »

adamnemecek wrote: post #48
mathgladiator wrote: post #46

Earlier quoted context omitted.

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?

Can you compose incoming OS interrupts?

Re: An introduction to Reactive Programming

#60

Post by omginternets »

naasking wrote: post #35
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 w…

>codata

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

Post reply on HN