FRP is simply the true way to build real time application.
Functional Reactive Programming
51–60 of 121 posts
Re: Functional Reactive Programming
#52As much as I'd love to learn Haskell, Lisp, OCaml or F#, try https://reactivex.io/ and pick your language.
Re: Functional Reactive Programming
#53I 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
Haskell is sort of the base model option if you want real full-power FP, and not just support for some FP techniques.
Re: Functional Reactive Programming
#54This short fun video demonstrates how FRP is related/similar to spreadsheets:
Re: Functional Reactive Programming
#55Earlier quoted context omitted.
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.
https://github.com/apple/swift-async-algorithms
Requires Xcode 14, which is still in beta and cannot push to the App Store.
Also, Apple fucked their back port badly. It’s supposedly fixed now, but if you built an app that used async/await anywhere in Xcode 13.X and a user installed running iOS 12/13/up to 14.5 they’d crash on launch.
So I personally wouldn’t trust it, and instead just push to raise your iOS minimum. I’ve had no problems requiring iOS15 in my projects over 1M installs
Re: Functional Reactive Programming
#56Angular is using rxJs which is a reactive programming framework, but I think it was an error to do so. The angular project I am working on is now 5 years old and the parts of the application that are the least understood are the ones with more rxJs in it. We even have custom rxJs operators that nobody understand anymore... The way we do things now is to transform everything we can into promises because it's more easy…
Yes - totally the opposite. In fact, I think the issue with Angular is that they've not finished the work to make Angular RX-everywhere (for example, reactive components need to be manually plugged into Subjects at the moment).
With RxJS you should use it everywhere (observing state, observing component inputs, side effects etc). It's when you use it half-heartedly that you get problems with merging different programming paradigms.
The biggest issue with RxJS that we've found is that some devs have a super hard time getting to grips with the paradigm, and if your project is mostly those types of people, it will end up a disaster.
Re: Functional Reactive Programming
#57Earlier quoted context omitted.
This is not MVC's problem to solve. It also doesn't solve global warming. If you have unprotected multithreaded imperative updates of global data, nothing is consistent. Has nothing to do with MVC or no MVC. Actually having a consistent state to present to the UI is the model's problem. Oh, and for goodness sake, don't have any kind of async update process running in the controller. All this stuff belongs in the mode…
> 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.
Re: Functional Reactive Programming
#58For those of you interested in hearing the inventor of FRP talk about it, take a look at Conal Elliott’s retrospective talk in 2015:
Especially useful for those whose only exposure to FRP is through frp-inspired libraries (they’re not the same thing).
Re: Functional Reactive Programming
#59Angular is using rxJs which is a reactive programming framework, but I think it was an error to do so. The angular project I am working on is now 5 years old and the parts of the application that are the least understood are the ones with more rxJs in it. We even have custom rxJs operators that nobody understand anymore... The way we do things now is to transform everything we can into promises because it's more easy…
On the one hand, I absolutely love working with rxjs on a fairly large angular app as a side project. It affords me the chance to be clever with code, to reason about coordinating multiple asychronous streams, and so on. Firestore gives me observables of the queries I run where the data update themselves, and the user generates events that turn into data mutations. It is all just super great.
On the other hand, I recognize that doing this well and correctly (understanding how to pipe together operators instead of creating lots of intermediate subscriptions manually, which I see a lot in example / stack overflow code) requires a high level of understanding.
It is a whole change in how you think about event pipelines and code structure. I don't think I would want to migrate my day job systems to it, because then you need everyone on the team to develop that understanding. I'm sure they _could_, but working with promises and trad event handlers is a lot simpler, as long as you keep the rest of the data / eventing pipelines simple.
Re: Functional Reactive Programming
#60Earlier quoted context omitted.
AsyncSequence is good to go with iOS 13+ now, you can start using it right away.
https://github.com/apple/swift-async-algorithms Requires Xcode 14, which is still in beta and cannot push to the App Store. Also, Apple fucked their back port badly. It’s supposedly fixed now, but if you built an app that used async/await anywhere in Xcode 13.X and a user installed running iOS 12/13/up to 14.5 they’d crash on launch. So I personally wouldn’t trust it, and instead just push to raise your iOS minimum.…
swift-async-algorithms can be used in earlier versions of Xcode if you checkout an earlier tag. They just moved forward more quickly.
Async / await's backport no longer causes crashes in Xcode 13.4, but it does have the downside of being the Swift 5.5 runtime, which has several unfixed issues, unfortunately.