10 ms·

I actually wrote a promise library for iOS (and didn't release it). The postmortem is here: http://sealedabstract.com/code/broken-promises/ http://sealedabstra

I actually wrote a promise library for iOS (and didn't release it). The postmortem is here: http://sealedabstract.com/code/broken-promises/ http://sealedabstract.com/code/broken-promises/ The tl;dr is that you can run into trouble on the iOS platform if you don't enforce a strict 1:1 chain of cause/effects and are very careful about the timing of adding new links to the chain. This library doesn't appear to do that, and they appear to consider this a feature, and actively push you in that direction. For example, a bullet in the readme is that tasks are "fully composable" and another bullet point discusses adding new tasks to the tree on-demand. These can work on some platforms, but iOS isn't one of them, and so this really reads like someone familiar with JS or .NET trying to add "missing" functionality to iOS without considering why these patterns are not generally used on iOS. Plus, it's trying to achieve API similarity with Android, which is a code smell. So I would really advise against using this library, at the very least use it a in a superficial way that would be easy to tear out later. If you really want to do this promises thing, I would push you toward Reactive Cocoa, which I am also skeptical about but it's been around much longer, seems to have a much more mature API, and I know at least some smart people who've used it successfully.

bklimt 13y ago
I should point out that the Parse iOS SDK has been built on top of this task framework for over a year, and the Facebook iOS SDK has been using it for months. So it has been battle-tested in at least thousands of production apps. Maybe promises aren't appropriate for every single situation, but we certainly haven't noticed anything that makes them particularly tricky in iOS.
davelee 13y ago
It really sucks that this is the top comment. To use the cliche: This is why we can't have nice things. Please consider the following as a more frank replacement tl;dr: "My promises implementation didn't work out for me. Maybe I just didn't go about it the best way, but judge for yourself by reading about my individual experiences, references from 70's papers, a bunch of 'what ifs', no code, no benchmarks, no constructive alternatives, and repeated use of 'we' instead of correctly using 'I'." Is the above unfair? Maybe somewhat, but if so only as unfair as your representation. I enjoyed your GC article, but any good points to take from "Broken Promises" (or your above comment) are impossible to see through the thickness of pejoratives.
- drewcrawford 13y ago
  This probably isn't the right place to discuss the article, but I don't think your summary is either accurate or applicable. For example, the article does include code, it does provide constructive alternatives, it goes well beyond my experience by outlining a general proof for why the problem I was working on is theoretically intractable, it was hacked on by multiple people (hence "we"), and so on. Even if that list of criticisms were accurate, the correct response to an article that has "no code, no benchmarks, no constructive alternatives" is to respond with code, benchmarks, and constructive alternatives. What you do here is essentially say "Because this does not meet some threshold of evidence I can ignore it" instead of what rational people say, "I should collect better evidence but in the meantime let's rely on the evidence that is available". Finally, you don't really state an articulable position on the actual issue, so the discussion does not really advance. My position is pretty clear: promises work on the platform if and only if there are particular guarantees, and the README of this project explicitly says you don't get those guarantees, ergo this library is trouble. Clearly you object to this position but you do not say, let alone defend, any alternative theory that would have predictive power over whether or not promises will work for a project and for that reason, the comment does not add anything to the discussion.
  - davelee 13y ago
    > This probably isn't the right place to discuss the article yeah, you're probably right.

bklimt 13y ago

I should point out that the Parse iOS SDK has been built on top of this task framework for over a year, and the Facebook iOS SDK has been using it for months. So it has been battle-tested in at least thousands of production apps. Maybe promises aren't appropriate for every single situation, but we certainly haven't noticed anything that makes them particularly tricky in iOS.

davelee 13y ago

It really sucks that this is the top comment. To use the cliche: This is why we can't have nice things. Please consider the following as a more frank replacement tl;dr: "My promises implementation didn't work out for me. Maybe I just didn't go about it the best way, but judge for yourself by reading about my individual experiences, references from 70's papers, a bunch of 'what ifs', no code, no benchmarks, no constructive alternatives, and repeated use of 'we' instead of correctly using 'I'." Is the above unfair? Maybe somewhat, but if so only as unfair as your representation. I enjoyed your GC article, but any good points to take from "Broken Promises" (or your above comment) are impossible to see through the thickness of pejoratives.

drewcrawford 13y ago
This probably isn't the right place to discuss the article, but I don't think your summary is either accurate or applicable. For example, the article does include code, it does provide constructive alternatives, it goes well beyond my experience by outlining a general proof for why the problem I was working on is theoretically intractable, it was hacked on by multiple people (hence "we"), and so on. Even if that list of criticisms were accurate, the correct response to an article that has "no code, no benchmarks, no constructive alternatives" is to respond with code, benchmarks, and constructive alternatives. What you do here is essentially say "Because this does not meet some threshold of evidence I can ignore it" instead of what rational people say, "I should collect better evidence but in the meantime let's rely on the evidence that is available". Finally, you don't really state an articulable position on the actual issue, so the discussion does not really advance. My position is pretty clear: promises work on the platform if and only if there are particular guarantees, and the README of this project explicitly says you don't get those guarantees, ergo this library is trouble. Clearly you object to this position but you do not say, let alone defend, any alternative theory that would have predictive power over whether or not promises will work for a project and for that reason, the comment does not add anything to the discussion.
- davelee 13y ago
  > This probably isn't the right place to discuss the article yeah, you're probably right.