Community feedback #162
Comments
|
The article doesn't even try to take a neutral stance (what the title translates to is "what went wrong in TC39"), so the answers are likely to be skewed in one direction, and even if the polling would somehow be statistically unbiased, it wouldn't add any new information, since it's already known that the proposal is controversial, which is a given for anything that breaks with familiarity. |
|
@slikts making a judgement basing only on title translation is not serious.
And there are more - please wait for translation before blaming me, because you already convinced few persons (@nicolo-ribaudo, @trotyl and @ccjmne) that this feedback is useless, which isn't true and leads to community breaks. Article gives full overview of existing proposal with all its advantages, disadvantages and trad-offs. And, I haven't seen anything like this before. Presentations from committee always avoid talking about trade-offs (like in existing README and FAQ), so community doesn't aware of ANY real problems behind it - from other side I did my best to be objective and cover all related things, including pros (mostly referring to existing docs/faq and justifying some committee decisions in comments) and cons without hiding problems under the carpet.
I can't agree, because this poll shows that not only few active persons in this repo care about disadvantages of existing proposal, but rather much bigger part of community. And this part would rather wait for better solution, than live with P.S.In my article I also raised important problem - lack of community feedback at early-stages. And, I personally will do my best to gather and provide such feedback for other proposals - but started from this one even though it's in |
|
I can read Russian, the tone is editorial, you make your preference against the proposal clear, so it biases any outcome of the poll.
No one has claimed the opposite, and a negative outcome to polling is expected just based on the unfamiliarity of the syntax. |
Repeating this again and again across threads doesn't make this statement true. I and many others showed dozens of times that negative feedback ISN'T caused ONLY by syntax even though it obviously affected it. |
|
It shouldn't need to be repeated that familiarity is a major factor in judgement. Everyone is closely familiar with syntax, while fewer people will have familiarity with decorators, and very few people will know what brands are in type systems. Negative reactions to changing familiar syntax for information hiding is completely predictable, and it was understood when the syntax was chosen as a compromise. Neither this poll nor the tallying of votes in #100 really add new information. What really matters are well-informed opinions, and that doesn't mean that they'll be uniform, if only because of human factors. The reason I keep repeating this is that it doesn't seem to be understood. |
|
@slikts it seems that you ignore the fact that syntax ISN'T major concern for most of the developers. When somebody (e.g. @littledan) presents this proposal, first reaction is "why Since, you mentioned that you can read Russian, and I start thinking that I haven't properly expressed my opinion, so you can understand it, I'll switch to Russian (everybody else, could ignore such part of comment, since it will be mostly paraphrasing of previous paragraph)
|
|
@slikts I get your position, but you're a little stuck. Those of us who want to stall this proposal don't care so much about the syntax. Look at the poll. In that poll, they said they don't want to kill the proposal. Why do you think that is? We all want language support for private! And admittedly, despite the issues with it, this proposal provides that. We want that. We just don't want to break any of the many other things we can do just to get it! I've been one of the biggest detractors of this proposal since I found out about it. As bad as the syntax is, if it didn't have all the semantic and functional problems, I'd gladly accept it without complaint. The problem is that this proposal interferes destructively with the existing language. That's what the people don't want. That's what this poll reflects. That's why TC39 should take heed. |
|
@Igmat You're making my point about turning the discussion into polemics by using loaded language about "spitting in the community's face" and arguing against imagined scenarios where the flaws would be withheld. @rdking The reason I'm "stuck" is because the numbers of votes keep being brought up as more meaningful than they are. For example, the meaning you're trying to read into this poll isn't even directly related to the questions asked; it's just what you want it to be. It would actually help your case more if you wouldn't grasp at every straw. |
I don't understand in what way the community's opinion is not important. It's not the TC39 that will be the lion's share of developers using the results, but rather the community. Now let's be honest about something: ~90% of all ES developers don't have a clue how it works under the hood and could care less as long as their intuition about what should and shouldn't work pans out. Among the remaining, only about half of them have the confidence to express their opinions on this. This tracks with every community poll I've ever seen done about anything technical related to ES. What does that matter?
Put another way, the opinions of the community are what's going to make or break this proposal. If the community rejects it in large part, then the proposal will have been a failure even after reaching stage 4. Of course, there will always be those who use it because it's far simpler than the alternatives, but that doesn't make this a good for the community.
I can't read Russian, so I'm basing my opinion on what's given in this thread. However, it looks to me like within the community that could understand @Igmat's article and decided to vote, there's an overwhelming consensus that this proposal needs to be re-worked. Few want to throw it away because there is a strong desire for language supported privacy, and this proposal is already so close, but it just isn't close enough. Tell me, what exactly am I reading into this that's not plainly obvious from the poll results? |
|
@slikts Part of the problem is that the various polls and "votes" on this repo are submitted by the community because TC39 members have repeatedly stated that they do not consider votes to be an appropriate or even useful metric to measure this proposal. I can understand this. However, the lack of information on the community feedback the TC39 did collect is troublesome. I see multiple comments from TC39 members on anecdotal and untracked conversations with "major frameworks, Node.js, large websites, etc". You yourself repeatedly state that the bulk of feedback has been about syntax when the vast majority of conversations I have been involved with in this proposal have less to do with the sigil/syntax and have been all about semantics and functionality and practical use cases. Every time an alternative is suggested, the result is always, this isn't new, we already thought of that, and it won't work because this other obscure thing that someone said about proxies, or membranes, or something else that is not mentioned in the FAQ anywhere. It was suggested to me to read the TC39 notes to see some of this conversation. I haven't gone through it all but I see plenty in the last meeting notes to see that it is anything but unanimous that this proposal is the correct path. There are no indications of a "consensus" written in the notes. In fact the conclusion is clearly marked "?". What other "major" frameworks were consulted? Were they presented with any alternatives? Were they presented with any of the trade-offs? What were their actual words on the matter? Right now the community has no visibility into this. Or at least it's very obscure. The constant feedback from the more advanced community on semantics and functionality in this repo over the last several months indicates to me that not everyone agrees with these "major" frameworks and websites of the TC39 members. The end result is that I (and I assume others) feel like this process is not working. Say what you want about the proposal or the alternatives, people have every right to disagree on different things and everyone thinks they know best. Fine, but the process is not working. |
This is a conjecture that doesn't even follow common sense. It takes no commitment to cast a vote in a poll, and it takes little commitment to leave a snippy comment about syntax. Meanwhile, the syntax being an universally familiar aspect of programming is a truism.
Your interpretation of the motivations behind the votes isn't reflected in the questions. The questions are just about what to do, not why. @shannon This is a thread specifically about votes and my remarks are in that context. Even though you say you understand why polling shouldn't dictate the design, you also seem to want to have it both ways and make the critics speak for "the community" based on the numbers. This actually detracts from the specific criticisms by taking away focus. I've personally grown weary of reading the long posts that amount to throwing things at the wall and seeing what sticks. |
|
@slikts My point was that the community is trying to fill a gap that the TC39 process has (at least with this proposal). I don't think every vote/poll should be taken at face value and there are lots of biases that get added without even realizing. But in the absence of any other information it's even easier to read them incorrectly. Framed correctly a questionnaire can be useful. Doing it correctly is hard but something a group of highly intelligent domain experts such as the TC39 committee should be able to achieve. If the process is really just let's ask the members of TC39 who happen to be the owners of major frameworks and large websites what they think and just go based on that. Well that's not community feedback, it's just committee feedback. It's not a democracy, I get it, but if that's the process then I don't think I really want to contribute to the process anymore and will just move on to something else. |
|
@slikts, we tried to focus on technical discussion with pros/cons of existing proposal and alternatives - it didn't work, because committee responded: So, what are you propose to do? P.S.
They are formulated in way which allows us to easily understand reasons behind them. |
|
What I propose you don't do is try to make this into the equivalent of a DoS attack, since it detracts from the actual technical points. If you insist on polling, look into topics like self-selection bias, since it's what a reliable polling methodology needs to control for. |
Somehow, I think you would be thoroughly dumbfounded by how often it occurs that in a technical community, those with insufficient knowledge find themselves unwilling to voice their own opinion on an issue they feel they do not adequately understand. Does that follow common sense? No. You're right on that point, but there are a lot of things in life that don't follow common sense yet are none-the-less real.
Ok. Then let's try rational analysis to see if my interpretations are truly not reflected. Let's treat this like a mystery. We have evidence (the poll) that a motivation exists, and decisions derived from that motivation. So tell me, what potential motivations exist that would make the community ~5 times more favorable towards either splitting the proposal or back-staging it over simply rejecting it? I'm offering
Notice this makes no claims about whether or not the proposal is wanted at all? Now tell me, what potential motivations are there for the community being ~20 times less likely to accept the proposal as is, and ~5 times less likely to accept the proposal with minor fixes, versus either splitting or back-staging the proposal? I'm offering
In all fairness, I have to offer both. However, given that @bakkot, @ljharb, & @littledan have all given testimony that an explanation of the syntax has been sufficient to make developers comfortable enough with the syntax, I find the second potential motivation significantly less likely. So, if you truly believe that my "interpretation of the motivations behind the votes isn't reflected in the questions", then please present me with other possible motivations that are a better fit to the evidence. I've shown you how I derived my opinion. Show me how you derived yours. |
|
Turning this into an existential discussion is what I mean by a DoS attack; I don't have time to unpack everything being said, so I'll just reiterate that the questions don't directly ask about motivations, so it's a matter of interpretation. A single leading article also won't turn people into domain experts, so they'll vote on what they know, which, for the most part, is syntax. |
|
I don't see why you're talking about an existential discussion and DoS attacks, which have nothing to do with the arguments being made in this thread. Here's the summary again: Out of all the people who felt confident enough voted on these issues:
If the goal of TC39 is to produce language features the majority of the community will want to use, then it should run polls of its own. Simply claiming that the will of the community is invalid or irrelevant is the same as saying that a business can stay alive indefinitely with little to no customers. Feel free to believe what you want, but it might be better not to refuse to see an inconvenient truth being put before you. |
As a courtesy you could try to understand what people take the time to say, especially since it's not with a rambling wall of text. |
As a courtesy, I'll say this once. Nothing that @Igmat or I have said is a matter of existentialism, but rather a discourse of how TC39's dismissal of the developer community's opinion could have a negative impact on the future of ES. Nothing we have said is a "rambling wall of text", or an attempt to flood the threads with off-topic information such as to prevent the necessary communication required to advance the current proposal (DoS attack) either. Your constant mischaracterization of other threads containing dissenting opinions, and your refusal to bother comprehending what's been said in this thread has helped me understand what value I should apply to your opinions. Thank you. |
|
There is just a lot of text. It takes time to read it all. I am not really sure how anyone can keep up. |
|
I get it, but I won't deign to comment on something I don't understand. What exists above is nothing more than an example of what happens when a community poll is given about this proposal, and conversation over why it would be beneficial for TC39 to do the same. I'm not entirely certain anyone can keep up. When unread portions of the thread get long, I mostly speed read looking for the important parts. |
|
There's minimal actual substance to keep up with; it's polling about things already known, asking for more polling about the same things, and doomsaying about what'll happen if polls aren't heeded; all padded in so many words that it takes too much time commitment to read and respond. |
|
To @Igmat's point, it would be great to have more confidence in the community feedback collection process. There's very little visibility into how feedback is collected outside of this repo. I believe (based on comments in this repo) that the committee members are generally objective and interested in listening. So I'm guessing that on a spectrum of comprehensive and balanced to completely biased, it's on the better end of that spectrum. But just as a survey can give skewed results depending on how it's written and conducted, it's also possible that private feedback from big websites and library maintainers could be biased depending on how tradeoffs were presented, or whether known downsides of certain decisions were presented at all. I don't know what could be done about this, since not all significant players in the industry will be interested in participating in public debates like the ones in this repo. I'll just say that I didn't find @littledan's comments in #151 very reassuring with regard to the Set vs Define issue. And even more importantly, I haven't seen any official consensus statement from the committee itself on this issue, explaining the technical reasons why they decided on Define, but only a few isolated comments in favor of it and a link to an earlier unsettled debate. It's great that the FAQ exists to explain the reasons for the syntax. I think it could be very helpful if there were a similar document explaining the most controversial semantic decisions. |
|
@rdking The verbosity is indeed an issue, and sometimes I think it actually hurts your cause. I can relate because I struggle to be concise sometimes too, but it's well worth the effort especially in public forums like this. (And to the rest of you reading this, I'm aware that I'm posting 3 comments at once here and I assure you that I am trying to communicate as concisely as possible.) Some of your comments could have probably been parts of a larger blog post or document that you would link to for those who want more detailed explanation. I think your creation of the class members proposal has been a good thing in this regard because it has provided a place to go deeper into some issues without inundating the issue threads here. |
|
@littledan On the other hand, I would also like to defend @rdking and others for repeating themselves in some cases. A lot of have it has arguably been unnecessarily verbose repetition, but there are a few sticking points to which the response from the committee has mostly been silence, and it's natural to repeat a question if it seems like it's being overlooked or disregarded. I sympathize with the committee because I know a herculean effort has gone into this proposal, including the community feedback process, and everyone has limited time. But I think it would really help the discussions here if the most controversial points other than the syntax (which has already been addressed a lot) were addressed more fully and formally by the committee, especially the request for a list of requirements for this proposal and the reasons for them. |
|
I finally translated my article, so you can read it in medium. I hope that @littledan, @ljharb, @zenparsing or anybody else from @tc39 committee is able to assess this article, poll and its results for possible further impact on proposal. |
|
@mbrowne I get the issue with me being verbose. I can be very terse when being concise, so it often leads to misunderstandings (mostly due to me thinking some concepts in my head are easy to understand when they're probably not), especially when dealing with a nuanced subject like language-internal details. That's the reason why I've been being verbose. |
|
@Igmat |
|
@DmitryOlkhovoi There's a major problem with that. Consider: class Demo {
// if this gets set to Demo.prototype.arr...
arr = [1]
}
const d1 = new Demo()
const d2 = new Demo()
d1.arr.push(2);
console.log(d2.arr) // [1,2] - the same array is shared across all instances! |
|
@mbrowne Yes, but on the other hand we don't create the array every time. |
|
Yes, that predates stage 3. |
|
@ljharb, @littledan but what about questions raised in the beginning of the thread? |
|
@ljharb, @littledan why do you ignore this thread? Should I take such behavior as a signal that you don't care about such kinds of feedback? |
|
@Igmat I think the criticism of your surveying techniques is valid. I also think that while community feedback is important, making decisions via poll is a very poor way to do language design. Although I personally prefer [[Set]] over [[Define]], and argued for it strenuously over the previous years, i think the current proposal (using [[Define]]) is sufficient, and I think this feature is too important to delay even more over the difference between Set and Define. All other criticisms of the current proposal I've heard either fail to account for various requirements; or are objections merely over surface syntax that don't offer an equivalent better solution (or deal with Proxy issues that predate this proposal, and should be solved, but independently). There are no questions in the beginning of the thread to answer; the only question is the one that heads your "survey" results. Can you share any questions (new ones are fine, since there are none otherwise in this thread) for which you'd like answers? |
|
This survey represents community much better than anything provided by committee till this moment - all we have from you is only "we've talked to some peoples at conferences and they agreed with our approach". You also mentioned, that community wants I can bet that, while you were presenting current proposal to somebody who isn't aware of it fully, you were avoiding all of its controversial parts (e.g. Ok, I can talk about wrong assumptions behind this proposal further and further. But my question is: Would you make at least some steps to reach consensus with community or you're fine with your internal |
This continues to be rather uncharitable towards the members who have spent time addressing the issues. It's not that you haven't received answers, but just that you don't like them. The simple truth is that the process isn't and shouldn't be dictated by polling. |
No important issues were truly addressed. Some of them (like Proxy problem with brand-checking) were left as is with comments like "we know that this is a problem, we don't have any workarounds for it with current solution, but we don't care - somebody in future will somehow solve it", and others left as is with comments like "we prefer X instead of Y, because... well, because we like X". It's not a problem solving, but rather just ignor of them. Also, I understand that some of those issues could appear because of different priorities. But committee don't share this priority list with community, despite the fact that we asked about it dozens of times.
I didn't get answers why some alternatives doesn't work, because after addressing several issues from committee according to one or another alternative they just stop talking about it, leaving them unassessed.
I don't propose to dictate process by polling, I propose to have better process. In this repo, we provided a lot of technical arguments against this proposal - and get answer |
|
Nobody said they didn't care; but the Proxy thing can not be solved as part of this proposal, because it affects the existing language too. It only makes sense to address it independently. The committee consists of dozens of people - are each of us under an obligation to explicitly and painstakingly document the things we care about, and publish them? If there's an alternative that won't work for which you don't feel an answer has been provided, please do locate the issue for that alternative (please, not in this thread) and clarify what you don't understand? |
This is just case in point for being uncharitable, as the one specific example you mention actually was addressed. |
|
@Igmat @slikts Must you both describe your opinion in such an extreme way that implies those who disagree with you are completely unreasonable and unfair? I am glad that I am not the only one here defending the committee nor the only one criticizing where their efforts at transparency have fallen short, but the acrimony just makes things worse. Although I don't want to completely side with the committee, I do feel compelled to say: there are those who have been flooding threads with an overwhelming volume of comments (I'm not referring to you, @Igmat) and it's really unreasonable to expect a detailed response to every single point raised by every single person. |
|
@ljharb A private symbol approach was dismissed because it had an issue with Membranes and Proxies. As far as I understand based on your (and others') comments this issue is not new and already exists for weakmap based private. If this is a problem that should be addressed independently for the private fields proposal how can it simultaneously be an objection for private symbols? I say this because it is becoming increasingly difficult to understand what TC39 considers important. |
|
@shannon i believe it’s the opposite problem - private symbols give too much access; the existing proxy issue is that too little access is available. It’s better imo to err on the side of proxies being too transparent in the absence of membranes rather than erring on the side of allowing encapsulation to be broken in the case where membrane-based approaches are necessary. That said, i still hope we can come up with a middle ground solution - and if we do, it would likely cover internal slots of builtins as well as private fields. |
@ljharb it's impossible to solve proxy transparency problem, unless you agree that |
No, but if you want to have community support you must not ignore frequent and explicit asks from them. You may not need list of priorities for a lot of other proposals, because they aren't such controversial as this one, but for this particular case it's required to seriously justify your decision, which wasn't done (existing FAQ overs only ~30% of issues) unless committee doesn't care about community. I realize, that I may sound very offending and aggressive. Sorry about that, I don't attack anybody personally - and I appreciate all your efforts (whether you'r committee member or not). |
This continues to be rather uncharitable towards the |
Actually V8 implement private field use privatesymbol-like mechanism --- the brand-check error is just like: If current |
Constructive discussion requires a basic level of charitability, and this is not it. |
|
@slikts do you have something constructive to say, or you're able only to repeat yourself again and again? All technical reasoning behind this proposal, while capable of answering some questions at first glance, always failed to answer deeper questions, like in this #149 (comment) or in discussion why foot-guns of We, as community, don't get any priority list or properly justified reasons for controversial parts of this proposal. For any particular technical parts - we have number of unanswered questions and arguments. P.S.
I did put much more than just a basic level. For example, this issue (#134) I started from advantages of current proposal and was trying to leave them unchanged. I spent a huge amount of time investigating I put so many efforts to all this activities, trying to find solutions for committee problems (even though they aren't problems for me) to get NOTHING back. Each time some of committee members didn't have answer or had to confirm that some decisions were wrong, he just starts to ignore this question, or even close unfinished issues (like #134, #136, #140 (comment), #133, #122) |
|
Charitability doesn't refer to effort but to interpreting others charitably; your statements I've quoted about the members basically portray them as irrational (supporting decisions without valid reasons) and evasive, which is obviously not the case. Me pointing this out should be helpful since it explains why you're not getting the responses you want. |
|
@slikts I and others may indeed hold the view that TC39 has been evasive. This is true. However, what they've been evasive about is the validation of their decisions. What constraints were they bound to? What requirements must hold true? What justification validates their particular perspective that the trade-offs they're about to force onto the community will represent an overall good instead of an unwanted new collection of foot-guns? I doubt any of us think TC39 has actually been irrational. They are obviously an intelligent group. However, we in the community can only respond to what we are shown. When we are given "just because" reasons without any divulged rational backing as a response to a rational argument complete with examples and backing justification, despite the numerous attempts to acquire the rational backing for their perspective... Well.... Suffice it to say that at some point, we eventually have to stop assuming that there is a rational reason backing their decisions at all. I don't think we're there yet. Though, I can't guarantee that this is true for all of us. |
|
A couple of thoughts:
In America we're celebrating Thanksgiving today. In that spirit I want to thank everyone that works on these standards and who engages in these often times difficult conversations. But while being thankful, let's not settle in and believe that we've arrived at the perfect process. Let's continue to work to improve all of this so that we can build the best web for as many people as possible. /cc @littledan What next steps can we take to improve this process, engagement, communication, etc.? Should we get together some people to start brainstorming? |
|
@EisenbergEffect Thanks for your kind message. I would be happy to brainstorm on further improvements here. I agree we're at the beginning. I am not sure if TC39 has a good place to put these suggestions right now, so how about we draft ideas at tc39/js-outreach-groups#4 for now? |
|
FYI: #180 |
|
I appreciate the work @Igmat put into the article described above. I'm excited to work with you on a local meeting at tc39/js-outreach-groups#6 . Let's follow up about next steps for improving inclusion in https://github.com/littledan/js-outreach-groups . |
I've written overview article (English version) for current proposal at the biggest portal for Russian-speaking developers yesterday.
Obviously, article is in Russian, so majority of you won't be able to read it, until I make a translation (it's in progress now).
But important thing is that I also organized a poll there, since habr uses invite system such poll is little bit more accurate, because users most likely have proper background to provide valuable feedback. And current result is:
class-fields-proposal?[[Define]]semantic to[[Set]]ProxyProxy, and change[[Define]]semantic to[[Set]]stage1/stage2in order to solve existing problems and/or assess alternativespublicandprivate), wherepublicpart should be accepted andprivateshould be reworkedTotal views: more than 4700
Total voters: 109
Those who only interested in results: 35
In most cases duration of discussion around articles at this portal is one week, so in 7 days we'll have more accurate result (I expect that it will have at least 10k views, because my previous article was viewed more than 25k times) and I'll update this post.
But it seems that we can already say that community doesn't satisfied with current proposal.
The text was updated successfully, but these errors were encountered: