Uh, i don't say, fork and prevent. we're talking about adapting language feature into core code, right? never said, node should do that. i said, don't addapt anything, if it doesnt make node better than before.
Am Dienstag, 6. August 2013 16:58:21 UTC+2 schrieb Rick Waldron: > > > > > On Tue, Aug 6, 2013 at 5:35 AM, greelgorke <[email protected]<javascript:> > > wrote: > >> Few points in my opinon: >> >> 1. Callbacks are not un-intuitive. We do it all the way in our life. i >> mean besides the programming. >> 2. Callbacks are not hard to compose. they are functions, do them right, >> nothing stops you to compose, currie or memoing anything. >> >> One just have to make a little switch in his/her mind. I find it >> surprising, that many of us are willing to make a bigger switch to more >> abstract concepts, just to be back in old sync-imperative world... And it >> doesn't even save you from this so annoying task to think about your >> architecture... >> >> Besides of the callbacks, i think its hard to reason about if node should >> keep with v8 and adapt es6 features until we have real field experience >> with them. >> > > Node.js (the core) isn't obligated to immediately use ES6 features, but > forking v8 to prevent the use of new language features will only result in > Node.js stagnation and ultimately, abandonment. I think it's safe to say > that won't happen. > > Rick > > > > >> Node is supposed to be done and be crazy fast. so i'm with Trevor here. >> > >> Am Dienstag, 6. August 2013 10:38:22 UTC+2 schrieb Trevor Norris: >> >>> I'd like a clarifying point. By callback system I'll assume that means >>> the EventEmitter modal. >>> >>> > But the concept of abstracting the callbacks away using a more >>> composable and more natural way is definitely a good thing, at least in my >>> opinion. The callbacks are a implementation detail of asynchronous io but >>> low-level stuff is not what a normal developer should rely on. >>> >>> Getting to the point of calling the callback has gone through so many >>> layers of abstraction I'd hardly call it low-level. >>> >>> > Nodes key feature is that it strongly encourages thinking about >>> concurrency but the best concurrency abstraction is the abstraction which >>> abstracts concurrency totally away. All I'm saying is that the node library >>> could evolve when the language does. >>> >>> As far as I'm concerned most the new "features" coming to JS are sugar. >>> The event based callback system is straight forward and cheap. Well, it >>> _can_ be cheap. Also easily extendable. I don't buy the argument it's >>> unnatural or difficult to reason. It's simple to define. The end of an >>> asynchronous task is an event. Then, if there's a listening callback it >>> gets fired. >>> >>> There are many ways to handle this, and unfortunately it seems there's >>> inconsistency. Do we just have one callback that we always call and pass >>> the status, or do we listen for several events and only fire for those that >>> have listeners? It's all implementation details, but adding an extra layer >>> of keywords and control flow isn't going to remove the fundamental problem. >>> That's easy enough to see in this thread. Even to the point of discussion >>> variable naming conventions to remove confusion. Seriously? >>> >>> I used to be on the band wagon of "let's chain all the things!" Then I >>> began to see how all the map() and forEach() in the world just makes things >>> run slow. It's all just syntactic sugar that for some reason makes >>> developers feel fuzzy. And it encourages bad patterns like writing >>> functions in functions. Can it be done? Yes, but if you ever take the time >>> to trace execution you'll see it has to reoptimize that code every time. >>> >>> And at the very least, until those "features" work without introducing >>> performance penalties I can't see them being integrated into core. >>> >>> -- >> -- >> 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
