Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Two wee caveats here. One is that this is ultimately a matter of taste, and two is that closure is not (as mentioned in other comments here) the only approach to achieve our goals.
one should inline or indent because it is a break from the normal flow ... as far as the next line is concerned.
In this specific case, we can view these closures not as breaks from the normal top level flow, but continuations of the same flow, however with an assignment thrown in to the expression. Normally a JS assignment would require a new statement, but closure and lambdas let us do that without breaking the flow of the expression. In that regard, everything after the => is really part of the same fluent flow.
My aim here is to get developers out of the mindset that they need to mentally execute every char of source. I don't think you have to read these as "then, execute a callback which takes users, and the body of the callback is such and such, blah blah blah, close the closure and pop the callstack, move on.". I'd prefer to read this as "then, with the cooked and ordered dishes in hand, fetch the guest list. Keep both in the back of your mind while inviting the guests, then when they arrive, serve them."
It's not that developers should ever think in terms of the callstack, it's that when considering the expression as a whole, they should have the mental agility to abstract over it.
I dunno, does that make a lick of sense?
Anyways, you're right 100% that closure is not the only way to get'er done here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Two wee caveats here. One is that this is ultimately a matter of taste, and two is that closure is not (as mentioned in other comments here) the only approach to achieve our goals.
In this specific case, we can view these closures not as breaks from the normal top level flow, but continuations of the same flow, however with an assignment thrown in to the expression. Normally a JS assignment would require a new statement, but closure and lambdas let us do that without breaking the flow of the expression. In that regard, everything after the
=>is really part of the same fluent flow.My aim here is to get developers out of the mindset that they need to mentally execute every char of source. I don't think you have to read these as "then, execute a callback which takes users, and the body of the callback is such and such, blah blah blah, close the closure and pop the callstack, move on.". I'd prefer to read this as "then, with the cooked and ordered dishes in hand, fetch the guest list. Keep both in the back of your mind while inviting the guests, then when they arrive, serve them."
It's not that developers should ever think in terms of the callstack, it's that when considering the expression as a whole, they should have the mental agility to abstract over it.
I dunno, does that make a lick of sense?
Anyways, you're right 100% that closure is not the only way to get'er done here.