4 ms·

I have to agree. This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics (hint: the author's own library wins this cont

by woah 9y ago

I have to agree. This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics (hint: the author's own library wins this contest). It doesn't consider what programmers use them for. Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors. The author's "improvements" would ruin this. If I need a bunch of features that a promise doesn't provide, like cancellation, I will write something to do it manually with callbacks. This is far less than 1% of async calls though.

naasking 9y ago
> This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics Or you could consider the possibility that they aren't arbitrary at all. Perhaps these properties are well motivated by, for instance equational reasoning, which is a cornerstone of extensible and maintainable programming. > Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors Why? What purpose does that ultimately serve given we already have functions? The whole point of an abstraction is to provide sophisticated semantics to do an important job you would otherwise have to do by hand.
- amptorn 9y ago
  > equational reasoning, which is a cornerstone of extensible and maintainable programming What are the other cornerstones?
  - naasking 9y ago
    Abstraction. Composition. Probably a couple of others.
squiggleblaz 9y ago
Although I don't like most of his alleged improvements, surely a separate map/flatMap would be more like function calls. If I write function foo(v) { return function () { return v } } const fv = foo(4) then I expect fv will be a function, not a number. In that respect, I think the choice to make `then` flatten was a poor decision that makes it more confusing for people who don't really take the time to understand. Such people don't realise it's confusing: they simply notice it's usually convenient; but they're inhibited from drawing the correct analogies. But as for the rest. Yeah, it's just arbitrary and weird. Maybe we should make integers all arrays lazy by default too?

by woah 9y ago

naasking 9y ago

> This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics Or you could consider the possibility that they aren't arbitrary at all. Perhaps these properties are well motivated by, for instance equational reasoning, which is a cornerstone of extensible and maintainable programming. > Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors Why? What purpose does that ultimately serve given we already have functions? The whole point of an abstraction is to provide sophisticated semantics to do an important job you would otherwise have to do by hand.

amptorn 9y ago
> equational reasoning, which is a cornerstone of extensible and maintainable programming What are the other cornerstones?
- naasking 9y ago
  Abstraction. Composition. Probably a couple of others.

squiggleblaz 9y ago

Although I don't like most of his alleged improvements, surely a separate map/flatMap would be more like function calls. If I write function foo(v) { return function () { return v } } const fv = foo(4) then I expect fv will be a function, not a number. In that respect, I think the choice to make `then` flatten was a poor decision that makes it more confusing for people who don't really take the time to understand. Such people don't realise it's confusing: they simply notice it's usually convenient; but they're inhibited from drawing the correct analogies. But as for the rest. Yeah, it's just arbitrary and weird. Maybe we should make integers all arrays lazy by default too?