I understand all the hook rules and all the gotchas around stale closures. But I don't want to have to deal with those as part of my everyday, regular programming, it's just stupid. React is no longer productive and hooks are way out of control. Did you know hooks are even more stupid with concurrent mode on?
There's a difference between trying to make the community inclusive, and trying to make the core development group inclusive. Asking people not to say "guys" in community fora is an attempt to make more people comfortable using those fora in the first place. It has nothing to do with actually developing the language itself, just with using the language.
That's like saying it's ironic that a taxi driver will let you sit in the back but won't let you drive the taxi.
I must have some very womanly traits then. When I first joined my engineering school, I felt so bad/inadequate because all the guys were like "yeah this is easy, I totally got this" and I was like "really? it's not that easy imo!" (for me, easy means I understand 100% of the topic)
First few exams and I had WAY better marks than all of them, lol.
More specifically, it's called the Dunning-Kruger effect. Impostor syndrome is a broader description that heavily overlaps with the "give up competing due to perceived losses" that the article talks about.
(As a side effect of this, one could predict that approaches to mitigation of impostor syndrome (which there are a few of) will be especially helpful if you're concerned about improving women's representation. Somewhat ironically though, the "ideological echo chamber" that is most active in pursuing these goals is not always very open to such notions!)
Saying a class is easy is not the Dunning-Kruger effect, especially when the class is easy for the individual. Thinking mastering the entire field is easy because the intro class was easy is a far better match of the Dunning-Kruger effect.
Someone who is well aware of how complex a subject is can find a given class to be easy, which would imply they are not under the Dunning-Kruger effect. Confidence alone is not sufficient.
Edit: that they ended up with lower marks due to not studying due to overconfidence due to the earlier ease of the topic seems like it would fall under Dunning-Kruger.
No, you have it backwards. Dunning-Kruger describes incompetent people thinking their work is high quality, or overestimating their level of competence. Impostor syndrome is when people feel inadequate despite producing acceptable work.
Not sure why Evan is not being more transparent regarding this renaming.
It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"
Insead he's like: "what? it was the plan all along :)"
That's partly my fault. Evan focuses on more technical sides of things but there are people in the team that focus more on the community aspect and we didn't catch that potential naming issue and the whole message that the RFC gives away.
We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.
The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.
Yes it's terrible naming. The more abstract the naming, the harder it is to reason about.
Plus, JS/TS already have proper union types without a need for a construct like Either.
A better naming for 99% of cases is (like found in Elm)
Plus, JS/TS already have proper union types without a need for a construct like Either.
I disagree - what if on success it returns a string representing some data, and on failure it returns a string detailing the error? A `string | string` return type is not very useful, while an `Either<string, string>` is IMO.
I'm not sure I would consider uniformity "low" standards.
It's quite useful when there are multiple smallish projects, for example your typical web agency.
Also useful when you have one or two experienced programmers and a few less experienced ones: makes it easier to review the code.
That said for a highly custom application, especially one you're betting the company on, and need full control, a lower level approach can be beneficial.
Not limited to Angular vs Vue.js, the same applies to Django and Flask for example.
