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

The Misunderstood Roots of FRP

futureofcoding.org

Post reply on HN
Print view View original

21–30 of 66 posts

Re: The Misunderstood Roots of FRP

#21

Post by nh2 »

proc0 wrote: post #11
pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

Isn't Redux FRP? You can easily do the basics in React as well. I would say it's the dominant paradigm in UI development and most don't know they're using it.

Having worked with both Redux and a "real" FRP implementation (Haskell's Reflex library), I wouldn't call Redux FRP.

In Redux one explicitly, imperatively sends messages to a top-level message dispatcher, which then invokes more imperative code.

This feels /very/ different to Reflex's folding over events, and transforming dynamic values with pure functions.

The API you use is pretty different as well; consider:

* https://github.com/reflex-frp/reflex/blob/develop/Quickref.m...

* https://github.com/reflex-frp/reflex-dom/blob/develop/Quickr...

Re: The Misunderstood Roots of FRP

#22

Post by danharaj »

pubby wrote: post #5

Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…

I use it professionally.

Re: The Misunderstood Roots of FRP

#23

Post by perl4ever »

I notice the mention of spreadsheets.

Something I never thought about until I started writing scripts in Excel is that when you define new functions to be used in cell formulas, they are not allowed to have side effects...and it didn't take long before I wanted to write functions with side effects.

Sure, this makes sense from a certain perspective, but when you're using a dialect of Basic, you kind of think it's down and dirty, anything goes. I mean, this is the language that used to usually have "peek" and "poke".

Re: The Misunderstood Roots of FRP

#24

Post by skybrian »

dustingetz wrote: post #9
skybrian wrote: post #8

Earlier quoted context omitted.

You can think of a timeline as immutable, but you don't know values from the past unless you arranged for them to be recorded, you don't know values from the future until they happen, and you don't know what's going on at any other node unless they send you a message about it and it eventually makes it across an unreliable network. (So, sometime after it actually happened.) If you model this in a declarative way then…

> be careful to avoid implying that all events should be remembered Is that true in a post-AWS world with storage getting cheaper faster than you can consume it? Maybe don't put 4k video in the log. But, you're right, we can stream, shard and forget as necessary. > also avoid depending on anything in the future unless you want to wait for it Can you elaborate on this, my gut reaction is to ask why I need to avoid dep…

If you use a value to do a calculation and it's from the future then often you end up blocking until it's available. This is how a Future works and is similar to what happens when you read from a TCP connection and the data has to be retransmitted because the network dropped the packet, so you block. If you want responsive output then you should avoid blocking or at least have a timeout and/or cancel button.

The conceptual idea of a value that continuously changes is nice for animation or maybe video (though that's both discrete and lossy), but seems messier when your knowledge is limited to an unknown selection of discrete data points from that timeline, arriving with an unknown amount of lag? Maybe you could talk about that mathematically, but it seems like it's going to be rather abstract and messy.

Re: The Misunderstood Roots of FRP

#25

Post by blondin »

jonstewart wrote: post #3

What’s FRP?

yep. i knew in our field the F & P could only mean functional programming. but the R eluded my acronym decrypting skills. glad to find someone found what it meant. i almost thought it was "recursive"...

can we agree to stop using these meaningless acronyms?!

Re: The Misunderstood Roots of FRP

#26

Post by pasquinelli »

zyxzevn wrote: post #19

Nobody quickly understands: A(B(C(D(E(x))))) That is why they use the assignments. e= E(x) d= D(e) c= C(d) b= B(c) a= A(b) But many people can understand: x-> E -> F-> C-> B-> A // where -> is a pipe operator. Now you see that you first execute E with x as input. This shows that Functional program has some kind of problem, if it is not presented in a good way. There are also other problems. The overuse of Currying is…

The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline; if you have to combine multiple pipelines you'd need to bracket them, as in the first.

Re: The Misunderstood Roots of FRP

#27

Post by mathgladiator »

The problem here is FRP is still immature and produces too much toy-ness. I've done some work in space, but the core of it is that the techniques are too expensive at the moment. This expense manifests in poor capacity utilization in the data center, and poor battery usage in mobile devices.

Re: The Misunderstood Roots of FRP

#29

Post by falcor84 »

perl4ever wrote: post #23

I notice the mention of spreadsheets. Something I never thought about until I started writing scripts in Excel is that when you define new functions to be used in cell formulas, they are not allowed to have side effects...and it didn't take long before I wanted to write functions with side effects. Sure, this makes sense from a certain perspective, but when you're using a dialect of Basic, you kind of think it's down…

For better or worse, Google Sheets functions (written in App Script) are allowed to have side effects. Though when invoked in cells, you don't have full control over when they're actually recalculated (there seems to be complex caching), so you need to plan your side effects accordingly.

Re: The Misunderstood Roots of FRP

#30

Post by throwaway_n »

csande17 wrote: post #14

Imagine you were trying to explain the temperature-conversion program's behavior in the simplest, clearest way possible. (That is, after all, what programmers fundamentally do: try to explain things to computers as simply and clearly as possible.) You'd probably say something like: "When the user changes the Celsius textbox, the computer changes the Fahrenheit textbox to the converted value." And indeed, that's the p…

Won't your example trigger an infinite loop of celsius/fahrenheit conversions? Especially if the floating point value is slightly off.

I think your example is exactly why stuff like React won vs data-binding frameworks. With declarative programming, you just have a single source of truth that you change once (you can arbitrarily pick celsius or fahrenheit or even kelvin) and let the framework figure out what needs to be diff-ed in the derived views.

Post reply on HN