81–90 of 117 posts
Earlier quoted context omitted.
What do you mean by 'chaining'? Twisted's Deferreds provide at least a couple of things one might casually describe as 'chaining'.
Instead of: d.then(func1); d.then(func2); You can use: d.then(func1).then(func2);
In my own code, I tend not to use chaining because "methods returning self" is not a common idiom in Python (although tools like jQuery have given it currency in the JS world) and because I haven't yet figured out a way of formatting a multi-line method invocation that doesn't look messy.
It's unfortunate that Node doesn't use actor based coroutines. Most of the code readability issues would go away.
There's a die-hard core of callback proponents (especially in twisted- and lately in node-land) who claim the pure callback-style is more predictable, robust and testable.
This is not my experience. I've been through that with twisted (heavily), some with EventMachine and some with node.js.
The range of use-cases where I'd benefit from that style was extremely narrow.
For most tasks it would turn into a tedium of keeping track of callbacks and errbacks, littering supposedly linear code-paths with a ridiculous number of branches, and constantly working against test-frameworks that well covered the easy 90% but then fell down on the interesting 10% (i.e. verifying the interaction between multiple requests or callback-paths).
I'm sticking to coroutines where possible now (eventlet/concurrence) and remain baffled over the node-crew's resistance against adding meaningful abstractions to the core.
I like javascript a lot (more so with coffee), but I see little benefit in dealing with the spaghetti when that doesn't even give me transparent multi-process or multi-machine scalability.
And to prevent the obligatory: Yes, I know about Step, dnode and the likes. They remain kludges as long as the default style (i.e. the way all libraries and higher level frameworks are written) is callback-bolognese.
Nice article. Be sure to read the comments, as the author links to a library that makes the second example easy to rewrite in a short and elegant way. https://github.com/caolan/async#forEach Also the first example, the cache hitting and missing, could be rewritten with async , too. async.waterfall([ function(callback) { asynchronousCache.get("id:3244", callback); }, function(myThing, callback) { if (myThing == null)…
From a readability standpoint I'll take the "old" version any day:
function getFromDB(foo) {
var result = asynchronousCache.get("id:3244");
if ( null == result ) {
result = asynchronousDB.query("SELECT * from something WHERE id = 3244");
}
return result;
}It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier. To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what…
It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier. To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what…
can Deferred work so fast that it don't call some of callback functions because they were not added yet?
Earlier quoted context omitted.
Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.
The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, b…
If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…
> The reason is, there isn't something like node.js for erlang, and so I set out to fix that. That is not true, see: https://github.com/hookio/hook.io , been in development in Node.js for over two years.