Algorithms + Data Structures = Programs - Episode 61: 2021 Retro (Part 1)

Episode Date: January 21, 2022

In this episode, Bryce and Conor talk about the highlights of 2021.Date Recorded: 2022-01-08Date Released: 2022-01-21C++23C++ RangesC++ Range-v3 cartesian productC++ Range-v3 repeatC++ Range-v3 slidingC++ Range-v3 chunkGenerating Programs from Types (Keynote by Nadia Polikarpova at Haskell eXchange 2021)HoogleHaskell groupCppCast Episode 210: mdspan and /r/cpp with Bryce Adelstein LelbachChangeLog PodcastINCITS Inclusive Terminology Guidelines“Final Solution” Wikipedia pageIntro 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

You're just such a polished, off-the-cuff. Did Bryce prepare for any of this? 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. 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. All right, let's do the retro. Retro, episode 61, 2021, go. Top three? We'll do the retro. 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 2021 in review first from either Bryce's personal view or Bryce Library Evolution Working Group chair view, or what are you? Architect? HPC architect? Head of CCCL? You've got like a bunch of different hats

feel free to give a an amalgamation 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 would already when did you move back to toronto i moved back in uh nove of 2019, approximately three or four months before the pandemic. Yeah. So you were, you were already gone, but so, so I moved to the, moved to New York. I mean, I think we've done, you know, we, we really sort of finished the C++23 design cycle in 2021. You know, we have like a few weeks left to be design complete,

but most of the actual substantial work that happened for C++23 wrapped up this year. And I think that C++23 is pretty exciting. I think we've got some pretty exciting work coming. Yeah, I think it's shaping up to be a pretty interesting release. Ranges, woo! Yeah, there's a lot of ranges enhancements. Standard library modules stood expected.

Deducing this. There's a variety of other language enhancements. Extended floating point, something near and dear to my heart. MD span. And the jury is still very much out on what's going to happen with executors. Stay tuned for that. We'll find out soonish yeah there was a a fireside committee panel chats that i watched on youtube that took place in september and you were 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 c++ 23? And the answer was very limited. See, I find it a little bit, 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 i mean at least at least a few of the people on stage were but 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 going to say that i think if you're

going to have a panel of people talking about a thing, those people should actually be qualified to talk about the thing. And not everybody on that panel was qualified to talk about the things. So maybe they should have kept their mouth shut. All right. This is juicy content for the ADSP listener. Yeah. But yes, C++23. 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 at Jason Transform. I'm excited about Cartesian product. The thing I'm actually probably most excited about is that you can now write your own pipeable range adapters so that anything that we forgot to add as a range adapter,

you can now add yourself. So I think that's pretty cool. Yeah, you can use other... So you can basically use range V3 with the standard out standard ranges as well i actually i use yeah adjacent 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 the whole window and that family of ones. Oh, yeah.

Window and chunk and whatnot. Anamorphisms, unfolds. Yeah, slide, chunk, et cetera. Those are all pretty cool. I haven't quite figured out how to do all the exciting things that I want with them, but I wrote some pretty cool examples combining cartesian product and slide and chunk of building like um decomposing a multi-dimensional space into like tiles um i haven't like 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 yeah yeah i will this is a random, a random side note, but that the fact that you mentioned sort of unfolds and anamorphisms. I was just watching a Haskell keynote from Haskell Exchange 2021 by Nadia Polakopova. But she meant she showed it's an awesome keynote is the point. And she talks about Hoogle and a variation on Hoogle called Hoogle Plus, which I actually already had taken that name for a website that I haven't created yet. Perhaps you should remind people what Hoogle is, and then you can tell people what Hoogle Plus is. 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 another example of an unfold or an anamorphism similar to chunks of

and slide. Anyway, C++23, I think there's lots to be excited about. Obviously it's much smaller than C++20, but yes, back to 2021 retro. What else? Is that a top three thing for you? For me, I mean, like I spend like a lot of my time keeping the committee doing things. So yes.

