Not that it's terribly relevant but a clever reader may notice that a Promise is a monad that encapsulates and stands in place of some to-be-done operation.
The .then() method is this monad's bind operator. It allows you to chain a Promise through functions that do not have to know or care about how to accept promises as arguments.
Hopefully this might help Javascript programmers who are curious about the relevance of these esoteric functional programming ideas. They are in your language too! (just with less frightening names)
Oh, yes, of-course, now it makes it perfectly clear!
Reading HN sometimes make me wonder how I'm still getting paid for writing code / managing others that do so. Was software reinvented in the past few years while I was sleeping? Is functional programming taking over the world? Is understanding things like Monads and Promises now a must have for anyone calling themselves a programmer / developer / software engineer / hacker?
People are simply giving names for useful patterns that you can use to solve certain classes of problems. You can still write great code without using them and you can even use them without knowing what they are called.
Giving names to these ideas just makes it easier to communicate common concepts to yourself and others. (imagine how hard it would be if you didn't know the terms "binary tree" or "MAC address").
The existence of these concepts is not an affront to your existing knowledge. Learn them only if you think it helps you.
The point of the article is that Promises should not be just the name of a general pattern or idea for a common concept, but adhere to a very specific definition. Monads as far as I know are already that, not a pattern but a very specific type of construct.
That's one of the reasons I hate the reality of design patterns in modern software: they start off as useful vocabulary, then some specific variants of the pattern hijack the name, and soon it's impossible to communicate clearly as nobody knows which variants have which names and meanings, and vocabulary starts to diverge wildly (see also: MV* patterns).
The worst example of that phenomenon is Singleton, which everyone believes is about a static factory method that returns the instance. In fact, that was only an EXAMPLE given in the GoF book for a mechanism to get the singleton instance...
> Was software reinvented in the past few years while I was sleeping?
> Is functional programming taking over the world?
Yes and yes, and it's awesome! :) Previously functional programming was mostly an academic pursuit but in the last decade it has definitely entered the mainstream. Once you understand FP, you become a much more skilled programmer and can make more efficient solutions even in languages not designed for FP like C.
> Is understanding things like Monads and Promises now a must have
> for anyone calling themselves a programmer / developer / software engineer / hacker?
I don't understanding it per se is the water branching point. Instead the difference between an "office drone engineer" and a hacker is a natural curiosity and interest in learning new things. An office drone will say "damn! now i have to learn this NEW thing, argh." A hacker will instead enjoy it and have a very fun time learning about monads.
I love learning new things, but only if they serve a purpose, "back in the days" the "new things" were ground braking technologies like XHTML, Adobe Flex / MS Silverlight / JavaFX. Thank God I was an "office drone" back then and skipped it. (I don't have the time to waste, I have 2 small kids and I rather spend time with then then learning things for fun, no matter how fun it is)
And when I learn something new, it's rarely a new language construct, I rather create something new, or learn a new technology, not a design pattern. (e.g. can't wait to find some spare time for Meteor 0.5 experimentation. I wonder if I can write a TypeScript interface for it)
So call me an office drone, but if Promises are syntactic sugar, I rather have my coffee unsweetened.
I don't know if I agree that learning technologies that does not prove to be commercially viable are a waste of time. You can learn a lot from a topic even if it is not directly related to your income. Machine learning is a hobby of mine, which I, sadly, haven't had the chance to work with professionally. But by learning about it, I think my mind has sharpened and I think I now have a much better grasp of linear algebra which is related to my work.
Similar experiences can probably be derived by learning about JavaFX, like understanding its pretty smart canvas api. Silverlight has, I don't know, state of the art drm technology for video streaming?
The point is that learning is almost always a good investment that pays off. If you love what you are learning about, then the investment becomes much smaller and the payoff almost immediate.
In general, I get excited about learning new things. Regarding monads, I've made several efforts to grasp them over the course of multiple years now. I no longer get excited about trying to understand them. I'm currently taking Odersky's functional programming class at Coursera, and that has been coming naturally to me. But monads seem to inhabit a magical space which my mind cannot enter.
No, it clearly isn't. A Future, from Java 5's concurrency libs is close, but it doesn't offer the chaining construction -- it only offers get. The most similar-looking code commonly used in Java is probably people who use Option (or Maybe for those who stole from Haskell instead) with a .transform.
I don't think there's as much a need for it in Java because I'm less likely to want to write defensive code in that way outside of the browser.
It looks like Play supplies F.Promise, which provides the same functionality with a different API. I do like the simplicity of the API in the JS promises. The something.transform(good, bad, progress) is very easy to understand from the start.
I've never thought of the two mentioned monads (Promise and Option) as defensive. Option doesn't seem defensive because sometimes you need to represent the possibility that there is no value to be returned.
In this vein, it's also worth looking at Microsoft's "Reactive Extensions" (which have a JS implementation, too.) It's a similarly monadic approach to asynchrony, but deals in "observables" which produce zero or more events, compared to promises which produce only one.
(Edit: corrected "one or more" to "zero or more".)
Not exactly, unless the fulfilledHandler returns a promise. The examples didn't seem to have that requirement.
If fulfilledHandler is a regular function, then then() is just Functor's fmap.
If fulfilledHandler is allowed to be either variant, then you can imagine then() as applying an implicit return when needed, which makes the types a bit less clear
I've been writing a fair amount of AngularjS code recently and have been dealing with this issue. Angular has a $q service [1] for deferred actions, which is a cutdown version of the Q library [2]. I like it a lot.
The nice thing about Angular is that the use of promises is pervasive (eg the $http service) and Angular understands them so:
$scope.projects = $http.get('/projects');
and a template of:
<ul>
<li ng-repeat="project in projects">
{{ project }}
</li>
</ul>
I promise that when I will understand this, I'll call back.
But seriously, can someone please translate this to English? and this comes from someone that writes JavaScript for 12 years (and have read the first 3 chapters of "JavaScript the good parts") I just couldn't keep up with the article and ended adding it to pocket, (formerly read it later) which we all know that it means I'll never read it again.
Is there a good article that will make all this suddenly clear to me? What was so wrong with callbacks?
They're supposed to make things nicer. Syntactic sugar.
Personally, I don't really see them helping in most cases. They have just as much code and generally rearrange it into a form that I find less readable. For his first example, he provides the callback function (which is actually empty, but whatever) but the promise version doesn't show the function. If it did, it'd be just as verbose and hard to read, if not moreso.
Now, that changes a bit with the .then syntax later. With callbacks, you'd end up with a series of nested callbacks, which can get just as ugly as a series of nested if statements. The .then syntax lets you chain it all together in a more visually pleasing way, and I think it's easier to read, too.
In short, the way promises are often done is wrong (and he's saying so) and there's a proper way to do it. Unfortunately, a lot of frameworks are missing that feature, and so they're just screwed up.
This article made it click for me. I had read several others that went over my head.
The point of promises, as explained in this article, is to mirror the error handling semantics of synchronous code with minimal boilerplate.
In code based on callbacks, if an error occurs somewhere, you must either deal with it locally or pass it along the callback chain manually. Promises mimic the try/catch system.
Here's a variation based on the first example in the WhenJS documentation[0]. It demonstrates the basic control flow, we'll see later why it makes error handling easier:
function loadImage (src) {
var deferred = when.defer(),
img = document.createElement('img');
img.onload = function () {
deferred.resolve(img);
};
img.onerror = function () {
deferred.reject(new Error('Image not found: ' + src));
};
img.src = src;
// Return only the promise, so that the caller cannot
// resolve, reject, or otherwise muck with the original deferred.
return deferred.promise;
}
// example usage:
loadImage('http://google.com/favicon.ico').then(
function gotIt(img) {
document.body.appendChild(img);
return aSecondPromise;
},
function doh(err) {
document.body.appendChild(document.createTextNode(err));
}
).then(function(/*resolved value of the second promise*/){...});
First, lets focus on the `loadImage()` function, which wraps an async image load into a promise object.
It first creates a deferred object wich has two methods and one property:
* `defered.promise` is an objet with a `then` method that takes two optional handlers (success,error), which returns another promise. This allows chaining (more on that later).
* `defered.resolve(result)` resolves the corresponding promise: it takes one parameter and passes it to the success handler.
* `reject(error)` has similar behaviour but for the error handler.
These two methods are mutually exclusive. If you call one, you can't call the other.
As you can see, `loadImage()` defines two event handlers for the img object, that will either resolve or reject the promise. It schedules the async event, then returns the promise object. The `then` method of the latter registers two handlers one of which will kick in when the async call resolves the promise.
--
There's no point in using promises for trivial code like this.
Their usefulness comes from subtleties in the way the `then()` methods propagate the successes and errors when they are chained.
Success and error handlers are optional. If at a given step a success/error should have been triggered but isn't, the value is passed to the next one of the same kind in the then chain.
Let's take the example in this article:
getTweetsFor("domenic") // promise-returning async function
.then(function (tweets) {
var shortUrls = parseTweetsForUrls(tweets);
var mostRecentShortUrl = shortUrls[0];
return expandUrlUsingTwitterApi(mostRecentShortUrl); // promise-returning async function
})
.then(doHttpRequest) // promise-returning async function
.then(
function (responseBody) {
console.log("Most recent link text:", responseBody);
},
function (error) {
console.error("Error with the twitterverse:", error);
}
);
At each step, the promise can be resolved or rejected. If it is resolved, its result is passed to the next success handler. If if is rejected at any step, the following OK steps are skipped, and the error ends up being handled by the error handler defined in the last then clause. It is thus equivalent to this synchronous code:
try {
var tweets = getTweetsFor("domenic"); // blocking
var shortUrls = parseTweetsForUrls(tweets);
var mostRecentShortUrl = shortUrls[0];
var responseBody = doHttpRequest(expandUrlUsingTwitterApi(mostRecentShortUrl)); // blocking x 2
console.log("Most recent link text:", responseBody);
} catch (error) {
console.error("Error with the twitterverse: ", error);
}
Imagine how messy it would be to propagate the errors in standard callback-based code...
loadImage() returns a first promise and its `then1()` method registers the handlers and returns a promise, whose state will depend on the behaviour of the handlers once one of them is triggered. If the handler (either successH or errorH) returns a value, the promise will pass that value to the next success handler. If the handler throws an exception, the value thrown will be passed to the next error handler, and so on.
2. Promise fulfilled, fulfillment handler throws an exception: getting data, and throwing an exception in response to it
3. Promise rejected, rejection handler returns a value: a catch clause got the error and handled it
4. Promise rejected, rejection handler throws an exception: a catch clause got the error and re-threw it (or a new one)
At last, a handler can return a new promise. In that case, the handler that is called next will depend on whether that promise is resolved or rejected.
--
Sigh... I'm done. I hope I didn't make things more confusing.
Glad I could help. This post was mostly a stream of thoughts, and it contains errors and approximations. I'm preparing a real article on the topic. Hopefully ready in a few days.
The general case of a Future/Promise is that you can design a nicer (sometimes) API. Instead of forcing the caller to provide their own callback functions immediately when they call your function, you can return a Future instead and the client can ask for the data on that whenever. e.g.:
function read_key(key, cb) {
database.getItem(domain, key, cb);
}
..
read_key(key, function(err, res) { ... });
VS.
function read_key(key) {
var future = Future();
database.getItem(domain, key, future.fulfill);
return future;
}
...
var reader = read_key(key);
...
reader.when(function(err, res) { .. } );
As others have noted, you can make a generalization into Sequences that eliminates nested-callback-hell. In Node especially there are a lot of asynchronous calls (and especially especially if you are managing outside data) so they come in handy. I like this library: https://github.com/coolaj86/futures Instead of sequence-members having to return promises themselves, though, they can just call the next() function or not. As an example, you might define your program to do this:
var obj; // shared data
var seq = Futures.sequence();
seq.then(function(next) { ...dosetupstuff... next(obj); })
.then(fetchMetadataFromDB)
.then(validateFile)
.then(createFileInDB)
.then(copyToOtherDB);
And you might go on. Each function relies on the previous function having completed successfully and calling next(), otherwise the sequence is broken. You can more easily create standardized error handling mechanisms as well. Of course if all your functions are synchronous this doesn't really matter, but getting at an external DB might look something like this:
You could used named functions but that means a given named function must know the name of its successive named function, and that can make your program hard to follow and change. With the sequence approach, you have the whole sequential structure laid out at the top and can inspect functions themselves if you want to, and if a new async part enters the flow you can just insert it in the sequence. With a non-sequence named function approach, you have to jump around all the functions to get a sense of the sequence, and if a new async part enters the flow you have to change the function before to call the new function. You could define all your functions inline, which helps keep the order of execution straight and easy to follow, but adding a new async operation means adding a new level of indentation, so it's called nested-callback-hell.
It's very similar to the "Promises/A" system described in the article, except that it has different method names (instead of .then(), it has the more prosaic .addCallback() and .addErrback()), and you generally have only one of them (instead of the callback-adding function returning a new, fresh, clean instance). Deferreds have the same ideal of composability, and the same mapping to 'try/except' statements in synchronous code.
However, there's one particularly handy thing Deferreds do that I don't see described in the article: when "fulfilledHandler" gets called, it can return a value which gets passed to the next callback in the chain, _or it can return a Deferred_, in which case the callback chain pauses until the new Deferred fires and produces a value, at which point the original Deferred picks up and carries on.
This comes in very handy for things like this:
def getReservedBooksForUser(username):
# Look up the auth token for the library service in the DB
authTokenDeferred = db.runQuery("""
SELECT authToken
FROM users
WHERE username = ?
""", (username,))
# We know the DB result can only have one row and one column.
authTokenDeferred.addCallback(lambda resultset: resultset[0][0])
# When we have the auth token, use it when querying the library
# service.
authTokenDeferred.addCallback(
lambda authToken: web.getPage(
"http://library/books?authToken=%s&user=%s&format=JSON"
% (authToken, request["username"])
)
)
# Extract the list of books from the returned document.
authTokenDeferred.addCallback(
lambda page: json.loads(page)['books']
)
return authTokenDeferred
Note that the second callback (the web.getPage() one) is immediately called with the results of the first callback (the resultset-unpacking one), because the first callback returned an ordinary value.
However, the third callback (the JSON-unpacking one) is not called with the Deferred returned by the second callback - instead, the callback chain is paused while we wait for the second callback's Deferred to fire, then that result is passed to the third callback.
Is this kind of thing supported by JS Promises, too?
Unfortunately Promises/A omits this, so I didn't address it directly, although I did sneak it into the example code with the `return expandUrlUsingTwitterApi(mostRecentShortUrl);` line.
I've been using the 'async' lib in Node.js (I switched from 'step' lib) and I find the Promises' .then() method chaining and exception throwing really similar to async:
async.waterfall({
'step1':function(next) { next(null,1); },
'step2':function(num,next) { next(null,num,2); },
'step3':function(num1,num2,next) {next(null,num1+num2);}
},
function result(err,num) {
if (err)
console.error(err);
else
console.log("the number is:",num); //output: the number is: 3
});
If any exceptions get thrown, the chain is interrupted and the last function gets called with some err. That's just the 'waterfall' style. There are lots of other methods that make the callback hell very manageable. In fact, I don't know why I would use Promises over what async provides. Can anyone provide a reason to, aside from _some_ syntax sugar?
I have not dived into async, so it may have the ability to handle the following and I just don't know it. But here are the things I think it's missing:
- Interception of not only errors explicitly passed up to the callback, but also thrown exceptions (see the paragraph containing "we take care of both intentional and unintentional exceptions")
- Per-task error interception, translation, and re-throwing
- Guarantees like "never both fulfilled and rejected" or "the state never transitions once it's fulfilled or rejected" or "only at most one handler is called, at most one time". For example real bugs in popular libraries have stemmed from calling callbacks with both an error and a result, or calling them twice (with different parameters each time). A speaker at HuJS gave an example of this in one of TJ Hollowaychuk's libraries.
First and third are definitely true for async. I'm not sure about the second, but it looks like something one would achieve with a try/catch block inside a task.
It's lovely how Promises appear to be, in design, virtually equal to Tasks in the .NET library. This should make them very easy for C# programmers to understand.
`then()` is called `ContinueWith()`. .NET Tasks unfortunately lack the progress callback. In turn, JS Promises appear to lack the ability to cancel a running operation. Otherwise, they're nearly exactly the same.
I'd take this stuff over callback-passing anytime. I hope it becomes commonplace.
Yes, very true! In fact, many of the the Windows Runtime APIs are async. They get projected identically into C# with `Task` as they do into JavaScript with WinJS promises.
On cancellation, this is actually a feature of several promise libraries. When.js has it, as do WinJS promises (so those cancellable Windows Runtime APIs project just as well into JavaScript). We are hoping to add the feature to Q, but we haven't figured out the exact semantics yet, especially with regards to some of the object-capability security requirements Q attempts to address.
Of course, C# 5 has a huge advantage in their `await` and `async` keywords. But fear not! Shallow coroutines with `yield` are coming in ECMAScript 6 (the next version of JavaScript), and you can build very similar support on top of promises:
If we are on the subject of promises, Javascript is a poor language to learn about such things, no wonder developers understand the concept poorly.
The thing to understand about a promise is that monadic operations apply, which makes these instances composable and in Scala at least you can do all kinds of crazy things, like picking the first result that succeeded out of a list of promises, or filter/map over such promises, operations which are also async, producing other future results, or merging a bunch of future results and passing the merged-result to another unit of computation that executes in parallel and so on.
Note that in Scala, promises are actually named "Future", while a Promise is a Future that you build (and complete) yourself (or put it another way, a Future is an object from which you read, many times, while a Promise is an object to which you write once). A Promise implements the Future interface.
And because Scala provides syntactic sugar for monadic operations, you can write your code like this ...
val googleResult = queryGoogleMaps(lat, lon)
val bingResult = queryBingMaps(lat, lon)
val yahooResult = queryYahooMaps(lat, lon)
val bestLocation = for {
location1 <- googleResult
location2 <- bingResult
location3 <- yahooResult
} yield compareAndPickBestResult(location1, location2, location3)
Notice how this code could be completely synchronous, and yet if those functions I used return some Future[Result], then it still works as intended, with "bestLocation" being another Future result, so if you need it right now, you'll have to wait for it ...
That's actually a pity, because monads are easy to understand, being just like a normal design pattern ... name your favorite one and it's probably harder to understand than monads, because monads are actually well defined.
I was also giving Scala as a better language to experiment with such things, because the funny thing about Scala is that monads are more composable in comparison to Haskell or other functional languages.
I've spent more time trying to understand monads than all the named design patterns put together. And I don't have a favorite design pattern, just a vague skepticism for the lot of them, and a strong skepticism for anyone who promotes them.
Anyway, being well-defined is not a sufficient condition for being easy to understand.
It's also worth looking at Dojo's Deferred, which is what jQuery copied for its promises (and Dojo's itself copied the idea from Twisted). jQuery's implementation is broken and spread out over several releases though.
This article comes at a good time for me - was wondering how exactly I was supposed to be using the Promises in WinJS (which are woefully undocumented in terms of actual usage, as are, well, all things WinJS/Metro, unfortunately).
Yes and no. You can have stream-like functionality (piping the response of one promise to another), but that's not what promises are all about.
A promise at its core represents a result that will be available in the future. The other thing you have to understand is that an instance of a promise supports monadic operations (i.e. filter, map, flatMap, depending on the implementation of course, but without these monadic operations any implementation is useless).
What does this mean actually? It means that these promises are composable. Piping is only one usecase, however you can compose them in any way you want.
For instance, you can do something like ... execute tasks A, B and C in parallel and from whichever one finishes first, from its result start tasks D1, D2 ... Dn in parallel, drop whichever of the tasks timeouts or throws an exception, then merge the results of the tasks that succeeded and pass it to task E, which will produce a final response.
The author mentions jQuery's broken promises implementation and how it prevents the excellent chaining feature. I definitely see how jQuery's implementation differs from the Promises/A spec. However, doesn't .pipe() in jQuery basically allow for the same chainability as .then() from Promises/A? Is there a difference I'm not aware of?
I think the main point there was that unless you check 'promises' given to you from other APIs and applications you can't rely on them conforming to the spec.
As authors of Promises/A-consuming libraries, we would like to assume ... that something that is "thenable" actually behaves as a Promises/A promise, with all the power that entails.
If you can make this assumption, you can write very extensive libraries that are entirely agnostic to the implementation of the promises they accept! Whether they be from Q, when.js, or even WinJS, you can use the simple composition rules of the Promises/A spec to build on promise behavior...
Unfortunately, libraries like jQuery break this. This necessitates ugly hacks to detect the presence of objects masquerading as promises, and who call themselves in their API documentation promises, but aren't really Promises/A promises. If the consumers of your API start trying to pass you jQuery promises, you have two choices: fail in mysterious and hard-to-decipher ways when your compositional techniques fail, or fail up-front and block them from using your library entirely. This sucks.
No, jQuery's `pipe` (or their `then` in >= 1.8) still does not do error handling. I updated the article a couple days ago to address this directly:
---
This breaks down into four scenarios, depending on the state of the promise. Here we give their synchronous parallels so you can see why it's crucially important to have semantics for all four:
- Fulfilled, fulfillment handler returns a value: simple functional transformation
- Fulfilled, fulfillment handler throws an exception: getting data, and throwing an exception in response to it
- Rejected, rejection handler returns a value: a catch clause got the error and handled it
- Rejected, rejection handler throws an exception: a catch clause got the error and re-threw it (or a new one)
Without these transformations being applied, you lose all the power of the synchronous/asynchronous parallel, and your so-called "promises" become simple callback aggregators. This is the problem with jQuery's current "promises": they only support scenario 1 above, omitting entirely support for scenarios 2–4.
---
So you get chaining, sure; you can flatten your callback trees into callback lists. That's cool, I guess. But they're still missing the point, which is to allow composability not only of always-successful functions, but of functions that sometimes fail as well.
> This is the problem with jQuery's current "promises": they only support scenario 1 above, omitting entirely support for scenarios 2–4.
Actually, `pipe` kind-of handles case 3 as well: if a promise is returned from either `pipe` handler it's used as replacement for the `pipe`'s resolution (a value merely replaces the existing resolution or rejection value), so
promise.pipe(null, function () {
return $.when(42);
});
will replace a rejection of `promise` by a resolution to 42.
Also, there's a mistake with the text I believe:
> That means if you give a promise out to multiple consumers, they can interfere with its state.
No, if you give a deferred to consumers they can alter it but the result of `.promise()` doesn't provide mutator methods, only state change callbacks. Promise producers are supposed to return the result of `.promise()`, returning a non-rejected and non-resolved Deferred directly is an error. And while — as you note — Deferred#then doesn't behave per-spec, Deferred.pipe does create and return a new promise.
(jQuery's deferreds have other issues which your post hasn't touched, such as the very special handling of single-value resolutions.
The .then() method is this monad's bind operator. It allows you to chain a Promise through functions that do not have to know or care about how to accept promises as arguments.
Hopefully this might help Javascript programmers who are curious about the relevance of these esoteric functional programming ideas. They are in your language too! (just with less frightening names)