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

Functional Reactive Programming

wiki.haskell.org

Post reply on HN
Print view View original

81–90 of 121 posts

Re: Functional Reactive Programming

#81

Post by Paradigma11 »

dllthomas wrote: post #73

There's a lot of talk of Rx libs, but from https://reactivex.io/intro.html I see: "It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX op…

There was reactive programming coming from c#. You can look up Eric Meijer and the duality of Observable and IEnumerable. It is discrete, push and event based and has some history with flow based programming.

FRP comes from Conal Elliot and has a continuous pull based aspect with maybe an additional reactive event based component on the side.

Then the javascript horde discovered rx and since functional programming is cool, rp is now frp.

Re: Functional Reactive Programming

#82

Post by valenterry »

mpweiher wrote: post #57
valenterry wrote: post #47

Earlier quoted context omitted.

> If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Yeah, but that is exactly what FRP solves (or strives to solve) and MVC does not give you on it's own (as you said). Ofc MVC can be used in combination with other techniques to gain consistency, but it doesn't provide it on its own, which is what I believe was implied by your original post. If you were just talking about…

> If you were just talking about the UI in isolation Comment I was replying to: >> But it's really cool to have UIs that are completely consistent. So yes, we kinda were talking about the UI, keeping that consistent (with the model, presumably). Hence MVC. Keeping the model consistent is another topic.

I see - I guess the OP had something different in mind when they meant UI, not just the pure View. But point taken, I understand your response.

Re: Functional Reactive Programming

#83

Post by dllthomas »

Paradigma11 wrote: post #81
dllthomas wrote: post #73

There's a lot of talk of Rx libs, but from https://reactivex.io/intro.html I see: "It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX op…

There was reactive programming coming from c#. You can look up Eric Meijer and the duality of Observable and IEnumerable. It is discrete, push and event based and has some history with flow based programming. FRP comes from Conal Elliot and has a continuous pull based aspect with maybe an additional reactive event based component on the side. Then the javascript horde discovered rx and since functional programming is…

But an article on FRP on haskell.org is probably actually about FRP, right?

Re: Functional Reactive Programming

#84

Post by josteink »

hnthrway wrote: post #80
josteink wrote: post #33

Earlier quoted context omitted.

> As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. I had a similar experience maintaining and reviewing an Angular+Typescript application at work. I was fascinated about RX and was looking forward to see it in action. In practice Angular exposes everything f…

>I made a renegade effort to eliminate all Observables and replace them with standard, well-understood Promises instead. Wow. You would have been better off ditching Angular entirely, or sucking it up.

You’re downvoted but entirely right.

Unfortunately I didn’t have the time nor management buy-in for doing that (a full rewrite), so instead I went for the second best option, which was making the code we had at least manageable.

Re: Functional Reactive Programming

#85

Post by aporetics »

725686 wrote: post #76
aporetics wrote: post #58

For those of you interested in hearing the inventor of FRP talk about it, take a look at Conal Elliott’s retrospective talk in 2015: https://youtu.be/j3Q32brCUAI Especially useful for those whose only exposure to FRP is through frp-inspired libraries (they’re not the same thing).

This might be interesting from a CS perspective, but useless to developers who have to create real life messy business applications.

As a developer of real life messy code (as opposed to unreal life?), I have never found ignoring CS to be beneficial; and on the other hand, deciding in advance that CS is not helpful is hubristic: you never know when theoretical insight will become actionable.

On the other hand, who wouldn’t be curious? Like someone who purports to enjoy fast cars but has no interest in understanding internal combustion or electric engines?

Re: Functional Reactive Programming

#86

Post by mdcds »

dfee wrote: post #67

Is it viable to build a traditional web product/company on top of Haskell? That sounds like a silly question - but I’m serious. I’m enamored by the beauty of FP, but I’m not sure if there’s enough tooling or libraries to get to market. For example - GraphQL. There are two packages (mu and morpheus), but neither clearly document their feature parity in relation to other packages for other languages - and things like d…

In 2015-2016 SF Haskell meetup used to be hosted by an ed-tech company that used Haskell as the main language, so maybe viable.

Re: Functional Reactive Programming

#87

Post by Paradigma11 »

dllthomas wrote: post #83
Paradigma11 wrote: post #81

Earlier quoted context omitted.

There was reactive programming coming from c#. You can look up Eric Meijer and the duality of Observable and IEnumerable. It is discrete, push and event based and has some history with flow based programming. FRP comes from Conal Elliot and has a continuous pull based aspect with maybe an additional reactive event based component on the side. Then the javascript horde discovered rx and since functional programming is…

But an article on FRP on haskell.org is probably actually about FRP, right?

Indeed. That is why you have: at : Behavior α → Time → α which is a pull based continuous data type. This is a very elegant concept but comes with its own set of difficulties if implemented naively (space and time leaks).

A similar concept is shown here: https://www.microsoft.com/en-us/research/uploads/prod/2000/0...

Imo the main problem in the end is/was that not many problems are that conveniently described as continuous. Discrete and push based (rx) can do most things and even that is overused. It makes problems that are otherwise very hard, much easier to describe and solve using the many powerful combinators https://www.learnrxjs.io/learn-rxjs/operators

On the other hand you make all those easy problems quite a bit harder and if you are not disciplined you end up with complex rx "queries" that have semantics that you dont understand.

Re: Functional Reactive Programming

#88

Post by swyx »

BoumTAC wrote: post #5

I learn FP throught ELM and I really enjoyed it. Unfortunately the language seems dead. What are the easiest FP language to learn ? I checked multiple time Haskell but it seems really hard

what makes you say Elm is dead?

Re: Functional Reactive Programming

#89

Post by rstarast »

brabel wrote: post #69
rstarast wrote: post #25

Earlier quoted context omitted.

I have high hopes for the young Gren fork of Elm https://gren-lang.org/ .

It was pretty obvious that at some point, someone would fork Elm, given how Elm has always preferred purity over practicality... but it's not clear how this fork improves things even after reading the (tiny) documentation... can you expand on that?

It seems to address the important problems with Elm, around its overly restrictive project management, by 1. introducing more flexible package management (e.g. you can depend on a fork of a core package, or a private git repo etc.) 2. being open to adding various missing web APIs (e.g. while I'm not sure it's there yet, I expect websockets to make a return, which were dropped with Elm 0.19) 3. generally going for an open development model (even just not having to wait years to fix trivial crippling bugs in the compiler is a step forward...).

The other part is that I have a good impression of the person/people behind it and could see it sticking, for whatever that's worth.

Re: Functional Reactive Programming

#90

Post by ajuc »

cybrox wrote: post #23

As someone who had to maintain two applications written entirely using the FRP Paradigm (Rx in Kotlin/Swift with a heavy focus on FRP principles), I am fascinated the idea but I absolutely hated the experience. Writing behaviour flows can end in beautiful blocks of easy to understand operations. However, as these get more complex and you need to combine multiple data streams, logic is scattered all over a module. Ref…

> Refactoring data-flows that go through multiple modules is a huge hassle. Sometimes, we would spend hours just refactoring data-passing, wrapping and unwrapping and tests surrounding modules, because we needed to pass some additional values.

Same experience. Functional/declarative code is more elegant, but a small change in desired behavior might require completely different structure of the code (or an ugly hack). Meanwhile imperative code changes much less even if it's less elegant.

Post reply on HN