Hi José
Transforming *every* construct of Javascript is exactly what streamline.js
does. Here is a typical piece of code:
function mongoSearch(_, q) {
var t0 = new Date();
var db = new mongodb.Db('tutorial', new mongodb.Server("127.0.0.1", 27017,
{}));
db.open(_);
try {
var coln = db.collection('movies', _);
if (coln.count(_) === 0) coln.insert(MOVIES, _);
var re = new RegExp(".*" + q + ".*");
return coln.find({
$or: [{
title: re
}, {
director: re
}]
}, _).toArray(_).map(function(movie) {
return movie.title + ': ' + movie.director;
}).join('<br/>') + '<br/>completed in ' + (new Date() - t0) + ' ms';;
} finally {
db.close();
}}
It contains 6 asynchrounous calls to the mongodb API: db.open,
db.collection, coln.count, coln.insert, coln.find and toArray mixed with
standard javascript constructs: if, return, chaining (a(_).b()), even
try/finally.
There is a lot of talking with lots of opinions on this topic, but not
enough facts. I think that a bench with a realistic application use case
would bring clarity to the debate.
Bruno
On Tuesday, July 3, 2012 3:13:20 AM UTC+2, José F. Romaniello wrote:
>
> 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 nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
