notes-computer-programming-programmingLanguageDesign-prosAndCons-promises

" Getting the result out of a callback- or event-based function basically means “being in the right place at the right time”. If you bind your event listener after the result event has been fired, or you don’t have code in the right place in a callback, then tough luck, you missed the result. This sort of thing plagues people writing HTTP servers in Node. If you don’t get your control flow right, your program breaks.

Promises, on the other hand, don’t care about time or ordering. You can attach listeners to a promise before or after it is resolved, and you will get the value out of it. Therefore, functions that return promises immediately give you a value to represent the result that you can use as first-class data, and pass to other functions. There is no waiting around for a callback or any possibility of missing an event. As long as you hold a reference to a promise, you can get its value out.

var p1 = new Promise(); p1.then(console.log); p1.resolve(42);

var p2 = new Promise(); p2.resolve(2013); p2.then(console.log);

prints: 42 2013

"

https://github.com/promises-aplus/promises-spec

http://www.foundationdb.com/white-papers/flow/

promises are completable futures: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/CompletableFuture.html

http://twitter.github.com/scala_school/finagle.html

http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html

"

Promises 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. "

---

chaining promises and escaping: https://news.ycombinator.com/item?id=5467834

" function doTask(task, callback) { return Q.ncall(task.step1, task) .then(function(result1) { if (result1) { return result1; } else { return continueTasks(task); } }) .nodeify(callback) }

  function continueTasks(task) {
    return Q.ncall(task.step2, task);
    .then(function(result2) {
      return Q.ncall(task.step3, task);
    })
  }

As opposed to with stepdown[2]:

  function doTask(task, callback) {
    $$([
      $$.stepCall(task.step1),
      function($, result1) {
        if (result1) return $.end(null, result1)
      },
      $$.stepCall(task.step2),
      $$.stepCall(task.step3)
    ], callback)
  }

I would really love for a post to include a non-trivial problem implemented with promises, vanilla callbacks, and async (and I'd be happy to add a stepdown equivalent), and allow people to see for themselves (how in my opinion promises make code harder to read).

[1] http://stackoverflow.com/questions/11302271/how-to-properly-...

[2] https://github.com/Schoonology/stepdown (docs need updating, view tests for documentation) "

---

a library: https://news.ycombinator.com/item?id=5466960

an argument for promises over callbacks: http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/

alternative: http://dfellis.github.com/queue-flow/2012/09/22/why-queue-flow/