I saw your slides and I cant agree more with you. The other day I did some thinking about all the javascript code I have been writing and I came to this conclussio (bear with me, please): - for me the problem with CPS (continuation passing style) for asynchronous code is not the cascade of nested callback. The code gets ugly when you mix CPS constructs with non-CPS constructs. Think when you have to do something async while looping something, or when you have to do something async IF some condition is true, and then something else even when the condition is not met. - javascript has ifs, for, and lot of constructs that are non-CPS. In Clojure and LISPs everything could be CPS, so in this regard we can say is "better". -tamejs, iced coffee script, f# (with its async workflows) etc has constructs to avoid CPS for asynchronous code and one of the best things of this is that non-CPS IF statements play nice with ... non cps async code.
I wrote an example in my blog about this http://joseoncode.com/2012/06/24/messing-with-cps-in-js/ where i explore a way to create a CPS IF statement and it makes the code easier than with the standar IF statement. Another thing Id like to have is a language with nice syntax for asynchronous code (as your await example) that compiles down to LISPish javascript. El domingo, 1 de julio de 2012, Domenic Denicola escribió: > I'd like to submit my promises talk for consideration as well :). I agree > with Mariusz that once you get it you will never go back. > > > http://www.slideshare.net/domenicdenicola/callbacks-promises-and-coroutines-oh-my-the-evolution-of-asynchronicity-in-javascript > > On Sunday, July 1, 2012 2:55:05 PM UTC-4, Mariusz Nowak wrote: > > @Andy Async is just sugar for control flow written with plain callbacks > and promises address asynchronicity from very different angle. > In promises approach asynchronous state is represented with the object, so > instead of registering single callback, you get the object, which you can > pass to many different functions, or on which you can listen for value with > many different listeners. Promises also provide clean separation of success > and error flows. It's much more powerful than plain callbacks, but also > takes some time to get familiar with that. Once you get it, you will never > go back ;-) > I've once done introduction to promises speech. See > http://www.medikoo.com/**asynchronous-javascript/<http://www.medikoo.com/asynchronous-javascript/> > (**promises starts at 16 slide) > > -- > Mariusz Nowak > https://github.com/medikoo > http://twitter.com/medikoo > > > On Sunday, March 25, 2012 10:42:32 AM UTC+2, Andy wrote: > > *Note, I am not asking which tool is better, I am simply trying to > understand the differences. > > *I'm trying to wrap my head around promises in node. Right now I'm > writing all my code in callback soup. I am researching libraries and I > found async <https://github.com/caolan/async> (duh) but I also found the > horribly named but seemingly very popular q<https://github.com/kriskowal/q> > . > > What I am trying to figure out is if these libraries are mutually > exclusive. The async page mentions nothing about "promsies" and instead > talks about "flow control." But it seems like both libraries are sugar for > handling async function flow and callbacks. Do they both solve the same > problem, or can / should they be used together? > > Take this example: > > async.waterfall([ > function(callback){ > callback(null, 'one', 'two'); > }, > function(arg1, arg2, callback){ > callback(null, 'three'); > }, > function(arg1, callback){ > // arg1 now equals 'three' > callback(null, 'done'); > } > ], function (err, result) { > // result now equals 'done' > }); > > > vs: > > Q.call(step1).then(step2).then(step3).then(step4).then(function (value4) { > // Do something with value4}, function (error) { > // Handle any error from step1 through step4}).end(); > > > Both libraries are doing things in a series, and both are passing their > results to the next function. Is there really any difference between the > two results other than Q returning a promise that you can chain to with > .then? > > Is async really just a more versatile q? Or are there reasons to use one > and the other and they could be used together? > > And can you do parallel functions with promises? Or is that not what > they're used for? (And if not, should you use async + q, or is there too > much overlap?) > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http <http://groups.google.com/group/nodejs?hl=en?hl=en> -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
