What's The Point Of Promises?

&#62; since I don't throw errors very often<p>I call shenanigans. Maybe you don't <i>intentionally</i> throw exceptions very often, but that's hardly the point of exceptions.<p>Javascript is an interpreted language. <i>Everything</i> is an exception. Do you ever fat-finger a function name during development? That's an exception. Ever accidentally try to use "this" when it's pointing at "window"? Exception.<p>Those simple, natural mistakes can be lurking anywhere. They're far easier to detect and correct when the failure is propagated backward correctly to the right callers.

For a more in-depth example of the way that Promises/Futures should work, check out the implementations in Scala or Haskell. The concept of a delayed computation is actually nothing new - the idea has been around for quite some time. I'm actually a little surprised that it's just becoming popular in the Javascript world. From what little experience I've had with reading and writing javascript code, it seems like you are forced by the language into heavy usage of callbacks/continuations. Promises are really the only way to elegantly manage and reason about heavily async code.

Can someone correct me if I am wrong. But why do I feel like promises are basically just semaphores in disguise?<p>I'm a big fan of semaphores, that being said I am aware of how many people shoot themselves in the foot. It requires discipline.<p>Have a couple of asynchronous operation queued behind each other?<p>Setup a semaphore before each one. Signal when previous operation is done.<p>Could have different semaphores for fail and success operation even.

Unfortunately, due to JavaScript's single-threaded nature, you don't get what I consider to be the most useful part of Futures on other languages: ability to block on async calls while work happens in a different thread. In JS, if an async operation rears its ugly head into your synchronous code, you're still in for some rewriting.

I adore promises, as they make some very complex situations a lot easier to develop for.<p>They also make me even less likely to use any code that makes use of node-fibers (such as MeteorJS).

Promises and Deferreds are anti-patterns, in my book. They pollute the call stack and explicitly introduce uncertainty. Why would you want to code against an object representing a thing that may or or may not be complete? Good software strives for determinism. Passing around "maybes" is the opposite of that.<p>Promises are a poor solution for people not willing to properly model their tasks.<p>A far better way is to actually think about what you are trying to achieve and stick with a simple sequential control flow, rather than using some sort of overwrought API hammer to bash nails into your codebase everywhere.<p>Don't nest inline callback functions. When you pass callbacks, pass references to object functions. Model these asynchronous flows as objects. Don't pass around uncertainty. Embrace events.

I wrote a pototype helper class that makes using promises super easy for node.js (<a href="https://github.com/icodeforlove/node-promise-object" rel="nofollow">https://github.com/icodeforlove/node-promise-object</a>)

Hmm came here thinking we were going to talk about the philosophical implications of keeping/breaking promises and how deals are still made with handshakes over Ommegang Iron Thrones.

Thanks. I hadn't gotten around to learning about these yet, but this was a very nice read.