On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> I think a large part of the confusion here is that when Tab says "streams"
> he really means "observables" or "signals." As you point out, this would be
> completely inappropriate as a stream API, as it does indeed ignore many of
> the lessons Node learned. Surprisingly, it doesn't seem to draw on any of
> the existing observable or signal APIs that I've seen either, instead being
> some entirely new hybrid of promises and the nascent monads-in-JS movement.

Not quite - I've seen things like what I describe called "Streams"
before.  The recent things I've been looking at while writing this up
don't call it that, but that doesn't mean the term is unused.  ^_^
But I'm not wedded to any particular term.  I find "Observable" to be
not a great term, but whatever.

I do somewhat resent the implication that I invented something wholly
new without drawing on any existing APIs.  I looked at the syntaxes of
several similar APIs in other languages while designing this, and took
lessons from them.  Of course, I optimized it for JS.  I did purposely
cleave close to Futures, because Futures and Streams are very similar
and will be used for very similar things in DOM, so it makes sense to
make them have similar APIs, and I think the Futures API works well.
It was also definitely influenced by some of the recent JS monads
talk, but the two bits influenced by it are also very natural -
Stream.of is identical to Array.of (as a simplified "just put this in
the damn container" constructor), and Stream#then is one of the basic
stream combinators in other languages (I just chose the name to match
the JS-monads suggestion of using of/then as the monadic op names,
which I think are quite reasonable).

~TJ

On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> I think a large part of the confusion here is that when Tab says "streams"
> he really means "observables" or "signals." As you point out, this would be
> completely inappropriate as a stream API, as it does indeed ignore many of
> the lessons Node learned. Surprisingly, it doesn't seem to draw on any of
> the existing observable or signal APIs that I've seen either, instead being
> some entirely new hybrid of promises and the nascent monads-in-JS movement.

Not quite - I've seen things like what I describe called "Streams"
before.  The recent things I've been looking at while writing this up
don't call it that, but that doesn't mean the term is unused.  ^_^
But I'm not wedded to any particular term.  I find "Observable" to be
not a great term, but whatever.

I do somewhat resent the implication that I invented something wholly
new without drawing on any existing APIs.  I looked at the syntaxes of
several similar APIs in other languages while designing this, and took
lessons from them.  Of course, I optimized it for JS.  I did purposely
cleave close to Futures, because Futures and Streams are very similar
and will be used for very similar things in DOM, so it makes sense to
make them have similar APIs, and I think the Futures API works well.
It was also definitely influenced by some of the recent JS monads
talk, but the two bits influenced by it are also very natural -
Stream.of is identical to Array.of (as a simplified "just put this in
the damn container" constructor), and Stream#then is one of the basic
stream combinators in other languages (I just chose the name to match
the JS-monads suggestion of using of/then as the monadic op names,
which I think are quite reasonable).