Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write logic, not mechanics

jeditoolkit.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Write logic, not mechanics

#31

Post by wonnage »

A good example of deferreds can be found in jQuery - every AJAX method returns a deferred that you can chain success, error, etc. handlers to. So it's not like this idea isn't a mainstream one.

The main problem I see is that very few libraries handle receiving promises as arguments, probably because there isn't a standard/widely-used implementation of them. So your logic ends up being backwards, e.g you'd chain Mustache.render off of a jQuery success promise, rather than just passing the success promise in.

Re: Write logic, not mechanics

#32

Post by wonnage »

ricardobeat wrote: post #29

That last line return Mustache.render(template, data) Isn't exactly equivalent to the non-promise one, since now `Mustache.render` is async, is it?

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).

Re: Write logic, not mechanics

#33

Post by gozala »

wonnage wrote: post #31

A good example of deferreds can be found in jQuery - every AJAX method returns a deferred that you can chain success, error, etc. handlers to. So it's not like this idea isn't a mainstream one. The main problem I see is that very few libraries handle receiving promises as arguments, probably because there isn't a standard/widely-used implementation of them. So your logic ends up being backwards, e.g you'd chain Musta…

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.

Re: Write logic, not mechanics

#34

Post by skrebbel »

ricardobeat wrote: post #30
gozala wrote: post #23

Earlier quoted context omitted.

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

You were writing an article about it and didn't get it right on the first time - maybe that's the reason more people don't use it.

That, or a majority of the JS coding crowd is too novice to appreciate maintainable code better than copying and pasting "simple" plumbing all over the place.

Re: Write logic, not mechanics

#35

Post by stephank »

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available.

Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems:

- The application I work on, and have in mind with this, would need just about every function decorated.

- It doesn't account for methods, unless you're default decorating the method, ie.: `Foo.prototype.myMethod = promised(function(/* ... /) { / ... */ });`

- Every decorated function takes a noticable performance hit, because things like `Function#apply` and concatenating `arguments` are relatively slow.

- It doesn't sit well with me that the example rewrites a method on a prototype declared elsewhere: `console.log = promised(console.log)`

Further, the article and library don't even scratch the surface of complicated async flows. Think async versions of common functional-style methods like `map`, `reduce`, etc.

For example, a basic scenario from our own build process is: Scan a directory for template files, read them, compile them, then concatenate the result and write it out.

We used to have a promise library to do all of this, from handling a build process to performing database queries. I discovered Async.js at some point and haven't look back since: https://github.com/caolan/async

Re: Write logic, not mechanics

#36

Post by MatthewPhillips »

stephank wrote: post #35

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available. Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems: - The application I work on, and have in mind with this, would need just about every f…

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

Re: Write logic, not mechanics

#37

Post by IsTom »

sergimansilla wrote: post #16

Well put. It still puzzles me that promises and/or CPS don't have a greater adoption in the JavaScript community. I guess that what happens is that the concept of a callback is a very easy to understand one, but a system becomes more complicated and cumbersome (exponentially, I would say) with every new callback that is added to it. The real problem comes when creating big async applications in JavaScript based entir…

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.

Re: Write logic, not mechanics

#38

Post by stcredzero »

gozala wrote: post #27
stcredzero wrote: post #12

I will be down voted for saying so, but "than" and "then" seem to be reversed throughout the entire article. I would like to learn more about promises now.

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 ;)

I was thinking about promises, because I just wrote a procedurally generated universe in Javascript with over 2^100 locations. To do the procedural generation correctly, the Math.random() function has to be called in the same order every time for generating each "sector." I had used promises in Smalltalk, but never found an application super for them and was thinking that promises would be a way to code this cleanly.

Re: Write logic, not mechanics

#39

Post by gozala »

stephank wrote: post #35

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available. Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems: - The application I work on, and have in mind with this, would need just about every f…

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.

Re: Write logic, not mechanics

#40

Post by gozala »

MatthewPhillips wrote: post #36
stephank wrote: post #35

It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available. Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems: - The application I work on, and have in mind with this, would need just about every f…

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.or…

Just to be clear this library implements just a subset of Q with exact same API, with only addition of `promised` wrapper. I'm convinced that this wrapper is a better way to deal with promises than dozens of utility functions that you have to learn about.

For example Q.all is promised(Array) I find later more intuitive.

That's not to say don't use Q! Q is brilliant piece of software and I'd be more than happy to see more people using it.

Post reply on HN