4 ms·

Why do you say "bizarre meme"? Observables are not like event emitters. RxJS Subjects would fit that description. See http://stackoverflow.com/questions/2533893

by staltz 10y ago

Why do you say "bizarre meme"? Observables are not like event emitters. RxJS Subjects would fit that description. See http://stackoverflow.com/questions/25338930/reactive-programming-rxjs-vs-eventemitter-in-node-js#35239241 http://stackoverflow.com/questions/25338930/reactive-program... and https://www.youtube.com/watch?v=uQ1zhJHclvs https://www.youtube.com/watch?v=uQ1zhJHclvs Observables are just an API for any push system based on callbacks, to make it composable and lazy. Array.forEach uses callbacks, Promise.then uses callbacks, Node.js streams are consumed using callbacks. And observables can model those cases without losing their properties (e.g. Array.forEach is called synchronously).

cwmma 10y ago
> Why do you say "bizarre meme"? the bizarre meme is that they are 'replacements' for promises, they are really intended for (as you rightly put it) push streams which is a different, though occasionally overlapping, use case then promises.
- staltz 10y ago
  I said push system, not push stream. Promises are a push system.
  - spion 10y ago
    If there was a specialized Observable that is guaranteed to only generate one value per subscription, and the API indicated this clearly by naming such an observable "Task" or "Future", I'd be all for it. Otherwise, its like using Arrays or Lists instead of Maybe. Hope that clears up why its "bizarre", but if not, its because the contract is not restrictive enough. Example: `let x:Observable<Row[]>`. Does this generate a single event with all the rows? Or does it do row batching? No idea. Can I consume both the same? Not really, depends on the use. e.g. if I want to sort the items, I'd have to implement merge sort for the second case.
    - int_19h 10y ago
      I think the argument here was indeed to treat promises as a subset of observables, not replace them with observables. Just as option type is a subset of collections that can have at most 1 element (but all operations that apply to any other collection, like say "map", still make sense for it).
    - staltz 10y ago
      > If there was a specialized Observable that is guaranteed to only generate one value per subscription, and the API indicated this clearly by naming such an observable "Task" or "Future", I'd be all for it. Given any Observable `obs`, you can consume it with `obs.take(1).subscribe()` instead of `obs.subscribe()` and then you'll be sure it only generates one value per subscription. But in practice the generation of multiple values in itself is rarely an issue to worry about. Often you just want to drop consecutive duplicates, there's an operator for that: `distinctUntilChanged`. You can also end an observable based on a timeout. Multiple values emitted is a pseudo-problem, and often your programming becomes more powerful ("does more in less lines of code") by using that capability.
      - spion 10y ago
        Okay. Please replace all Maybe instances in your code with Arrays and let me know how that goes.
bad_user 10y ago
In fairness, while Observables look similar to Promises and while it seems that a Promise could inherit from an Observable (like the Single type is doing in RxJava), this is one of those real-world cases of inheritance gone terribly wrong. The fact of the matter is Observables get used for different use-cases than Promises. And for the use-cases for which Promises end up being used Observables are broken. For example Observable's flatMap operation is most likely not memory safe and so it cannot be used in a "tail recursion". This is because we have to wait on the "onComplete" event in order for resources to be de-allocated and that cannot happen before the last Observable emitted by the last "onNext" signals its own "onComplete". But tail-recursion is a primary use-case for a Promise type and so its "flatMap" needs to be memory safe. I've thought long and hard about it btw, I even have a library that implements both a lazy Task abstraction and the Observable pattern: https://monix.io https://monix.io I love observables obviously, but Observable isn't a substitute for a Promise and I hope we don't go down that road.
- staltz 10y ago
  flatMap isn't memory safe but switchMap is, and it's often used for the type of request/response chaining that we do with Promise.then. With pratical experience using Observables in production for any use case people normally use Promises, I disagree with you about not being a substitute, and specially about being "broken".
- naasking 10y ago
  From the FRP literature, an observable can be viewed as a stream of promises, something like: { "value" : ..., "next" : new Promise(...) } So it's basically a linked list of the current value, and the next value which is a promise for the same type of structure.
  - bad_user 10y ago
    An observable is definitely not a stream of promises, because an observable is push-based, while a stream of promises would be pull-based. Big difference in performance, implementation and what operations are possible or not. Even if you add back-pressure in that protocol, it's still a big difference. And yes, my point is that an observable is close to being a sort of superset of a promise, but not close enough.

by staltz 10y ago

cwmma 10y ago

> Why do you say "bizarre meme"? the bizarre meme is that they are 'replacements' for promises, they are really intended for (as you rightly put it) push streams which is a different, though occasionally overlapping, use case then promises.

staltz 10y ago
I said push system, not push stream. Promises are a push system.
- spion 10y ago
  If there was a specialized Observable that is guaranteed to only generate one value per subscription, and the API indicated this clearly by naming such an observable "Task" or "Future", I'd be all for it. Otherwise, its like using Arrays or Lists instead of Maybe. Hope that clears up why its "bizarre", but if not, its because the contract is not restrictive enough. Example: `let x:Observable<Row[]>`. Does this generate a single event with all the rows? Or does it do row batching? No idea. Can I consume both the same? Not really, depends on the use. e.g. if I want to sort the items, I'd have to implement merge sort for the second case.
  - int_19h 10y ago
    I think the argument here was indeed to treat promises as a subset of observables, not replace them with observables. Just as option type is a subset of collections that can have at most 1 element (but all operations that apply to any other collection, like say "map", still make sense for it).
  - staltz 10y ago
    > If there was a specialized Observable that is guaranteed to only generate one value per subscription, and the API indicated this clearly by naming such an observable "Task" or "Future", I'd be all for it. Given any Observable `obs`, you can consume it with `obs.take(1).subscribe()` instead of `obs.subscribe()` and then you'll be sure it only generates one value per subscription. But in practice the generation of multiple values in itself is rarely an issue to worry about. Often you just want to drop consecutive duplicates, there's an operator for that: `distinctUntilChanged`. You can also end an observable based on a timeout. Multiple values emitted is a pseudo-problem, and often your programming becomes more powerful ("does more in less lines of code") by using that capability.
    - spion 10y ago
      Okay. Please replace all Maybe instances in your code with Arrays and let me know how that goes.

bad_user 10y ago

In fairness, while Observables look similar to Promises and while it seems that a Promise could inherit from an Observable (like the Single type is doing in RxJava), this is one of those real-world cases of inheritance gone terribly wrong. The fact of the matter is Observables get used for different use-cases than Promises. And for the use-cases for which Promises end up being used Observables are broken. For example Observable's flatMap operation is most likely not memory safe and so it cannot be used in a "tail recursion". This is because we have to wait on the "onComplete" event in order for resources to be de-allocated and that cannot happen before the last Observable emitted by the last "onNext" signals its own "onComplete". But tail-recursion is a primary use-case for a Promise type and so its "flatMap" needs to be memory safe. I've thought long and hard about it btw, I even have a library that implements both a lazy Task abstraction and the Observable pattern: https://monix.io https://monix.io I love observables obviously, but Observable isn't a substitute for a Promise and I hope we don't go down that road.

staltz 10y ago
flatMap isn't memory safe but switchMap is, and it's often used for the type of request/response chaining that we do with Promise.then. With pratical experience using Observables in production for any use case people normally use Promises, I disagree with you about not being a substitute, and specially about being "broken".
naasking 10y ago
From the FRP literature, an observable can be viewed as a stream of promises, something like: { "value" : ..., "next" : new Promise(...) } So it's basically a linked list of the current value, and the next value which is a promise for the same type of structure.
- bad_user 10y ago
  An observable is definitely not a stream of promises, because an observable is push-based, while a stream of promises would be pull-based. Big difference in performance, implementation and what operations are possible or not. Even if you add back-pressure in that protocol, it's still a big difference. And yes, my point is that an observable is close to being a sort of superset of a promise, but not close enough.