Skip to content
This repository has been archived by the owner. It is now read-only.

Community feedback #162

Closed
Igmat opened this issue Oct 30, 2018 · 63 comments
Closed

Community feedback #162

Igmat opened this issue Oct 30, 2018 · 63 comments

Comments

@Igmat
Copy link

@Igmat Igmat commented Oct 30, 2018

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:

What should be done with class-fields-proposal? Total votes %
Accept as is 3 2.7
Accept, but change [[Define]] semantic to [[Set]] 7 6.4
Accept, but tunnel private properties through Proxy 2 1.8
Accept, but tunnel private properties through Proxy, and change [[Define]] semantic to [[Set]] 6 5.5
Move to stage1/stage2 in order to solve existing problems and/or assess alternatives 32 29.3
Reject in favor of one of the alternatives 6 5.5
Reject fully, since we don't need neither public nor private fields 11 10
Separate into 2 proposal (public and private), where public part should be accepted and private should be reworked 42 38.5

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

@slikts
Copy link

@slikts slikts commented Oct 30, 2018

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.

@Igmat
Copy link
Author

@Igmat Igmat commented Oct 31, 2018

@slikts making a judgement basing only on title translation is not serious.
While, it's not a 100% neutral (because it's just impossible) I tried to be as objective as possible. For example few translated quotes:

Despite all the above, I am not an irreconcilable opponent of the [[Define]] semantics (although I would prefer [[Set]]), because it has its own positive aspects.

All this stuff is related to syntax only, which means that subjective aesthetic opinion comes in play. In the end we could live with such syntax and get used to it.

It's very good - we could have hard-private , which can't be accessed/intercepted/tracked from outer code and at the same time we're even able to access privates of another instance of same class.

brand-check, actually, has its own use cases - in most cases they relate to secure execution of untrusted code in same process with possibility to share objects directly without serializing/deserializing overhead.

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.


it wouldn't add any new information

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 half-backed feature.

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

@slikts
Copy link

@slikts slikts commented Oct 31, 2018

I can read Russian, the tone is editorial, you make your preference against the proposal clear, so it biases any outcome of the poll.

I can't agree, because this poll shows that not only few active persons in this repo care about disadvantages of existing proposal …

No one has claimed the opposite, and a negative outcome to polling is expected just based on the unfamiliarity of the syntax.

@Igmat
Copy link
Author

@Igmat Igmat commented Oct 31, 2018

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.

@slikts
Copy link

@slikts slikts commented Oct 31, 2018

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.

@Igmat
Copy link
Author

@Igmat Igmat commented Oct 31, 2018

@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 #?", he answers why (repeating FAQ) and developers agree that it's ok - then committee decides that developers would be ok with proposal after getting used to new syntax. But developers AREN'T aware of other trade-offs (e.g. brand-check and [[Define]] semantic), because they just don't think about them and committee doesn't tell. My article tries to fulfill this gap.

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)

Я уже много раз писал, что, несмотря на факт того, что первая реакция - это непринятие синтаксиса, проблема намного глубже т.к. происходит приблизительно следующее:

  1. Комитет презентует этот пропозал
  2. Разработчики высказывают недовольство синтаксисом
  3. Комитет его объясняет
  4. Разработчки соглашаются с ними
  5. Комитет решает, что всё ок и любой дальнейший фидбек не имеет смысла

Но это не так, разработчики могут СПОКОЙНО принять синтаксис. Но когда они узнают, что пропозал обладает СЕМАНТИКОЙ, которая ломает существующие юз кейсы и добавляет скрытые проблемы, они НЕ ХОТЯТ его принимать несмотря на другие преимущества, которые он даёт. Между ПЛОХОЕ + ХОРОШОЕ или НИЧЕГО они предпочитают НИЧЕГО.
Моя статья описывает изменения в семантике, а опрос демонстрирует, что людям такие изменения НЕ НУЖНЫ. Игнор подобного фидбека комитетом это просто плевок в лицо комьюнити, мол "вы (комьюнити) ничего не понимаете и юз-кейсы ваши ничтожны, а мы (комитет) всё знаем намного лучше и наши юз-кейсы и планы намного важнее ваших".

@rdking
Copy link

@rdking rdking commented Oct 31, 2018

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

@slikts
Copy link

@slikts slikts commented Nov 1, 2018

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

@rdking
Copy link

@rdking rdking commented Nov 1, 2018

@slikts

The reason I'm "stuck" is because the numbers of votes keep being brought up as more meaningful than they are.

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?

  • The voter turn-out over a non-filtered open poll tracks those numbers closely enough, lending them credibility.
  • Those who voted have a high likelihood of having enough experience to understand the ramifications of this proposal on their projects and the libraries they import.
  • The opinions of such developers should not be taken lightly as it is they who are most likely to either encourage or dissuade the use of any given language feature within their sphere of influence.

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.

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 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?

@shannon
Copy link

@shannon shannon commented Nov 1, 2018

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

@slikts
Copy link

@slikts slikts commented Nov 1, 2018

Those who voted have a high likelihood of having enough experience to understand the ramifications of this proposal on their projects and the libraries they import.

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.

