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

31–40 of 121 posts

Re: Functional Reactive Programming

#31

Post by christophilus »

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…

I feel the same way about RxJS. Moving from that to plain React hooks and data flow saved me a ton of sanity on one project a few years back.

Re: Functional Reactive Programming

#32

Post by Akronymus »

miggol wrote: post #18
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

So sad to hear that Elm appears to be dead. It really excited me at first but I guess that like many I never made the time to give Elm a serious attempt. For me, learning Racket was not too hard. The offical learning materials are excellent, although they are also meant for programmers starting from zero. For me that meant that I occasionally skipped over parts I considered "too easy" only to be confronted by my hubr…

Maybe elmish could be of interest to you? https://github.com/elmish/elmish

Re: Functional Reactive Programming

#33

Post by josteink »

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…

> 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 from its internal framework and interfaces as Observables, making RX everywhere the default.

The simplest things became mindbogglingly complex and asking “what does this code actually do” became the most frequent code-review question.

When we were unable to get the application stable, I made a renegade effort to eliminate all Observables and replace them with standard, well-understood Promises instead.

The result was fewer lines of code, clearer code, fewer bugs and more tests as bootstrapping/mocking a Promise-based API is significantly less effort than doing the same for its Observable-based counterpart.

It was a terrible experience all over and realistically (given the choice) I’ll never touch an Angular or RxJS based app ever again. My team will just touch React for any new development from now on.

Re: Functional Reactive Programming

#34

Post by pkilgore »

jamil7 wrote: post #24
cardanome wrote: post #21

Earlier quoted context omitted.

Elm is not dead. It just prefers a slow release schedule but is still actively worked on in the background. That said, you might want to check out OCaml for general purpose programming. Super fast compiler, great performance, can target both native and JS. It is easier to use than Haskell due to defaulting to eager evaluation (like most languages) strategy instead of laziness and being generally more pragmatic, offer…

> you might want to check out OCaml for general purpose programming Any tips on backend frameworks to look at? I need to write a small websocket service for a side-project and have always wanted to try OCaml. I came across https://github.com/aantron/dream .

Dream is great for small http services -- I've not used the websocket support so I can't say much about it.

I do highly recommend starting with one of the Dream example projects just to lower the barrier to entry on the tooling side.

You can also use Rescript (compiles to very readable Javascript), which is the OCaml type system with more familiar syntax and some of the complexity shaved off.

Re: Functional Reactive Programming

#35

Post by manmal »

zionic wrote: post #28
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…

I moved everything from RxSwift to Combine back with iOS (13?) and was happy with the experience. As for the “complexity”, I largely solved this problem by limiting dimensionality of stream handling to 1, and chaining streams via explicit function calls so that I was never map/flat mapping stream to stream to stream etc. This made everything much easier to understand in my projects, and also test etc. But you’re righ…

AsyncSequence is good to go with iOS 13+ now, you can start using it right away.

Re: Functional Reactive Programming

#36

Post by mpweiher »

valenterry wrote: post #8
mpweiher wrote: post #4

Earlier quoted context omitted.

The funny thing is that good ole MVC also gave us UIs that are completely consistent.

Not really. It's just that at the time, SPAs and concurrent requests were not really a thing or only used rarely.

Yeah, actually really.

Actual MVC has the model notifying the UI that it has changed and then the UI updating itself from the model, by pulling data. That's always consistent.

We then did all sorts of things that we call MVC, but that do not follow the MVC-defined interaction patterns at all, particularly either the model or other views incrementally poking data into the view.

That doesn't work, and it is nigh impossible to keep consistent. It also isn't MVC.

I haven't written this up stand-alone, but I talk about it a little here: https://blog.metaobject.com/2022/06/blackbird-simple-referen...

Re: Functional Reactive Programming

#37

Post by disantlor »

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…

i’ve been writing FRP code in JS for years now. Ease of refactoring and total clarity of what is happening (assuming you are familiar with the FP methods, etc) are the biggest advantages.

I agree the code can balloon in size, and gets a bit hard to organize at some point, but the self-documenting aspect of it is amazing.

I combine an FRP framework (bacon.js) with Ramda.

I’ll admit I’ve had trouble working with things like React because I’m so used to wiring everything up explicitly and there being no “magic” behavior.

The explicitness is probably what makes it seem so unwieldy as the code/team scales

Re: Functional Reactive Programming

#38

Post by cybrox »

amarant wrote: post #30
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…

Huh, my experience with Rx-Java is (partially) the opposite to yours. Partially because I've seen it used poorly in one project, and it was quite horrible, but that time it was more due to misusage of RX than it was the fault of RX itself. The second time I've used it in a big commercial project it was used well, and that remains the best codebase I've ever worked with. Super easy to reason about, extremely performan…

I agree that the surrounding framework (and I'd like to add also additional libraries) have a huge impact on this experience.

The codebase I have worked on might be a bit of an edge-case too, as it was used in realtime audio/video communication, so ms-timing, order of async operations and keeping a consistent state were absolutely necessary.

Using Rx for such complex, long-lived business logic is probably a long shot from using it for a cleanly structured SPA for example. I've used a lot of reactive concepts in applications that simply fetched and displayed data and in those cases, I really enjoyed it.

Re: Functional Reactive Programming

#39

Post by wiseowise »

cybrox wrote: post #26
valenterry wrote: post #8

Earlier quoted context omitted.

Not really. It's just that at the time, SPAs and concurrent requests were not really a thing or only used rarely.

You can build perfectly fine SPAs using an MVC architecture, even with lots of concurrent requests and data fetching. This is why JS has an event loop and why we invented data-binding.

You can build perfectly fine SPAs in one big file, what’s your point?

Re: Functional Reactive Programming

#40

Post by valenterry »

mpweiher wrote: post #36
valenterry wrote: post #8

Earlier quoted context omitted.

Not really. It's just that at the time, SPAs and concurrent requests were not really a thing or only used rarely.

Yeah, actually really. Actual MVC has the model notifying the UI that it has changed and then the UI updating itself from the model, by pulling data. That's always consistent. We then did all sorts of things that we call MVC, but that do not follow the MVC-defined interaction patterns at all, particularly either the model or other views incrementally poking data into the view. That doesn't work, and it is nigh imposs…

So, what if you have a background process (running in the controller I assume) that updates data in the model periodically from somewhere. And at the same time you have the user making changes to the model. How is consistency guaranteed here by having "UI updating itself from the model, by pulling data"?

Maybe I have a different understanding of "consistency" but this might very well lead to undesired results if the logic of data updates isn't well-controlled. The developer needs to decide if the updates can happen arbitrarily or if some kind of transaction-model needs to be used, forcing the background process to wait during user interactions or the other way around, etc.

I don't see how MVC solves that problem.

Post reply on HN