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.


Reply via email to