Why I am switching to promises

>How many more ways of reinventing basic programming-language design is the JS community going to come up with before we realize that the emperor has no clothes?

Yes, JS was a rushed language that was then left to rot for 15-odd years. Unfortunately it's the language that powers the web, runs everywhere, and (along with HTML/CSS) is the only thing that all the big guys agree on.

It's getting better but it is what it is.

How long? Until one of the other languages (say... clojureScript) develops a large enough ecosystem and best practices around it to allow portions of code to be shared between the client and server.

Oh, that also means that this given system has to reach critical mass. Oh, and since everything's server and client side, the compilation has to be rock solid and be easy enough to understand without reverting to javascript in frustration.

I miss programming in Node, for nothing else that I hate having to keep up with so many paradigms and switch between the two. I only have X amount of hours to keep up. When I move back to heavy development in a language after even a few days off, there is friction.

And as someone who writes both front end and back end code, it gets frustrating. I'm not as good as I could be, given the hours in the day I have.

Threads are quite useful, and Javascript has them. However, if what you have is a computation you have the inputs to start now and won't need the result of for a while, lazy evaluation is a far more natural representation for that than a thread.

Ideally, a language ought to have one representation for lazy evaluation, not a dozen; perhaps at some point a new standard will come out that standardizes some subset of lazy evaluation that has won out. Welcome to Javascript.

Yeah I just started working on a node project and can't help but feel like I have been transported to a time 40 years ago where my operating system didn't have a process scheduler and I have to do it all myself. I literally have to think about how asynchronous behavior works every 2 or 3 lines of code. It's sheer madness.

Some of those "things" you counted are based on generators, which let you to do exactly what you want.

Example: https://github.com/spion/async-compare/blob/master/examples/...

With promises, generators are not really necessary -- especially if you add arrow function syntax into the mix. https://gist.github.com/spion/8254661

(Note: that particular method in doxbee has long since been refactored to something saner with better separation of concerns :)

Promises are actually very simple - so fundamental that you can think of them as dual to function composition. By a dual to function composition i mean that you can mechanically convert async promise code to everyday synchronous function calls - including everyday exceptions. That means that literally the code can look exactly the same whether or not you are async or sync. The trick is you need either macros or monads to do this.

(This is kind of the whole point of monads - you could write a piece of code by composing a few functions, and then make it asynchronous without breaking the function composition! No need to rewrite your code to use callbacks; the same code will just work.)

You mean like fibers? :)

https://github.com/laverdet/node-fibers

This is what Meteor uses on the server side, and it's a pleasure. Everything is suddenly synchronous.

(Edit: Oops! Sorry, I see that you're already familiar with continuations, but let me explain them for those who aren't)

Sometimes, fundamental switches in thinking are worth it. :)

For example, continuations would be perfect here, and are a wonderful tool for simplifying "nested callback hell" type problems.

But why should a web developer care about continuations?

Consider Paul Graham's Arc challenge: Build a web page that presents a form to the user. After they submit the form, a new page presents them with a link. The link takes them to a third page where the submitted value is presented back to the user. The restriction is that the input field must not be passed in via the URL.

Right now, the user must write in "continuation-passing style", which means threading callbacks, like this:

   function serve(req,res) {
      askUserForValue(req,res, function(value){
          showLink(req, res, function(){
              render(res, {"user-value": value});
          });
      });
   }

Or perhaps the user could somehow stuff the variable into a "session" library with three separate URL routes:

    function serve(req,res) {
       render the form with the POST action of /submit;
    }

    function submit(req,res, value) {
       req.session["uservalue"] = value;
       render the link that sends the user to /view;
    }

    function view(req,res) {
       render the value of req.session["uservaule"];
    }

This one is even more fragmented since you have three separate functions that model one user interaction flow! I certainly like it less than the callback example -- at least I can keep one in my head.

We can do better though. Continuations let you write this:

   function serve(req, res) {
      var value = askUserForValue();
      showLink();
      render(res, {"user-value": value});
   }

If node.js supported continuations, the askUserForValue() function would respond with the form and suspend the serve function right then and there. After the user made a new HTTP call, the suspended askUserForValue() call would return to serve() and its return value would be placed into our variable. Then, the showLink() function could render the link and suspend the function again. Once the user makes another HTTP request, the function resumes, and so on.

The server would have to store the state of the computation itself to disk so it could continue later.

With continuations, we can pretend the user's web browser is the program counter. This frees my mind up. First, I don't have to keep callbacks in my head since there aren't any callbacks anymore. Second, stack traces work the way I expect because functions explicitly call each other. Third, if askForValue() throws an exception if the user inputs a string where I entered a number, no problem! Just wrap it in a try{} block that asks the user to enter a valid value, as if I'm writing a text program that calls readline().

Also note that this is different from just letting each user interaction be in its own thread! Consider:

1. Continuations should be serializable to disk. You wouldn't want blocked threads to just pile up as more users visit your website, and if your server crashes, you certainly wouldn't want to forget their state.

