Without it i would have never been able to succeed in life. For me it was the single greatest decision i have ever made in my life. I simply could not focus on anything important, I was a miserable mess.
I was a consistent grade D student in high school, I was that werido in class who everyone hated. In my final year my parents realizing I was not going to have a great future, decided to bring me to our doctor, I was prescribed Dexedrine for ADHD.
That Pill completely and utterly changed me in my final year, i could think clearly. I understood what was being said, it completely changed me. I suddenly decided to go to University for CS, forcing me to do a victory lap in high school. I was able to get into University on an amazing scholarship.
However the biggest thing was the few people who i was vaguely friends with me praised my 180 personality change, they liked being my friend.
I am now 36 years old taking the same dose of meds i have been for the last 20 years. It works for me, immensely. At the same time there is a huge stigma around ADHD medication. My ex hated the idea of me taking meds saying its big pharma pushing this, i don't need this, i just need exercise, etc. She changed her tune after she saw me not on my medication.
I know there are probably people out there that don't need this or abuse it. Sure, but that is true for almost everything.
The company I work for did something similar at the end of last year. We had consultants who went over everything, and made a massive document of all sorts of things they deemed "problematic". Along with a week long of seminars/training/workshops on sensitivity/inclusion/etc.
- Everyone had to list what pronouns they wanted people to use. In slack / our email footers everything. This was not optional. We were also told that referring to people by their names instead of pronouns can be offensive.
- Words such as "master", "owner", among some other ones were deemed problematic and needed to be changed. Ironically they also said use of "CRUD" was inappropriate because it was slang for poop.
- We have a bunch of things where we have an owner of users/reports/etc, and we have a bunch of code with stuff like "listUsersOwnedByUser", which apparently could be construed as offensive by certain groups of people.
- A bunch of verbs such as "see", or "visible" could be ablest, etc.
- Our company had a completely optional get out/get exercising type of thing since everyone is WFH, and apparently exercise could be considered offensive to people.
- Our company of 300 people does not have some sort of LGBTQIA+ outreach program.
Some of it made sense, but a lot of it was frankly so nitpicky and difficult to even understand. Pretty much everything we were told/taught went out the window almost immediately.
> Words such as "master", "owner", among some other ones were deemed problematic and needed to be changed.
This is slippery slope happening right before your eyes. For those who claimed that slippery slope is just a fallacy and never ever can be true.
When did Github change the default branch name from "master" to "main"? Few months ago? Now it's "owner" too, and using this word probably could get you in some real trouble.
I'm not even going to comment on "see" and "visible".
Every time I see a project on GitHub being pressured to change a term because of PC a little of me die inside. I still remember the PR where someone changed the term master to primary in Swift and Chris Lattner wrote a comment to object, only to delete it shortly after likely due to pressure.
It's a shame we can't stand up against bullshits like that because there's too much to lose.
What drives me crazy about the "master" vs "main" branch name is that before this started the branch name "master" was in my mind a completely un-racist definition. Now the debate has changed my the link in my mind to the point where I feel like a branch name has racist history and I feel dirty typing it.
That is where this movement is being counterproductive -- it's injecting racial division into places where there was none (neither systemic, nor overt, nor covert) before.
You give them too much credit. Injecting racial division is the entire point. Critical race theorists want to divide everyone up by their immutable characteristics, discriminate on the basis of race, and make everyone as hyper-conscious about skin colour as possible. They explicitly say that they want to undermine the American liberal order and do away with such concepts as legal neutrality and equality under the law; here's a quote from page 3 of Critical Race Theory: An Introduction, one of the leading textbooks:
> Unlike traditional civil rights discourse, which stresses incrementalism and step-by-step progress, critical race theory questions the very foundations of the liberal order, including equality theory, legal reasoning, Enlightenment rationalism, and neutral principles of constitutional law.
You saw this with Trump's anti-CRT executive order, widely misreported as "banning diversity training" or "banning federal employees and contractors from being taught about racism". People who claim that this is what the EO said either haven't read it or they're deliberately lying; section 10 of the order explicitly says that diversity training is still allowed.
What the EO actually banned was "diversity" or other training which teaches any of nine specific things, all of which are perfectly reasonable ideas to not want in government, for example that "one race or sex is inherently superior to another race or sex" or "an individual should be discriminated against or receive adverse treatment solely or partly because of his or her race or sex." Look it up yourself; read the full list of nine points and tell me which ones you would want to see taught to government employees (or anyone else).
Wokeists went nuts at this EO, and Biden reversed it on his first day. Why? Because they want to discriminate, scapegoat and spread stereotypes based on race and sex. What other possible explanation could there be? Wake up.
I think the discussion about “master” started within the context of “master/slave” DBs.
“Master” has both a non-racist and racist definition. After seeing it used in the context of a “slave” DB, I can see why the innocence of the word was lost for many in the programming community.
How can the definition of a word be racist? Making people slaves based on race was, obviously, horribly racist. But the words "master" and "slave" are not inherently racist.
> You mean the almost exclusively US interpretation is the most relevant.
As far as I'm considered, the worst part about this is that because of American propaganda in the mass media and popculture, people from outside the States are projecting American history and problems onto themselves, because that's a hip and cool thing to do now.
Sorry, I mean “master” can be used to describe a racist slaveowner or a non-racist skilled worker among many other definitions. But using the words master and slave together is to my knowledge primarily used in the context of describing a racist relationship, especially in America. The word pair has been co-opted by the programming community but I’m not sure why originally.
I was familiar with it in the hardware world before I was ever exposed to it in software, as in master and slave devices in SCSI, then later in context of data replication. People opposed to these words are making them racist (or acquiescing to those that want us to think that way) where their origin was never anything of the sort. The master/slave relationship predated the American continent and across the broad swath of human history has been a pretty color-blind enterprise. This accommodation to absurd American sensitivities is an embarrassing insult to basic intelligence that’s only getting worse. People need to grow the F up.
> People opposed to these words are making them racist (or acquiescing to those that want us to think that way) where their origin was never anything of the sort
I’m pretty sure actual masters and slaves were the origins of the words and predate your SCSI example.
> The master/slave relationship predated the American continent and across the broad swath of human history has been a pretty color-blind enterprise
But it’s never been healthy or admirable, wether based on racism, class, tribalism, religion, etc.
So we’re upset that we can’t personify inanimate objects and describe mechanical processes using words that were originally used to describe horrible human behavior? Is this really the hill to fight on? Does renaming a DB pair primary/secondary really mark the downfall of our society? No one is trying to make you “acquiesce”. If personifying an application with the words master/slave is super important to you, go for it.
It just seems more odd to me those that insist on using it rather than the multitude of words that aren’t associated with generational pain and suffering.
Obviously, where did you read me saying otherwise?
> [bunch of hyperbole about downfall of civilization]
The idiocy of attempting to change language like this and the rationale given is certainly making society dumber, to say nothing of the insulting nature of people pretending this buffoonery is perfectly natural.
> no one is trying to make you acquiesce
The comments on this thread contain many examples and testimonies to the contrary - corporate training programs, censorship.
> seems odd to me
Perhaps it’s odd to you because you see it as a small and limited change; it’s ridiculous to me because there’s no limiting principle to what’s offensive. This word pair is actually one of the less ridiculous attempts at linguistic overhaul (somewhat less ridiculous than trying to ban whitelist/blacklist, e.g.).
> where their origin was never anything of the sort
It sounded like you were trying to use the SCSI example or the programming example to show that “master/slave” is an innocuous word pair commonly used in ways that don’t apply to the slave trade. But their semantic origin is the slave trade. It’s like if we started referring to DB wipes as “genocides”. The origin of “genocide” and emotional impact of the word doesn’t change when the word is co-opted (poorly and for no ideal reason) down the road.
It sounds likes silly argument to argue that the origin of the word pair and it’s emotional/historical context should be secondary (or even ignored) because it was used innocently in a niche domain like hardware or software far later down the line. I guess I’m arguing the reverse that the original meaning matters the most and the latter applications of the word matter the least, simply because the original meaning is still taught in school and used as a reminder of the horrors of human behavior while the overhauled use of the word pair is a poor analogy that directly attempts to reference that original meaning.
> This word pair is actually one of the less ridiculous attempts at linguistic overhaul
Yet there’s huge resistance and debate about it. I don’t understand why one would want to draw a line in the sand here and insist on overhauling the original meaning of an emotionally charged word like “slave” to poorly personify an inanimate process. Even if I was going to personify a replica DB, I’d call it a “clone” or “twin”. I don’t think renaming “master/slave” is the social oppression / thought police we’re all worried about.
It is already difficult enough to come up with naming things that makes sense. I kind of get "master" when used in the context, however things like "owner" i struggle extremely hard with. Especially since major companies like Microsoft use it.
I remember asking what did they suggest instead of owner, and they basically gave a list of synonyms that frankly did not really work the same way, or are insanely long e.g. "Primary Account Holder".
I'm surprised I haven't seen "trunk" be suggested more as it works well with the branching analogy. It's used by SVN but I don't think that should matter.
DBs used to be master/slave. Should we keep that naming so as not to participate in a slippery slope?
It’s a fine line between a slippery slope and progress.
I remember in the 80s and 90s when older generations would complain that they couldn’t gay bash anymore. They thought it was a slippery slope that if they were forced to respect homosexuals, they’d be forced to respect other types of behavior they deemed immoral. Turns out it was just progress.
Recently, I noticed that I would refer to adult females as “girls” and adult males as “men”. I want to be careful with that in the future and try to change because I’ve been called out a few times and I can see how it’s disrespectful. And I don’t want to be those adults from the 80s I saw so resistant to change.
I guess I try to view it as each year brings new ways of communicating and interacting. It’s OK that I wrote master/slave years ago and it’s OK that I’d never allow that in my code base now.
We’re all trying to be better and that means change.
I’m glad folks are sounding the alarm because we don’t want to be complacent, but not every new social norm is suppressive either.
Personally, I don't see what the issue is with master/slave for databases. Of course it's a terrible and immoral relationship to have between two humans, but that doesn't render the words themselves immoral when used descriptively in a completely different context.
By the same logic, shouldn't it be offensive to refer to the "owner" of a house? Or the "torturous" path up the mountain? Can we also not "kill" a process? Or run a "headless" browser? Or talk about a project being a "death march"?
Counterpoint--the word "slave" does inherently refer to a relationship between humans (i.e. animals or inanimate objects cannot be slaves, as that word is defined). When it is used as a CS analogy, the analogy does refer back to that relationship between humans as its source of meaning.
"Owner" is fine because the generic, base meaning is not inherently wrong. Claiming to a person as a slave is one application of that generic meaning (which is ofc very wrong). Owning a record in a database or owning some land is another, distinct case (which is perfectly fine).
"Death march" and explicitly militaristic terms are not ideal, although many people do believe in some kind of just war, so theoretically words themselves are not fundamentally immoral, the whole topic is understandably not going to result in any positive feelings so it would be best to avoid it.
Likewise, "headless" if we really want to stretch it to a human analogy, would not refer to cutting off someone's head, but rather to a type of creature that doesn't have one in the first place.
I understand that these and other terms have historical baggage, but that seems like a property of language in general.
If we’re really thorough about this stuff, we’ll probably end up with hundreds of words and phrases that we can’t say because they could remind people of something dark or unjust in our history. Everyone will have to think about it constantly to avoid slipping up.
It strikes me as a lot of sound and fury for something that ultimately isn’t going to make a single oppressed person any better off, and that will lead to a lot of conflict and resentment when people feel that innocent patterns of speech are being policed.
> It strikes me as a lot of sound and fury for something that ultimately isn’t going to make a single oppressed person any better off
It’s not meant to make them better off, it’s meant to not make someone feel worse.
> completely innocent patterns of speech are now being policed
No one is perfect but if someone’s telling you that a word pair like “master/slave” sucks for them to have to type, why is our response anger and resentment at the “word police” rather than compassion and understanding?
If we consider the worst fates for a race or ethnicity we often think about genocide or slavery.
Just like we could “genocide” a DB by deleting everything, it would probably suck for many to see that word normalized in a new context. It’s probably good for some words to maintain their strong visceral reactions. I’d say the fact that “slave” feels like an innocent speech pattern is actually a good reason why we should want to move away from using it outside of it’s original historical context. The word “slave” should hopefully elicit fear, sadness and contemplation. Instead it seems it generates confusion as to why anyone would feel negative emotions in response to that word. Just like swear words, they carry weight largely because they’re seldom used and are often attached to emotions. To dilute their potency seems like a mistake to me.
In any event you’re not a bad person by any stretch if you use those words innocently. But I personally would rather use a different, less charged word to describe a DB if others were so inclined to indulge me.
I think the broader question is whether it's a good idea in general to go through terminology or common idioms with a fine-tooth comb looking for unintentional offense or the potential to offend.
It's of course very different when the intention is to offend, as with racial slurs, but when it comes to things like master/slave db, git master, 'sanity check', the masculine/feminine in Spanish, and others that have been mentioned in this thread, you're really talking about a project to 'reform' everyday speech, with no clear boundary on when this project would ever be complete. And really, there can be no clear boundary since 'unintentional offensiveness' is a purely subjective determination that anyone can claim in response to almost any word or phrase, no matter how benign others may find it.
However progressive someone's politics might be (mine are fairly progressive fwiw), this seems like a highly questionable undertaking. There are clear echoes to measures that have been taken by totalitarian regimes in the past, like asking citizens to call out and report each other for ideological transgressions.
Considering this danger and how much it aggravates people to feel that they must walk on eggshells with their words, there seems to be very little practical benefit toward advancing any concrete progressive goals. People not feeling bad seems like kind of a wash since it also feels bad to have your character questioned based on using common/widely accepted terms.
I hear what you’re saying about history. I studied abroad in Germany and those lessons are painfully obvious there. But for me the line is drawn at facts and opinion and words in their original historical context. No one is rewriting the definition of “slave”, they’re actually trying to preserve it.
“Master/slave” is a recent manufactured idiom. No one is hunting through dusty books trying to find things to be offended about. As more African Americans enter the field of programming the more apparent it has become how unnecessary it is to use this idiom. It certainly wasn’t coined in a programming context by an African American. It would be inherently obvious to them that it’s not even a good idiom from a semantic view. It’s only because African Americans were absent from those naming decisions that it ever gained traction.
No one is censoring facts or opinions here. They’re simply saying: “hey, now that African Americans are participating more in our programming community it’s become apparent how uncomfortable it is for African Americans to have to use this master/slave idiom that is barely even semantically appropriate. No one is blaming anybody but can we agree to use a term that’s both more semantically accurate and one that all of us including our African American colleagues feel more comfortable with?”.
It’s like if we’re in a public park and I ask you to take turns on the swing. There’s no rule about it and you could say I’m on a power trip trying to get you to give up the swing, or that I’m blaming you for not having noticed that I was getting annoyed waiting. Or we could just take turns and be friends. I want you to stop using the swing so I can use it. You being on the swing isn’t a problem, but acting like I’m oppressing you by asking you to change positions is a bit of a stretch in my opinion. No ones character is being questioned and no one is wrong. But if you say no to sharing the swing because you’re afraid of a slippery slope of me expecting you to share your house, your car, etc. then you’re operating out of fear rather than responding to my actual request. Or, you could trust that when my requests actually inconvenience you, you’ll say no.
> it also feels bad to have your character questioned based on using common/widely accepted terms
I’m know it does. But insisting you’re not offending anyone or have never offended anyone isn’t the goal. No one is perfect. No one can go through life without being a jerk or offending people. The real test is how we respond after we have done so.
If you used an idiom that made some people uncomfortable, just apologize and move on. Don’t be afraid to give up the swing worrying about everything else that might happen later. It’s just a swing and this is just an idiom. Offering understanding and compassion and even an apology costs you nothing but your ego.
I also hear what you're saying, and I agree with your point that a black person wouldn't have come up with master/slave. That said, I've also worked closely with black developers and while I don't want to make assumptions, it's really hard for me imagine them being offended by something like this. It's more like a parody of what a white person who has never spent any time with black people thinks a black person would be offended by.
But regardless, it's not that I'm so stuck on using this specific term. I don't care that much, and primary/secondary is fine, as you say. My point is that many people and groups will have more-or-less equally valid complaints about countless other words and terms, and I don't think attempting to excise all of them from our language is a helpful or productive path to go down. As many anecdotes in this thread have demonstrated, it's not "just a swing" or just a single idiom. It's already starting to snowball into a pretty long list.
> Personally, I don't see what the issue is with master/slave for databases.
Because there are other words that convey the same programming intent that don’t also personify slavery. I can think of dozens of oppressive human relationships that could also be used to describe a subordinate database architecture, but why? What do we gain by personifying our DBs with terms like “slave”?
They’re short words of convenience rather than some malicious intent, I get it, but it’s not hard to name it something just as relevant like “primary/secondary” or “source/replica” and move on to bigger and better things.
The other words you mentioned don’t have the same painful historical connotations for a large minority of the population.
Killing child processes could certainly have painful historical connotations for anyone who's miscarried, had a forced abortion, or is distressed by the historical existence of those events. I'm sure if it becomes politically advantageous to remove the kill command, a community organiser or developer advocate somewhere will immediately start lobbying for it.
> I'm sure if it becomes politically advantageous to remove the kill command, a community organiser or developer advocate somewhere will immediately start lobbying for it.
Politically advantageous? I’m not sure why social change is assumed to have ulterior motives. If one of my employees said a violent personification of a programming process was distracting or disturbing to them and made their job harder, why not change it? It’s not like these are technical terms. These are words that relate to human interaction that we’ve embedded into a non-human field.
There are tons of words throughout history that were accepted by previous generations that aren’t accepted by subsequent ones and vice versa. Language and social norms are always changing.
If you can’t speak the truth freely, that’s a huge problem. If you can’t program with others using your preferred personified analogy for a variable name when another variable name will communicate the intent just as well, that doesn’t strike me as quite the same existential threat to society and public discourse.
I don't believe that most of the cancelled terms were distracting or disturbing anyone who wasn't a political activist to any significant degree prior to being cancelled. Staking them out as unacceptable terms has brought into existence a battlefield where there didn't need to be one, and caused people to be offended by terms that hadn't offended them before. When I look for reasons why this might have been done, I find a lot of people making careers out of their advocacy, and getting a lot of dopamine hits from social media.
It's my impression that there are a lot of people looking for things to cancel, justified by their political beliefs, but motivated by social approval and career-building.
If this is the case, it's obvious why we shouldn't change our language to suit those demands: the demands are motivated by a positive feedback loop where cancelling is rewarded, and rewards enable cancellation, and so whether a term is a real problem is irrelevant so long as outrage about it can generate enough income or likes.
As the programming field becomes more diverse, isn’t it reasonable that some might have a legitimate emotional reaction to the word “slave” especially in the context of a “master/slave” relationship?
Or is it more realistic to assume that it’s people on power trips manufacturing outrage for social or physical currency? And that no African American would ever have had a problem with that word pair until a social justice warrior came along and told them to be outraged?
The latter is pretty insensitive, but not an uncommon view.
> we shouldn't change our language to suit those demands
Programmers used an analogy that attempted to change the meaning of the word pair “master/slave”. People are advocating not to change the meaning of our language but to respect the original meaning that is still taught in every school. “Master/slave” has an important historical meaning and isn’t something we should casually co-opt.
If someone wrote a script to “genocide” a DB instead of “wiping” it, I’d hope that we could see that co-opting a word that already has important historical meaning doesn’t help anyone, but surely hurts some.
I often think about how every generation I can think of had a fight over what was OK. The younger generation would set down some new standards, and everyone who grew up with the old "normal" thought it was ridiculous that the standard was changing.
So, whenever I think some "new standard" is ridiculous, I try to think on that for a moment and err towards not wasting too much time worrying about it.
Does using the new term hurt me in anyway? Does it help someone else? Alright, then. I might not get it, and it might feel ridiculous to me in the moment, but I don't want to be the guy yelling about how calling something "gay" isn't homophobic.
Maybe it doesn't "hurt" you in a direct way, but forcing people to change their behavior for a power trip is not something you should willingly bend over for. If change is for good, you should be willing to change. If it's for nothing, it's okay to resist.
I think the idea a change is "for nothing" is subjective, and that the people most likely to say a given a change is "for nothing" are the people who don't benefit from it.
Again, I go back to my example.
Were LGBT activists "forcing me" to change the way I used the word "gay"? Sort of. Did doing so hurt me? No. Did it benefit them? They say it did. Was it for "nothing"? They say it wasn't.
Language changes. I'm not going to waste a lot of energy worrying about it.
Those are examples where you examined the choices and decided that a change makes sense. That may not always be the case. Again, you are capable of deciding. "For nothing" is subjective, and, as such, you get to use your best judgement. Good luck.
My point is that because "For nothing" is subjective, my own bias will lead me towards discounting the benefit of a given change. So, I err towards being accommodating when the request requires something so small from me.
At the time, I thought the change was ridiculous. It took me a few years to realize I was just being petulant.
Isn't there a risk that, like feeding pigeons, you end up encouraging minority groups to become over-sensitive, because they become addicted to the power of controlling what other people say?
2. Going back to my example, the whole "if we let them do X, where does it stop?" was a big part of 90s discourse regarding LGB rights. So far, the slope hasn't slipped into any of the scenarios people brought up. Language changed a bit. Some people felt more included by society. I suffered no injury beyond letting go of the notion I was entitled to use certain words to mean certain things.
I found other ways to convey those things. It turned out fine.
I apologise if my analogy made you feel uncomfortable, and I'd be happy to learn a different analogy which expresses the same idea just as clearly. If there isn't an effective alternative analogy, though, then it might appear as if you are using claims of discomfort to limit legitimate criticism of your ideas, which I trust isn't the intention.
I appreciate you responding to my criticism despite my analogy, but I was concerned you might try to discourage or prevent people using such an analogy in future, without offering an alternative (and despite me having no ill intent behind it).
As for why I used an analogy, I don't know what reason will satisfy you. People use analogies to help other people get an intuitive sense of an idea which might otherwise be hard to explain. If you understood my point without needing the analogy then that's great, but I don't want to assume that analogies are never helpful.
It's possible to recognize some changes as warranted and some changes as being misguided or based on entirely false premises. You are capable of examining your thoughts and listening to other people's explainations for determine which is which.
I often like to imagine that if I were in that situation I announce that I sexually identify as military attack helicopters and insist my pronouns are apache/apachim, but I know the irony would be lost on them and really would just result in me getting fired for thought crimes.
Honestly the person running the seminars was very very strict. Several people said "I don't really care what people call me by", or can I just leave it blank to be what people want. The person explained how that attitude is disrespectful to people who do care about these things, and how it can foster an environment of hostility towards people who put them. Which in turn marginalizes those people etc.
However in January the entire sales team removed them after apparently a customer reacted negatively to the inclusion. Which lead to other external facing teams removing it to prevent the same issue. Most people have removed it from emails, and honestly many people just don't seem to care, and HR doesn't seem to be enforcing it.
The funniest thing of the whole "thou shalt list your pronouns" thing is that the actual trans folks I've talked to tend to be opposed to those policies. It paints them into a corner - either state that you want to be misgendered, or out yourself as trans.
Mandatory pronouns are a pure shibboleth in the culture war. Trans activists don't want it. Anti-trans activists don't want it. The only people who want mandatory pronouns are the folks wanting a cheap signal for how much of an ally they are and an easy way to identify and ostracize people who aren't in-line with their politics.
"It paints them into a corner - either state that you want to be misgendered, or out yourself as trans."
Huh? What do you mean? How would not listing pronouns help?
That's awfully strange they would have a problem with that, because there are some non-binary people who do welcome the use of all pronouns and even discourage people from using only one, or only the one they were initially using.
If someone is really okay with all of them and wasn't just saying it to be disrespectful, then it's fine. If they said it just to devalue someone else who did care (but really cared themselves all along and in no way would actually be okay with it), then it is wrong.
That's the whole point. It's a billion-dollar industry created by useless people with no real economic value. They need to inject racism and sexism and division into every situation so they can claim credit for opposing it. How else are they going to justify their bloated paycheques?
> Everyone had to list what pronouns they wanted people to use
I’ll be glad to demonstrate my knowledge of Unicode, Sumerian and Chữ Nôm in my signature and be OFFENDED by any "woke" idiot who get it wrong. Bonus point if the fault lies in fact in software the company uses.
In my opinion, its definitely worth getting rid of "master/slave" since after all it does directly refer to a violent and wrongful historical relationship. It may be only a metaphor, but it does clearly refer to that and I can understand how that makes some people feel unwelcome. But ownership is a little different. One object owning another doesn't make any reference to the "ownership" of people in slavery, it just as well references the ownership of literally anything else which is perfectly legal.
I also don't buy the "see is ableist" thing. Entire languages would be unacceptable if that were true. For example Japanese appends -て見る (see) to verbs for the meaning "try to <verb> and see (how it goes). That notion of "seeing" is a fundamental part of the linguistic concept of "see" in most languages and it is in no way a reference to blind people. When you say someone is "blinded by the sunlight" or describe a "deafening roar" you are obviously not saying anything about blind or deaf/Deaf people, those words clearly have included a wide variety of definitions including temporary ones which were then the basis for metaphorical ones. That's different than "master/slave" which is a metaphor for a word/concept that was inherently racist and violent from the beginning.
On the other hand, I don't think pronouns in email signature is a bad rule. Even if the pronouns you use are the same ones you have used your entire life, you do have a preference nonetheless, so I don't think there's anything inherently unfair about making people specify them. It's not like you don't want people to use any pronouns or you don't feel that they should exist at all, so it's not really harming your rights. It does help trans people feel more accepted in sharing their pronouns, and it doesn't really cost other people anything to do it.
The stuff about CRUD is just absurd. As is creating ultra-expensive outreach (that make money for the people writing these reports) for companies to small to support it. If HR was concerned about inclusion, they could add a tasteful note on their website about how their workplace was affirming/welcoming space and that they welcomed those applicants. Of course, employees should certainly be free to create such a group if there is actually interest in it.
I hate this. We moved from Okta a few years ago after we were basically received almost no actual real support for a bunch of issues, even though we were paying a premium cost. Nobody cares about issues on their Github, the kicker was a when we received a support response as suddenly something was no longer working after an update, we got help in the form of "We have no plans to address this anytime soon." when asking for an ETA.
We ended up switching to Auth0, after we had a few calls with them. We shaved a decent amount off our costs with Auth0's Enterprise plan, and their webtask based rules worked. While the migration sucked for a bit, in the end we were much happier.
Can second this, Okta requires you to "contact support" to turn on basic features like email customization, and even though I'm a paying customer, I was given a multi-week estimate (after waiting a week or two) for how long it would take to enable this feature.
Yeah current Okta customer and same experience as you. I was thinking of maybe going to Auth0 but well at least this news came out before we put any serious work into planning.
sigh
Auth0 at least has much better docs and libraries. It feels like Auth0 at least cared more.
I've never dealt with Okta support but my support issue with Auth0 was top notch.
However, their 'Rules' system for hooking into the Auth request is abstracted at the Auth0 account level rather than the individual app level. That makes it too easy to accidentally screw up all of the apps on an account.
I like the product but the extension points confuse me. Rules, Hooks and Actions are all more or less the same thing? I never know which one I want. What's difference between a flow and a pipeline? You definitely can't guess from the terms.
Sounds right. We use Okta for multiple AWS accounts and they "ran a bad migration" that deleted half our permissions and took a month to resolve. On top of that, nothing appeared in the audit logs.
To make matters worse, they have 3 APIs. Two are internal with 1 html and 1 json-based. The external one is the least feature rich and is missing configuration items that make IaC a challenge (you get about 80% configured then have to make changes in the gui)
Agreed - trying out nest.js the first time gave me hope that we'd see something like Django for typescript/javascript. Especially paired with nx workspaces, with shared code between front & backend... so nice.
How's their authentication solution? Auth is such a critical component of most web apps, yet something that IMO a lot of web frameworks don't fully flesh out compared to how easy it is with Django.
I took a quick look at their auth docs, and while the docs seem pretty detailed, I noticed it involves multiple packages (@nestjs/passport, passport, passport-local, and their corresponding types) that you then have to glue together into a full solution. The instructions also apparently only show you how to store passwords in plain text, and using something like bcrypt to do it yourself is an exercise left to the reader. Not rocket science, as this [1] (older) article pointed out, it's hard finding quality auth-related tutorials in the Node ecosystem. With Django a lot of this stuff is built-in and solidly implemented. Granted, this was after a quick look at the docs, so my impression might be off.
Passportjs is the standard across all these frameworks. It's modular by design, so you can easily compose the right auth system for your needs. I've always found it quite intuitive and I've never seen anything even nearly as comprehensive in any language.
What do you find you get from auth libraries? I've always found them much more trouble than they're worth. But I feel like I must be missing something.
Why isn't Auth0 on that list? For most enterprise customers SAML is required for SSO. However SAML is locked behind their enterprise plan (and enterprise is stupidly expensive).
On top of that now enterprise plans now require you to pay by connection as well. So if you want to allow multiple customers SSO connections the cost starts increasing drastically.
Auth0's pricing really disappointed us, but we don't have the resource to switch to another vendor at the moment. We're a SaaS who need a few dozen enterprise SAML connections, but each connection only has 5-10 logins per month. Their sales team flat-out told us that our only option is the $25k/year enterprise plan plus more for each connection. It's totally bonkers.
SAML is not that difficult to support in Rails with few Ruby gems; took us a couple of weeks to implement, most of that sorting out various integration snags with customers.
The last time i talked to Elasticsearch about pricing, it was so extremely expensive for our use case to the point of it basically being a non valid option for us.
I think what most people miss for these and similar services is you’re paying for really good, on call, white glove Elastic support. In my experience they can often go as for as to replace having a search specific ops team. The cloud hosting isn’t really where the value is.
I guess my issue is that we didn't want or need support. We just wanted x-pack features such as Auth and the Alerting plugins.
We were already hosting it fine ourselves on AWS, as we had devops people very familiar with ES. However the price they quoted us per year was insane for our cluster size for ~20 nodes.
I looked at the price of a Tesla the other day and thought it was too expensive.
doesn’t really say much, I could be in a bad financial position, Tesla could be expensive or I have a different preference to spending my money or I don’t love the environment enough ;)
Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing together dozens of various hooks and HoC's to achieve the same balance is beyond confusing.
Recently i was assigned a PR for a component (a login form) i wrote about a two years ago which was a whole 300 lines. The person who wrote the PR also took the time to make it "functional", which has now resulted in it being split into almost a dozen different files. I don't find this cleaner or easier to understand at all.
Current team i am on uses MobX, and Typescript for our app and frankly it is painfully simple, and yet people keep arguing that we should drop mobx, and switch to hooks and i don't see any benefit.
One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. However, I would agree that I often find the opposite to be true when everything is scattered around in mini functions over hundreds of files.
> One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand.
This part is wrong. Your huge components are made of what? Small things. Isolating all those small things just let you add more boilerplate and mental load when trying to debug. To reduce complexity you have to remove code, not move it around.
I don’t think we promote isolating every little thing. That would indeed be counterproductive.
It’s more about being able to reuse some stateful logic between components. That’s the point of custom Hooks. There are pretty cool libraries existing already. For example React Spring takes advantage of that programming model for animations: https://www.react-spring.io/docs/hooks/use-spring
This whole thread is wrong. Nobody said you had to split the functions off into a bazillion files that's just stupid. Youre taking the worst part of enterprisey OO culture and ruining the best part of functional.
And no, you do not need to remove code to reduce complexity you're mistaking correlation for causation.
Boilerplate may occur in the short term during a refactor to pure functions but that can eventually be refactored out once things are unshackled enough to be refactored.
Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.
We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature.
The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.
mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.
I'm a bit dumbfounded about the "this" and "class" confusion concern as well. I'm not surprised to hear people have trouble with that per say.. I am surprised a company like Facebook cares about those people. Isn't this the same company that wouldn't hire the homebrew author? I get the sense the only UI people who really know programming work on the React team.
>Isn't this the same company that wouldn't hire the homebrew author?
I think you’re confusing it with Google.
>I get the sense the only UI people who really know programming work on the React team
I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression.
>I'm a bit dumbfounded about the "this" and "class" confusion concern as well
In the grand scheme of things it’s a pretty minor concern (although people do tend to overfocus on it because it’s easiest to explain and discuss).
The motivation for Hooks is:
* Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call.
* Colocate related logic instead of artificially splitting it into lifecycle methods.
* Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state.
Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling.
All of these motivations can be challenging to explain. So people tend to overfocus on “this”.
> All of these motivations can be challenging to explain. So people tend to overfocus on “this”.
> I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression.
I can't recall if I've seen it brought up in other "official" channels, but it does certainly get talked about a lot in discussions such as this and I believe that's because of information sources such as the link. I will defer to you on the real situation, but I think hearing about classes and "this" being confusing, coming from React, is where people might wonder what's going on. Mentioning it at all may have caused a large distraction as people latch onto it as you say, and find the situation a bit incredulous.
It is unfortunately the only point that we can clearly explain to beginners, designers, and other people who aren’t deeply familiar with programming principles. We still care about them and want to emphasize we’re not ignoring them with some new paradigm. When you have such a vast audience as React does, someone will get upset anyway.
> * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call.
In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now?
> * Colocate related logic instead of artificially splitting it into lifecycle methods.
Nope, all this did was make a mess. If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been. All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible.
> * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state.
Besides this not making any fucking sense, why don't you call new and leave me out of it?
As a user, Why do I need hooks today?
> Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling.
>In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now?
Hooks are composable, unlike mixins. That's pretty much their whole point. Hooks are functions so you can pass values between them.
Consider that reading everything with a cynical mindset might be obscuring the design. I encourage you to play with it a little bit to get a feel for it.
>If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been.
Dismissing them as unnecessary doesn't really point to any concrete solutions so it's hard to debate.
>Besides this not making any fucking sense, why don't you call new and leave me out of it?
Sorry, I don't know what you mean by that.
I tried to answer your questions the best I could. It seems clear that you don't find Hooks useful. That's cool.
I'd be happy to continue this discussion but I'd appreciate if you could tone down the aggression and snark a little bit. You seem to be very annoyed by our conversation, in which case I'm not sure why you talk to me at all. Answering comments like this isn't a part of my job, and I'd appreciate if you could at least talk respectfully even when you disagree. Thanks.
First of all I apologize. I wrote that late at night and couldn't really get out what I wanted to say down without the frustration but I also really didn't want to miss the opportunity to pick your brain on this. Its rare you get a chance to speak with the people who build these features.
> Consider that reading everything with a cynical mindset might be obscuring the design.
I was concerned about this, I have pretty strong criticisms about redux. Well, actually, I love redux, I hate that flux dictated its design choices and blurred its abstractions which eventually resulted in the mess you now see in "userspace".
> I encourage you to play with it a little bit to get a feel for it.
I plan to, I'm simply still not convinced they're a solution that has a problem to solve.
> Hooks are composable, unlike mixins. That's pretty much their whole point. Hooks are functions so you can pass values between them.
Hooks are composable, yes, well sorta, at the top level, in a certain order, but if I want composable components I cannot use them.
By definition, calling a hook within a function gives it state. Once it has state, that function is no longer pure.
At that point, you may as well just use a class object and instance, at least then you can separate logic from state in a clear language defined way. This is preferable opposed to in amongst a bunch of useThis and useThat callback hell.
But I'm wasn't really arguing they're not composable, they API is a bit meh but its workable. I'm really just saying they don't have a reason to exist in the first place: Why do I need hooks? or why did/do I need mixins? What is the use case they solve when I have a correctly designed composable implementation of react components?
>> If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been.
> I don't find this argument convincing.
What is not convincing? Why does logic need to be colocated further than it is unless there is more than one thing happening in the component confusing things.
subscribing to data - why would I want my presentation layer to be subscribed to data? The whole reason for binding data into the presentation layer via props is to avoid that proverbial shitshow.
form input - use browser builtins, if they don't work because react broke them then maybe react should fix them? or, you know, you just do what we all do right now - use a stateful react component class.
or animations - this smells like a jquery sales pitch. We don't need marquee, never did and never will. But see above, if it needs state, its a class.
I guess my confusion is stemming from the fact I don't see classes as a problem, or at least, I don't see pure functions as a sole solution. Pure functions solve a lot of problems by ensuring boundaries are correctly drawn and all state flows through props but that data needs to come from somewhere. Dropping state via hooks into things does the same thing redux does right now. Only hooks violate prop boundaries where as redux (correctly) respect them.
Personally, I would just fix redux if you have a problem with it.
> Sorry, I don't know what you mean by that.
"Accurately model component as being in multiple states at the same time for concurrency." - this is just words and needs a lot of context to unpack correctly.
(Important for future React features.) - As a user, I don't know or care about future React features.
Closures can do that because they capture specific props and state. - You know what else captures specific object state? Instances of objects. Call `new`, don't re-invent OO with pure functions.
All of which is besides the point ant still doesn't answer my question: What developer/user problem do hooks solve? Why should I use them as a developer? - opposed to refactoring into composable stateless components.
> I tried to answer your questions the best I could. It seems clear that you don't find Hooks useful. That's cool.
That's not quite correct I can see they solve the problem they set out to in an elegant, if kludgey, way. I'm just not convinced of their need (which still remains unclear and undefined)
Why do I need hooks? You keep falling back on framework or js reasons, these are not good enough reasons for a user to use, want, or even understand your new feature.
> All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible.
You've nailed it. Their solution to the issues with certain JS OO features was to re-implement Objects minus the features that were a problem, with new syntax. The code's worth a read for anyone who's read how the feature works and is still thinking "no, surely they didn't, it must work some other, magical way".
The company isn't in a third world country they are basically reliant on an extremely specialized piece of software/hardware that doesn't work on anything more modern.
Unfortunately this is basically what i am dealt with and i don't have any real options of changing the environment.
I was a consistent grade D student in high school, I was that werido in class who everyone hated. In my final year my parents realizing I was not going to have a great future, decided to bring me to our doctor, I was prescribed Dexedrine for ADHD.
That Pill completely and utterly changed me in my final year, i could think clearly. I understood what was being said, it completely changed me. I suddenly decided to go to University for CS, forcing me to do a victory lap in high school. I was able to get into University on an amazing scholarship.
However the biggest thing was the few people who i was vaguely friends with me praised my 180 personality change, they liked being my friend.
I am now 36 years old taking the same dose of meds i have been for the last 20 years. It works for me, immensely. At the same time there is a huge stigma around ADHD medication. My ex hated the idea of me taking meds saying its big pharma pushing this, i don't need this, i just need exercise, etc. She changed her tune after she saw me not on my medication.
I know there are probably people out there that don't need this or abuse it. Sure, but that is true for almost everything.