promises | Communicating Event-Loop Concurrency and Distribution

Kris Zyp kris at sitepen.com
Fri Jan 28 06:05:08 PST 2011


On 1/27/2011 10:37 PM, Mark S. Miller wrote:
> On Thu, Jan 27, 2011 at 8:23 PM, Kris Zyp <kris at sitepen.com
> <mailto:kris at sitepen.com>> wrote:
>
>     This looks like a case of creating in-language for a library. This
>     was done with json2.js because it was one of the most widely used
>     libraries in existence and similar JSON handlers were used in
>     numerous libraries. The ref_send library and sibling Q style
>     implementations are not anywhere close to that level of adoption.
>     It seems like there are a large number of library functions that
>     have proven useful enough (by real usage) ripe for incorporation
>     into the language before the Q api. In fact, even with the realm
>     of JavaScript promise libraries, this implementation/API, which
>     has been discussed and known about for a number of years has not
>     become the dominate interface API, there are other approaches that
>     have been found more use. While I certainly like and appreciate
>     the Q API, I don't think it has proven itself worthy to be added
>     to the language.
>
>     The real pain point with promises isn't that it takes too many
>     characters to type Q.post. How many bytes does the average
>     JavaScript program spend on promise API calls? It negligible, this
>     proposal isn't solving any real world problem.
>
>
> Hi Kris, I appreciate your other points. However, from my own
> experience having programmed in this style with syntactic support, and
> attempting to bring myself to program in this style without syntactic
> support, I disagree. In this particular case, the syntactic difference
> between
>
>     Q.post(a, "foo", [b, c])
>
> and
>
>    a ! foo(b, c)
>
> makes a tremendous difference in one's willingness to use these
> abstractions, and in one's ability to read and understand code
> expressed in these abstractions. I believe this difference is adequate
> to deter most usage -- even in my experience by people like me, who
> already like these abstractions.

Of course syntax makes a difference, but doesn't that same argument
apply to the thousands of other JavaScript libraries out there? If I
just had syntactical support for my cool library, I know people would
start using it...

On 1/27/2011 10:47 PM, Mike Shaver wrote:
> On Thu, Jan 27, 2011 at 9:37 PM, Mark S. Miller <erights at google.com> wrote:
>> I don't understand why single-frame continuations are not at least as
>> vulnerable to the criticism you make above. They are even more unproven
>> among JavaScript programmers than are the concurrency abstractions in the
>> strawman. The main benefit of moving support for single-frame
>> continuations into the language is notational, which you dismiss above. I
>> don't get it.
> We have some experience with single-frame continuations in the Firefox
> code base (and elsewhere such as threads.js from Neil Mix), based on
> our years-old implementation.  The thing *I* like most about it,
> versus working from a callback-based model, is that you can use the
> language's flow control constructs.  Having to turn everything inside
> out via function chaining hurts a lot, even with helper libraries that
> are popular in the node.js community.
>
> for (var i in hash) {
>   doSomethingAsyncAndWait();
> }
>
> versus gross hackery like breaking out of the enumeration every time
> and deleting the just-processed property.  Nothing that code to be
> written out of order, or shattered by function decomposition and glued
> back together in the programmers mind, will be as satisfying I fear.

Exactly. On the NodeJS mailing list there is constant, never-ending
stream of messages from (generally new users) who are complaining about
the pain of callbacks (not from typing some API, I have yet to ever get
a request for shorter syntax for node-promise, which is one of the
commonly used helper libraries). In fact I think someone recently
created another continuation library (in the same vein as Narrative,
generators, etc.), continuing to add to our collective experience in
this area. I  could look up the address if desired.

Thanks,
Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110128/36ba8c80/attachment.html>


More information about the es-discuss mailing list