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

> "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]

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]

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.

I think that live coding can serve as a really good tool if you do it right and it applies directly to what you're doing. For example, it works well in this demo [VIDEO] because it's a demo of how Elm can help you think about what's going on and debug your code on the spot. This presentation would have been a lot more boring if it lacked a live demo.

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)

Definitely not ignoring. I talk about the relation between Elm and that sort of stuff in [VIDEO] Lots of things look similar in this area that are not. I also offer an analysis of "higher order" observables in [LINK] , and the big difference is the underlying thread architecture you get using these two. I hope I'll be able to make these sorts of things clearer in time!

A few notes: - Elm dropped frp [0] - Even in it's older frp incarnation, elm didnt allow changing of the flow graph (sorry I cant remember the correct elm term for this) while the program ran [1], making it hard to say this would be an ideal way to go for true 'interactive coding' for games. To clarify my opinion I would like to add that I am assuming an ideal of 'interactive game coding' where one would start a GL context & repl session at the start of the day and make the game whilst never closing the session or killing the context. The OP limited himself to retrogames which is a wise move for exploring this topic, _one_ of the things that makes writing modern games hard is the extent to which you are pushing what the hardware can do. It is normal to be required to really be strict about what happens when in each frame and it's not possible to do this if, part-way through rendering you have to process events coming from some input thread that has no idea about the context your program is in. Lastly I would add that your program itself is state. Interactive programming requires you to create and remove functions from your running program and bugs particular to doing this can occur (some object has a reference to a version of a function you have removed etc etc). Unless we move to a point where our code (compiled & text) live in a some persistant data-structure that allows rollback in some meaningful way I find it hard to imagine _real_ functional interactive programming. Thi

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