Quildreen Motta (2014-02-08T12:57:19.000Z)
domenic at domenicdenicola.com (2014-02-10T22:46:38.011Z)
On 8 February 2014 07:37, Benjamin (Inglor) Gruenbaum <inglor at gmail.com>wrote: > - Promises solve an interesting problem They do. And that problem is representing the eventual value of asynchronous computations, allowing you to compose them as usual. (there are different approaches to this too) > - There are a number of promise libraries that are *working* > implementations that solve real world use cases. They have evolved for > several years _for_ those use cases. > - I believe that was a big consideration for adding them to the > specification to begin with. > - Promise libraries _could_ have added some of the methods and > alternatives discussed here but didn't. > - Q is not the only library nor it is the 'de facto standard'. Kris is > very knowledgeable but was not the only one building APIs. There are at > least 4 more libraries that do promises (RSVP, When, Bluebird, kew, > vow...). .chain , while very interesting is not very common to say the > least. > - Tens of thousands (probably more) of people have been using these > libraries for years now. Well, "promises" are a fairly old concept, with several different implementations throughout the history of CompSci, and even in JavaScript land itself. `.chain` itself is not common because it doesn't need to have that name, but it is a common operation (`.then` encodes that operation, for example, but you can't control when it gets applied). As for working implementations of `.chain-able` promises, you can see: https://github.com/folktale/data.future#example, and https://github.com/fantasyland/fantasy-promises, although they are not Promises/A+, it should be easy enough to implement `.cast` and `.then` on top of those primitives. There are three things you want to do with a promise: - You want to sequence asynchronous computations, such that you can specify computations that depend on a particular value. This is what `.chain` does. - You want to transform the value of a computation, but the computation itself is synchronous. This is what `.map` does, and `.chain` can generalise `.map`. - You want to assimilate the result of a different promise. This is what `.cast` does. Unfortunately, Promises/A+ only provide you with a `.then` method, which does all of those things for you, but you can never control which of those gets applied. Thus, `.chain` is a more general approach, and `.then` can be easily derived from `.chain`. A specification should favour the general use cases to make it easy for people to write more specific computations in userland, instead of constraining the expressive power to particular higher-level use cases. This is what the discussion on Promises right now is about. > I mean no disrespect to the hard work of the people here. I know everyone > who is participating in the discussion here is putting a lot of time and > effort to better the language and the community. However, from my > "complete" outside it sounds like: > > - There is a working tested solution that evolved through usage and > solving real problems over several years*. * > - The committee is dictating a lot of changes for it. > - Changes are based on new design goals and theoretical considerations > like "purity". I'm not saying there are no very good arguments for > non-recursive assimilation and .chain (there are) , but they're still being > "dictated" over existing library solutions. > > I was under the impression the goal is to adopt what works in practice as > much as possible and not dictate solutions from the sky. If someone wants > `a different API there is nothing preventing them from creating a library > and doing that - then coming back with "Hey, our solution works, we have > 1000 dependencies on NPM" or "on second thought, that sounded very > interesting but people are complaining about usage". One of the problems with just following existing solutions is that you'd also be copying the evolution mistakes and technical debts in those solutions. The committee **is** considering the existing solutions, and the use cases presented by people, which is a good thing. For example, for the "asynchronous map" use case, `.then()` is not usable short of adding plenty of special cases, and special cases don't compose cleanly. Standards are difficult because what you decide will shape the solutions that people write in the language for decades, standards evolve slowly, that's why you have less chances to make mistakes — in a library you can make a mistake and promptly fix it in the next version, this is not true of standards.
domenic at domenicdenicola.com (2014-02-10T22:46:26.691Z)
On 8 February 2014 07:37, Benjamin (Inglor) Gruenbaum <inglor at gmail.com>wrote: > - Promises solve an interesting problem They do. And that problem is representing the eventual value of asynchronous computations, allowing you to compose them as usual. (there are different approaches to this too) > - There are a number of promise libraries that are *working* > implementations that solve real world use cases. They have evolved for > several years _for_ those use cases. > - I believe that was a big consideration for adding them to the > specification to begin with. > - Promise libraries _could_ have added some of the methods and > alternatives discussed here but didn't. > - Q is not the only library nor it is the 'de facto standard'. Kris is > very knowledgeable but was not the only one building APIs. There are at > least 4 more libraries that do promises (RSVP, When, Bluebird, kew, > vow...). .chain , while very interesting is not very common to say the > least. > - Tens of thousands (probably more) of people have been using these > libraries for years now. Well, "promises" are a fairly old concept, with several different implementations throughout the history of CompSci, and even in JavaScript land itself. `.chain` itself is not common because it doesn't need to have that name, but it is a common operation (`.then` encodes that operation, for example, but you can't control when it gets applied). As for working implementations of `.chain-able` promises, you can see: https://github.com/folktale/data.future#example, and https://github.com/fantasyland/fantasy-promises, although they are not Promises/A+, it should be easy enough to implement `.cast` and `.then` on top of those primitives. There are three things you want to do with a promise: - You want to sequence asynchronous computations, such that you can specify computations that depend on a particular value. This is what `.chain` does. - You want to transform the value of a computation, but the computation itself is synchronous. This is what `.map` does, and `.chain` can generalise `.map`. - You want to assimilate the result of a different promise. This is what `.cast` does. Unfortunately, Promises/A+ only provide you with a `.then` method, which does all of those things for you, but you can never control which of those gets applied. Thus, `.chain` is a more general approach, and `.then` can be easily derived from `.chain`. A specification should favour the general use cases to make it easy for people to write more specific computations in userland, instead of constraining the expressive power to particular higher-level use cases. This is what the discussion on Promises right now is about. I mean no disrespect to the hard work of the people here. I know everyone > who is participating in the discussion here is putting a lot of time and > effort to better the language and the community. However, from my > "complete" outside it sounds like: > > - There is a working tested solution that evolved through usage and > solving real problems over several years*. * > - The committee is dictating a lot of changes for it. > - Changes are based on new design goals and theoretical considerations > like "purity". I'm not saying there are no very good arguments for > non-recursive assimilation and .chain (there are) , but they're still being > "dictated" over existing library solutions. > > I was under the impression the goal is to adopt what works in practice as > much as possible and not dictate solutions from the sky. If someone wants > `a different API there is nothing preventing them from creating a library > and doing that - then coming back with "Hey, our solution works, we have > 1000 dependencies on NPM" or "on second thought, that sounded very > interesting but people are complaining about usage". > One of the problems with just following existing solutions is that you'd also be copying the evolution mistakes and technical debts in those solutions. The committee **is** considering the existing solutions, and the use cases presented by people, which is a good thing. For example, for the "asynchronous map" use case, `.then()` is not usable short of adding plenty of special cases, and special cases don't compose cleanly. Standards are difficult because what you decide will shape the solutions that people write in the language for decades, standards evolve slowly, that's why you have less chances to make mistakes — in a library you can make a mistake and promptly fix it in the next version, this is not true of standards.