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 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] 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.
