Algorithms + Data Structures = Programs - Episode 14: Inclusive Terminology

Episode Date: February 26, 2021

In this episode, Bryce and Conor talk about inclusive terminology.Date Recorded: 2021-02-13Date Released: 2021-02-26Words Matter: Why We Should Put an End to “Grandfathering”Writing inclusive documentationLex Fridman Podcast #160 - Brendan Eichstd::colony ProposalIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Three, two, one, clap. You were a full two seconds late for that, bro. There's this thing called latency. There's this thing called latency. It's not important that it's at the same... Well, do you want to do it again? Three, two, one, clap. There we go. Nailed it.

Welcome to ADSP The Podcast, episode 14, recorded on February 13th, 2021. My name is Connor, and today with my co-host Bryce, we talk about inclusive terminology. Because that's the thing, they introduced the ribbon and a bunch of new shortcuts for everything, but they grandfathered in. Is that an inclusive term, grandfathered? I'm not sure. No, it's not. We're going to take a brief tangent for me to explain why grandfathered is problematic. One of the things I've been working on recently is I'm the de facto editor for these inclusive terminology guidelines for the insights and tech specs. And the document lists a bunch of terms you should avoid. There's only one term that has a lengthy explanation because all the other ones are fairly straightforward why they're problematic

and so they don't need an explanation. But we had to add a lengthy one for grandfathered because people kept asking why it was problematic. So I'll just explain here just so that more people know and fewer people ask me. A grandfather clause was a type of law that was passed in the American South post-Civil War that was intended to suppress the ability of African Americans to vote. So the basic idea is you would pass a law that says to be eligible to vote, your grandfather must have been eligible to vote. And if you were

somebody who was a slave and who was freed after the Civil War and your parents were probably slaves and your grandparents were slaves, then you would not be eligible to vote so essentially it was a law that said black people can't vote just you know goes through some uh some hoops to get there so yeah don't use grandfathered grandfather clause grandfathering um those terms are now grandfathered that is uh that is way worse than i like clearly grandfathered is a gendered term which is is why immediately when I... Yeah, and that's what everybody immediately thinks. They think either gendered or that it's ageist.

Pete, that's what people's reaction is. But no, it can be those things too, but it's also racist. So that's the thing. I immediately said it because that is the word that was stored in my brain. And then as soon as I said it, I was like, oh, wait, yeah, that that's gendered probably not inclusive uh and so then i asked i was not expecting that um so yeah that is and so what is there uh what's are we gonna what are we gonna brainstorm what's the alternative um hang on i i ironically i had that the document open in another tab because i was working on it this morning the alternatives that we recommend are legacy or historical.

Yeah, legacy shortcuts. Yeah, that's good. The 2003 legacy shortcuts. And if anybody has better ideas for alternatives, send me a DM or smoke smoke. Well, not that I want to you know veer off of talking about Mono but I have a question. What is the alternative to first-class? That's this is like the biggest Ironically that is actually the entry right after grandfather than this document. So I don't even have to scroll

So the reason that first class is problematic is that you know it has connotations of you know political or societal systems where there's inherent striation you know like where there's like one one type of people has more rights than other types of people. So the alternatives that we suggest is if you're just using first class with then something like core built-in top level, I think I got all of those from the Google documentation guide, their section on inclusive terminology. And if you're using the term like first class citizen, you could potentially replace citizen with entity, feature, facility, something like that.

So I've been using like top level a lot as a replacement. It is a term that comes up a lot in programming languages because we often talk about first class entities in a programming language, which is something that's sort of, you know, like we talk about whether or not a programming language, whether functions are first class or not, whether you can store a function to a variable, et cetera. Like in C++, functions are not class or not, whether you can store a function to a variable, etc. Like in C++, functions are not top level, but in a lot of functional programming languages,

they are. So it is certainly something that I think you and I as programming language geeks come across more frequently. Well, so yeah, I don't want to be controversial but like i am i'm completely on board with you know master domain you know blacklist whitelist to allow list deny list uh grandfather to legacy those make zero difference for me um and and obviously it makes or it's more inclusive and it makes it makes more people feel comfortable um whatever. So it does make a difference to me. It's better to use the alternative.

First class, all of those alternatives cause confusion. So I'm in the midst of listening to the most recent Lex Friedman podcast where they've got Brandon Eich. He has Brandon Eich on who's the JavaScript creator and later went on to work at Mozilla and is now working at Brave. They've probably used the word first class, like, I wouldn't be surprised.

I'm not exaggerating, like, 50-plus times, because when asked, you know, what do you think the best thing is about JavaScript that you got right in the early days when he wrote it in, you know, 10 days was, like, sort of the story, he said first class functions functions, first-class functions. And, and I've recently encountered, uh, the term types as values. And I didn't understand that for like two weeks because I didn't understand that what they meant as types as values was first class types and um i like so i'm i'm so

