The real test here for Elm isn't just "can you write a program that throttles input". Of course you can. It's can you write a library that would allow people who needed to throttle input or detect double-clicks or detect other more complicated gestures without needing to know the specifics of how you do such things. As others have noted, we could write everything in assembler but we don't because that level of detail isn't productive and opens up opportunities for mistakes in implementation.
How do you handle timeouts? What if you want to try multiple things and take the first response canceling the other work? Reactive and promise systems provide standard ways of representing this (though a lot of promise system implementations are very weak when it comes to cancelation). And again, if we can do it at all in Elm, can we do it in a way that doesn't surface all of the details? When I first started exploring reactive programming seven or eight years ago, my go to example was trying to step through a list of image ID's fetching the actual image data from an asynchronous service. You want to cancel fetches when no longer interested. It's better to keep showing the same stale images than to switch to a new stale image. You want to show a spinner if the currently displayed image has been out of step with the position in the list for too long. And possibly the images themselves aren't a single result but rather a stream of images of improving resolution. This is all very succinct in a reactive framework. That said, I've also seen what happens when you then thread reactive concepts through a large program particularly with a team that hasn't made the mental leap to thinking in terms of signals and particularly if you have backdoors to do things like look at the values of signals. The results are a tangled mess. So, my assessment is that if you can readily describe a computation with signals, that can be a great boon to simplifying code but there are things that can't or shouldn't be described with signals. Furthermore, lacking any sort of flat map for signals made Elm's previous FRP implementation pretty severely limited so I'm not sure it's really a loss. The bigger question is whether Elm has alternative means to deliver the sorts of useful abstraction that signal libraries provide. Mark > On Mar 10, 2017, at 8:53 AM, 'Rupert Smith' via Elm Discuss > <[email protected]> wrote: > >> On Thursday, March 9, 2017 at 9:43:41 PM UTC, Răzvan Cosmin Rădulescu wrote: >> Take for example debounce with 500ms interval, every 500ms it should trigger >> the update function with the latest object from the stream, that's it. > > Would be interesting to implement this in Elm and see how it turns out. > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
