4 ms·

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 h

by pubby 7y ago

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 just one). He replied that he had no idea. Apparently it was still an open problem he was working on. Yikes! State turns out to be a convenient, natural way to represent... state. Funny, isn't it? That if you have some real world problem that involves state, that you want to model that using virtual state and not the high-order time-varying continuous functions that FRP uses. Even Alonso Church admitted that Turing's tape-based model of computation was easier to understand than his lambda calculus. BTW one more thing. Spreadsheets are commonly cited as a good example of real-world FRP use. The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state.

proc0 7y ago
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.
- pubby 7y ago
  To me, the core of FRP is hiding state. You couldn't look at a FRP program and say, "Yeah, here's where we define value X". Instead, you'd see various time-varying functions and the manner in which these functions are composed will implicitly define the state. I think Redux isn't true FRP because it's very much about defining state. You plainly state every variable your program needs, while in FRP, variables just don't exist.
  - proc0 7y ago
    Hiding state is more the priority of declarative programming. FRP being declarative definitely does that, but I think the update loop is what's at the core of FRP, namely function changes over time and how they compose together to create chains of function changes over time, or something like that.
- nh2 7y ago
  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.md https://github.com/reflex-frp/reflex/blob/develop/Quickref.m... * https://github.com/reflex-frp/reflex-dom/blob/develop/Quickref.md https://github.com/reflex-frp/reflex-dom/blob/develop/Quickr...
  - proc0 7y ago
    Completely agree Reflex is proper FRP. Redux does have some of the basics of FRP and you can stick to pure functions as well, which is limited by JS but not necessarily by the Redux pattern. I believe Redux is subset of FRP, that uses discrete commands instead of continuous function of time, and the time function can be made into descrete events for implementing commands. The rest builds on top of that.
_bxg1 7y ago
Agreed, partly. > The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state. People view some spreadsheet cells as state, and they view others as functions. There's a distinction between things that are naturally represented as one, vs the other. This is why I preach to people about MobX whenever I get the chance. It's a Redux alternative that embraces state for things that make the most sense as state, while giving you tools to easily FRP not only React content, but any pure function of that state.
- heavenlyblue 7y ago
  >> People view some spreadsheet cells as state... But a cell with a function is not a function, it’s a result of calling a function at a certain set of values. That is even true if you only use ArrayFormula. E.g. you can’t define a formula inside a cell and the call that cell with certain arguments.
  - _bxg1 7y ago
    The arguments are the other cells it references, which are themselves either state or other functions
chii 7y ago
> How could we fit HTTP requests into the DCTP model? ... > HTTP requests are too low level ... We need to go higher level and build a denotative model for “whole systems.” So this points out a flaw in thinking i think : that you own the whole system. I think the reason FP and FRP is hard to use is because a lot of work involves interfacing with existing systems that are inherently created imperatively (the examples in the article - files, network IO, etc). It is the same story as LISP machines - the idea is great, but the existing infrastructure and computing devices all rely on register based machines, and run imperative instructions means that at some point, somebody had to write code to work with those machines, and that code tends to infect upwards to the high-heavens of clean abstraction, taking it down. And this happens on every level - because one implementation details is another's interface.
- h0h0h0h0111 7y ago
  >the existing infrastructure and computing devices all rely on register based machines, and run imperative instructions I don't think the author is disputing this at all, but positing that for writing application layer programs this is unnecessary complexity and ought to be abstracted by the language/compiler. Perhaps as it stands our programming languages are too general purpose; in future, will we see a clearer distinction between languages for different purposes?