And let's see, what other stuff? I mean, my team at NVIDIA, yeah, my team at NVIDIA has done a whole bunch of, you know, super awesome stuff in the past year. Almost none of which I can claim any credit for other than standing around and promoting it. But yeah, it was a huge year for us. The team doubled in size.

Obviously, Eric Neva came and joined our team, which is super exciting. Yeah, there's just so much stuff that we've gotten done the past year, both in our C++ core libraries and also in our NVC++ 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.

Very, very politically. You're just such a polished, you know, off the cuff. Did Bryce prepare for any of this? 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. Still one of my favorite things. I'll go find the episode.

It was when you were on CPPcast once and you were talking about all the traveling you were doing. And then Rob asked, one of the hosts of the podcast asked, 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 they're a big supporter of the ISO process and all this stuff. And I was just like, you could tell it wasn't prepared at all.

But it was this like three or four minute sort of, you know, what could have been a very prepared and polished speech that he just off of the cuff, you know, said, and then I was just like, my guy, I wish I had, I'm a decent public speaker, but I cannot just. You're not as good of a bullshitter as I am, is can't just well 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 atVIDIA has produced, but really more it's the team that we've built. When I joined NVIDIA in 2017,

the C++ team was Jared Hobrick, Michael Garland, and Olivier Gouraud. That was it. And NVIDIA was an important player on the C++ committee, but it was not a major player on the C++ committee. And as of right now,

NVIDIA sends the largest number of representatives to the committee. We're very deeply involved to the committee. Um, uh, we are, 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 plus plus, and also other languages like, um, standard Fortran. And that commitment is not just for our own purposes. We understand that it's important for these languages to thrive in general because they're the basis of computing on our platforms. And so we first and foremost care about what's good for the language and what's good for us in particular is secondary. And that sort of philosophy has been adopted at a very high level within the company. So when I started at NVIDIA, our commitment to standard C++ and our dedication to doing what was good for standard C plus plus was sort of like a gorilla movement that was up

in the Hills. Um, uh, but now like the gorillas have like taken the Capitol, um, and are like in power. Is this a, is this a politically insensitive, uh, analogy? We're going to get canceled. Um, there are many potentially problematic things about what I just said, but 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 any large company like NVIDIA that is contributing to a standard, you know, your first priority should be doing what's good for the standard and building goodwill in the community. It really comes down to stewardship. And that's one of the reasons why NVIDIA is okay

with me spending so much of my time running library evolution. Probably 60 to 70% of my time is spent running library evolution and sharing other standards committees. I chair a number of other committees like the inclusive, I don't chair but I'm the project editor for the inclusive terminology guidelines for the US national body. I now am the convener for the vocabulary group for JTC1 and for like two other related vocabulary groups. And you like none of that has like a direct, none of that can directly be linked to like revenue at video. Um, but, uh,

you know, if, if nobody invests in those things, then they're, they're just gonna, you know, wither away. Um, somebody has to invest in, in doing the, the, the, the maintenance, and somebody has to invest in, you know, handling all the logistics and the planning of organizing these standards committees. And we should say it's not just NVIDIA. There's a coalition of companies that, you know, which is sort of interesting, you know, when you're talking about... Not just companies, a coalition of companies and individuals. And individuals and national bodies, yeah.

Some very motivated individuals. I won't mention him by name because I think he would not want me to call him out. But there is a certain French individual who is a freelancer and has made very substantial contributions to the committee over the years. And I say that not just that he writes a lot of papers, but he writes papers and he takes on a lot of leadership roles. And he doesn't just write papers that interest him. He writes papers that nobody else is writing, but that everybody agrees needs to be written. And, you know, 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 of these people are just doing it in their free time. But, you know, that's how, that's how open standards and open source tends to work. Yeah. Which in some ways it's unfortunate. It would be better if we had a model where everybody who was doing this work could have it be a part of their official job and get paid for it. 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. I mean, it's slowly changing. I mean, we're definitely not at the point where you can click a button on GitHub and that funds you to go to like a C++ committee meeting. But 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 funding models and GitHub sponsors, like GitHub's doing a ton of great work and they're sort of adopting like different Patreon models 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. And completely randomly, but not completely randomly, because you talked about the insights inclusive terminology document. This is both a interesting anecdote and a call to action for people whenever they're correcting someone. Please give an explanation, like a brief explanation 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. Yeah. Yeah. And I got like the first couple comments. I shouldn't laugh, but yeah, I can understand. I see where we're going with this. Yeah. And I also understand why you wouldn't have picked up on this. 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 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, 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. Do they not like teach the Holocaust in like Canadian schools? They definitely do. But I, if they taught that thing that final solution is another name that the nazis used 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.

