4 ms·

The issue with `of` is that it special cases when `a` is already a Promise. Promises try hard to not be nested (a promise of a promise) but that nesting is crit

by tel 9y ago

The issue with `of` is that it special cases when `a` is already a Promise. Promises try hard to not be nested (a promise of a promise) but that nesting is critical for algebraic properties. The then issue is multifarious. On one side, splitting the two uses makes the algebraic justification for then more clear, but it's not a big deal. The real issue is that `then(f)` does different things when `f` returns a Promise. This breaks in the same way that `of` did—you need to be able to discuss nested promises.

BigJono 9y ago
That just raises more questions. Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec? There's a lot of talk about FP and type theory here, and none about actual work. To me, all this stuff is still in the "cool to play around with at home" category. But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck.
- pka 9y ago
  > But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck. That's a seriously toxic attitude to have. People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking. > Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec? There are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on. [0] https://github.com/facebook/Haxl https://github.com/facebook/Haxl
- tel 9y ago
  Just responding as op, but pka nailed it. If you're writing every line of code directly then these all feel like conveniences. If you write code that's more generic then they become exponentially compounding edge cases.

by tel 9y ago

BigJono 9y ago

That just raises more questions. Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec? There's a lot of talk about FP and type theory here, and none about actual work. To me, all this stuff is still in the "cool to play around with at home" category. But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck.

pka 9y ago
> But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck. That's a seriously toxic attitude to have. People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking. > Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec? There are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on. [0] https://github.com/facebook/Haxl https://github.com/facebook/Haxl
tel 9y ago
Just responding as op, but pka nailed it. If you're writing every line of code directly then these all feel like conveniences. If you write code that's more generic then they become exponentially compounding edge cases.