Conor

You're just such a polished off the cuff. Did Brace prepare for any of this?

Bryce

It's it's I don't have an off mode. I don't have an off switch for this. It's just I just wake up in the morning and I'm just in politician mode.

Conor

Welcome to ADSP the podcast, episode 61, recorded on January 8th, 2022. My name is Connor, and today with my co-host Bryce, we cover part one of our 2021 retrospective.

Bryce

Alright, um, let's do the retro.

Conor

Retro. Episode 61. 2021. Go. Top three? We'll do top three. Top three highlights of the year. Or if you want to just give a little uh a little uh 2021 in review first from either Bryce's personal view or Bryce uh Library Evolution Working Group chair view, or what are you, architect, HBC architect, head of CCCL? You've got like a bunch of different hats. Feel free to give a an amalgamation.

Bryce

For me, like, you know, I moved to New York, which was like a very substantial part of my year. So that was uh that was sort of a big deal, and that consumed like a whole chunk of my time. Um I guess you you had already when when did you move back to Toronto?

Conor

I moved back in uh November of 2019, approximately three or four months before the pandemic.

Bryce

Yeah. Um so you were you were already gone, but so so I moved to the moved to New York. Um I mean I think we've done, you know, we we really sort of finished the C23 design cycle in uh in 2021. Um you know, we have like a few weeks left to be design complete, but most of the actual substantial work that happened for C23 um wrapped up this year. Um and I think that C23 is pretty exciting. I think we've got some pretty exciting um uh work coming. Um yeah, I think it's shaping up to be uh a pretty interesting release.

Conor

Ranges. Woo!

Bryce

Yeah, there's a lot of ranges enhancements, um, standard library modules, state expected, um, deducing this, there's a variety of other language enhancements, um, extended floating point, but something near and dear to my heart, md MD span, and uh the jury is still very much out on uh what's gonna happen with executors. Stay tuned for that. We'll uh we'll find out soonish.

Conor

Yeah, there was uh a fireside committee panel chat that I watched on YouTube uh that took place in September. And uh you were I I I mean I'm biased because you're my podcast co-host and colleague and friend, but I think you were sorely missed because at one point there was a question about you know what is there to look forward to in C23, and the the answer was very limited.

Bryce

I see, I find it I find it a little bit um I think it's a little bit hard to have a C committee fireside chat where almost none of the people on the chat are actually actively participating in the committee. So um that might perhaps explain why people were unable to coherently answer why you know. At least a few of the people on stage were, but uh a couple were, but there were also a number of prominent people on the panel who are not actively participating in the standardization process. That's that's that's that's all I'm gonna say publicly on this. That I think if you're gonna have a panel of people talking about a thing, those people should actually be qualified to talk about the thing. Um, and not everybody on that panel was qualified to talk about the things. So maybe they should have kept their mouth shut.

Conor

All right, this is juicy content for the ADSP listener. Um yeah. Uh but yes, C23. I do, I mean, there's lots of range of stuff getting in. There's a bunch of talks that I'm looking forward to giving um adjacent transform.

Bryce

I'm excited about Cartesian product. The thing I'm actually probably most excited about is is the um is that you can now write your own pipeable range adapters so that um anything that we forgot to add as a range adapter, you can now add yourself. Um so I think that's pretty cool.

Conor

Yeah, you can you can use other custom so you can basically use range v3 with the um with the standard out the standard ranges as well.

Bryce

Um I actually I I used yeah, a JSON transform is pretty cool. I used it the other day when I was writing an example. Um I've been using repeat a bit. Um I've been it the whole like shift in um uh uh no no the the whole window and that family of ones of window and chunk and whatnot.

Conor

Anamorphisms unfolds.

Bryce

Yeah, slide, chunk, etc. Um, those are all pretty cool. I haven't quite figured out how to do all the exciting things that I want with them. Um, but I I I wrote some pretty cool examples combining Cartesian product and slide and chunk of building like um uh decomposing a multidimensional space into like tiles. Um I haven't like quite I don't think that it's quite the right way to do it, but I was able to do some cool little things with it. I think I showed you some examples of that. Yeah. Um yeah.

Conor

I will this is a random uh a random side note, but that the fact that you mentioned sort of unfolds and anamorphisms. I was just watching uh Haskell keynote from Haskell Exchange 2021 by Nadia Polakopova. But uh she meant she showed it's an awesome keynote, is the point. And she talks about Google and a variation on Hugo called Hugo Plus, which I actually already had taken that name for a website that I haven't created yet.

Bryce

Perhaps you should remind people what Hugo is, and then you can tell people what Hugo Plus is.

Conor

We'll save that for another episode. We'll save that for another episode. But the point is that she talks about group, which is uh another example of uh an unfold or an anamorphism similar to chunks of in slide. Anyway, C23, I think there's lots to be excited about. Obviously, it's much smaller than C20. But yes, back to 2021 retro. What else? Is that so is that a is that a top three thing for you?

Bryce

For me. I mean, like I spend like a lot of my a lot of my time uh keeping the committee doing things. So yes. Um and uh let's see what other stuff. Um I mean my my team at NVIDIA, yeah, my team at NVIDIA's done a whole bunch of you know super awesome stuff in the past year. Um almost none of which I can claim any credit for, other than uh standing around and promoting it. But uh yeah, we we've got we've got we've it was a huge year for us. We the team like doubled in size. Um you know, we had uh obviously Eric Niebler came and uh joined our team, which is super exciting. Um yeah, there's just just so much stuff that we've gotten done the past year. Um both on both in our C core libraries and also in our uh NV C ⁇ compiler. And I think the future is very bright for both of those things. I'm looking forward to what we'll be able to do next year.

Conor

Very, very politically uh you're just such a polished, you know, off the cuff. Did Bryce prepare for any of this?

Bryce

I don't have an off switch for this. It's just I just wake up in the morning and I'm just in politician mode.

Conor

Still one of my favorite uh things. I'll link, I'll find, I'll go find the episode was when you were on CPP Cast once and you were talking about all the traveling you were doing, and then and then Rob asked, one of the hosts of the podcast, asked, Is uh, are you allowed to travel that much? Nvidia's okay with that. And then you quickly had to transition into an explanation why how all this traveling and work on C was invaluable to NVIDIA and and their big supporter of the ISO process and all this stuff. And I was just like, you could tell it wasn't prepared at all. Uh, but it was this like three or four minute sort of, you know, what could have been a very prepared and polished uh speech that he just off of the cuff, you know, said, and then I was just like, my guy, I wish I had uh I I'm a decent public speaker, but I cannot just what you're saying.

Bryce

Yeah. I can't just Well, it it's it's funny. What one of the other interesting things that's happened at NVIDIA um over the past year, and I think this is really probably the third thing, is not necessarily any of the, for me at least, not necessarily any of the deliverables that my that the C ⁇ organism that NVIDIA has produced, um, but but really more it's the team that we've built. Um when I joined NVIDIA in 2017, um the C team was Jared Hobrick, um, Michael Garland, and Olivier Giro. Like that was it. Um and and NVIDIA was an important player on the C ⁇ committee, but it was not a major player on the C committee. Um and as of right now, NVIDIA is um the larger has sends the largest number of uh representatives to the committee. Um uh we're you know we're we're very deeply involved in the committee and and and more importantly, within the company, um there's a very strong commitment to standard C and also other languages like um standard Fortran. Um and that commitment is not just for our own purposes. Um uh we understand that it's important for these languages to thrive in general because they're the basis of computing on our platforms. Um and so we like we first and foremost care about what's good for the language and what's good for for us in particular is a s is secondary. Um and that that sort of philosophy has been adopted at a very high level within the company. So when when I started at NVIDIA, um our commitment to standard C and our dedication to doing what was good for standard C was sort of like a guerrilla movement that was up in the hills. Um uh but now like the gorillas have like taken the capital um and are like in power.