Sure enough, the first hit is a Wikipedia page talking about 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 the oppressed group to explain to their oppressors, or, you know, society at large, we 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, 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. Cause like, I've got this comment a few times and like, I had no idea. I just had no idea and

it was conflated with the fact that it is actually just a bad function name regardless of it having some other semantic meaning and so anyways my thing is 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'm not, 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, I, um, I mean, it did take me a minute to, to, to, to get there, but I, it would not have taken me quite that long um yeah don't yeah 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 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 correct the document is a set of guidelines for how to determine whether, you know, like the terms listed in the document, all the terms are in an annex. And that annex is examples of terms. And 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, you know, guidelines like, you know, Google has one, IETF has one, 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. And like, I know like final solution doesn't appear in any of those other documents because 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.

We have some tools that allow us to search across tech standards to see whether we get hits for anything. But yeah, certainly if it did appear, if it appeared in like a tech standard, I would definitely, you know, advocate for us adding it to the list of terms. But yeah, it's an interesting question when, when you decide to add something. I don't think that we add things, um, proactively like that.

Um, or at least we haven't added anything proactively like that in the past. Um, I just did a search on GitHub for final solution and it got 8,000 hits across code, Java being the worst offender, C++ being in second. Those probably just say more about the popularity of it though. I'm going to slightly modify what I said about not taking steps proactively. If, even if there's not an existing, like, cases of a problematic term being used in the wild, if you could reasonably imagine circumstances in which that term could be used, even if it's not used today, then you'd probably want to list it. And actually, you know, I would want to go and look in more detail at those hits on your GitHub search. This isn't, now we're sort of getting into this research process that I do when I'm evaluating whether a term should be listed in our guidelines. And it may surprise people to learn, but every term that's listed in the inclusive terminology guidelines has been like extensively researched, like 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 that 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's like, what's the pattern there? So you said a lot of them are in Java. Well,

so actually 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 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. So here's what I would think. Here's probably what would, you know, like the thing that would really factor in my decision would be this question. Are all of these uses falling in some pattern? And like the pattern that might come to mind is final solution, a common naming pattern, example in competitive coding like are all of these uses coming up like in the same like like you know in like solutions to

competitive coding problems 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, then we definitely want to cut that off before it would even enter the world of standards. So yeah, I'd really have to go and look and understand more about that usage. And hey, now that GitHub is 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 do these sorts of things. Although 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 something that has like symbols in it as well. You know, like operators, et cetera, or like a function signature, things like that. 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 and then but that actually that actually might be sufficient like if it um well 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 keep in mind. There's some advent of code and competitive programming stuff. It looks like a lot of this is people solving some school problem, doing homework or something. So maybe, yeah. Maybe college professors just, like, should take a note that maybe don't have people call. No, I'm sure it's not even, it's probably not even the profs. It's just an organic thing that, like, came up if you 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 you know like it's it's far it's far better for us to solve

these terminology issues before they become a problem yeah um like we we i said earlier that like we don't want to like proactively youactively, you know, add terms to this document. But that doesn't mean that we don't want to proactively address the problem. as being problematic in an inclusive terminology guideline, because we do such a good job of thinking about the language that we're using, that there is no sort of existing art of problematic terms. Obviously, we're never going to get there. But, but, you know as early as possible about uh being cautious about the language that they use yeah yeah no i totally agree all right we're close we're approaching the 30 minute mark and uh we haven't we've done my 2021 retrospective what about your 2021 retrospective stay tuned next week for part two thanks for listening we hope you enjoyed and have

a great day