Yes, this is basically my understanding of observables. But I've yet to see a compelling example where they are "needed" in Elm. This is not an argument against them, it's just that with Elm we have a different paradigm.
So if you want to make the case for additions to the Elm language or think about how to design an API to solve the problems you are facing with asynchronous data streams, then an example is invaluable. Because ultimately we write computer programs to solve problems, at least I do. I've found that having the state explicit instead of hidden in a stream collection function like "flatten" or "switch" or "union" or "foldp" makes reasoning about what actually happens so much easier. This may very well come at the cost of having to write extra code, but as you see in my drag and drop example, the state can be abstracted away to a single variable in your overall state and functions that give information about it. This is the state/update/subscribe state model, and I really don't see where streams fit in there. Den fredag 10 mars 2017 kl. 01:15:22 UTC+1 skrev Răzvan Cosmin Rădulescu: > > When you got some time give this a read: > https://gist.github.com/staltz/868e7e9bc2a7b8c1f754#the-introduction-to-reactive-programming-youve-been-missing > > On Thursday, March 9, 2017 at 11:08:38 PM UTC+1, Martin Norbäck Olivers > wrote: >> >> Well, it may very well be that I missed the point of observables, I'll >> have another look, but my somewhat limited experience using them was that >> it was easy to lose track of all the event going through a lot of streams. >> >> Maybe what you are looking for is something like the Process in Elm, >> which is not very useful right now, but with a message API could be used to >> implement some kind of stream. >> >> Or maybe it's sufficient to have some kind of object in the state that >> collects certain messages and then subscribes to a future time when it >> emits them again. The multiple-click is not a really clear-cut example of >> this as it's just a matter of collecting events and then comparing times. >> >> I find it helps enormously to have examples. Otherwise the discussion >> about API and constructs can go on without making any progress, because you >> don't really know what problem you are trying to solve, instead you have a >> solution (streams) in search of a problem. >> >> Den torsdag 9 mars 2017 kl. 22:43:41 UTC+1 skrev Răzvan Cosmin Rădulescu: >>> >>> I agree with you on mostly everything. I think the current architecture >>> with one state, update etc. works really well. The only thing is I see >>> streams (reactive objects in general) is that when they *fulfill* their >>> objective they will call the update function. 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. I see this as a very natural >>> way to extend the current architecture and I feel it fits very well, at >>> least at this theoretical level, I don't know enough to think about the >>> implementation, race conditions (if they were an issue), side effects etc. >>> >>> So, to recap, I'm not talking about using reactive objects to drive the >>> state directly, but to manage incoming data through time transforms, which >>> then trigger updating the state. I don't know if I was clear enough, I hope >>> you get what I mean. >>> >>> <<The fact that you can combine observables and get very "complex" >>> effects is true, but the point of Elm is not to make programs complex, but >>> to make them simple>> here you missed the point, you don't combine >>> observables to make a more complex program, but exactly the opposite, to >>> manage complexity through time-aware transform operators. >>> >>>> -- 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.