Tell me, what exactly am I reading into this that's not plainly obvious from the poll results?

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.

@shannon
Copy link

@shannon shannon commented Nov 1, 2018

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

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 1, 2018

@slikts, we tried to focus on technical discussion with pros/cons of existing proposal and alternatives - it didn't work, because committee responded: it doesn't affect the majority, but only few active persons in this repo. Then I tried to get response from community, and you say that such poll doesn't make any sense.

So, what are you propose to do?

P.S.

The questions are just about what to do, not why.

They are formulated in way which allows us to easily understand reasons behind them.

@slikts
Copy link

@slikts slikts commented Nov 1, 2018

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.

@rdking
Copy link

@rdking rdking commented Nov 1, 2018

@slikts

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.

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.

Your interpretation of the motivations behind the votes isn't reflected in the questions. The questions are just about what to do, not why.

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

  • "a strong desire to gain some of the features of the proposal sooner rather than later".

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

  • "a strong desire to not pay the trade-offs that the current proposal demands"
  • "a strong desire not to put up with the syntax the current proposal demands"

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.

@slikts
Copy link

@slikts slikts commented Nov 1, 2018

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.

@rdking
Copy link

@rdking rdking commented Nov 1, 2018

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:

  • Only 3 out of 92 would choose to accept the proposal as is.
    • Regardless of their motivations, that's a pretty strong indication of a potential problem.
  • Only 13 out of 92 would choose to accept the proposal with a small modification.
    • Put another way 13 out of 16 voters who would accept this proposal believes it needs at least some small modification.
  • 76 out of 92 voters would rather see this proposal stopped, stalled, replaced, or split.
    • Infer what you will about motivation, but if that's any indication at all about how this proposal will be received by the public, this is not good news.
  • Only 13 out of 76 voters who won't accept it even with a small modification would see this proposal rejected or replaced.
    • Again, infer what you will about motivations, but it looks like there is at least some desire to get these features released sooner rather than later.

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.

@slikts
Copy link

@slikts slikts commented Nov 2, 2018

… which have nothing to do with the arguments being made in this thread.

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.

@rdking
Copy link

@rdking rdking commented Nov 2, 2018

@slikts

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.

@littledan
Copy link
Member

@littledan littledan commented Nov 2, 2018

There is just a lot of text. It takes time to read it all. I am not really sure how anyone can keep up.

@rdking
Copy link

@rdking rdking commented Nov 2, 2018

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.

@slikts
Copy link

@slikts slikts commented Nov 3, 2018

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.

@mbrowne
Copy link

@mbrowne mbrowne commented Nov 6, 2018

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.

@mbrowne
Copy link

@mbrowne mbrowne commented Nov 6, 2018

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

@mbrowne
Copy link

@mbrowne mbrowne commented Nov 6, 2018

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

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 6, 2018

I finally translated my article, so you can read it in medium.
I focused on trade-offs of this proposal, since they aren't covered anywhere outside of this github repo, so community feedback could be reasonable ONLY if responders are AWARE of limitations of this porposal and not only of advantages.
I also updated first post in this thread with latest related info.

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.

@rdking
Copy link

@rdking rdking commented Nov 6, 2018

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

@DmitryOlkhovoi
Copy link

@DmitryOlkhovoi DmitryOlkhovoi commented Nov 10, 2018

@Igmat
I think fields should be setted in the prototype as methods. For now plugin-proposal-class-properties sets them in the constructor as an object property and I don't understand why. It looks inconsistent, could someone explain?

@mbrowne
Copy link

@mbrowne mbrowne commented Nov 10, 2018

@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!

@DmitryOlkhovoi
Copy link

@DmitryOlkhovoi DmitryOlkhovoi commented Nov 10, 2018

@mbrowne Yes, but on the other hand we don't create the array every time.
I understand the problem. But maybe then it should be called differently? Object fields? :)

@ljharb
Copy link
Member

@ljharb ljharb commented Nov 10, 2018

Yes, that predates stage 3.

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 11, 2018

@ljharb, @littledan but what about questions raised in the beginning of the thread?

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 18, 2018

@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?

@ljharb
Copy link
Member

@ljharb ljharb commented Nov 19, 2018

@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?

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 19, 2018

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 privates ASAP based on your talks with somebody (with whom?) - but as we can see community would rather prefer getting them later, than getting them broken.

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. Define semantic, brand-checking, Proxy issues and others) and you still refer to such feedback, saying "after explaining motivations. majority accepts this proposal" even though responders weren't aware of ANY trade-offs.


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 consensus in the room?

@slikts
Copy link

@slikts slikts commented Nov 20, 2018

at least some steps

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.

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 20, 2018

This continues to be rather uncharitable towards the members who have spent time addressing the issues.

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.

It's not that you haven't received answers, but just that you don't like them.

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.

The simple truth is that the process isn't and shouldn't be dictated by polling.

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 you don't represent wider community, so these issues important only for you (3-5 persons) and not important for us (committee, 20+ persons (sorry if I'm mistaken with number)), in this case we choose to continue with our approach.
In this thread I provided feedback from community - and you tell me that I'm trying to make process dictated by polling? It's wrong - I'm just trying to show that in addition to all our technical issues, we have some kind of community support that share our concerns regarding existing proposal.

