Explicit is better than implicit, and there's a lot of implicit behavior in that promise chain. And counting the number of parentheses to follow the chain in that last example is just a disaster waiting to happen. Of course, there's the problems you mention with the async version as well.
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*
I'm not sure what you mean specifically here when you use the words "implicit" and "explicit" here. Re-reading your insights, I can't tell whether or not you just mean "good" and "bad" or "my style" vs "not my style". Can you be a drop more explicit (badum-ching!) and provide an example of how you would rather do this?
WRT the closures, counting parens is definitely a chore. One better suited to IDEs and linters, which I consider pre-requisites. Even with all that, though, closure isn't the only option here. As mentioned above, the sharp refactorer might prefer to pass POJOs or more sophisticated ADTs to handle all that state.
Well, I agree with Dustin that without some context highlighting IDE it's hard to argue what's happening down that .then chain. (I probably would start with re-indenting such code if I saw it in a codebase)
And async operations are already tough to understand. (Probably that's why some people invented async/await)
So, IMHO, it's a cool approach with all those curried functions, really!
Though in real code (if I had friends to invite) I'd use more declarative way, e.g.:
// parallelall(groceries().then(a).then(b),friends().then(c).then(d))// and then combined.then(results=>{// ...})
there are some libraries actually that have parallel/sequential helpers to get rid of those .then chains, though I haven't found any quickly enough
It's a bit more like a callback hell, I know, yet for me personally this way its easier to understand the sequences and dependencies.
Again, it's a personal opinion. Still, it was interesting for me to read those point-free (?) functions. So thanks, Benny!
P.S. Maybe, the lesson here is that we should mix those approaches.
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.
Explicit is better than implicit, and there's a lot of implicit behavior in that promise chain. And counting the number of parentheses to follow the chain in that last example is just a disaster waiting to happen. Of course, there's the problems you mention with the async version as well.
I don't love either version.
Hi Dustin!
I'm not sure what you mean specifically here when you use the words "implicit" and "explicit" here. Re-reading your insights, I can't tell whether or not you just mean "good" and "bad" or "my style" vs "not my style". Can you be a drop more explicit (badum-ching!) and provide an example of how you would rather do this?
WRT the closures, counting parens is definitely a chore. One better suited to IDEs and linters, which I consider pre-requisites. Even with all that, though, closure isn't the only option here. As mentioned above, the sharp refactorer might prefer to pass POJOs or more sophisticated ADTs to handle all that state.
Thanks for dropping by :D
Well, I agree with Dustin that without some context highlighting IDE it's hard to argue what's happening down that
.thenchain. (I probably would start with re-indenting such code if I saw it in a codebase)And async operations are already tough to understand. (Probably that's why some people invented
async/await)So, IMHO, it's a cool approach with all those curried functions, really!
Though in real code (if I had friends to invite) I'd use more declarative way, e.g.:
there are some libraries actually that have parallel/sequential helpers to get rid of those .then chains, though I haven't found any quickly enough
It's a bit more like a callback hell, I know, yet for me personally this way its easier to understand the sequences and dependencies.
Again, it's a personal opinion. Still, it was interesting for me to read those point-free (?) functions. So thanks, Benny!
P.S. Maybe, the lesson here is that we should mix those approaches.