i'm completely for like finding a way to use more inclusive language but when it comes to this i'm not saying i'm not on board i just i'm just conflicted about it because when you're when you're when you're causing confusion like first class functions explicit has an explicit meaning and saying top level functions, to me, something got lost and I don't actually know what you're talking about. Yeah, but the issue here is that it's an established term of art. There's a difference with grandfathered, which is grandfathered is a term that has usage outside of CS and it doesn't really have a specific usage within CS. Whereas talking about

a first class functions, that is a specific term of art specific to our field. And it is much harder to replace a specific term of art that is specific to our field. The reason is because why do we coin terms of art? The reason that we coin terms of art is that there's not a good word in the broader language for it. So something like grandfathered is much, much, much easier to replace because it's not a specific term of art

to our industry. It's not something that needed a specific word. So there's plenty of other candidates. Whereas something that is an established term of art is a lot more challenging to replace. So I'll agree with you on that. So as an industry, as whatever, a group of professionals in industry and academia, is there still a push? Because I don't know how many people listen to Lex Friedman, but he often quotes that it's like hundreds of thousands.

And so hundreds of thousands of people are, you know, potentially for the first time as, you know, working in a certain language or as junior developers in university, they're hearing first class functions for like the first time. So like, I'm guessing that there's like a non-trivial amount of folks that in the next couple of days are going to hear first class functions for the first time. So like what is like do we give up and just say, well, for first class functions, we say it's a term of art. It's OK. Or do we say, no, this is just going to be a long battle and we agree that we're going to relabel it to something. And then, you know, after a decade, it happens yeah so the the current guidance that we're giving within standards is when it's a

term of art um uh you should introduce a new term of art and then when you're using the new term of art you can say you know previously known as or otherwise known as, you know, old term of art. Interesting. Yeah. I mean, it's the same sort of problem when you're replacing a problematic word that has semantic meaning. You know, when there's something that's a keyword or where it's not just something that is a documentation change, it's an actual, you know, code change to replace the term. You know, if it's a code change to change the term, then that means that it's probably not something that you can necessarily do overnight. And in which case our guidance is, you know,

well, you can try to replace it if possible. And if you can't replace it immediately, then, you know, introduce an alias for it, a new word for it. You can continue to support the old word, but in all new material, you should use the new term. And then you should try to move towards deprecating the old term. It's the same problem for terms of art. Yeah, that's going to be a long, that's a long road for some of those um yeah because that's the thing is yeah most most of them you know some people make a stink about it and i'm like literally like it makes zero difference like right right right what you're saying what you're saying is what you're saying is that there's very low cost in most cases to moving towards a new

term yeah exactly yeah literally like, literally like going to GitHub and changing your master branch to main is literally like it takes two seconds and then people just have to repoint it locally. That one's a bad example though because that one is one that requires a code change because there might be old existing references that are pointing towards main.

A better example is if you're using something solely in documentation. That is absolutely 100% free. If it's just a word that you're using to describe something, that's totally free to change. Or if it's in something that that you're using to describe something um uh like that's that's totally free to change or if it's in something that's in an unreleased product that's that's you know totally uh totally fine or you know when you are selecting a name for something new um it is totally free for you to just pick a different name um yeah if you've got some readme file that says uh blacklisted, that doesn't cost anything.

Yeah. Anyways, I said not to go on a digression, although I was very curious about your thoughts on the first class thing. Yeah, I have been spending a lot of time thinking about this lately because I sort of accidentally fell into putting it together, you know, being the person that's doing the drafting for this document for Insights. So I've been spending a good chunk of time the past few months working on that. Yeah, it's, you know, it's important stuff, especially when you hear, you know, the context behind a word that you had no idea, you know. Like you said, I hear grandfathered and I think, oh, it's just gendered. Is there a gender neutral? Then you find out, oh, it actually comes from this. And you're like, oh, yeah, humans suck and we should do better.

I was reminded of its importance this week when it came up in the context of a C++ committee proposal for a data structure that is currently called Stood Colony. And it actually sort of illustrates an interesting facet of what we're doing here. There's a bunch of terms on this list of terms to avoid that at first glance, they might seem like they're not something that would ever come up in a tech standard.

We have cast on that list, and we have widow and orphan on that list. Those ones are a little bit more obvious, but, um, uh, you know, something like colony, you might think, you know, that's not really a tech term, right? You know, like it's not a common name for a data structure. It happens to be the name of this data structure, but, um, you know, it's unlikely to come up, but as it turns out, like you'd be surprised, um, uh, you know, when, in, when, when tech standards and programmers are searching for a good name for something, they will, you know, uh, look at all of the possible options and, uh, that might include things that you hadn't previously thought of. And so it just like, it reminded me of the importance of this, where I was like, oh yeah, that's, I had not previously thought about that one. That one is kind of problematic. And this perfectly illustrates why we need to not only have guidelines for, like when we not need to,

why we need to not only have a list of terms that are problematic but also like guidelines for thinking about this because the list is never going to be comprehensive and so are you saying that stood colony is going to get uh axed i think it is unlikely that that will be called stood colony interesting do you i'm just curious or is there a leading, or is this like hot off the press? There's like 150 email deep thread discussing the names here. I think there were other the name colony conforms with the ISO and Insights rules with regards to inclusive terminology, because we've had a number of people who have objected to it. So, yeah, I don't think it'll be called colony. I think it'll be called something else.

All right. what we'll do is I'm gonna cut this whole inclusive language bit, because now we've probably been talking about this for like 20 plus minutes, into its own episode, and we'll call it, I don't know, something like inclusive inclusivity in language or something. Oh, but we're not even done with the Excel stuff. I still got

two or three more. Yeah, so you're gonna hear me say, is that inclusive? And then I'm gonna cut in myself saying, turns out it's not. Stay tuned for next time. But back to Excel. And then we'll loop back to this point now. So I'm not, yeah, I'm going to go on a brief spiel on another thing, which is what I believe is one of the core principles of inclusive terminology, at least within the context of standards, this principle makes sense. it it's not a question so when we're dealing with standards we're often looking for consensus and uh consensus doesn't mean majority vote um it's most supposed to mean that you know

everybody agrees but um consensus means neither a tyranny of the majority nor a tyranny of the minority so it means you can't just have the majority of people vote out the minority. And you also can't have the minority, you know, indefinitely hold up the majority. And we often are like, seek to make decisions by consensus. I mean, we're supposed to make all decisions by consensus. and so I was thinking about how does that play into making decisions about whether terms are inclusive or not and the conclusion I came to is it is not a question of you should not be asking the question do we have consensus that this term is problematic you should instead be asking the question is, do we have consensus

that the term is not problematic? So the reason that the distinction is important there is we need, it's a different bar. The bar of consensus that the term is problematic is a much higher one. It requires essentially everybody to agree that it is problematic. The bar of consensus that it's not problematic means that if there is a sustained minority that has a sustained objection, so a smallish part of the group, not the entire group, but a notable chunk of the group has a sustained objection that after discussion there's no resolution to, then you don't have consensus. That's a very different bar from trying to convince everybody that it is problematic.

It flips it so that instead, if you want to use a particular term and some people think it's problematic, you would need to convince them that it's fine instead of them convincing you that the term is problematic. So it's sort of the difference between innocent until proven guilty or guilty until proven innocent. And I think that's one of the key principles that folks should keep in mind. And the other one that is important is that it's not a question of whether the term is objectively problematic. And you should avoid entering discussions about whether it's objectively problematic because the reason that we avoid problematic terms is because they might be harmful or hurtful or evoke negative feelings or emotions among certain people. Non-inclusive terms, it's all

about the experience of, you know, impacted individuals, their subjective experience. It's not about whether it's objectively, you know, problematic or not. If somebody is experiencing it, experiencing negative, you know, associations with that term, it doesn't matter, you know, their reason. If they're legitimately experiencing that, then that is sufficient for it to be a non-inclusive term. And as soon as we get into the world of trying to objectively determine whether a term is problematic or not, then it becomes a litigation of somebody who's probably from an underrepresented minority in that group and who might have strong personal reactions to the problematic term. And there's just no good that's going to come of trying to litigate that. So I think essentially to summarize what I'm saying is that you sort of got to take people at their word. It's sort of a question of does anybody object to this? And if anybody does,

we're just going to go and find some other term. We're not going to litigate whether the objection, whether we all personally you know believe in that objection it is sufficient that there are people here that object to that yeah and i think the only thing i'll add because those are both great points is for the first one when talking about consensus is not to forget to if you're in a room to look around the room and see if you have a good representation of all folks in your community. Because you can quickly reach consensus with, you know, a bunch of people that look exactly the same as you in the room. And that's, I think that's probably one of the biggest mistakes, at least in, you know, the last, or i don't know how many how many years but it's just i think people think that they're they're doing a great job and they just no one has pointed out the fact

that hey there's no insert uh underrepresented uh you know demographic in the room and so everyone thinks oh great thumbs up we did a great job high fives all around and it's not until you know we we launch something and then it it hits a bunch of users and oh yeah we missed that why did we miss that well we didn't have anyone in the room that would have pointed that out to us um yeah but yeah very important stuff it's like inception it's like inception there's a podcast inside the podcast that's where we'll end it thanks for listening have a great day and we'll see you in the next episode