It is hard for me to fathom the negative feelings towards Promises. They are quite clearly a great way to perform async programming in a civilized way (see Twitter's Future/Promise in Finagle on github). JDK 8 will even have the equivalent in CompletableFuture. The only thing better is to combine Promises with coroutines for a more linear programming style like in Flow: http://www.foundationdb.com/white-papers/flow/
Callbacks are imperative, promises are functional
71–80 of 154 posts
Re: Callbacks are imperative, promises are functional
#72Ryan Dahl in February 2010, when Promises were removed from core:
Because many people (myself included) only want a low-level interface
to file system operations that does not necessitate creating an
object, while many other people want something like promises but
different in one way or another. So instead of promises we'll use last
argument callbacks and consign the task of building better abstraction
layers to user libraries.
Re: Callbacks are imperative, promises are functional
#73Promises are just tools for managing a list of callbacks with less boilerplate. I wouldn't call one imperative and the other functional. Both are functional. You might dislike callback patterns, but through one of the beautiful parts of JS, you can trivially wrap any callback-oriented API you want and have it become a promise based one. I've done this before when I had a very complex dependency graph at the start of a program and a few API calls were callback related. It looks something like this:
SomeClass.prototype.someActionPromise = function(){
var deferred = makeADeferred();
SomeClass.prototype.someAction.call(this, function(err){
err ? deferred.reject() : deferred.resolve();
});
return deferred.promise();
};
Re: Callbacks are imperative, promises are functional
#74I don't agree that there is any fundamental difference in functionality between callbacks and promises.
Promises don't somehow magically make asynchronous code easy to write while leaving callbacks out in the cold. They have very similar strengths and weaknesses and I didn't find any of the OP's arguments compelling.
In fact, if I had to choose, I would take the opposite view and say callbacks are neater, cleaner and more consistent than promises.
Re: Callbacks are imperative, promises are functional
#75It is hard for me to fathom the negative feelings towards Promises. They are quite clearly a great way to perform async programming in a civilized way (see Twitter's Future/Promise in Finagle on github). JDK 8 will even have the equivalent in CompletableFuture. The only thing better is to combine Promises with coroutines for a more linear programming style like in Flow: http://www.foundationdb.com/white-papers/flow/
if you want this on the JVM today and can abide Scala, see: http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html
Re: Callbacks are imperative, promises are functional
#76Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing. If I wanted to compute the size of one file relative to a set, I’d probably do something like this: queue() .defer(fs.stat, "file1.txt") .defer(fs.stat, "file2.txt") .defer(fs.stat, "file3.txt") .awaitAll(functi…
do f1 do fs Re: Callbacks are imperative, promises are functional
#77Promises are just tools for managing a list of callbacks with less boilerplate. I wouldn't call one imperative and the other functional. Both are functional. You might dislike callback patterns, but through one of the beautiful parts of JS, you can trivially wrap any callback-oriented API you want and have it become a promise based one. I've done this before when I had a very complex dependency graph at the start of…
The author "promisify"s a callback-based API in the article - which is worth a read by the way.
I'm interested in your opinion RE: his argument for why callback APIs are imperative - because I think he has a very good point and has supported it with a solid argument and you haven't offered any rebuttal.
Re: Callbacks are imperative, promises are functional
#78So, calling magic subroutines is more functional than passing about first class functions?
Functional programming is not just about first class functions and I disagree with the idea that using first class functions means you are doing "functional programming".
See the second paragraph of the article for the authors take on this. Specifically, the concept of values is very important.
Re: Callbacks are imperative, promises are functional
#79This is an interesting perspective. But to me, even having spent a year on a large node.js project, I just don't see how promises would have simplified things at all. If you have some crazy graph of dependencies, I can see how breaking out promises could help simplify things. But I don't feel like that's a super-common scenario. The author says: > * [Promises] are easier to think about precisely because we’ve delegat…
The point is promises free you from wanting or needing to know about the order that things happen in. I hear you saying you fear promises, because it means it would get in the way of your ability to know that. But the truth is once you embrace them, that need becomes unimportant. The idea that webservers are "all about side effects" gives me a chill. The whole architecture concept of HTTP is no side effects , so to c…
> The point is promises free you from wanting or
> needing to know about the order that things happen in
> ... But the truth is once you embrace them,
> that need becomes unimportant
This smells like the classic leaky abstraction though. Like when people tried to paper over the difference between remote calls and local calls with abstract interfaces (CORBA, RMI, etc.). Everyone would say it was so awesome, remote calls look the same as local calls! But it wasn't awesome, it was horrible, because the details of the abstraction 'leaked' through and you got all kinds of problems from having delegated away what was actually one of the most critical, sensitive parts of your code to a layer you had no control over. 15 years later we're back to nearly everybody using REST because it turns out to be way better not to shove those abstractions on top of your most important code.
Now, I'm not saying that analogy is perfect here ... but it does remind me of it. Why should you care about the order of things? Just to suggest something, sometimes it's just useful to be able to reason about it. "We know the first operation definitely happened before the others, so an earlier one failing can't be a side effect of something a later one did ... oops, we don't know that any more. We actually have no idea what order they happened in."
Re: Callbacks are imperative, promises are functional
#80Promises seem cool but if you are not liking callbacks very much you should take a look at just using CoffeeScript indenting two spaces, specifying functions instead of inline, he async module, icedcoffeescript with await and defer, and Livescript with backcalls. All of that is more useful and straightforward than promises.