TC39 bashing

David Bruant bruant.d at
Thu May 10 01:41:27 PDT 2012

Le 10/05/2012 04:44, Mikeal Rogers a écrit :
> The core problem is that people who work nearly full time on designing a language are necessarily out of touch with people using it, and the people using it are ill equipped to balance the priorities all all the parties involved in designing it.
I understand your point, but I'm afraid I disagree with your vision 
which I think is too simplistic. Dave Herman's task.js is a library that 
has been suggested on the JSFixed thread about asynchronisity [1]. Dave 
Herman is part of TC39 and what he did seems to resonate well in the 
developer community.
It seems like you're opposing people who design the English language and 
people who use the English language. The world is not that dichotomic. 
People who used ECMAScript 3 felt the lack of .bind. People who design 
the language added it in ECMAScript 5.

> I think a better strategy is for TC-39 to state definitively what is *not* currently working on or is of a very low priority. This would allow the community of people using JavaScript to tackle those problems more directly rather than just waiting. At some point in the future TC-39 can adopt or ratify behavior that has proved itself in the community. I know this process is eluded to often but I don't think you understand how much momentum gets sucked out of the community when they are under the impression that new behavior will be handed down from TC-39 and that their work may fall in conflict or out of date.
> The recent discussion about Object.isObject is a great example. If this isn't happening please state so definitely so that we can rally around existing work (underscore) or build something new.
This point is interesting. Among the changes that TC39 have to make to 
the language, I see 2 categories. One is adding new language 
capabilities (WeakMap, proxies, lexical |this| functions, binary types, 
proto operator, etc.) the other is new built-in functions (for Array, 
Math, Object, etc.).
Maybe the latter category could be "(partially) delegated" to the 
developer community and ratified by TC39.
I foresee that with modules, a new field for this second category is 
opening and there will have some important discussion about what module 
should be in the standard and which shouldn't. Maybe the responsibility 
for this part could be also shared with the developer community since 
they are those who usually write these functions (out of need).

> It might be beneficial to invite a few people from the developer community to meetings and to rotate them out so that no one becomes truly intrenched in the process.
Or that the developer community decide to gather by itself and then 
share feedback on es-discuss.



More information about the es-discuss mailing list