I was quite disappointed to see that signals have been removed in Elm 0.17 (I found out about elm 6 days ago). I only seen a few bits of code using signals from before which had very simple `merge`/`map`/`filter`/and the notorious `foldp` operations. But I think signals & current implementation of Elm are complementary, not mutually exclusive. Just before getting into Elm I was looking at reactiveX and what struck me is the simplicity with which you can combine signals in time to get very complex effects *especially* when dealing with UI interaction (think of double tap, pinch, etc. - where you need to be able to extract data on a timeline and interact with previous "states"). Of course, for driving the main program forward I think the current architecture is really nice to work with. Only problem is now without signals you are unable to (easily) do operations involving time. You have to keep track of stuff, do your own math etc. So what I'm saying is that `merge`/`map`/`filter`/`foldp` isn't where signals' strength is but more like in `throttle`/`delay`/`group` etc. I might be wrong but I think that signals were useless in Elm were because they were only working with the "current data point" (from time perspective) or with "current & last - using `foldp`", but that's not the point of signals, not really.
So I'd like to know what this community thinks about this stuff as I'm very new to Elm maybe it's an unfounded claim and you can easily do this sorts of calculations in a simple way comparable with reactive observables somehow?! -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
