---------- Forwarded message ----------
From: Brendan Eich <brendan at mozilla.com>
To: Kevin Smith <zenparsing at gmail.com>
Cc: "Mark S. Miller" <erights at google.com>, EcmaScript <
es-discuss at mozilla.org>
Date: Fri, 07 Feb 2014 16:05:20 -0500
Subject: Re: Promise.cast and Promise.resolve

>> A *working* implementation should be created and solutions to real-world
use cases should be programmed using the design before any spec language is
authored.  Spec-language is apoor medium for communicating both design
intent and programming intent.

> Yes, this.

I just want to add my two cents on this part here.

A lot of us are following this thread from the outside, being unable to
keep track of all the meetings ambiguities and agreements and the such.
Tracking it is hard with all the ambiguities and 'big words' people
sometimes throw and unclear use cases.

The way 'we' see it is:

 - Promises solve an interesting problem
 - 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.

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".

Sorry for the 'rant', will keep following closely.

Thanks,
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140208/c34d85c2/attachment-0001.html>

>> A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored.  Spec-language is apoor medium for communicating both design intent and programming intent.

> Yes, this.

I just want to add my two cents on this part here.

A lot of us are following this thread from the outside, being unable to
keep track of all the meetings ambiguities and agreements and the such.
Tracking it is hard with all the ambiguities and 'big words' people
sometimes throw and unclear use cases.

The way 'we' see it is:

 - Promises solve an interesting problem
 - 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.

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".

Sorry for the 'rant', will keep following closely.