2. The browser "back" button would have to step a program backwards in time; something that is unsupported in a naïve thread-equals-user-interaction system. (E.g. how many of you have booked an airplane ticket with Travelocity/Expedia/whatever, pressed "Back", and then got a big error because the server didn't know how to step backwards through its user stack?) But the ability to save continuations to disk is the ability to save the current state of the program to disk, which makes stepping back in time easy: you can simply reload what was about to happen, just like savestates in a video game emulator.

This is not a new idea. Many Common Lisp and Smalltack web frameworks work well with continuations and have done so for years (the first Seaside release was 2002, I'm not kidding you!)

Racket, a great dialect of Scheme, ships with such a web framework out of the box. Here's my implementation of the Arc challenge in Racket. Note how the 'start' function is implemented: https://gist.github.com/gcr/ad116f565e105c8b2e0d

It's super easy to try this out and you don't need to fiddle with dependencies or anything. Just download Racket from http://racket-lang.org/ , copy+paste the code into DrRacket's giant text box on the top, press Run, and your web browser will pop up with the example.

I find one of your premises very thin: browser implementors are implementing DOM promises, so promises were clearly not invented solely to make up for the difficulties of Node.

The emperor may have no clothes, but what's so great about clothes? (If God meant people to be naked, they'd be born that way! Same goes for programming languages.)

The naked Emperor JavaScript runs everywhere, and runs fast, and isn't going away. He's streaking at lightning speed all over the kingdom, everybody's seen him, and he doesn't stay still.

The emperor is naked. Long run the emperor.

No its not. I address this immediately afterwards (below "But spion, why don't you wrap your calbacks?"), but basically, this simple wrapper makes stack traces unusable.

Bluebird (and also Q) stitches together stack traces from multiple previous events. This is amazingly awesome.

Nope, `doStuff().then(function(value)" != try`

A closer representation would be `try { var value = doStuff()` which has similar verbosity.

ES6 will have generators and "arrow" function syntax. Meaning:

  doThing().then(function(value){
     //blah blah blah
  })
  .catch(function(err){
     //handle it
  })

becomes either:

  try { 
    var value = yield doThing();
    //blah blah blah
  } catch (err) {
    //handle it
  }

or

  doThing().then(value => /* blah blah blah */)
    .catch(err => /* handle it */);

meaning you can pick your paradigm :) Except that the functional one composes slightly better, perhaps.

  doThing().then(value => /* blah blah blah */)
    .catch(only(ParseError, err => /* handle it */));

vs

  try { 
    var value = yield doThing();
    //blah blah blah
  } catch (err) {
    only(err, ParseError); // argument repetition
    //handle it
  }

I haven't heard of ToffeeScript before, but this is pretty much how Erlang works. Whenever you make a blocking call, all of the async stuff happens under the hood, so that you just deal with sequential code.

Erlang's concurrency model deals with lots of lightweight processes. Rather than having callbacks it uses a message system. Whenever a process waits for a message it yields so other processes can be executed.

In your example there would be a process separate from the main[0] process that handles the database connection. When you request the update to the database, you are just sending a message to the database connection process. This will receive the message and handle the update when it can[1], and once complete, send you a message back with the result of the update. During the waiting period the VM will continue executing other processes. No callbacks needed :)

[0] Erlang concurrency is based upon the actor model. There isn't really a main process, but for the sake of explanation...

[1] The database connection process will actually block while making the update, so if you have 10,000 processes calling this, you will have a bottleneck. As such you should have a pool of database connection processes, rather than just one.

Have you tried IcedCoffeescript? http://maxtaco.github.io/coffee-script/ if so, how do you think it compares to ToffeeScript?

Also IcedCoffeeScript

http://maxtaco.github.io/coffee-script/

It's just CoffeeScript with await and defer keywords, essentially. I personally would never touch toffeescript/coco and friends as they differ too much for CoffeeScript, which already segregates the JS userbase enough. I figure IcedCoffeeScript is the lesser evil for compile-time control flow as it's not adding a bunch of other changes to the language that users have to understand to contribute to a project written in it. Another issue with these CS spinoffs is; what if the main contributor says "Fuck it" and bails? CS itself is big enough to have a lot of talented contributors. What happens when CS moves over to CS 2.0 ie. coffeescript redux? Do these spinoffs need to recoded?

That being said I probably won't use Iced either, as much as I want to... Maybe I'm all wrong about this? Maybe this userbase segregation crap is not as big a deal as I may think.

See my comment below about ToffeeScript which compiles to JavaScript.

Then again, Simon Peyton Jones has said that were he to make a new Haskell, it would have strict evaluation. As far as I know, lazy IO is considered a pain in the butt. That beeing said, laziness does have its merits and some ideas can be elegantly stated in a lazy language.

> Promises attempt to resolve this by coercing all exceptions to error passing, but not all exceptions are safe to be passed. Specifically, any exception originating from core that is not an invalid argument exception (think 4XX vs 5XX class errors) cannot safely be caught / coerced / continued on. Also, not all errors passed to callbacks are even theoretically passable as the unofficial policy of core is that core callback errors are only distinguishable from exceptions in that they occur after the origin tick. In other words, they are equally crash-worthy and equally non-crash-worthy.

This is not true. With promises, the wrapper of core functionality is left up to you. You can either write a crashy wrapper, an uncrashy wrapper, or a wrapper which picks whether to crash or not depending on the kind of error. I wrote more about this here [1]

Most default wrappers provided by promise libraries catch all synchronous errors but don't do anything with asynchronous errors. So far, this seems to be a fine default -- most unrecoverable, state-corrupting thrown errors in node core are asynchronous, and all the invalid argument errors are synchronous. But even if that weren't the case, it would be a simple matter to write a more specific wrapper.

[1]: https://github.com/petkaantonov/bluebird/issues/51#issuecomm...

Yup, from what I recall of history both Twisted Deferreds and JavaScript promises have their heritage in E's promises.

Yup. jQuery: http://api.jquery.com/category/deferred-object/

Debugging with Bluebird (mentioned in the article) is not a pain because it stitches stack traces across events for you when you run it in development mode :)