New private names proposal

Brendan Eich brendan at mozilla.com
Thu Dec 23 18:53:17 PST 2010


On Dec 23, 2010, at 5:20 PM, Mark S. Miller wrote:

> On Thu, Dec 23, 2010 at 1:06 PM, David Herman <dherman at mozilla.com> wrote:
> 
> All we've asked is that we not assume prima facie that we must pick a winner and stop all work on the other. That said, I don't think we should do much design work on the list or in committee meetings. The "champions" model has worked well (for example, for the proxies spec). I think Allen and others should continue working on private names, and Mark and others should continue working on soft fields. This conversation has raised helpful feedback and ideas, so now it's time for people to go back to the drawing board and do some more independent design work.
> 
> 
> 
> +1. 
> 
> I feel like we've made important progress on this thread: We broke through an impasse of mutual inability to understand each other, are now in a position of a fair degree of mutual understanding, and at a remaining impasse only at making progress from understanding towards towards agreement. I have had some good aha's in getting here, and I hope others have too,

Agreed. It felt painful because it *was* painful. Mistakes were made but to err is human. The only way forward is "up".


> but now I feel like we're arguing about the nature of our argument rather than the subject matter. I do not feel I am learning anything new. I think reverting to off-list design work before another round of on-list discussion is a fine thing, and I do like the champion model. So I fully endorse your paragraph above.

+∞


> That said, once we do resume these on-list or in meeting discussions, I see much right and nothing wrong with comparing the proposals and seeing how much use-case ground that we actually care about we can cover with how little mechanism. Questions of the form "If A can cover this subset of the use cases motivating B, do we need B?" are perfectly legitimate. Indeed, asking such questions vigorously is our only hope at avoiding a kitchen sink language. We have seen the usability of other languages be ruined by undisciplined growth.

Agreed, post-hoc or as I put it a while ago, _a posteriori_.


> That does not mean that we need to ask these questions so early as to suppress exploration and brainstorming. But we are the gatekeepers between "strawman" and "proposal". We need to ask these questions before admitting designs across this threshold.

Fully agree.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101223/e3d955c6/attachment.html>


More information about the es-discuss mailing list