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

61–66 of 66 posts

Re: The Misunderstood Roots of FRP

#61

Post by solidsnack9000 »

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…

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.

Re: The Misunderstood Roots of FRP

#62

Post by sriku »

iamwil wrote: post #55
sriku wrote: post #34

This stuff is close-to-heart for me as FRP (and Elliott's work in general) greatly inspired my thinking over the years. Here are a few instances where the drive to be denotational in api design led to very satisfactory results. This is a massive "shameless plug" post, but I justify it as a dedication to Conal Elliott. First, a couple of old talks on the topic - - "Functional thinking" - Brings together some of the th…

What did you replace Elm with in your later work with FRP systems? Also, with your Elm-anima project, what were the lessons and takeaways? It seemed like it was working, but what are the limitations of the approach?

I wrote a small JS "framework" that's not even worth that name, but which works well enough by decoupling components CSP style. The HTML rendering part was not the most complex piece in the system (it was webaudio code, wasm, etc. dominated) to warrant dependency on a language so the additional complexity wasn't worth it.

Elm-anima - yes I felt that the elm-anima approach worked fine conceptually and is fairly performant too with scope to inject caching and laziness, but its approach ran into 0.18 's subscription mechanism (it was done before subscriptions) and I couldn't wrap my head around the loss of control there for this purpose. Things didn't compose after that.

Edit: elm-anima also needs more work to support effects, without burdening the API too much, to be truly useful.

Personally, I'd have liked the whole program in Elm to be modeled as just an "Automaton Input (Html, Task x ())" or something. That would've given enough freedom to do these kinds of things and, with some effort, be performant too.

Re: The Misunderstood Roots of FRP

#63

Post by mbrodersen »

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…

Yep completely agree. FRP sucks. FP rocks.

Re: The Misunderstood Roots of FRP

#64

Post by tsimionescu »

Izkata wrote: post #59
zyxzevn wrote: post #57

Earlier quoted context omitted.

You must be used to reading inside out, instead of left to right. The parameters will mess up as soon you have multiple parameters. Especially messy if you want to reuse them. Or when you have conditions. In a graphical system you do not need brackets, which is why I added it as a possible solution.

The first and third are both easier for me than the second. At least in my case, it's not an inside-out or left-right thing, it's a funnel that shows the exact relationship of the data. The problem with the second one is that the multiple distinct statements require scanning up and down across them to ensure the local variables aren't used anywhere else, and then mentally reconstructing the data's flow from one funct…

But the second form is also more general, since you can express any computation that way, whereas you can't in the first or third forms.

For example:

    x = A(B)
    y = D(x) 
    z = C(x, E(y))
Is either an important optimization (possibly affecting asymptotic complexity in more complex cases), important for correctness (if any of the functions have side-effects), or at least more succint than the alternatives (in a lazy language like Haskell).

Re: The Misunderstood Roots of FRP

#65

Post by proc0 »

nh2 wrote: post #21
proc0 wrote: post #11

Earlier quoted context omitted.

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: * htt…

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.

Re: The Misunderstood Roots of FRP

#66

Post by proc0 »

pubby wrote: post #18
proc0 wrote: post #11

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN