I don't think this is very well written. It doesn't start with any motivating problem, it introduces terms (functor) without defining them, and a lot of what is discussed doesn't apply to solving the problem.
Folding Promises in JavaScript
11–20 of 48 posts
Re: Folding Promises in JavaScript
#12I can't quite understand the difference between endomorphism ("input and output of the transformer must be from the same category") and homomorphism ("structure preserving transformation. We always stay in the same category"). Can someone help?
Endomorphism has less implied structure. Lots of dumb things are endomorphisms. Homomorphism implies "structure preservation" which can make it more specific.
Re: Folding Promises in JavaScript
#13> Folding Promises in JavaScript Or: How to make simple things complex and make a codebase a complete puzzle for those that come after you?
I feel nothing has improved code readability like the recent mainstreaming of map/filter/fold/reduce and "const all the things". This type of code is so easy to follow, reason about and trivial to debug at every step, once you internalize the few primitive functions.
I don't think you need to necessarily memorize these transformation names, but writing these types of functions is all I seem to be doing these days, transforming one thing into another line for line.
Re: Folding Promises in JavaScript
#14With async/await this can become:
const reduceP = async (fn, identity, listP) => {
const values = await Promise.all(listP)
return values.reduce(fn, identity)
}
let total = 0
while (listP.length > 0) {
total += await listP.pop()
}Re: Folding Promises in JavaScript
#15"Programs must be written for people to read, and only incidentally for machines to execute." - Harold Abelson
Re: Folding Promises in JavaScript
#16>How can we make it better ? Let's start by removing the requirement for identity value to always be the promise. I challenge the view that making the identity value being able to be something other than a Promise is 'making it better'. Pointless abstraction is one of my pet peeves in this industry. This looks like it has gone from a fairly straightforward, if kludgy, piece of code to something far more complex. Why…
Same reason given in the bluebird library documentation:
> Promise.reduce will start calling the reducer as soon as possible, this is why you might want to use it over Promise.all (which awaits for the entire array before you can call Array#reduce on it).
Whether this is ever necessary is another matter :)
Re: Folding Promises in JavaScript
#17With async/await this can become: const reduceP = async (fn, identity, listP) => { const values = await Promise.all(listP) return values.reduce(fn, identity) } The whole thing feels like a synthetic and overcomplicated example, though. In practice I'm sure I'd just write: let total = 0 while (listP.length > 0) { total += await listP.pop() }
That code does the same thing as https://news.ycombinator.com/item?id=15302465 but not the same thing as the code in the article.
Re: Folding Promises in JavaScript
#18I can't quite understand the difference between endomorphism ("input and output of the transformer must be from the same category") and homomorphism ("structure preserving transformation. We always stay in the same category"). Can someone help?
Homomorphisms are structure-preserving mappings between different types (called “category” in the post, in usual terminology, these would be »objects« in a »category«, though). Endomorphisms are special homomorphisms, mapping from a single type (»object«) to the same type (»object«).
It is indeed very unfortunate that the article conflates terminology.
Re: Folding Promises in JavaScript
#19> Folding Promises in JavaScript Or: How to make simple things complex and make a codebase a complete puzzle for those that come after you?
I feel nothing has improved code readability like the recent mainstreaming of map/filter/fold/reduce and "const all the things". This type of code is so easy to follow, reason about and trivial to debug at every step, once you internalize the few primitive functions. I don't think you need to necessarily memorize these transformation names, but writing these types of functions is all I seem to be doing these days, tr…
I feel the code I wrote while on this bandwagon is the hardest to understand for others and for me myself today.
pullAllBy(pluck(things, 'bar').map(compose(xor, lol, rofl)).reduce(differenceWith('id'))
Re: Folding Promises in JavaScript
#20>How can we make it better ? Let's start by removing the requirement for identity value to always be the promise. I challenge the view that making the identity value being able to be something other than a Promise is 'making it better'. Pointless abstraction is one of my pet peeves in this industry. This looks like it has gone from a fairly straightforward, if kludgy, piece of code to something far more complex. Why…
Same reason given in the bluebird library documentation: > Promise.reduce will start calling the reducer as soon as possible, this is why you might want to use it over Promise.all (which awaits for the entire array before you can call Array#reduce on it). Whether this is ever necessary is another matter :)
I suppose this might be useful in situations where you are querying an API(s) with multiple requests and some will certainly return seconds before others.
This way you could have the same reducer handle the results and begin updating the UI as the results come in.
An example real-world app might be a price comparison tool or social media aggregator.