Conor

Um is this is this uh is this a politically insensitive uh uh analogy here? Are we gonna get canceled?

Bryce

Um there are many potentially problematic things about what I just said. Um but I I think it's uh I think it's fine. I think it's fine. Yeah. But really like a large part of our philosophy on the committee is that um any large company like NVIDIA that is um contributing to a standard, um you know, your first priority should be doing what's good for the standard and building goodwill in the community. Um and sort of it really comes down to stewardship. Um and you know, that's one of the reasons why NVIDIA is okay with me spending so much of my time um uh running library evolution. Probably 60 to 70 percent of my time is spent running library evolution and sharing other um standards committees. I I chair a number of other committees like the inclusive, I chair the uh, or I don't chair, but I'm the project editor for the inclusive terminology guidelines for the US national body. Um I now am the convener for the uh vocabulary um uh group for JTC one and for like two other related vocabulary groups. Um and you like none of that has like a direct none of that can directly be linked to like revenue at NVIDIA. Um but uh you know if if nobody invests in those things, then they're they're they're just gonna you know wither away. Um somebody has to invest in in doing the the the maintenance and and somebody has to invest in um you know m handling all the logistics and the planning of organizing these these standards committees.

Conor

Um uh and we should say it's not just NVIDIA, there's a coalition of companies that, you know, and the which is sort of interesting, you know, when you're not not just companies, a coalition of companies and individuals. And individuals and nationals.

Bryce

Um I I I won't I won't mention him by name because I think he would uh he would uh not want me to call him out, but there is a a certain a certain in French individual who um uh is a freelancer and has made um very substantial contributions to the committee um over the years. And not and and I say that not just that he writes a lot of papers, um, but he writes papers and he takes on a lot of leadership roles. Um and and he doesn't just like write papers that interest him, he writes papers that sort of nobody else um uh is writing, but like that everybody agrees needs to be written. Um and you know, we we have a lot of people like that, and it's you know, there's nobody paying some of these folks to do this. Some some of these people are just doing it in their f in their free time. Um but you know, that's how that's how open standards and open source tends to work.

Conor

Yeah.

Bryce

Which in some ways is unfortunate. It it would be better if we had a a model where um uh everybody who was doing this work could get could have it be a part of their official job and get paid for it. Um I'm very fortunate that I'm one of the people who is actually have a job where literally this is what I'm paid to do, but that's not the case for everybody.

Conor

There, I mean it's uh it's slowly changing. I mean, we're definitely not at the point where um you can click a button on GitHub and that funds you to go to like a C committee meeting. But um one of the podcasts I listen to is called Changelog, and it's about open source, and they talk about sort of the open source uh funding models and GitHub sponsors, like GitHub's doing a ton of great work, and they're sort of adopting like different Patreon models um for individuals and companies to basically like fund open source work. And there are now like way more than a handful of folks that are basically get paid their full-time jobs is working on open source projects. Um and completely randomly, but not completely randomly, because you talked about the Insights inclusive terminology document. This is both an interesting anecdote and a call to action for people whenever they're correcting someone. Um please give an explanation, like a brief explanation um or a link, because for a couple months now, in one video or a couple videos, I used in in uh pro like a live coding on a YouTube video, I used the function name for the solution at the end of it, because I would show like solution one, two, three, four, and then the final one I would call final solution. And I'm not sure if even you're aware.

Bryce

Yeah, yeah.

Conor

And I got like the first one.

Bryce

I can I I see where we're going with this, but I can also understand why you wouldn't have picked up on this.

Conor

My guess is that there's a bunch of folks that don't know, similar to me. And the thing is, is the first couple comments that I got were that like great video, but like the final solution function name uh uh rubs me the wrong way. Or they just said it very nondescriptly, and I thought that they just meant it was a bad function name, which admittedly, calling a function final solution or just solution are both bad function names. They don't say anything, and so I just was like, yeah, that's a good point, didn't respond to it. And then the third or fourth comment that I got said, great video, really love these deep dives. Only problem is that as a Jewish person, I I find I'm a little bit uncomfortable with final solution. And even still, I was still thinking, like the first time I read it, I was like, that's odd, like why I know it's a bad function name.

Bryce

Do they not like teach the Holocaust in like Canadian schools?

Conor

They definitely do. Um, but I if they taught that thing that final solution is another name that the Nazis use to refer to that, um, I either don't remember it or that wasn't taught. And so after thinking, like, that's weird that he's pointing out that he's Jewish, like I get it. It's a bad function name. And then I was like, wait a second, maybe all these people are saying it for another reason. So I Google final solution, and sure enough, the first hit is a Wikipedia page talking about um how this is the term that the Nazis use. So it is definitely, I know there's a whole thing about like it's not on uh the oppressed group to explain um to their oppressors or you know, society at large, you know, what they're going through. But it would have been just amazing. Like I got three or four comments and like didn't pick up on it even in the final time when I picked up on it, it was like implicit. And all like I was I responded to the person and said, Oh my goodness, thank you so much. Like, I'll definitely avoid this in the future. It's funny because like I've got this comment a few times and like I had no idea, I just had no idea. Yeah, and it was conflated with the fact that it is actually just a bad function name, regardless of it having um some other semantic meanings. And so, anyways, my thing is that like I was super happy to be corrected, but in the future, folks, whether it's on a YouTube video or something, don't just say that it makes you uncomfortable. If it like I I'm not sure, maybe there's times that it's not great to explain, but like I would have learned this um like four months ago or three months ago if someone had just linked the Wikipedia final solution. Anyways, I'm not sure if you have thoughts, uh, but I just I thought it was yeah.

Bryce

I um I mean it did take me a minute two to to to to get there, but I it would not have taken me quite that long. Um yeah. Don't yeah.

Conor

I'm not sure if that's in the I'm not sure if that's in the insights document, but uh maybe worth adding.

Bryce

I don't I don't think that that would need to go in because I think it's unlikely that that would come up. Uh like like the the the crite the document is a set of guidelines for how to determine whether, you know, like the the the terms listed in the document, all the terms are in an annex, and that annex is examples of terms. Um and the the actual body of the document is defining what are terms with negative connotations and like how do you identify them and how should you go about mitigating them and how do you migrate away from them, etc. Um uh and so not everything needs to be listed there. Um I I do not think like usually our criterion for listing something is that there needs to be prior art. So like I have an extensive spreadsheet where I've looked at 20 different other inclusive terminology and tech um uh uh you know guidelines, like you know, uh Google has one, IETF has one, uh W3C has one, you know, like all these other organizations have one. And I just like have every term you know cross-listed there. And so I can go look up like, oh, this term that you want to like discuss adding, well, it appears in these three other documents. Um and like I know like final solution doesn't appear in any of those other documents, um, because it it's uh uh it's not it's not like I think it's not a thing that I've come across in any standards documents. I could also, you know, we could also search. Um we have some tools that allow us to search across um tech standards to see whether we hit get hits for anything. Um but yeah, certainly if it did appear in if if it appeared in like a tech standard, um I would definitely you know advocate for us adding it to the list of terms. Um but uh yeah it's it's it's it's an interesting question when when you decide to add something. I I don't think that we add things um proactively like that. Um or at least we we haven't added anything proactively like that in the past.

Conor

Um I just did a search on GitHub for final solution and it got 8,000 hits across code, Java being the worst offender, uh C being in second. Those probably just say more about the popularity of it though.

Bryce

I I'm gonna I'm gonna excitely modify what I said about about not taking steps proactively. Um if even if there's not an existing like cases of the of a problematic term um being used in the wild, um if if you could reasonably imagine circumstances in which that term could be used, um even if it's not used today, then you'd probably want to list it. Um and actually, you know, I I would want to go and look at look in in more detail at um at those hits on your GitHub search. Um uh this isn't now we're sort of getting into um uh this this research process that I do when I'm uh evaluating whether a term should be listed um in our uh in our guidelines. And I I I it it may surprise people to learn, but um every term that's listed in the uh Inclusive terminology guidelines has been like extensively researched. Um like it extensively researched and extensively discussed because we we want to understand what the actual usage is like in the wild and we also want to understand like how different like impacted groups would feel about it. And so knowing that there's 8,000 hits on GitHub is one thing, but like what I would want to look at is like what like what's the pattern there. So you said a lot of them are in Java?

Conor

Well, so actually what what what I was what I saw is actually Python was really low on the list, and I was like, that's odd because I was figuring it would sort of map to the most popular languages, but then I realized I I had typed it just as a single word, final solution, no underscore, and that's that corresponds to camel case, not snake case. And then when I switched it to snake case, I got another 3,000 hits, and then Python was number one, and C is number two.

Bryce

So so here's what I would here's what I would think. Um here's probably what what would you know uh like the the thing that would really factor in my decision would be this question. Um are all of these uses um uh falling in some pattern? And like the the pattern that might come to mind is is final solution a common naming pattern, for example, in competitive coding? Like are all of these um uh uses coming up like in the same like like you know, in like solutions to uh uh competitive coding problems? Um because if so, then then yeah, it would probably make sense to list the term because if it's something that's that's becoming a term of art in a particular field, um, then we definitely want to like cut that off before before it would even you know enter the world of standards. Um so yeah, I'd really have to go and look and understand more about that that usage. And hey, now that GitHub is like in the process of making their code search like better, which I'm so excited about, that's that's really excellent. Um, it will be substantially easier to go and and do these sorts of things. Although I I say that, but the thing that GitHub's code search actually used to be okay at was searching for like function names. The thing that it was really bad at is for searching for like anything that's not just like alphanumeric, like, you know, like searching for like like something that has like uh symbols in it as well, you know, like uh operators, etc. or like a function signature, things like that.

Conor

Yeah, I can't it doesn't really look like there's much of a pattern just on sort of first. It looks like a mix of like homework seems to be like the number one thing, um, which makes sense.

Bryce

And then but that actually that actually might be sufficient. Like if it um I mean well per perhaps that would mean that that's not something that should go into an inclusive term into the insights inclusive terminology guideline, but maybe that's just something that um you know that some CS curriculum guidelines should point to keep in mind. Yeah.

Conor

Yeah. There's some advent of code and yeah, competitive programming stuff, but it yeah, it doesn't look like a lot of this.

Bryce

It looks like a lot of this is like uh is like you know um people solving some school problem, some doing homework or something. So maybe yeah. Maybe college professors just like should take a note that maybe don't have people called it.

Conor

No, I'm I'm sure it's not even it's probably not even the profs. It's just it's just an organic thing that like came up if you're got a couple different solutions and then but um you know it's something that like if you're a professor and you have students that are submitting like like you can just mention it to them. Right, right, right.

Bryce

You know, like it's it's far it's far better for us to solve these terminology issues before they become a problem.

Conor

Yeah.

Bryce

Um like we we I I said earlier that like we don't want to like proactively you know add terms to to this document, but that doesn't mean that we don't want to proactively um address the problem. Like in an ideal world, um we we don't need to list any terms um as being problematic in an inclusive terminology guideline because we do such a good job of um thinking about the language that we're using that there is no sort of existing art of problematic terms. Obviously, we're never gonna get there, but um, but uh you know, I think it's important to start uh to to educate people as you know as early as possible about uh being cautious about the language that they use.

Conor

Yeah. Yeah, no, I totally agree.

Bryce

All right, we're close we're approaching the 30 minute mark and uh Yeah, well we uh we haven't we've done my twenty twenty one retrospective. What about your twenty twenty one retrospective?

Conor

Stay tuned next week for part two. Thanks for listening. We hope you enjoyed and have a great day.