Algorithms + Data Structures = Programs - Episode 69: Special Guest Andrei Alexandrescu (Part 2)

Episode Date: March 18, 2022

In this episode, Bryce and Conor finish their interview with Andrei Alexandrescu.TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachWebsiteADSP: The PodcastAbout the Guest:Andrei Alexandrescu specializes in all aspects of designing and implementing software systems, as well as Machine Learning applied to Natural Language Processing and Speech Recognition. He has authored three best-selling books (The D Programming Language, 2010; C++ Coding Standards, 2004; Modern C++ Design, 2001), and dozens of papers and articles in conference proceedings and trade magazines.Show NotesDate Recorded: 2022-02-15Date Released: 2022-03-11Andrei Alexandrescu on TwitterD Programming LanguageCategory Theory for Programmers by Bartosz MilewskiIterators Must Go by Andrei Alexandrescu, BoostCon 2009C++Now 2017: Ali Çehreli “Competitive Advantage with D”Fastware - Andrei Alexandrescu - NDC London 2017CUDA C++ Programming GuideADSP Episode 51: Efficiency vs SpeedIntro 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

What a percentage of the time was it always D-design or sometimes was Bartaj given a little, you know, category theory? Bartaj should always try to sneak in some category theory. Always. But I learned nothing. Welcome to ADSP The Podcast, episode 69 recorded on february 15th 2022 my name is connor and today with my co-host bryce we finish part two of our two-part interview with andre alexandrescu oh speaking of bryce you mentioned this like i don't think i'm the best in every meeting or something like that right you mentioned that it's kind of funny so i have this interview question so when i interview people i was just uh i worked for symmetry investments uh this um fintech company and you know i had this interview question in a meeting like let's say you're at work in a meeting what do you want

to be in terms of skill do you want to be be the best, the worst, or someone in the middle? Right? Yeah. Well, it's actually interesting because I think I have two different answers. It used to be that when I was solely an individual contributor, my answer was, I always want to be in the room with people that are smarter than me. And usually if I'm having like a typical meeting with like multiple people, you know, that is usually a meeting where like, I want to be there with people that are going to educate me in some way. But since I've moved into more of a leadership role, and I've always sort of over the years, I've always had some amount, some number of people that I have mentored in some way, shape or form,

but I do a lot more of it these days. i have learned that it is incredible like i think one of the highest value things that i do is have one-on-one meetings with um like the various members of the my team and the other teams that i work with especially the um uh the less senior members or the members that I'm trying to encourage them to take on more responsibility and to grow into a bigger role. And I've started realizing that sometimes I can have a 30-minute or an hour-long meeting with somebody and I can say one thing

and that will completely change how they're going to operate for the next week the next week. And like, it'll lead to a much better outcome. Yeah. Yeah. Awesome. So it's, you know, what would you answer Connor? Because then like one of my biggest things that I'm after in life is like learning. I'm very curious and I always want to be learning. And if you're the least intelligent, that doesn't mean you're unintelligent. It just means relative to the people in the room. Right, right. That being said, like I always want to be at a place where like I have the context and

the tribal knowledge because there's like, there's, you know, regardless of what your job title is, it's like those two different states where you're feeling like you're an imposter and people are assuming that you have a certain level of knowledge but it's like it's not that you don't have that knowledge is that you can't contribute in it's like i always have this metaphor of when you're trying to learn something especially a programming language you start out and it's like this planet or something that you can't wrap your hands around and then at certain point, you sort of feel like you can palm it like a basketball. And then at a certain point, you feel like you can get your whole mind

around it. And like languages like, you know, lisps are super easy to like, you know, you know, scheme, you can learn in a day or two, and then you feel like you're a god, you know, operating that that language, but C++, I never feel like, you know, supposedly, operating at that language but c plus plus i never feel like you know supposedly i'm an expert in the language but like i never feel like i fully have my hands wrapped around it because it's there's it's just too large it's changing too often so maybe bjorn doesn't have his hands around it or her yeah well i mean i mean famously what does he give himself a six or seven out of ten or something um that there's some quote and then we've we've had this conversation offline that like even though you may feel

like a one or two out of 10, that doesn't make you not an expert because like relative to, you know, the C++ engineers at large. So I guess my point here is less than being like the smartest or the least intelligent relative to the folks in the room. I always want to feel like I have,

like I'm not missing out on the context or the tribal knowledge or like the assumed knowledge because that's when you're really able to like ask the questions, like, I'm not missing out on the context or the tribal knowledge or like the assumed knowledge, because that's when you're really able to like ask the questions and like feel comfortable. Yeah. And like that, there's always like a certain period of time when you join a company. And that's like, that's one of the hardest things. Like when I switched from my first company that I worked for four or five years at, you get to this place where you have all that knowledge and you're the person in the room that knows the questions to ask and the things to bring up. And then when you switch to a new company,

you're giving up all of that tribal knowledge. And in some companies, like some of it is more transferable if it's like, you know, standard C++ and you're going to another company. But at my first company, it was all just this very, very narrow sort of actuarial, you know, domain knowledge

that is just, you know, all of that expertise just goes poof and you're not really bringing it. And it's hard to like, go from a place where you're kind of, you know, the expert or one of the experts in the room, and then being to the person that needs to go back to square, you know, not zero, but I do follow the Chris Lattner philosophy, though, that he's, he's always, you know, trying to surround him with people that know way more about their top, you know, their domain than he does does because then he can just leech off of them i love these answers um and you know bryce mentioned the whole mentoring aspect and that's wonderful and the whole like sharing and you know this is like really a nice thing like this this one thing you can say that completely

changed like you know dostoevsky manner it changes completely the life of the, you know, the person you're mentoring. And I think that's awesome. And Connor, you mentioned this, like, I want to, you know, I want to have be somewhere in the middle, kind of have the tribal knowledge, but also have people to learn from. Well, you folks, you would be shocked at how many folks walk into that interview and ask them this question and they answer,

I want to be the best in every meeting. And, you know, in a way, there's no wrong answer to this question, but I think they wouldn't realize just how boring that life would be. It definitely would mean they're in the wrong employment, they're in the wrong place, because you don't want to be in a place where you're the best at everything and have nobody to learn from anything, you know. So definitely it's not a good place to be in the long term. So, you know, that also harkens back to the whole discussion of humility and you know a necessary quality of a programmer

so good stuff you folks um hey i want to discuss politics all right here we go here we go folks this is where our pg-13 podcast is going to have an explicit rating for uh henceforth yeah take your kids to sleep upstairs you know close the door and let's talk politics so you know i i'm not you know i'm not here to your kids to sleep upstairs you know close the door and let's talk politics so you know i i'm not you know i'm not here to kind of ask you what you know who you voted for whatever and um i'm gonna i'm gonna say i'm desperately trying to stay centrist but centrist being in a center seems to be nowadays nobody believes you like if you talk to someone on either side they're gonna assume you're on the bad side

and you know that kind of stuff um but i i just i do i don't want to discuss politics per se as much as the impact of politics on uh on the new uh generation of programmers because i have this feeling that uh there may be some uh crosstalk some influence and. And here's my take. It is my opinion that in the last few years, let's say, and not only in the States, but globally, there's been an increasing relativization of the truth. An increasing, you know, actually in the whole like the alternative facts like this, the fact that this phrase was even authored on

like in public. The sheer fact that somebody with political acumen mentioned there's alternative facts and there's alternative facts. And the sheer fact that this phrase got even said is a huge deal for for sciences for everything that's hard science everything that is programming and everything that's in engineering and i wonder somebody who grows up in such an environment

in which you know the truth is uh pretty much you can you can you can work it out you can work out your own truth if you don't like the, you know, whatever the real facts indicate. I fear that there's going to be a problem with like five years from now and all of these kids who actually missed a lot of

school and that's yet another issue, right? They missed a lot of school for a variety of reasons related to COVID, right? Missed a lot of school, missed a lot of school for you know for a variety of reasons related to covid right missed a lot of school missed a lot of hard science preparation and grew in this environment where actually uh truth is uh is not an absolute um you know it's not an absolute reference and how do you get to program a computer where actually if one bit is out of place, it's kind of the ghost, it goes berserk, right? There's no absolutely nothing, there's no telling what's

going to happen if one bit is in the wrong place, right? So, you know, I just wanted to ask you about what's your take about this? Well, I think it's an interesting question. I think that, yeah, I definitely think the current generation that's had some amount of like their schooling where they've been like during the pandemic, like there's going to be, we're going to see that five, 10 years from now. But what one, I think one interesting thing has changed since when Connor and I were in school, which is, and maybe it's even not the case for Connor, but when I was in like school before college, like all my schooling before college, there was never any programming courses. It was not an option.

I went to school in Connecticut, which is a very wealthy part of the United States. I went to a private middle school that was a science-focused middle school. I went to a magnet school that was a science-focused high school, but no coding. And every year I run the C++ Now student volunteer program, and I started noticing more and more over the years that people had coding experience younger and younger in the classroom. And I think a lot of programmers of Connor and I's age and and older where they're self-taught or they started

programming because, you know, a parent had a computer at home. But I think programmers that are younger than us, more and more of them had exposure at a younger and younger age in some form of more structured, you know, education. And I wonder whether that's going to, you know, how that will change the field. And I wonder, I think that might even be more impactful than, you know, the pandemic experience, although obviously the pandemic experience is pretty impactful for everybody. Yeah, I don't know. What do you think, Connor?

So the question is, how is like the relative truthiness of society going to impact software engineers? I mean, I don't know. I'm not really like a philosopher. I think that the polarized society that we live, like, you know, there's sort of articles that'll come out and say that, like, we're missing the fact that, like, we live in the best sort of time in history. Like, if you look at crime rates and you look at, you know, education and et cetera, just in general, like quality of life metrics that are measured by the WHO and NIH or I don't know, whatever the organizations are that in general, we've been life metrics that are measured by the WHO and NIH, or I don't know,

whatever the organizations are that in general, we've been on an uptrend in terms of like the average quality of living across the globe. But due to whatever social networks, you know, Twitter, Facebook, etc. And the polarization of politics and whatnot, it sometimes doesn't seem like that. And I guess I just like I am very lucky and I think privileged that I grew up in a country and in a family that like taught critical thinking and that at a certain like my dad was a journalist. And, you know, we learned at some point that like whenever you consume anything, you need to know who wrote it, you know, what it was funded by. And these days, like I think that's super important that, you know, what it was funded by. And these days, like, I think that's super important that, you know, when you read something or consume something, it's good to know, like, you know, it starts off like in, you know, in history that like, when was it written? That

seems like a super trivial thing. But a lot of times you don't, do people look at the C++ article? Was it written in 2003? Or was it written in, you know, 2018? That's going to heavily influence the best practices that you're you're reading and anyways i just i don't think i have anything really important to say it's just that like i i hope that you know across the globe we teach youth and just everyone to not do your own research or find your own facts but just like know where stuff is coming from and like what the agenda is behind it because these days whether it's buzzeed and just trying to suck you in to read as you know, many top top 10 things or you know, you won't believe what happened next. And just know that like, the goal of that website is

just to keep you keep your eyes glued to the page as long as possible is just like, know the context and think critically about that stuff. I will say in general, I do think everyone should be trying to be more welcoming, we should be trying to build communities and spaces where everyone feels welcome. Like if you don't understand where someone's coming from, you don't need to understand. You just need to want to be a decent person and like build a space where no matter how someone identifies or, you know, the background is that everyone feels welcome. And I don't know, I think that's, that's something that gets lost in the politics war. Yeah, exactly. So this kind of community building and stuff goes against the whole polarization tendency that we've been having as of late.

So I'm just, you know, I'm just a bit preoccupied about this matter, you know, and the whole like critical thinking, which is essential nowadays, but now it became bastardized by, you know, the whole do your research kind of thing is like yeah you can find anything on the internet if you anything you want on the subject support for anything you're you may be thinking of so the whole do your research is is uh is uh you know is a clever um twist on actually know the source of uh of your information and you know it's kind of a bummer that things like that are happening and you know twist on actually know the source of your information. And, you know, it's kind of a bummer that things like that are happening. And, you know, I'm just a bit worried that programming, which is this absolutely the

ultimate deterministic, you know, the ultimate deterministic job to have and kind of attitude to have. I wonder how somebody who's growing up in this environment would be inclined to take on programming. I hope, of course, there's going to be a detente of the current situation. But right now, I'm just a bit worried that the political climate is really unfavorable to learning programs. Just to put it like in a kind of direct way, something that is rather subtle. That's fascinating. I would have never thought of that.

But, you know, I think you may be right. You know, and I think potentially not just programming, but also, you know, just the STEM fields in general. Exactly. Anything that's kind of hard science. For example, I remember there's this article. There's a percentage in an article that was kind of a bad number. I forgot. It was 17.

I forgot. It was a number that was like a year, like the year of... I forgot. It was a bad year. And it appeared as a percent. You know, 17 point something. And it became a year that slavery something bad happened that year i forgot the details but essentially they had to they sent an excuse saying oh we're sorry the

percentage came to be this offensive number a number should not be offensive folks a number is a number and that's the end of it like yeah maybe it's a coincidence but you shouldn't apologize for well we kind of divided like uh how many whatever by how many whatever and it came to this percentage number and uh oh we're so sorry it came to a bad number there shouldn't be bad numbers and that kind of stuff we shouldn't bad numbers so anyway so uh what else is up, Connor? sort of HPC academia, tends to lack the rigor in dealing with data and statistics that other fields have. Like if you go read a paper... Bryce, I swear, you never read an article on medicine then, because medicine is terrible at statistics. They just don't do statistics well at all. but at least they have like they report like sample sizes right like i've

read so many cs papers where there's like a performance graph and there's like no indication of like the sample sizes or like no discussion of of uh you know the statistical treatment of the data at all and it just drives me crazy whenever whenever i see i know i agree i agree some some some stats are bad but again i gotta say there are there are fields that also like uh in finance the math is sometimes like really like real bad maybe this is like a grass the grass is always greener thing we're like we think it's bad here but it's actually just bad everywhere yep yep it may as well. Yeah. All right. So, Connor, I thought you wanted to get some stories.

Yeah, you wanted to drive this somewhere. Yeah. What are the odds that we could get a podcast panel with Eric, you, Walter, and Bartaj? I would love that. We wouldn't even, I mean, I don't even know. Would we introduce? I think we would just sit there and be like we wouldn't even we wouldn't even I mean we'd introduce I don't even know what we introduce I think we would just sit there and be like go yeah actually panels are like uh yeah they're fun and um you'll never get out of things to say like people just you know this is gonna talk forever whenever I've been in a panel we started with the notion that oh what are we gonna

say for one hour in this panel? And it ended like, oh, guys, it's like two hours now, so we should go. So it always was like that. So a panel would be fun. So, you know, just to mention a bit of what Eric, you know, was reminiscing about. It was, we had like some infamous, in Bryce's words, meetings at a coffee shop in Kirkland, which has since closed.

And it was, essentially, we would meet, we would talk shop, and we would design the deep programming language. That was it. And these meetings would last for literally like 10 hours. We were like, again, infamous among the folks at that coffee shop because we had this table, we'd always go at the same table

and we'd always like talk loudly and everything and whatnot. We'd be very enthusiastic about things. And probably, you know, the folks at the coffee shop would, you know, would be happy with the sales or whatever because we'd drink coffee nonstop and occasionally eat there and stuff. But during those meetings, a lot of the D language has been designed and a lot of features that I think are very interesting

were designed during those outings. You would have 10-hour meetings at this call? Like on weekdays, on weekends? Who were would have 10-hour meetings at this conference? Like on weekdays, on weekends? Who were at these 10-hour meetings? It was Saturdays and or Sundays, every weekend for months. Wow. Yeah.

Yeah, so who was there? Walter, Bartosz, Eric, myself, Brad Roberts, and occasionally, yeah. And there's David Held. I think he's with Expedia now so it does a motley crew and a nice gang and we've had a lot of fun and sometimes the meetings would go through like we would eat dinner so you know we'd meet in the morning for coffee and it goes and goes and goes it's like

oh it's dinner time we should eat now so we could have dinner so um i remember a lot of um a lot of uh the modern features were designed and improved and you know notably things like the you know the constant system uh which is uh interesting because it's transitive so in c++ when you say const on a pointer it's const applies to pointer, but not to the data that the pointer points to. So it's not, it doesn't go all the way, right? So in Indeed, it's actually a rabbit hole. So if you, if you put const on something, it goes all the way through by following pointers and pointers to pointers and pointers to pointers, pointers, et cetera. So it's, it's really a kind of transitive, right? So there are interesting consequences to that and that kind of stuff

and uh that feature was designed during those meetings uh we would uh it took it took us a while uh the downside was that there was little formalization so there's like little record there's no records of those meetings having occurred and there's like uh there's a lot of, you know, design by excitement, if you wish, as opposed to a rigorous process. Damn. What a percentage of the time was it, was it always D design or where sometimes was Bartosz given a little, you know, category theory? Bartosz should always try to sneak in some category theory. Always. But I learned nothing. So I can't speak to that

maybe Bartosz could maybe his perception is that he always talked about that but my perception is he always tried to talk about that without much success but you know clearly the vast majority was on the design of the D language that was definitely

the lion's share of the time. Interesting. So that's, because that's the thing, is I don't think Eric ever mentioned, not mentioned, obviously the D language came up, but he never said that, you know, he helped design parts or... Oh, he did.

He did, but, you know, maybe his perception is different because like that elephant, right? So there's these discussions by the stable and you discuss shop and maybe maybe you discuss things like you know how do you do templates or how do you know how do you generate code and how do you do this or how do you do that and to him maybe he was thinking of talking shop in general speaking generalities or maybe speaking of how C++ does it but to

Walter it was oh I'm gonna you know I'm gonna take this experience into the D language so for for Walter clearly it was about the D language for, it was, oh, I'm going to take this experience into the D language. So for Walter, clearly it was about the D language. For Eric, it was about more general things. For Bartosz, it was about category theory and that kind of stuff. Do you remember, Andrei, giving, I think, a keynote or a talk at C++ Now about ranges and D? Was that the infamous iterators must go? Yeah. No.

Yeah, that should have been it. 2009, I think. Sorry, which contest is this, Bryce? It wouldn't have been 2009. It would have been... I think you're thinking of Ali. No, no, no. It was an Andre talk.

It was an Andre talk, I think. It was an Andre talk. It was an Andre talk, I think. It was an Andre talk? Yeah. Well, there's like this talk that had the title iterators must go, which discussed ranges versus iterators and made the argument that ranges have advantages. And, you know, as I mentioned in the NVIDIA meeting,

this was clickbait. I mean, I used clickbait before it was cool, right? So iterators must go. It was a bit of an exaggeration. So clearly, you know, there's a lot of good about iterators. But the talk was mainly about what if you used a range and not the iterator as the lowest level of abstraction possible. So you had the range.

Assume you have like ranges in C++, but you never want to use iterators. And how far can you go? It turns out you can go as far as you want. So that was the gist of the talk. It turns out ranges are enough expressive, expressive and wise to design a large template library. That should be the talk you're referring to, Bryce, right?

I'm not sure. I'll have to find it, and we'll talk about it the next time. But maybe it wasn't you. I thought it was you, but that was like 10 years ago. So who knows how well I remember things. Yeah, there's a bunch of – I don't actually remember all the talks because I've – I mean all the names of the talks because I've seen so many of them um did you i can't remember if you gave a talk by the same

name of your hypothetical book which i'm not actually sure if it was a joke or yeah fastware um is that actually is that a book that's ever gonna it's not a book and you know you know why i'll tell you exactly why because i figured there I figured in this day and age, there should be no fastware without some parallel programming CUDA style. There cannot be. I'm going to do fastware on the CPU. You two know why, but I'm going to explain it for the sake of your listeners.

Nowadays, if you look at any computer, even the laptop I'm facing right now or you know desktop computer even a phone the vast majority of the computing power is not in the cpu it's not in there it's like it's 10 of the power is there how can i write a book about 10 of the power right and claim that's fast where that's what you need to you know it's gotta be so in a way the the third reason and the most um uh the most dark of all reasons i joined nvidia for was to learn cuda and parallel programming and how to use the gpu for computing and then to kind of have enough uh understanding and material for writing fastware the way it should be written.

And Bryce, I'm not sure if you even remember, in 2019, you and I met in the hallways at CPP Con and I discussed fastware with you as a possible co-author. And that's still something that could be in the books. It would be great to work together on this stuff. So fastware is... I have ideas for 10% of fastware because that's how important the CPU is.

This book is going to be like your life. You literally took a job to learn for this book. I'm not kidding. This is actually not an exaggeration. So, definitely fastware should be written. It needs to be written. A book on how to write fast software because we're getting to the point where,

you know, the molecules are not going to get smaller. You know, those crystals in the silicon are not getting smaller. The light is not getting faster and we got to make do with what the hell we have. And that's what we have. And we need to solve all of those good problems that we discussed in the beginning, the self-driving and the climate and all that good stuff.

We should solve with the means we have. Go ahead, Bryce. Well, one of the reasons why I like the title Fastware is because Connor and I got into this discussion on earlier episodes of the podcast about speed versus efficiency and, you know, fast really sort of fast is vague enough that it, it, it captures what you want. Like it meets, it meets its,

its requirements in terms of performance. Right. And the, the weird, you know, the weird unintuitive thing about parallel programming is that what is efficient is not often the fastest thing to do yeah well why don't you give can you give a simple example for our listeners because i think this uh this is

a exactly as you said it's not intuitive it's not an intuitive topic um for for a lot of algorithms uh it is like the way that you paralyze the algorithm might might do more work than it needs to yeah exactly but that's necessary to allow it to be paralyzed um like the uh um a lot of the parallel versions of scan algorithms um are like inefficient they they do more evaluations than the serial versions but doesn't it doesn't matter if it's the difference between happening in parallel versus happening in serial. Yeah, exactly. So I think this is a very important point. For example, like in first approximation, faster is going to be more power efficient because you complete the work faster. But there's, for example, like the simplest example that somebody without CUDA experience could master is like there's speculation in a traditional CPU, right?

There's speculation and if you do a lot of speculation, it doesn't turn out to be what you wanted. You throw the results away, but you do more computation, right? But what you're saying is actually the whole algorithm is redesigned in a way that does wanted you'd throw it you throw the results away but you do more computation right uh but what you're saying is actually the whole algorithm is redesigned in a way that uh does more work but that work is to set up more parallelism and you still finish faster but you do you do consume a bit more power yeah so yeah so uh these i'm glad we got to this uh this well it's i think most computing tends to fall into like one of two different end goals.

Either one, you're trying to do something in the most power efficient way possible or two, you're trying to get an answer as quickly as possible. You know, minimize the time exclusion. You got to break

to not go over that pedestrian. Yes, yes. Land the plane. Yes, land the airplane. Thanks for listening. We hope you enjoyed and have a great day.