First crack at a Streams proposal

Isaac Schlueter i at
Mon Apr 22 16:13:43 PDT 2013

On Sat, Apr 20, 2013 at 12:47 PM, Tab Atkins Jr. <jackalmage at> wrote:
> On Sat, Apr 20, 2013 at 9:19 AM, Isaac Schlueter <i at> wrote:
>> I'm not seeing what in this proposal can't be implemented in
>> JavaScript as it is today.  Is there an implementation of this
>> somewhere?  Are there any programs that use these streams?
> This is a fully-general counter-argument against literally everything
> that doesn't require new primitives, and so is useless as an actual
> argument.

It's not fully-general counter-argument, because it's not an argument.
 It's a request for more information.  Until I have that information,
I don't have enough information to form a reasonable opinion.

I read your proposal.  It appears to be something that is
implementable with today's current JavaScript.  Am I mistaken?  If so,
how so?  (Ie, what new language semantics or primitives are required?)

If I'm not mistaken, then where's the reference implementation?  I
don't even see example code.  I figured that I must be missing

You're wrong about what it would damn, in every case.

>  It would damn Promises/Futures

Promises had many, many iterations in working code long before a
specification was ever proposed.

> Sets, Maps

Both required new language semantics.  But there WERE reference
implementations of both, long before either of those reached a spec.

> and a number of other new things.

Please be more specific.  There are many numbers.  Don't allude to the
vastness of your point, just make it, or don't.

Search npm and github before making claims about what things would be
damned by the request for a reference implementation in advance of a

> Please note that the proposal topping this thread is already
> long-obsolete.

Then please update the thread with the updated proposal, and
preferably a link to the github account with the reference
implementation, if such a thing exists.

If such a thing does not exist, please explain why it is not feasible
to write an implementation of this with today's language semantics.

If I seem a bit impatient, it is because I am eager to have an opinion
about this idea of yours, but I find myself incapable of responsibly
having an opinion without seeing it in action.

As you say, the concept of event streams appears in many libraries.  I
work daily with Node.js, which is full of event emitters and binary
data streams.  You mentioned that it would be easy to implement binary
streams on top of your streams idea.  I'd like to see that.  I know
from firsthand experience that streams can be surprisingly hard to get
right.  In my opinion, if you can't easily implement TCP, TLS, and
Zlib on a stream implementation, then you haven't gotten it right.

So, the fact that an implementation has not yet been shown seems quite
strange to me, because that would be the *first* thing that I'd expect
anyone would want to see, and it seems like it'd only take a few
hundred lines of code to do.  I say that because other "streaming" FRP
pattern libraries have been implemented in just a few hundred lines.
Look at the work of Dominic Tarr (dominictarr) or Irakli Gozalishvili
(gozala) on npm and github.

Until there is an implementation, I don't really see what there is to
talk about.  As I said, this is not a counter-argument, because as far
as I'm concerned, there's nothing to even argue about!

More information about the es-discuss mailing list