@ljharb
Copy link
Member

@ljharb ljharb commented Nov 20, 2018

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?

@slikts
Copy link

@slikts slikts commented Nov 20, 2018

No important issues were truly addressed.

This is just case in point for being uncharitable, as the one specific example you mention actually was addressed.

@mbrowne
Copy link

@mbrowne mbrowne commented Nov 20, 2018

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

@shannon
Copy link

@shannon shannon commented Nov 20, 2018

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

@ljharb
Copy link
Member

@ljharb ljharb commented Nov 20, 2018

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

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 20, 2018

@ljharb I've already shown here that membrane pattern could be effectively implemented with private symbols approach without breaking encapsulation. And I even volunteered to create repo with such implementation - but nobody responded.

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 20, 2018

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 brand-checking isn't required for encapsulation. So any future solution will dismiss brand-check from requirements in order to solve this problem. But if you can imagine that we'll dismiss this requirement later, why do we have to stick with it now?

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 20, 2018

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?

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).
But I'm tired - I spent a lot of time trying to figure out what happens here, how it works and justifying existing proposal for myself and I failed. I don't see any valuable reason to accept this proposal as is without even giving a chance for alternatives and arguments from proponents of this proposal are to week comparing to arguments in favor of private symbols for example...

@hax
Copy link
Member

@hax hax commented Nov 20, 2018

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.

This continues to be rather uncharitable towards the members objectors who have spent time addressing the issues (remember it's the job of TC39 members to solve the issues, not us, we discuss here in our free time or even work time with no pay). It's not that you haven't received answers feedbacks from the community, but just that you don't like them. The simple truth is that the process isn't and shouldn't be dictated by polling is just broken.

@hax
Copy link
Member

@hax hax commented Nov 20, 2018

@ljharb

private symbols give too much access

Actually V8 implement private field use privatesymbol-like mechanism --- the brand-check error is just like: Invalid private field 'Symbol()'

If current Symbol.private proposal give too much, we can just make it behavior just like weakmap --- this is just what V8 did.

@slikts
Copy link

@slikts slikts commented Nov 21, 2018

… don't see any valuable reason …

Constructive discussion requires a basic level of charitability, and this is not it.

@Igmat
Copy link
Author

@Igmat Igmat commented Nov 21, 2018

@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 [[Set]] are worse than foot-guns of [[Define]], instead committee refers to some earlier internal discussions or hidden feedback from some big projects maintainers.

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.
For any organizational part e.g. feedback from some guys, we have this poll and reaction of Aurelia (@EisenbergEffect) and Vue.js (@yyx990803) maintainers.

P.S.

requires a basic level of charitability

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 Membrane pattern, it's possible use cases and implementation details (because it seems to be a reason for some decisions), even though I DON'T need it neither for my pet-projects nor day-to-day work. I put so many efforts that I even found a solution for implementing this pattern with Symbol.private proposal (which seemed to be the reason why this alternative is non-starter).

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)

@slikts
Copy link

@slikts slikts commented Nov 22, 2018

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.

@rdking
Copy link

@rdking rdking commented Nov 22, 2018

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

@EisenbergEffect
Copy link

@EisenbergEffect EisenbergEffect commented Nov 22, 2018

A couple of thoughts:

  • We have a diverse, global community. After leading open source for 13+ years, I've come to learn that sometimes what seems as aggressive communication can just be a language or cultural difference. So, I try not to be too quick to jump on communication styles. I try to see through that to the usually meaningful point under all that. There's very rarely nothing to be gleaned from the conversation.
  • Some of us have interacted with various standards bodies over a number of years and have a collection of experiences which color our expectations and interpretation of responses. It's not ideal but it's human. I've had negative experiences with WHATWG, W3C, and tc39, and so have others. So, we bring that with us when we see responses coming from standards group members.
  • When the Aurelia core team started engaging on this issue, we saw an almost universal dismissal of our concerns. I applaud @littledan because he was someone who not only didn't dismiss things, but worked to find compromises and took action to set up opportunities for discussion. Thank you.
  • When we met to discuss this, there was talk about not only this feature but what tc39 could do to increase transparency, involve more people and ensure that features were designed with a solid set of use cases from the real world. We should get some concrete action items related to this and move them forward. In my opinion, this is more important than any particular language feature.
  • Regardless of the above, it should be acknowledged that there is an odd relationship between the web standards bodies and the rest of the world. To throw an American-ism in here, it feels a bit like "taxation without representation". The decisions made here affect the whole world but those people don't always feel that this group has our best interests in mind, nor do motivated individuals have a good way to interact. Moving things to GitHub is a positive change, but more is required.

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?

@littledan
Copy link
Member

@littledan littledan commented Dec 6, 2018

@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?

@hax
Copy link
Member

@hax hax commented Dec 10, 2018

FYI: #180

@littledan
Copy link
Member

@littledan littledan commented Jan 4, 2019

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 .

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants