Functional Reactive Programming

Post by andrekandre » Tue, Aug 16, 2022, 11:07 PM UTC

jshier wrote: post #60

zionic wrote: post #55

Earlier quoted context omitted.

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.

Post by quickthrower2 » Tue, Aug 16, 2022, 11:48 PM UTC

carapace wrote: post #68

miggol wrote: post #18

Earlier quoted context omitted.

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…

Elm isn't dead. It's in that happy place of stability, people are getting things done with it w/o hassle or churn. I've heard that an Elm-to-native app compiler is in the works somewhere, which IMO is very exciting.

Post by bbkane » Wed, Aug 17, 2022, 2:38 AM UTC

InflexHQ wrote: post #15

I'll be adding this to Inflex ( https://inflex.io/ ), I have the design worked out on paper. (But I'll be open sourcing it first and releasing as a desktop app, and then get back to dev.) It's also helpful to think of FRP in terms of "push" and "pull" (for which there's a related paper by the same chap). This refers to control flow. Behaviours are "pull" i.e. your program has to pull from them. Events are "push" i.e.…

Post by brabel » Wed, Aug 17, 2022, 6:04 AM UTC

rstarast wrote: post #89

brabel wrote: post #69

Earlier quoted context omitted.

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…

Post by cybrox » Wed, Aug 17, 2022, 9:37 AM UTC

marcosdumay wrote: post #62

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…

FRP is like OOP. For some problems, there is a level of granularity where it's an absolute killer, and nothing gets even nearly as effective. But if you write it with too much granularity, it will completely destroy your code. (And with too little granularity, it will be useless.) This phrase alone: "data-flows that go through multiple modules" is a very good indication that you broke things down too much, and should…