"Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki

If you're interested in Elm but don't really know what it's about, I highly recommend Evan's Strange Loop talk, "Controlling Time and Space: understanding the many formulations of FRP." It will help to already have a bit of background in functional programming. [VIDEO]

There's an important issue with async iterables: what's the initial value of derived "signals"? In the Dart/Flutter world, async iterables are known as streams. The biggest problem is that they are asynchronous so if you derive new streams from existing streams, you won't have a value immediately for those streams available, you'll have to wait a frame for values to propagate. That's not a problem if you're just processing data, but if you're using them in a UI framework and your UI framework is coupled to the event loop, then you have a problem. This doesn't happen with the ReactiveX approach because things are evaluated immediately, one doesn't have to wait for the event loop to tick. (A fun historical artifact is that ReactiveX has not caught on in the Dart/Flutter community around 2019-ish because it was eventually migrated to use Streams and the initial-value-problem was a real problem that made the benefits of ReactiveX not carry its weight nobody noticed that but I was heavily involved and I am still using a custom framework derived from my observations back then). If we zoom out a bit, the problem is actually that we are trying to define a computation graph and then need a strategy for evaluation it. I think Elm has actually made the biggest progress on that front (here's THE talk on that topic that shows how complicated working out all the kinks can be: [VIDEO] ) I still think that functional reactive programming solves most of the problems we have in UI-land, but th

> "FRP is programming with asynchronous data streams." Maybe, if you drop the F. For clarification on FRP there was a great talk at strangeloop this year: [VIDEO]

It's been around in various forms, and implemented on top of various languages, for quite some time. The earliest full-fledged FRP implementation for JavaScript was Flapjax – work on it dates all the way back to 2006! [LINK] The paper Flapjax: A Programming Language for Ajax Applications is worth reading. [LINK] The principal designer and maintainer of the Elm Language (a functional reactive lang that compiles to JS) did his Master's Thesis on FRP, and that's a great resource if you want the big picture: [LINK] See also Controlling Time and Space: understanding the many formulations of FRP , by the same author: [VIDEO]

For those just getting started in FRP or whom may have not seen the presentations at StangeLoop: - [VIDEO] - Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi) - [LINK] - FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub) - [LINK] - ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

Higher level concepts in area so rife with incidental complexity like programming tend to get lost in the details of the implementation. Patterns and abstract concepts like FRP can only be understood by with implementation. Ideas tend to bend before working code, then again with an example app you enthusiastically write for your blog, and then again when someone bases her next project on that (not to mention HN discussions...). I like to learn thing this way, and not care that much about what the alphabet soup entails. Try to find what is a proper JavaScript MVC framework. And then write the first one yourself ;) I'm currently reading Clojure Reactive Programming, which differentiates from FRP using another term, CES for Compositional Event Systems, and goes to some length into history of these concepts, like higher order FRP, First Order FRP, Arrowized FRP, and of course Observer pattern and Data Flow programming. There is also Elm's creator's presentation at Strange Loop last year of the same topic: [VIDEO]

> The web community pioneered UI development paradigms involving > functional programming techniques and immutable data Ugh, No. [LINK] and [VIDEO]

I appreciate your resources, namely the video by the creator of Elm, [VIDEO] . However, I agree with above poster. I remember developing my first windows app by doing a main event loop. It's been that way for a long time. Only recently are we doing more asychronous callback / bound type mechanisms of reaction. And still not as strong as the FLP stuff mentioned in the video. Not as much functional stuff, just functional paradigms. I personally really like the perfection of static input/output transformation graphs. But yeah..it's not been that way for a while and I agree with OP, the web being so event/input/signal based, has spurred the movement for better ways of reactive programming.