danharaj 7y ago
I use it professionally.
jamil7 7y ago
Kinda agree, but would add the counter point that it not being popular doesn't necessitate it being bad. We're also starting to see it become more mainstream, Rx* have been pretty popular on both mobile platforms for a while now. We've also just seen Apple release the Combine framework essentially making FRP a first class citizen in their SDKs.
darkkindness 7y ago
The author addresses some if not all of these points: "It's awkward as hell to use and takes way to many brain-cells to achieve simple results." > Even I find the above [react.js FRP] code hard to read, despite having written it! While this could be seen as a downside of the denotative approach, I see it as a mismatch between the denotative approach and textual syntax. There’s been interesting work visualizing streams, which I hope to build on. Currently, I’m in the mockup phase, but I hope to build a developer tool experience that will automatically generate a live visualization. My understanding is that right now it certainly does require too much brain to do anything in FRP, but that isn't a downfall of FRP as a concept ("FRP kinda sucks") but rather that making FRP convenient is still today an open research question. "That if you have some real world problem that involves state, that you want to model that using virtual state and not the high-order time-varying continuous functions that FRP uses." > Denotative languages better convey the global structure of a program. We can fully understand an expression by its subexpressions, and their subexpressions, recursively. There are no spooky action-at-a-distance side-effects that can manipulate things from afar. We don’t have to read the entire codebase to ensure we understand a single piece; we must merely read its subexpressions, recursively. This allows us to quickly rule out what we do and do not need to read, saving us a lot of time in large codebases. I don't disagree that using concrete, non-abstracted state is a simpler way to model state-related problems, but this isn't about modeling and solving state-related problems, it's about solving them in a way that's maintainable. It's easy to argue for simplicity now (i.e. when first approaching a problem) and we have many, many tools for using state for that, like ipython notebooks, or pen and paper. But let's point out that simplicity of these initial concrete-state-minded approaches tend to grow into entangled messes, messes that are arguably solved by encapsulation and patterns. Regardless of whether they do solve the problem, having to understand things like inheritance and all their related problems kind of defeats the purpose of using state to make the problem simpler to understand in the long run. Which is what FRP purports to solve. Except we don't have the pen and paper for FRP yet. "The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions." True. No one thinks that. The author doesn't think that. Probably not even the folks who made the neat stats-oriented spreadsheet[0] thinks that, and that's data as continuously varying as you can get. All of this kind of props up the title which is that FRP is grossly misunderstood. [0] https://news.ycombinator.com/item?id=18785371 https://news.ycombinator.com/item?id=18785371
foobarian 7y ago
Step 1: when selling something, it helps to explain what it is and why it is good.
sansnomme 7y ago
The Svelte framework is something that's pretty close to being truly reactive. Not functional though.
solidsnack9000 7y ago
Sometimes it is tough to use theory directly, even when it is a sound theory. This can be disappointing for theorists and very frustrating for practitioners.
mbrodersen 7y ago
Yep completely agree. FRP sucks. FP rocks.

by pubby 7y ago

proc0 7y ago

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.

pubby 7y ago
To me, the core of FRP is hiding state. You couldn't look at a FRP program and say, "Yeah, here's where we define value X". Instead, you'd see various time-varying functions and the manner in which these functions are composed will implicitly define the state. I think Redux isn't true FRP because it's very much about defining state. You plainly state every variable your program needs, while in FRP, variables just don't exist.
- proc0 7y ago
  Hiding state is more the priority of declarative programming. FRP being declarative definitely does that, but I think the update loop is what's at the core of FRP, namely function changes over time and how they compose together to create chains of function changes over time, or something like that.
nh2 7y ago
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.md https://github.com/reflex-frp/reflex/blob/develop/Quickref.m... * https://github.com/reflex-frp/reflex-dom/blob/develop/Quickref.md https://github.com/reflex-frp/reflex-dom/blob/develop/Quickr...
- proc0 7y ago
  Completely agree Reflex is proper FRP. Redux does have some of the basics of FRP and you can stick to pure functions as well, which is limited by JS but not necessarily by the Redux pattern. I believe Redux is subset of FRP, that uses discrete commands instead of continuous function of time, and the time function can be made into descrete events for implementing commands. The rest builds on top of that.

_bxg1 7y ago

Agreed, partly. > The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state. People view some spreadsheet cells as state, and they view others as functions. There's a distinction between things that are naturally represented as one, vs the other. This is why I preach to people about MobX whenever I get the chance. It's a Redux alternative that embraces state for things that make the most sense as state, while giving you tools to easily FRP not only React content, but any pure function of that state.

heavenlyblue 7y ago
>> People view some spreadsheet cells as state... But a cell with a function is not a function, it’s a result of calling a function at a certain set of values. That is even true if you only use ArrayFormula. E.g. you can’t define a formula inside a cell and the call that cell with certain arguments.
- _bxg1 7y ago
  The arguments are the other cells it references, which are themselves either state or other functions

