Write logic, not mechanics

I found this very useful for architecting larga javascript aps: http://speakerdeck.com/u/addyosmani/p/large-scale-javascript...

CPS is best suited for intermediate code, it's not something to be written/read by humans as it's basically the same as goto.

Promises are likely to be baked into JavaScript at some point in the future[1], so I would recommend becoming familiar with them now. Even if you don't use the pattern personally you will likely run into libraries that do use it once it is part of the spec.

I don't too much like the promise pattern this article gives, Q is the definitive implementation: http://documentup.com/kriskowal/q/

[1]http://wiki.ecmascript.org/doku.php?id=strawman:concurrency

First of all I implement abstraction using language features and there for I take advantage of it.

  - I favor maintainability over performance, also keep in
  mind that promised function take promises as arguments
  and can't do much until they're fulfilled (associated IO
  is done) so that small performance hit is insignificant
  in most of the cases.
  - You can write your own decorators to wrap constructors
  and their methods if you need to. That being said, I'd
  recommend against, mixing mutable state with logic does
  no good in long run. You'll be better of with functional.
  - As for map / reduce, promises represent eventual values,
  not sequences of them. For that there are streams and I
  have explored that area as well:
  https://github.com/Gozala/streamer/wiki/stream
  I have not wrote about it because I don't think it was
  good idea to dump everything in one post.

I'm happy async did that for you.

I think the OP refers to the syntax/API for each. If you're already using async APIs, adding a sync one that runs in a separate thread won't change much.

On the other hand, you need something like CPS or coroutines to cleanly use an async function in a program mostly using sync APIs.

Of course, if you have the right tools (CPS/coroutines) you can make any async API look sync, as you said.

It's a bit misleading way to put it, but more or less correct when talking about client-side JavaScript. There are essentially no blocking calls, so a "synchronous" function in this context just means a normal function which directly returns a value and "asynchronous" means a function that takes a callback.

What the quoted bit boils down to is that any function that returns normally can be converted into a function that calls a callback, but not the other way around.

Sorry for confusion, I meant indeed a sync / async APIs. You could easily wrap sync function to give it an async API in order to chain with functions that had async APIs, but it's not really possible other way round (not in JS).

What I'm suggesting is that promises don't need any special treatment. If you have a function that you want to feed a promise just wrap it: promised(Mustache.render). That's all it takes.

I have already fixed that, it was a typo, I meant following instead:

    var deferred = defer()          // make promise
    var a = deferred.promise
    var b = sum(a, 1)
    var c = sum(b, 5)
    console.log(c)                  // eventually prints => 17
    deferred.resolve(11)            // fulfill promise

It looks like a bunch of us have had the same idea for Node.js. I wrote for example this: https://github.com/drostie/ducky/blob/master/promises.js

I've abandoned it at this point for a very particular reason: operators don't work well in this phrasing. That is, the example case given in the above discussion:

    function makeView(templateURI, dataURI) {
        var template = readURI(templateURI),
            data = readURI(dataURI);
        return Mustache.render(template, data);
    }

...while it's not bad, also doesn't actually try to "write logic", in a post that's about "write logic, not mechanics."

What you really want to do is much more complicated because the example code starts to look ugly:

    var userPromise = db.getUser(data.session);
    return userPromise.attr("role").equals("admin").then(
        render(open("yay.xml"), db.send(data.request)),
        render(open("no_permissions.xml"), {})
    );

Don't get me wrong, I still like the idea and think that there might be a very promising way to do this sort of work in Node. Certainly I prefer those five lines to always writing:

    db.getUser(data.session, function (err, user) {
        if (err) return callback(err);
        if (user.role === "admin") {
            db.send(data.request, function (err, reply) {
                if (err) return callback(err);
                render_file("yay.xml", reply, callback);
            });
        } else {
            render_file("no_permissions.xml", {}, callback);
        }
    });

But as much as I really don't like that lame error stuff which breaks in a stiff wind, I also really want to be cautious about the exchange of these two lines:

    if (user.role === "admin") {
    
    userPromise.attr("role").equals("admin").then(

What we really want, I guess, is some sort of mesoscopic system -- we still want operators and familiar control structures from our "micro" world, but we also want lazy evaluations and so on from our "macro" framework. This is not impossible but it is hard to get right. If my "ducky" project moves forward it will probably look something like this:

    return db.getUser(data.session)(function (user) {
        return (user.role === admin) ? 
             render(open("yay.xml"), db.send(data.request)) :
             render(open("no_permissions.xml"), {})
    });

You bubble up the lazy constructs with returns, the error handling gets internalized within the lazy constructs, and the "control-method" invocation allows you to build an arbitrary control structure with whatever object you have right now.

You just have to write function per operation that is it:

    var auth = promised(function(user, data) {
      var isAdmin = user.role === admin
      return  isAdmin ? render(open("yay.xml"), db.send(data.request))
                      : render(open("no_permissions.xml"), {})
    })
    
    var puser = getUser(data.session)
    return auth(user, data)

Oh noes!!! and his library starts with the dreaded exclamation point!!! -- another disgruntled JavaScripter.

I know that people identify strongly with technical choices[0] (and if you feel uneasy, you're probably the victim of this natural inclination of ours[1]), but I'm tired of the semicolon drama here on HN.

Could we please stop?

--

[0] http://paulgraham.com/identity.html

[1] or did I miss your sarcasm?

It's much more useful now, IMO. Now you can chain an error handler onto your view's render method, and the level of abstraction becomes "I couldn't render the view" rather than "I couldn't get some JSON from the server".

Functionally the behavior is the same - you're still going to have to gate an asynchronous stream of actions (make sure steps a, b, c have completed before d, etc.), but with this, you can describe that logic where it matters - renderView().then(attachHandlers).then..., instead of callback nesting hell (attachHandlers would have to be in renderView).

Yeah I had this comment there // Assuming Mustache.render = promised(Mustache.render)

But my hope is that more libraries will be accepting promises in a future so one won't have to do the wrapping of a world around.

You're absolutely right! My English is far from being perfect and in addition I was rushing to get this post out making bunch of mistakes. I tried to fix all the "than" "then" issues, thanks for pointing that out ;)