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

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: ▶ this video ) I still think that functional reactive programming solves most of the problems we have in UI-land, but th

in “We've had front end reactivity since 2018 – via Async Iterables” · View on HN

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. ▶ this video

in “Elm 0.14 – Simpler Core, Better Tools” · View on HN

For those just getting started in FRP or whom may have not seen the presentations at StangeLoop: - ▶ this 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)

in “New Adventures for Elm” · View on HN

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: ▶ this video

in “React vs. Angular 2” · View on HN

> "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: ▶ this video

in “Introduction to Reactive Programming” · View on HN

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

in “Purely Functional Retrogames (2008)” · View on HN