> PS: I just recently heard about node's past ability to froze stack with promise.wait(). It's sad that this ability was removed just because some guys used it wrong. It's useful and needed feature for right hands.
While I personally wasn't part of the community when that went down I did a lot of research into that era. Node did have a wait() method, but it was naively implemented. No continuations were used; everything was on the same stack. The result was that you could only resolve the last promise that had been yielded. However the straw that broke the camel's back was that Node's HTTP parser was not reentrant; if you froze the stack while in a callback initiated from the HTTP parser the fun would stop. Fibers solves the first problem completely, and leaves the second problem as an exercise for the user (though does make it much harder if not impossible to mess up core modules). On Sun, Apr 15, 2012 at 5:53 AM, Eldar <[email protected]> wrote: > There are many kinds of application domains. One is a system programming. > Node's core and the majority of npm modules belong to such domain. In > system programming whether function performing IO, blocking or not is > important matter. Assuming that any kind of faux blocking enabled let's > consider the following line: > > mkdirp('path/to/something') > > What does it mean? It's sync? It uses faux blocking? If it's so, why it > doesn't allow me to run it in parallel? > > I guess for the reasons above Tim Caswell wrote: > >> Node “promises” had a method called “wait” that would just suspend the >> current stack and return the value after the promise was resolved. This was >> dangerous because libraries were using this technique and it meant that >> *any* function call could potentially cause your code to get suspended and >> have things change out from under you. > > Please correct me if I get it wrong. > > System programming is about solving small concrete tasks with non-changing > requirements and known in advance data flow. May be it's about something > else, but practice shows that it's always possible to organize system code > so that it wouldn't be a hell while sticking with only callbacks, event > emitters and pipes. I personally agree with the following and came to the > same value: > >> Also, despite being the author of half a dozen control flow libraries, I >> never use any of them anymore. I don't like the extra dependency on my >> library or app, and most importantly, I don't like all the inserted frames >> in my stack traces. >> > > Everything above was about system programming. There are other application > domains. Saying business apps. Lets consider the following: > > calculate_taxes(item) > > It doesn't have IO? It has and blocks? It has but doesn't block? The > answer is - who cares? To day it does IO, yesterday it didn't, tomorrow it > will become sync again. The only right way to program in such conditions is > to hide IO completely. Consider the case when all you code consist's just > from functions like calculate_taxes. Is it possible to stick with pure js? > No! > > So "How to avoid callback hell?" The answer is - you should learn to > program. Sometimes it's better to refactor your code while sticking with > pure js, sometimes you should pull extra dependency like fibers. There is > no definite answer and everyone can make a mistake. > > PS: I just recently heard about node's past ability to froze stack with > promise.wait(). It's sad that this ability was removed just because some > guys used it wrong. It's useful and needed feature for right hands. > > > On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote: >> >> I posted a follow-up on my blog: http://bjouhier.wordpress.com/** >> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/<http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/> >> >> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote: >>> >>> I'm trying to write a simple app that preforms a db query when a user >>> connects to a tcp port. >>> >>> I can get the query working if I do everything as callbacks: >>> >>> db.open(... fn() { >>> db.collection(.... fn() { >>> db.query(...... fn() { >>> }); >>> }); >>> }); >>> >>> But as you can see this creates callback hell. >>> >>> What I would like to do is have a class, but being as everything is >>> async it makes it incredibly difficult to ensure all your variables are >>> set. >>> >>> var client; >>> db.connect(connect, fn(){ >>> client = connect; >>> }); >>> client.close(); >>> >>> Will cause an error because client hasn't been set yet. Another thing I >>> thought of doing was chaining it all together: >>> >>> db.connect(connect, fn(){ >>> ... >>> process.nextTick(fn(){ doNext(); }); >>> }); >>> >>> this gets very messy and hard to manage, how can I deal with callback >>> hell? >>> >>> >>> > On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote: >> >> I posted a follow-up on my blog: http://bjouhier.wordpress.com/** >> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/<http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/> >> >> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote: >>> >>> I'm trying to write a simple app that preforms a db query when a user >>> connects to a tcp port. >>> >>> I can get the query working if I do everything as callbacks: >>> >>> db.open(... fn() { >>> db.collection(.... fn() { >>> db.query(...... fn() { >>> }); >>> }); >>> }); >>> >>> But as you can see this creates callback hell. >>> >>> What I would like to do is have a class, but being as everything is >>> async it makes it incredibly difficult to ensure all your variables are >>> set. >>> >>> var client; >>> db.connect(connect, fn(){ >>> client = connect; >>> }); >>> client.close(); >>> >>> Will cause an error because client hasn't been set yet. Another thing I >>> thought of doing was chaining it all together: >>> >>> db.connect(connect, fn(){ >>> ... >>> process.nextTick(fn(){ doNext(); }); >>> }); >>> >>> this gets very messy and hard to manage, how can I deal with callback >>> hell? >>> >>> >>> > On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote: >> >> I posted a follow-up on my blog: http://bjouhier.wordpress.com/** >> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/<http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/> >> >> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote: >>> >>> I'm trying to write a simple app that preforms a db query when a user >>> connects to a tcp port. >>> >>> I can get the query working if I do everything as callbacks: >>> >>> db.open(... fn() { >>> db.collection(.... fn() { >>> db.query(...... fn() { >>> }); >>> }); >>> }); >>> >>> But as you can see this creates callback hell. >>> >>> What I would like to do is have a class, but being as everything is >>> async it makes it incredibly difficult to ensure all your variables are >>> set. >>> >>> var client; >>> db.connect(connect, fn(){ >>> client = connect; >>> }); >>> client.close(); >>> >>> Will cause an error because client hasn't been set yet. Another thing I >>> thought of doing was chaining it all together: >>> >>> db.connect(connect, fn(){ >>> ... >>> process.nextTick(fn(){ doNext(); }); >>> }); >>> >>> this gets very messy and hard to manage, how can I deal with callback >>> hell? >>> >>> >>> > On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote: >> >> I posted a follow-up on my blog: http://bjouhier.wordpress.com/** >> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/<http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/> >> >> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote: >>> >>> I'm trying to write a simple app that preforms a db query when a user >>> connects to a tcp port. >>> >>> I can get the query working if I do everything as callbacks: >>> >>> db.open(... fn() { >>> db.collection(.... fn() { >>> db.query(...... fn() { >>> }); >>> }); >>> }); >>> >>> But as you can see this creates callback hell. >>> >>> What I would like to do is have a class, but being as everything is >>> async it makes it incredibly difficult to ensure all your variables are >>> set. >>> >>> var client; >>> db.connect(connect, fn(){ >>> client = connect; >>> }); >>> client.close(); >>> >>> Will cause an error because client hasn't been set yet. Another thing I >>> thought of doing was chaining it all together: >>> >>> db.connect(connect, fn(){ >>> ... >>> process.nextTick(fn(){ doNext(); }); >>> }); >>> >>> this gets very messy and hard to manage, how can I deal with callback >>> hell? >>> >>> >>> > On Saturday, April 14, 2012 8:30:33 PM UTC+4, Bruno Jouhier wrote: >> >> I posted a follow-up on my blog: http://bjouhier.wordpress.com/** >> 2012/04/14/node-js-awesome-**runtime-and-new-age-**javascript-gospel/<http://bjouhier.wordpress.com/2012/04/14/node-js-awesome-runtime-and-new-age-javascript-gospel/> >> >> On Monday, April 9, 2012 2:42:14 AM UTC+2, Matthew Hazlett wrote: >>> >>> I'm trying to write a simple app that preforms a db query when a user >>> connects to a tcp port. >>> >>> I can get the query working if I do everything as callbacks: >>> >>> db.open(... fn() { >>> db.collection(.... fn() { >>> db.query(...... fn() { >>> }); >>> }); >>> }); >>> >>> But as you can see this creates callback hell. >>> >>> What I would like to do is have a class, but being as everything is >>> async it makes it incredibly difficult to ensure all your variables are >>> set. >>> >>> var client; >>> db.connect(connect, fn(){ >>> client = connect; >>> }); >>> client.close(); >>> >>> Will cause an error because client hasn't been set yet. Another thing I >>> thought of doing was chaining it all together: >>> >>> db.connect(connect, fn(){ >>> ... >>> process.nextTick(fn(){ doNext(); }); >>> }); >>> >>> this gets very messy and hard to manage, how can I deal with callback >>> hell? >>> >>> >>> -- > 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 > -- 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