chii 7y ago

> How could we fit HTTP requests into the DCTP model? ... > HTTP requests are too low level ... We need to go higher level and build a denotative model for “whole systems.” So this points out a flaw in thinking i think : that you own the whole system. I think the reason FP and FRP is hard to use is because a lot of work involves interfacing with existing systems that are inherently created imperatively (the examples in the article - files, network IO, etc). It is the same story as LISP machines - the idea is great, but the existing infrastructure and computing devices all rely on register based machines, and run imperative instructions means that at some point, somebody had to write code to work with those machines, and that code tends to infect upwards to the high-heavens of clean abstraction, taking it down. And this happens on every level - because one implementation details is another's interface.

h0h0h0h0111 7y ago
>the existing infrastructure and computing devices all rely on register based machines, and run imperative instructions I don't think the author is disputing this at all, but positing that for writing application layer programs this is unnecessary complexity and ought to be abstracted by the language/compiler. Perhaps as it stands our programming languages are too general purpose; in future, will we see a clearer distinction between languages for different purposes?

danharaj 7y ago

I use it professionally.

jamil7 7y ago

Kinda agree, but would add the counter point that it not being popular doesn't necessitate it being bad. We're also starting to see it become more mainstream, Rx* have been pretty popular on both mobile platforms for a while now. We've also just seen Apple release the Combine framework essentially making FRP a first class citizen in their SDKs.

darkkindness 7y ago

The author addresses some if not all of these points: "It's awkward as hell to use and takes way to many brain-cells to achieve simple results." > Even I find the above [react.js FRP] code hard to read, despite having written it! While this could be seen as a downside of the denotative approach, I see it as a mismatch between the denotative approach and textual syntax. There’s been interesting work visualizing streams, which I hope to build on. Currently, I’m in the mockup phase, but I hope to build a developer tool experience that will automatically generate a live visualization. My understanding is that right now it certainly does require too much brain to do anything in FRP, but that isn't a downfall of FRP as a concept ("FRP kinda sucks") but rather that making FRP convenient is still today an open research question. "That if you have some real world problem that involves state, that you want to model that using virtual state and not the high-order time-varying continuous functions that FRP uses." > Denotative languages better convey the global structure of a program. We can fully understand an expression by its subexpressions, and their subexpressions, recursively. There are no spooky action-at-a-distance side-effects that can manipulate things from afar. We don’t have to read the entire codebase to ensure we understand a single piece; we must merely read its subexpressions, recursively. This allows us to quickly rule out what we do and do not need to read, saving us a lot of time in large codebases. I don't disagree that using concrete, non-abstracted state is a simpler way to model state-related problems, but this isn't about modeling and solving state-related problems, it's about solving them in a way that's maintainable. It's easy to argue for simplicity now (i.e. when first approaching a problem) and we have many, many tools for using state for that, like ipython notebooks, or pen and paper. But let's point out that simplicity of these initial concrete-state-minded approaches tend to grow into entangled messes, messes that are arguably solved by encapsulation and patterns. Regardless of whether they do solve the problem, having to understand things like inheritance and all their related problems kind of defeats the purpose of using state to make the problem simpler to understand in the long run. Which is what FRP purports to solve. Except we don't have the pen and paper for FRP yet. "The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions." True. No one thinks that. The author doesn't think that. Probably not even the folks who made the neat stats-oriented spreadsheet[0] thinks that, and that's data as continuously varying as you can get. All of this kind of props up the title which is that FRP is grossly misunderstood. [0] https://news.ycombinator.com/item?id=18785371 https://news.ycombinator.com/item?id=18785371

foobarian 7y ago

Step 1: when selling something, it helps to explain what it is and why it is good.

sansnomme 7y ago

The Svelte framework is something that's pretty close to being truly reactive. Not functional though.

solidsnack9000 7y ago

Sometimes it is tough to use theory directly, even when it is a sound theory. This can be disappointing for theorists and very frustrating for practitioners.

mbrodersen 7y ago

Yep completely agree. FRP sucks. FP rocks.