Callbacks are imperative, promises are functional

Post by psionski » Sun, Mar 31, 2013, 11:08 AM UTC

skrebbel wrote: post #100

schrototo wrote: post #95

Earlier quoted context omitted.

Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").

> (it also makes it look very "mathematical") Has that ever been an advantage?

Post by justincormack » Sun, Mar 31, 2013, 11:27 AM UTC

Derander wrote: post #69

mbostock wrote: post #32

Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing. If I wanted to compute the size of one file relative to a set, I’d probably do something like this: queue() .defer(fs.stat, "file1.txt") .defer(fs.stat, "file2.txt") .defer(fs.stat, "file3.txt") .awaitAll(functi…

>> but reading files in parallel would presumably be slower since you'd be jumping around on disk There is a lot of engineering that goes into making parallel reads go fast. Some combination of the file system and disk controller will probably be smart enough to recognize the opportunity for sequential reads and execute them as such if possible. This is not always true, and it does not undermine the rest of what you…

Post by hyperpape » Sun, Mar 31, 2013, 11:56 AM UTC

jasondenizac wrote: post #42

mbostock wrote: post #32

Not to focus too myopically on the given example, but I can’t help but wonder why it’s a requirement that the first file be handled specially? A less contrived example would make the argument more convincing. If I wanted to compute the size of one file relative to a set, I’d probably do something like this: queue() .defer(fs.stat, "file1.txt") .defer(fs.stat, "file2.txt") .defer(fs.stat, "file3.txt") .awaitAll(functi…

> I just feel like they might be a bit heavy-weight and a lot of API surface area to solve this particular problem. The surface area is `.then()`

Post by markov_twain » Sun, Mar 31, 2013, 12:02 PM UTC

spullara wrote: post #71

It is hard for me to fathom the negative feelings towards Promises. They are quite clearly a great way to perform async programming in a civilized way (see Twitter's Future/Promise in Finagle on github). JDK 8 will even have the equivalent in CompletableFuture. The only thing better is to combine Promises with coroutines for a more linear programming style like in Flow: http://www.foundationdb.com/white-papers/flow/

Post by mattmanser » Sun, Mar 31, 2013, 1:06 PM UTC

fruchtose wrote: post #86

crazygringo wrote: post #12

This is an interesting perspective. But to me, even having spent a year on a large node.js project, I just don't see how promises would have simplified things at all. If you have some crazy graph of dependencies, I can see how breaking out promises could help simplify things. But I don't feel like that's a super-common scenario. The author says: > * [Promises] are easier to think about precisely because we’ve delegat…

I can speak your comment, since my side project is a Node.js server that talks to several APIs, a database, and N web clients. Like you, I've worked more than a year on it, but I had a positive experience with Q [1] and jQuery promises. Promises make async code easy to manage, even at scale. Each API request gets its own promise. What happens inside that promise doesn't matter, as long as it returns a result or an er…

    function playlistCount(){
        return db.query('SELECT COUNT(id) AS count FROM Playlists;', function(rows) {                   
            return parseInt(rows[0]['count']);
        });
    }