On 1/27/2011 10:37 PM, Mark S. Miller wrote: > On Thu, Jan 27, 2011 at 8:23 PM, Kris Zyp <[email protected] > <mailto:[email protected]>> 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 <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
