Le 10/05/2012 20:04, Anton Kovalyov a écrit :
it'd be really nice to have down-to-earth explanation of harmonized
changes with code samples that resemble real world use cases.
Yes.
TC39 can not ask the opinion of every developers or community
representatives, and developers can not spend their time following TC39
But I am not sure that TC39 does really realize how far they are from
the "advanced" developers, not talking about the "usual" webmasters...
A side effect is that a lot of wrong things are advised or said on well
known forums or projects, then things keep being developed wrongly as it
is the tendance since a long time in the web world, and right code is
reserved to a very specific elite, making both life of language
designers and developers hard, making js less and less accessible
Then the truth should come from TC39 with the help of developers, and
maybe a significant effort should be made to make things more
understandable with simple real world use cases, starting with official
strawman proposals/ES specs simplificated version annexes that could
include for example this kind of attempt
https://github.com/es5/es5.github.com/pull/14
A performances annex would be good too (ie what to use or not use if you
care about performances)
On Thursday, May 10, 2012 at 9:34 AM, Mikeal Rogers wrote:
On May 10, 2012, at May 10, 20121:41 AM, David Bruant wrote:
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).
There is a difference to TC-39 but not much of a different to the
community. The web developer motto is "suck it up", if something is
broken we write a workaround or monkey patch it, If something is
impossible to do one way we find another way.
People in the community don't ask for "WeakMap" until there is a
proposal. Instead they come up with other crazy ways to accomplish
their end goals without needing such a type to varying degrees
success (we're still finding leaks in FreeList in node.js http.js
that might have been prevented had we had WeakMap a few years ago).
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.
That's hard. JavaScript is a diverse community which also means that
it is fragmented. I think the node.js community has a good core group
of leadership with somewhat consistent ideas about what the community
wants from the language. There are leaders in the web developer
community that I believe could speak well to their supporters (Jeremy
Ashkenas, Thomas Fuchs) but there isn't a place where the js
community really comes together outside of JSConf and the range of
ideas is a diverse as the community.
Maybe it would be a good idea to carve out some time at developer
events that bring these groups together to discuss what people want
out of the language and invite a leader from that group to a TC-39
meeting some time after. I can carve out some time at NodeConf and I
can talk to the BackboneConf guys about doing the same.
David
[1] https://github.com/JSFixed/JSFixed/issues/1
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
