Zach Laine 0:01

Bryce is fancy. It wants everyone to know it.

Conor 0:08

As soon as Bryce said that, I was like, here we go, Zep's gonna take him down a bit.

Bryce 0:14

Stepin up is very good at building up theory, but also remaining pretty close to how computers actually work.

Zach Laine 0:22

You know, Rust took the problem with writing code in C.

Bryce 0:27

Hey, that's enough, babe.

Zach Laine 0:29

Um, I I uh I'm sorry, but I mean I was just answering what you asked me, and I don't think you should call me babe. A good review of high-level design and a good design of a library are isomorphic in that you want lots of things to be the same about them. If it's possible to do so, you want to make it impossible to use it incorrectly. If that's not possible, we make it difficult to use it incorrectly.

Conor 0:49

Ah, damn. Shit's popping.

Zach Laine 0:53

I like how that just doesn't sound like it goes with uh hosted by Bryson Connor.

Conor 1:09

Welcome to ADSP the podcast, episode 161, recorded on December 18th, 2023. My name is Connor, and today with my co-host Bryce, we are joined by Zach Lane for our fourth holiday special, a special episode of our Longeseia all released in one commit. In today's episode, we talk about a plethora of topics, including the elements of programming, the rest programming language, the hilo programming language, C 2023, 26, 29, all of the upcoming features that people are excited about, and a lot more. We hope you enjoy today's special episode. Should we switch to a different like Google?

Bryce 1:57

It's just happening.

Conor 2:00

Also, should I be recording? Should I be recording?

Bryce 2:03

Yes. Just for the viewer right now, what what what we are seeing of Connor is we are seeing a black and white image that looks like it's nighttime and it's flickering at about, I would say, like 80 hertz at least.

Zach Laine 2:18

It is uh it's a little terrifying.

Bryce 2:22

Yeah, it looks like a horror movie.

Zach Laine 2:23

It really does. It looks like one of these cheap Blumhouse movies like paranormal activity or something. It's like got like the the the black and white, grainy, you know, one one light source uh you know night vision thing. It's just all creepy.

Bryce 2:40

You know, the the the really the really bad part here is so so Connor's reason for why this is happening.

Zach Laine 2:46

Oh no, I'm I was talking about you you, Bryce. Oh no, Connor's weird too. Are you are you also in a working kitchen?

Bryce 2:58

He's in an airport lounge. So he's he's using Linux, and uh does your laptop have an NVIDIA GPU?

Conor 3:07

It does, yes.

Bryce 3:08

Yes, this is this is uh this is entirely our fault.

Conor 3:13

I mean the thing is though, and and I've just realized that this Wi-Fi quality is not great, uh, so I'm gonna be dropping in and out of this call.

Bryce 3:21

So I'm gonna so I can't slack off today. I gotta I gotta carry this this recording. Which airport lounge are you in and at which airport?

Conor 3:31

I'm in San Diego in the Aspire Lounge in Terminal 2. Yeah, maybe this was a bad idea in hindsight. Before I before we informally introduce Zach, should I just I've turned my camera up. Is that the best option at this point?

Zach Laine 3:47

Uh I won't be able to keep us. It's super freaky.

Conor 3:53

Alrighty. I mean, this probably all ended up in the episode, so you've just been listening to absolute mayhem and chaos for the first few minutes. But welcome to episode 161. This is our third holida. I don't even know if it's our I think it's our third holiday special. Could be our fourth, who knows? And as promised, the returning guest from episodes 117 to 121 inclusive, probably the funniest, the most entertaining guest we've had of all time, Zach Lane is with us for the holiday special. And uh, how are you doing, Zach? I mean, we'll link your previous episodes. It's good to have you back. Have how have you been?

Zach Laine 4:36

It's good to be back. Yeah, I've been I've been good. It's um it's it's uh I think that the show is much more um uh you know, I since being on the show, like I had I'd heard uh several episodes of the show before, but now it's become like a regular thing. Like I listen to it all the time. So I've been keeping up with you guys a lot better than than I usually do. If you want to expand your listenership, you just gotta get people to come on one at a time. Uh just a few million people away from really good great numbers.

Bryce 5:05

That's a strategy. Oh man. So kind of what are you traveling for right now?

Conor 5:13

Oh, uh I was in I am in San Diego for at least for a couple more hours for the weekend for uh half marathon. Hmm.

Bryce 5:22

Yes. What was your time?

Conor 5:26

Uh it was one hour, eleven minutes, and sixteen seconds.

Bryce 5:31

Wow. I have no idea whether that's good, bad.

Zach Laine 5:34

That's that's that's pretty fast.

Bryce 5:36

Yeah.

Zach Laine 5:37

Yeah. So so since I've been listening to the to the show more, uh, there are a couple of things that stand out. Like one is that it's never not funny to me when Bryce gets 10x. I mean, I laugh every single time. You would think it would get old, but it never gets old. I'm laughing. I'm giggling in my desk. You're like, what is he listening to? I'm like, I'm listening to Bryce be low-key trolled by his co-host. And it's amazing. And uh another thing is um there was one episode we were talking about what the universal algorithm is, uh, you know, and and you guys were trying to figure out a name for it, and I was just yelling the unigrhythm at my terminal, which is the the best slash worst name for the universal algorithm. Um and and the the last bit of of outstanding business is you were also talking about what alternative names uh you could come up with for ADSP, like what initialism it could map back onto. And my favorite one is all damn, shit's popping with Roxy Clark. But the funny thing is, like, as soon as I as soon as you said that, I could not stop thinking of like four-letter initialisms. Like I came up with like 50 of them that day. I don't remember any of them except that one. But I mean, I was like, I literally I couldn't sleep that night. I was like, oh, that one works too. I was like, I don't know if you guys have trouble falling asleep, but this is what my brain does when it's time to lay down. I'm like thinking of stupid shit that doesn't matter, and I can't stop thinking about it. So uh yeah, that that took over my brain for about 24 hours. That's pretty fun.

Conor 7:08

This is fantastic. Odd, odd damn shit's popping. Uh that's clearly gonna be the cold open.

Bryce 7:13

Uh apparently we need to actually really read the book ADSP because we've uh we've we've talked about Pascal a little bit now. Yeah. Do we both own it? I don't think I actually own it. I have uh the dragon book and I have EOP. I don't think I have it because I was looking for it when we were recording the episode the other day.

Conor 7:32

Well, that's blasphemy. You should own it.

Zach Laine 7:35

Yeah, I've I've heard it talked about a bunch. I've never read it either. I've read EOP like you know multiple times. Uh because well, because you have to to understand it, you have to read it multiple times. Um, but but ADSP I've never actually read.

Bryce 7:47

EOP is like and sorry, that's Elements of Programming by Alex Stepanov.

Zach Laine 7:52

And Paul McJones, too.

Bryce 7:53

Yeah, and Paul McJones.

Zach Laine 7:54

Sorry, sorry, Paul McJones. Well, though, I mean to to hear the telling of how the book came to be, like, and and you should have Sean talk about it, it's really kind of fascinating. Um, but you know, Sean kind of uh made room for those guys who were who are Adobe plays at the time to like write this book uh kind of on company time. And um the way he tells it, like Stepanov had all these great ideas, and and uh Paul McJones was the one that kept pushing him to finish. So like they co-wrote the book together, but the point is that like without Paul McJones, there is no EOP, right? It's it wasn't just like and also Paul Jones Paul McJones is here. He was like the guy who was the motivating force to get it finished when uh Stepanov had these great ideas, but that he didn't he didn't have a lot of follow-through. That's um uh from uh again Sean's telling of it.

Bryce 8:44

It is a very uh it is a very good book. And like I I really don't read Berman books, but I have read a good chunk of this one.

Zach Laine 8:53

Yeah, and it's so dense um that like and I think I mentioned this actually last time I was on, but but it bears repeating that like I took the first, I want to say six or seven pages of the first chapter and I turned that into a one-hour talk about how to how to design types and why why you make the design decisions you make. And it is incredibly useful because uh one of the things that I found when I first started working at C, you know, you get this multi-paradigm language, it's got the legacy of C stuff, it's got the newer style stuff, it's got all these um uh idioms from the newer stuff, uh, and all these different paradigms that usually come from the newer parts. Uh and it's really overwhelming for a new programmer, right? You know, it's like, oh, well, um I've see people use getters and setters, and I people see people put public data members. I don't know which one to use or why. And and that's just one tiny question, right? There's there's dozens of questions like that. Uh and if you have some kind of rubric around which to make designs, um, and I think those first few pages of the first uh EOP chapter do that, uh, it makes everything clear. It makes it clear like why do these things work this way? Why, why should I make decisions? What's the basis for for doing so? Um, so that book is really amazing. The the later parts of it, it's interesting because later parts of it are like all about like, you know, algorithm design and you kind of see like where parts of the STL came from and stuff. But ultimately, if you already know the STL and use it, um, I think the later parts of the book, while they're interesting, are not as revelatory as like the very first chapter, which is so dense. Yeah, it's so dense. And if you internalize that first chapter, it's huge.

Bryce 10:26

A large chunk of the rest of the book is about um iterator abstractions and different methods uh and and philosophies for iteration um and algorithm design. But the first chapter is it's called foundations, and I I actually have that my copyright here. I'll I'll read there's a little summary at the start of each chapter, and I'll I'll read it because I think it'll give people an idea of what is contained here. Starting with a brief taxonomy of ideas, we introduce notions of value to the object, type, procedure, and concept, and all five of those words are in a different font because they're like key themes that represent different categories of ideas in the computer. A central notion of the book regularity is introduced and elaborated. When applied to procedures, regularity means that procedures return equal results for equal arguments. When applied to types, regularity means that types possess the equality operator, an equality preserving copy construction and assignment. Regularity enables us to apply equational reasoning, substituting equals for equals to transform and optimize programs. So there's a lot there, you know. This is the section of the book where he defines like what is a value, what is an object, what is a type, and then sort of defines a lot of the philosophy of value types in C today and the whole philosophy around regularity. Although it's interesting, I we so we talked so much about regularity of um of uh types, uh, but I forgot that this chapter also talks about the regularity of procedures, and that in in Stepanov's worldview, um, regularity was something that was not just about your your data types, it was also something that that that he intentionally um introduced this one overarching concept and then applied it to both types and uh procedures.

Zach Laine 12:23

Yeah, absolutely. And and that, you know, your intuition from a functional programming language of what a function is is the notion of regular function, more or less, right? Uh, I'm not sure if there's any concrete differences. I think there's basically the same thing. Um, but it's very similar if it's not exactly the same thing for some technical reason. Like you can think of it at the high level of abstraction as being like a function from a pure functional uh programming language. And it's nice because like you can reason about things so well with pure functions, right? Um and so that's why functional programming languages are popular to the extent they are. That's why people like them. That's the the value that you get from them, is that um the the easy ease of reason um uh reasoning that you can apply to them, right? And um, you know, whenever I see a function with an out um ref or pointer param, I'm like, why is that there? Like sometimes you really need it, like let's say a constructor, right? There's no way to return anything from a constructor. So you have to put an out param to get uh something out of a constructor if there's some reason to do that, right? It doesn't come up very often, but it does come up. But like regular functions, like you know, return a tuple dude, right? Like take a take that value as an input and return as an output. Now there's some things, there are partial exceptions to that, like passing very large objects, you know, in a non-inligned function that doesn't really work without making a big copy. So there's some things you should you should do that there's some cases where you shouldn't follow what I just said and just pass in a value and pass out the value. But very frequently people pass out parameters that are like, you know, a Boolean succeeded or not, or something like this. I'm like, return an optional, you know? It's so much easier to reason about your code that way. And it's just easier lexically just to read and write it. Like if you have this extra bool sitting around that you have to pass in and then it's just hanging around, you know, that's just problematic for its own kind of reasons.

Bryce 14:09

Yeah, totally agree. You know, what one of the fascinating things about this book in general, and um you see it just in like the first chapter, is like yeah, like from that description, it sounds like this is like gonna be like a very abstract, very theoretical, you know, uh book. But that is that's not um that's not that's not what it is. Stepanov is very good at um building up theory, um, but also remaining pretty close to how computers actually work. Like in in in in this section of this um chapter where he uh defines what like a value is, um he he's talking about you know like uh representations in binary. Um and like he's gonna he gives examples, you know, of like like uh talking about specific examples of representing you know floating point numbers and IEEE 754, like very low-level stuff. Um uh so it's it's in no way, I think, um uh too abstract. Um it's a very down-to-earth uh book, a very um practical uh book, and in his ability to um uh to tie together both um how computers work and how you get performance on those computers with you know uh uh uh good computer science theory is really what makes it such a strong book.

Zach Laine 15:41

Yeah, so if you've been persuaded by this, head over to Amazon, use promo code shit's poppin' to get uh your copy today. It's actually out of print, uh which is kind of sad. But but the good news is because it's out of print, um, and Stepanov and McJones like signed off in this, and they got the publisher that signed off on it, uh, you could get us a free PDF. So every anybody who can hear this and hasn't checked it out, you should do it. You should uh grab the PDF. One of the things I think is um uh uh so great about the abstraction of a of an iterator is that, like you said, you know, he started with like what is the computer doing? And let's make abstractions that generalize that. So like there's a there's a notion of a cursor in other languages. I think maybe Rust does something like this, where it's like, you know, you've got the you've got a reference to the object um being indexed into, and then some value that says word index into the object, right? So that's that's your your representation. So it's an index. So you know, one of the nice things about that is it doesn't get invalidated as long as the size of the thing you're pointing to exceeds the the position of the index. Um, and you can do some very easy checks to make sure that's still true on unlike a pointer where you can have like essentially a pointer pointing off into space and you have no way of detecting that. So there's some advantages of not doing it that way, but but Stepanoff was coming from the point of view that like pointers are fundamental. This is how the computer works. This is how your ISA works in your chipset. Doesn't matter what ISA it is, it's using pointers, it's using like the addresses of things to refer to locations of memory. So um those kind of considerations are in there. And you know, I know there's a lot of people that that you know, this has a more broad appeal than just C people, and that book uses C as an example, but really it's a book about computer science. And that's the thing that's interesting to me is that outside of C circles and even you know a subset of C kind of community, um, it's not a well-known book. Uh, but really it you can take all those lessons and apply it to any uh language, right? Like they're fundamental ways of writing code that's easier to reason about, easier to get right the first time you you write it, and easier, you know, harder to make mistakes and stuff like that. Um it's just really, really good stuff.

Bryce 17:44

Yeah. So so so on that uh uh topic of you know uh the iterator abstraction, the when when he introduces iterators in this book, um he he writes uh the iterators are a family of concepts that abstract different aspects of addresses. And this is right after a paragraph where he basically explains like what a what a memory address is and this idea that every object has a memory address. And so like I I think that's very um it's very interesting that that that that the way that he presents iterators are exactly like what you said. Like this is an abstraction, this is a more general form of an address of a pointer. Um and I think that that's not what a lot of our mental models uh uh typically are of iterators. Usually we think of it as, oh, well, this this is uh something that abstracts iteration. Um uh but really it was designed from the ground up to be an abstraction of the hardware of this notion of a pointer.

Zach Laine 18:45

You know, one of the things I so I've been dealing with uh JavaScript a lot lately because I've been uh working on this uh data visualization tool that's a web-based thing at work. And one of the things that kind of gets me is I know that people that deal with interpreted languages are particular, but you know, most languages that aren't um, as someone once called them, a semicolon language. I think that maybe even came from this from this podcast, I heard someone call them that. But like there's a whole class of languages for which you just don't have to know what a pointer is, right? And then when people go to C and C are like, whoa, what does this pointer think? But what drives me crazy about that is you already deal with a language that everything is a pointer, right? And you just had to you just had to internalize all the rules, and then the syntax of dereferencing or taking a reference to something is um is fixed. There's not options of how to do it. And it's also um the the times in which something acts like a pointer and doesn't are fixed, and you just have to know the difference. And you you've you've already internalized all these rules. So like you know, in uh in JavaScript, you can't write like a swap function, right? You can't say like given um values a and b to this function, let me swap their values. Like you just can't write it because um I mean I think maybe you can do like something where you like stringify the JSON and then parse it, and then you get a new object and you take that from B and assign that to A, and then you assigned A to some temporary like so you could do some funky stuff, but you can't just like take these two values, which are pointers to two real things, right? And you can't say like whatever they point to, make them point to the opposite uh of each other. Um that's just not something you can write. And and so if you do something like you know, A equals B, you're assigning the pointer B over the pointer of A. So now A and B now point to the same thing and they have shared state. So it's an inherently non-regular language, it's really hard to reason about. If you make um mutations to some uh parameters that you're passing, like it just looks like a value parameter. Sometimes you use it a value, sometimes you assign to it. And when you assign to it, you're assigning over the local copy of the variable. But if you assign through it using a dot, like mutating operation on the object, you're actually uh mutating the object you pass to the function, and it's visible from outside the function. So whether something is a local change or not is subtle. And and like, I mean, it's like really hard to reason about this code. And then people are like, but pointers are so hard to think about. And I'm like, are they though? Like I just don't, you know, just use values and you're great.

Bryce 21:08

I you know, I I I cannot tell you the number, and I I I am by no means um uh an expert Python programmer. I think I'm uh uh pretty bad at writing Python code, and I think most notably the problem is that I don't I don't know like the Pythonic way. I don't know like what's the idiomatic way to write Python code. So I end up writing Python code like my C code. But I can't count the number of times when I've been writing some Python function and I've been like I'm confused. Like, am I working with a local copy here? Like if I modify this thing, am I gonna modify the thing as a calling function? And uh it it's I just don't have the mental model for it. And um, I I mean I I I think that any any language like that, uh other than a language, something like maybe like Hilo, where it's like purely a value based uh system, or like you know, a lot of functional languages where it's purely value based. If it's not a language like that, That then you've got some sort of object model that has some form of references and shared state and some form of abstraction over pointers. And you know, okay, the C one has a lot of foot guns, but I don't think that it's necessarily harder to understand than the object model of like a language like Python or JavaScript. It's just different. It's just quite different.

Zach Laine 22:23

I think that's right. And and in particular, the the thing that excites me about Hilo as a as a project and as something that might be, you know, the the semantics of what its value um oriented model looks like you know might be bolted onto C ⁇ as a safe mode in some point in the future. Like the reason that is more exciting to me than than doing like a Rust uh version of it is uh you know, Rust took the problem with writing code in C and C is it there's reference semantics everywhere in the shared state everywhere when you have reference semantics, right? And so they said, well, let's make it harder to write those mistakes that we write when we use reference semantics. Um and so they have this very elaborate checker that doesn't let you write things that you know are safe, even though they're not, because it doesn't have like the proper heuristics to cover that case. There's a few like warts like this, and and it like takes a long time to compile. It's like hard, it's like a it's a mental model that everybody has to get ramped up on and stuff. And there's nothing inherently wrong with it, but it's just like you know, when I write C code, everything's a value, and I don't have to do this, right? I don't have to worry about references and whether something's dangling or not, because whenever I have pointers, they're like implementation details inside of stuff, right? Everything's a value at the top level. And so when you write code like that, um you don't have to worry about these things. And and and Hilo seems to be embracing that. Like, oh, well, let's instead of like trying to get all the weird stuff right, let's just not do the weird stuff and I'll let you do the weird stuff. So I had this, I had this housemate uh in college, and and right after school, he went to teach English uh in uh in Japan for a while. And he said, while he was there, this was in like uh like the late 90s, like 97 or something. And they had uh a few models of cars that were coming out at the time that had um TVs in the dashboard. So as the driver, you could watch TV while you were driving. And everyone who bought one, yeah, sounds a great idea, right? So all these people had with these cars, they were they were getting in accidents all the time, as you would expect, right? So instead of the government saying, hey, you can't put TVs in the dashboard of cars, they instead said, if you buy a dashboard TV car, you have to take this government-sponsored class that teaches you how to drive your cards safely with while watching TV, right? And to me, that's Rust. Like that's that's what Rust has decided to do. They're like, you know, this insane thing you chose to do, like use references for everything? Let's make that safe. And I'm like, why? Why do that? I mean, I understand, like it has good results, right? But but I think there's a there's a better way of of slicing the same uh problem.

Bryce 24:51

Yeah, I mean, I it makes makes makes one wonder why hasn't something like uh hilo been been attempted before. I think I think um I think that the challenge that you have with both something like Hilo and Rust is that you you lose some degree of control. Um uh and and and for systems programming that that that can that loss of control can also often lead to a loss of uh performance, loss of ability to write something in the the fastest way. And that's that's why we've we've always that's why systems programming has gravitated towards languages where you have a great degree of control and a great degree of butgums. Yeah.

Zach Laine 25:29

Yeah. So okay, so speaking of like future stuff that I'm super excited about. Uh the uh I think you were maybe in this session, uh Bryce, but at the last C meeting, we had a sp a session on uh metaprogramming and uh reflection.

Bryce 25:44

Yeah.

Zach Laine 25:44

And uh you were in that session, right? And they showed like, so there are some people that you know work on compilers that have taken this on as like we're gonna implement something and and and write papers supporting the implementation. Um and they were so much farther along than I think anyone in that room besides them suspected. And now it looks like there's it's no guarantee, but there is a chance that we're gonna get that for 26. I think it's pretty well, I think it's pretty likely that we'll get reflection in 26. I think it's likely too, but I didn't want to use the L-word uh in front of all of our listeners because I don't want to build expectations of something that might not happen. But but I do think it's likely, yeah.

Bryce 26:22

I I don't use it lightly, but I I I like its odds.

Zach Laine 26:25

Yeah, I do too. Because especially because everyone is excited about it. And even people that were in the room that had competing uh approaches were like, no, no, that's fine. You guys, you guys have done it. You have an implementation, it's working. People are building cool libraries with it already, with the reference implementation, uh, with the demo mode of your program, uh, your uh compiler. Uh and people are just like, Yeah, I just let's just get it in. Let's just get it done. Um, and that kind of thing, once people shift away from like, but you didn't do it my way, to like, let's just get it in there, things tend to move pretty quickly.

Bryce 26:54

Yeah. Yeah.

Zach Laine 26:55

So I'm really excited about that. And then you know, you know who you need to get on this podcast is uh Michael Park to talk about reflection because he has a reflection proposal that no one has implemented yet, which is the big, I think, blocker for it right now.

Bryce 27:10

He does or pattern matching.

Zach Laine 27:12

Oh I keep saying the wrong I've said that to multiple people that are like, I think you're confused. And I'm like, yes, I am confused. No, no, pattern matching is what I was trying to say. Um, but yeah, he's got a really, really interesting um uh proposal for pattern matching that is like really well thought out. He's done a huge survey of I think like 13 different languages that have pattern matching uh in, you know, that already in some other language in existence, and he could try it out and see the semantics. And um, so he's done the C version of that, and it's really great. And the the cool thing about it is like he's been thinking about this for a very long time. Like, I think the first conversation I ever had with him about this was in like 2017 or 2018. I mean, like it's it goes back a while that he's been working on this, right? And so whenever someone has a question, like, you know, he'll bring up like the paper and he'll show you like the the semantics and even has like you know part part of the grammar uh for the language and stuff he's thinking about at the grammar level too, so he doesn't miss anything. And he'll bring something up and you'll say, like, oh, but what about this? He's like, Oh yeah, and he'll talk about it like it's a new idea that he's never heard before. And at the end, he's like, Yeah, so that's why I'm not doing it that way, because like I don't think it works for the reasons we just came to like you you try to stump him or you try to come up with a whatabout, and then it never works because he's thought of everything.

Bryce 28:30

Yeah.

Zach Laine 28:31

Um, and when people have that level of uh fluency with the topic, it's just really exciting. So anyway, I don't think there's any chance that'll happen by 26, but I'm really hoping that we can get that in the 29 time frame. I think that would be awesome. And if we had both of those things, I mean that would be another seismic change in how you write C, I think.

Bryce 28:48

Yeah. I I think I think just reflection alone will be pretty, pretty impactful if we get if we get reflection in 26, it's gonna make it a major, a major release. And it's you know, it's not I've I've been giving uh uh my this talk, C Horizons, where I talk about the three things I'm most excited about and it's uh uh and the future of C and it's reflection, pattern matching, and um ascenders. Uh and I was like so excited to see to see that um uh we're making progress on reflection because it it had seemed like it'd been stalled for a while. And I I was at um so I was in Switzerland uh a week or two ago going to um uh to CERN to give um a couple talks there. And I got to go see the particle accelerator underground, which is super, super cool. So many wires, and they cut every wire to length, so there's like no extra slack in the wire. It's like they they designed this thing and then they're like, all right, we need a wire that's exactly this long, and it's amazing. We'll um we'll put some pictures on uh in the in the show notes. Um but when I was there, um a group of the CERN folks, they scheduled a meeting for me, and I thought it was just gonna be like, let's talk about data layout and reflection and whatnot. But no, it was like 20 people from CERN, and they had like a presentation, and they were like, we want to convince you to care deeply about reflection. Um and they were um they were talking about like their use case as a use case. Like, I think a lot of people hear about reflection, and they're like, Oh, that's cool. Like I can write the function that convert the like you give it an enum and it gives me a string of what the enum's name is. Um and that's the example it's used so often. But um, these CERN folks they use reflection to optimize their data layout. Um and the the problem that they have is that they got this giant particle accelerator machine, and it just generates a ton of data, just like tons and tons of data. They have like exabytes of data, you know, that are stored in and they've got this throughput problem. Um and so they they need to um, you know, it's not it's not always a like a compute bottleneck or a latency bottleneck or a storage bottleneck, but it's it's it's uh um just a throughput bottleneck if we've got so much data and how do we process it and get it it through. Um and one of the, you know, one of the things that they've done in a lot of their experiments is they have some you know clutchy form of reflection where they can, you know, in a certain place, um, they can switch from array abstract to destructive array, but they can also do things like, oh, hey, we we have some technique where we can change the data layout to make this representation fit smaller in memory. So we can save like 40% um uh memory usage. Um and like you you actually you see this a lot in a lot of other applications too. Like there's the um uh you know, there's like a GCC attribute for like packing your structs. Um I know a lot of people use stuff like that. Um like one of the really cool things we can do with reflection is we can build libraries that do all sorts of compile time optimizations of our of our data types um and our in the layout of our data, and that can have such a huge impact. And like what they're doing today, they like have to use like compiler extensions or just like macros, just like piles of macros, and it sounds so painful. Um, and like this future where we have reflection, it's uh it's gonna be great. It's gonna be so much cleaner to do those things.

Zach Laine 32:17

One of the things that uh so you know I have this um uh expression tablet library uh Yap uh that's part of Boost, and um there are some severe limitations in what you can and cannot do, because like you know, essentially what you want to do with Expression Table library is you want to capture some expression as uh, you know, uh a roll your own AST type, and you can see all the pieces of it, and then you have some transform that like walks the tree and does stuff, right? So if I had the reflection piece that fed into the pattern matching piece that then fed into the metaprogramming piece, I could write like the one expression template library to rule them all that would just supersede anything else, right? Like you could have one framework that said, like, here's how you specify transform. And the transform is just regular code because like the problem with doing transforms on ASTs is that you have to be like, oh, I have to know what your funky node type is and and all this stuff. And I have to say, like, oh, well, I match this kind of case, but if I don't match the exact kind of case, I have to have like this loose loose matching, and then what if I match the wrong thing because I uh there's a loose match that I was trying to hit, but then I also hit this other one that I didn't want to hit, and you know, it gets really complicated really quickly. But if you can just write regular code that just says like, well, if this thing has such and such on the left and such and such on the right or on the right, then let me let me recurse. And then it's just normal code, like with ifs and fors and stuff, then oh man, this is so much nicer.

Bryce 33:39

Well, I I like to think of that as that's it's the Louis Dion revolution in metaprogramming that we had, where it used to be that we would we would do all of our metaprogramming with this type-based metaprogramming uh that was like a completely different world than uh uh than what we do today, which is where today we we um sort of do value-based metaprogramming as it's called, or like constexper metaprogramming, where you could just write regular C. And uh like it's just regular C that's constexpr or constaval. And it's just so much, so much cleaner and so much better than how we used to how we used to metaprogram. Um yeah, yeah, totally.

Zach Laine 34:18

Well, I was just gonna say I'm I'm just really excited for it because, like you said, it is like if you think about before you could say if consexper, right? What you had to do was like make a bunch of you make a struct that took template parameters, and you had to have a bunch of partial specializations of that struct that some of them were some of them win in this case versus that case. And so, like, you know, I had this one thing in inside of Yap that had five cases in it. It was a function that took a bunch of different kinds of things and then returned a common return or common sort of operation on those kinds of things and different return types. So the way I wrote it first was using 17, I did if context per some predicate, and then I chained these these four alternatives after that, and those were the five cases, and it was easy peasy. Then I went back and did it for the 14 and earlier version, and I had to do this partial uh specialization thing where it the right one won in all five cases. And I mean, it's the kind of thing where when you're in it, you can write it. And then when you look at it six months, you're like, I don't, I don't know why this works. I I I don't I don't get why that specialization is better than that one.

Bryce 35:21

You know, you know, like like C is essentially just a series of complicated lookup systems glued together. You've got like the the specialization engine, you've got the overload engine, you got a couple others. And yeah, like anytime you have to write some some form of pattern matching or dispatching that relies on partial specialization or overload resolution, it's like unless you're a real wizard, uh you're gonna have to go look up like, okay, like why does this match versus like better than that? Um whereas if you're just writing like traditional, like, you know, if-else like construct, it's a lot, it's a lot simpler to figure out your logic, just by the simple case that um uh if I've got like you know branched if-s, um, or you know, pattern matching, the the pattern matching proposal, it's first match wins. Um, right. So like obviously you have to make sure that that um you know the things that you want to match match, but um, it's not like overload resolution or partial specialization where it it kicks some priority and it's not necessarily in lexical order.

Zach Laine 36:26

Yeah, yeah. You have to just have an overload set that works out. And and that's what I was gonna say next is that like this would take those if constexpr chains and turn them into regular ifs. So that's just uh you know, it's not the same order of magnitude difference it was from like the old bad days of partial uh template specialization, but it's better because like if constexpr is already kind of wonky, right? Like if you don't, if you don't have everything in an if-else chain, it doesn't work, right? Like you can't have like the the typical pattern where we say like if something return early and then later on I just do the regular logic and return because now I have like if the predicate is true in the if constexpr, now I've got two kinds of returns that might be differ from each other. So I have to have basically like an else, and that means I often have to repeat code in multiple places if I have if-else, uh if context per else stuff nested. Um and just making a regular ifs is just great. You know, it's really amazing. So uh all that stuff I find super exciting, and um I'm really looking forward to having it. But you know, it's funny because we we talk about these things, and I'm like excited because this thing might make it in 29. It's like six years away at the earliest, and uh yeah, it's just the pace at which things happen in C.

Conor 37:34

Speaking of you know, C29 and having to wait for pattern matching, this whole time I've been waiting to ask Bryce, would you like to revise what you said in our most popular episode of all time? If you if you ignore the first you know five or six, because those get more downloads. Episode 150, which we titled Is C dying, uh, I think just broke 5,000 downloads, and usually we get like two to three within the first month. Anyway, so I don't if if you look at our episodes, no episode breaks 5,000 since like the first few. And you famously said that you would be surprised if C ever shipped a major language feature. And now you're saying that it looks like in 26. But now you're saying it's likely that we'll get reflection in 26. So uh comments from Bryce 11 episodes later in episode 161.

Bryce 38:32

I don't I don't think that the fact that um uh that this thing has surprised me and is likely to happen is indicative of like n none of the systemic problems that I've highlighted with the C evolution problem have changed or been fixed.

Zach Laine 38:50

Um Bryce, aren't you concerned about your pants like getting caught in the in the gears when you backpedal so furiously?

Bryce 39:01

I mean, I I think it's great that we'll get well that we'll get reflection. Um, but uh I think that with a better evolution process, we would have gotten reflection a lot earlier. I mean the the the fact is that the proposal sat idle for two to three years um and then everybody thought it was dead. And like this is a this is a programming language that millions and millions of people work on. Like we should have had a better process where we didn't just have like a long delay in work on that um just because of the the volunteer nature of our process and variety of other factors.

Zach Laine 39:38

Um so so something uh something occurred to me. This is actually so Michael Park uh just got married and he brought his fiance with him to the last meeting, and she was asking about like Yeah, yeah. He got married like uh last week, week before. Yeah. I did not know this. Yeah. Um and he uh she she was asking like some questions about the process and how we do things, and she was just curious about it. And and I I I re you know, I was explaining something to her, and I had this kind of realization that you can only have when you explain to someone and you like step outside your normal frame of reference, kind of like the stuffed bear phenomenon where you explain to a coworker like what your bug is and then you fix it you know in your head as you're explaining it. So um she had asked something about like who are the typical people that show up to these meetings, like why are these people here not to the C programmers? Like, what makes this group show up to the meetings? And I was like, well, I think a lot of people are kind of volunteers and it's kind of like an open source project. And I said, um, you know, there's other programming languages that have um big foundations um that are well funded, and they have people that are like kind of paid to work on uh advancing the language and the standard library and stuff. And we don't really have that. I mean, we do have a a cadre of people that does that, but it's it's a minority for sure. And um and then I said something that I had not thought of before, maybe it was obvious to everyone else, but it I just realized this as I was saying it to her was that like, oh, I think the reason why we don't have such a thing is that we guarantee backwards compatibility. And so when you guarantee backwards compatibility, no one has to care about what you're doing in the language, they can continue to use it as is. But if you do something like um Python 2 to Python 3, and if that's on the table, then everyone is gonna send someone to the committee and being like, don't break our tool chain that we need to do our work. Right. And so people are allowed, like, you know, I work at a company with 3,000 C programmers, and I'm the only one that goes to the committee uh and and they don't pay me to do that, right? Like they they let they they support it, but like it's not part of my job, right? They don't have anybody that they say, like, go make sure that this thing doesn't break on us because they know it won't, because we don't make breaking changes really. So um that's kind of interesting to me, right? Like the the big thing that prevents our evolution from moving forward is break is uh you know unwillingness to break backwards compatibility, including ABI compatibility in in a lot of cases. And and yet that's also maybe one of the things that keeps people from being engaged with the standardization process, like on a on a company level, like willingness to support people and go uh work on this stuff. So um, you know, we really have this problem that it's an open source project, and any open source project lives and dies by you know what people feel like working on. You know, if no one feels like working on a particular feature, then it just doesn't get worked on. And if someone gets burned out, then that feature goes away, right? So that's just how it is.

Conor 42:30

I had never thought about that. Yeah. So you know, if if you take that as like, you know, as that is, if at some point C does decide to have like, you know, in C32 or 35, we are gonna have like a Python two to three where like here's your one chance to get a bunch of features in. You you would you would expect that there's gonna be like a huge uptick in the people like coming coming to the to those few you know standards meetings.

Bryce 43:04

I don't think that we want to have a uh a fear-based collaboration public. Um it's an interesting point. I I had never thought about that before. Um, I mean I think all programming language communities have problems. Obviously, the Python community, while it's great and I think is um run a lot better in many ways. There are many things about the Python the way that the Python ecosystem operates that I'm envious of, I think is the way I would say. Um but they've had their shared problems. Rust, again, I think very envious of uh how the Rust ecosystem works, and I I do think it's better than the C ecosystem, but they've also had some problems, uh especially more recently. Um there's been a lot of uh I'm not gonna try to figure out how to class going. I think it's categorized.

Zach Laine 44:02

Yeah, because I mean they're they're their um community is exploding in in size, right? And that that's always problematic. And you know, just getting bringing new people into the fold and not losing your culture is hard. Trevor Burrus, Jr.

Bryce 44:12

But but I don't I'm not sure if um I'm not sure if the I I think that the backwards compatibility is something that hangs over our our head. Um but I I think that the real reason that more people don't get involved is that um the decision making is so slow and the process is so arcane um uh that it it sort of keeps people away. And you know it it's hard for any person or company to ten year investment.

Zach Laine 44:43

Yeah. I I think really like the backwards compatibility issues are a big part of why it's so slow, especially for language evolution. Right? For library evolution, you just throw it against the wall and see what sticks, right? I put a lot of stuff in the library, then a couple of revisions later we're like, yeah, we don't need this anymore. Um but but with language, you put it in there and you you're married to that. Like you're never gonna get that out of the language, right? Um you know, there's like one major counterexample that basically no one ever implemented so we could strike it, which was export and everything else, like you know, not modules export, the old export, the template export.

Bryce 45:13

Yeah.

Zach Laine 45:14

Um so yeah, anyway, uh, you know, but but I think what you're saying is right. Like it's when you tell someone, hey, um, you know, well people have come to me in the past, right, and said, like, hey, why doesn't this work like this? And I'm like, write a paper, I can help you. And they're like, okay, and then um and then it's like, yeah, so then you need to like go to a meeting or I can champion it for you. And then when they come back with comments, like you need to uh you know uh address those comments and so on. And like it's daunting. And people are like, yeah, I'm not gonna, I'm not gonna do all this. This is too much, right?

Bryce 45:46

Yes.

Zach Laine 45:47

Yeah, it's it's a lot of work.

Bryce 45:48

And and and the whole, you know, uh, and I I'm always a big proponent of this, like one, you know, we have all this ISO process and procedure, which is very arcane, but then like just within the committee, there's plenty of um uh there's just too it's it's too insular in many ways. Like, like what why why do we have to number the study groups if you're new to the process, like SG25 or 27, like that that has no meaning to to to an outsider.

Zach Laine 46:24

Um well, even among insiders, I refer to SG SG9, and people are like, which one is that again? Like that's the Ranges one. They're like, oh yeah, right, SG9. Okay, great.

Bryce 46:31

And that's like like I I made a I made a big effort when I was uh chairing library evolution to never use the study group numbers.

Zach Laine 46:38

Um I would always type out the names. Yeah, that's a good policy. I I think it's the same with the with paper numbers, honestly, too, because no, I don't remember my own paper's numbers, right? Or my own paper numbers. Yeah.

Bryce 46:48

Yeah, and and so just like like uh you know, the the reality is that the process, the evolution process, wasn't really designed. It's just sort of a thing that like we we never sat down and thought like, how should we structure C evolution to be sustainable, um, to you know, grow the committee, to be able to handle growing the committee, to be able to, you know, set direction, make decisions. We we never like sat down and had a meeting about how to do that. It's just sort of been like this ad hoc thing. And I think that that's led to a to a lot of a lot of problems. And um and we we you know, on top of that, there's just a lot of infrastructure problems, and there's a lot of infrastructure problems and limitations from the uh the ISO process. Um and so the the fact that reflection looks likely to happen um doesn't uh change my opinion on um our overall process issues. Um I think uh reflection is gonna be the story of a feature that succeeds in spite of um uh the problems that we have. And also I'm sure that between now and when reflection ships, there will be some amount of um holdups and drama and and problems, and at least some of them will be caused by um uh the limitations of our process.

Zach Laine 48:12

Yeah. Yeah, and the thing is that like that this really leads to something that we have a lot in the committee, which is like little tweaks, right? Because a little tweak is some of the bite size you can be like, oh, I I don't like that. I could fix that. Let me let me write a paper for that. And you write a paper for it, people are like, Yeah, I see there's a problem, let's fix that. And then your thing goes through and they're done, you move on to the next thing, and and it's nice and and and tidy. And then you've got something like ranges, which took over Eric Niebler's life for like, you know, years. And uh and if you're willing to do that and stick with it, then then it it does pay off in the end. But like when I say took over his life, I mean for real. Like he was just doing nothing but this for a very long time. Um and uh, you know, in in terms of even professionally, like he was at one point um working on it as his day job, even uh so. Yeah, talking about the C foundation, yeah. Exactly. So he was you know really like all in on it, right? And um, you know, there's other people like you know, uh I don't know how much of Gore's time was monopolized by um um cover team stuff, but like it definitely was a long time getting it, you know, from like if you look at the this the time frame in which he was writing papers, it took a large number of years. So it takes a certain kind of person. I mean, I think we have a a pretty self-selected group of people like um as C plus plus programmers in general who like um are very comfortable with the delayed gratification because that's what it means to be a C programmer. Um but there's limits to that for most people, and it's uh the limits are far shorter than like you know six years for most people.

Bryce 49:42

Yeah, yeah. And I I mean I think that's you know, I mean maybe that's true of any language. Maybe it's the case if you want to do some drive some big feature in Python, it's gonna take longer than you expect. But um my my my impression is that uh we uh um we move uniquely slow.

Conor 50:01

Slowly. Yeah.

Zach Laine 50:03

Yeah, I think it's really fair.

Conor 50:04

I submitted a talk to PyCon just a couple days ago called The Power of Python, uh which is the point of the talk is to basically say that I think Python is like the best programming language for being productive. Like NVIDIA is not necessarily gonna ship a bunch of whatever compiler stacks written top to bottom in Python. But now that I'm in research, I basically do almost everything in Python. Like I want to write C code, I'll write Python to write me my C code. Like I I can move so fast with Python and not just not just the language, but like the ecosystem around it. Yeah. Um and also it's in this situation now where like Python is in a state where the rich are gonna get richer because LLM models they do best at like generating Python code because the corpus of Python code is so large up there. And uh there's something to be said about like like you you made me think of this, Zach, when you said like the C programmers are okay with delayed gratification because we're constantly fighting with the compiler and waiting things for it to compile. And with Python, it's the exact opposite of that. Like, sure, maybe you didn't write it correctly the first time, but like it's just so nice to like write code, hit a button, and things are running. Um and like I just I get frustrated sometimes. Like I'm supposedly a ranges expert, and then I'm I'm trying to write some code that I said I could get working in three minutes. I said this in a meeting on Friday. I was like, give me three minutes and I'll have the ranges code. Forty minutes later, I've like, oh yeah, GCC 13.2 doesn't implement ranges colon colon two, MSVC uh has some implementation thing that doesn't work, and you need a macro to use it on Gobbook, you know, compiler explorer. And like then I went to this internal tubo I had written, like went away from standard ranges, does this range v3, finally got something working, and I was just like, what the heck? Like 40 minutes during a meeting. And I, in my head, it should have should have been like a three-minute thing.

Zach Laine 51:59

Yeah, um that's been my big gripe actually with um with concepts uh is that you know, the the major uh use case for concepts in the standard libraries and the range of stuff. We're starting to add them to new things as we add them, but but basically the only big chunk of work that came in with concept constraints was the stuff in ranges. Well, whenever I try to use it, if there's a problem, I'm like, now what? Like, I mean, I'm you know, I'm I'm an expert level Cur guy roll. If I get a big huge template instantiation stack, I could I could debug that. Like I can figure out what the problem is with the concepts. Often it's very, very much depends on which implementation I'm using. With with Clang, I get this like this concept check failed because this subconcept check failed because this one failed, because and this is there's a nice chain of them. And with uh GCC, it's like uh hey, shit's broke, man. Uh like uh now you go. And it's the same way with with MSVC too. Uh like they they just don't have very good diagnostics, and and um there's some technical reasons I don't fully understand for why the the version of of concepts that we got um is hard to write diagnostics for. And people were really worrying about this when we were in standardizing it, um, whereas the old one uh lent itself to much better diagnostics. And again, I don't remember the technical reasons why, but I remember the the selling point. You know, if you look at Doug Greger's early prototype and he was giving talks, like here's what you get, like the you know, the famous example of an L-form template from like someone's book that people used to refer to a lot was uh, you know, let me call std sort, but I'm calling it on a list, like a std list, right? Uh so I'm calling std uh you know, for my list L, I'm calling uh sort uh L dot begin, L dot end, and I get some weird message that's like way down the bowels of like the sort algorithm itself, saying, like, hey, this is this doesn't you know make sense this line. And I'm like, why doesn't this make sense? And then you know, Doug Gregor's prototype implementation, the old version of concepts, the OX version of concepts before 11, um, it said like this doesn't work because that is the wrong iterator category. And it was like, yeah, yeah, that's what that's what we want. We wanted to say, like, this is the high-level problem with your code, and this the the fix is like you just can't sort that. Maybe you should look and see if there's a member sort. Turns out there is, and you should use that instead, right? So that was really cool. And then now if you if you do the same example, I'm pretty sure it gives you something along the lines of what you used to get with just uh unconstrained templates. That is to say, it gives you a a big mess of of an answer for why like stood ranges sort doesn't work. Um, but it doesn't um it doesn't give you this high-level thing of like this is the thing that changed in your code to make this work, or or not even just to make it work, but this is why this won't work. Um I I feel like that's really sad. And in fact, I have um, you know, a lot of the code that I write is is for boost, and so like a lot of stuff that I've been writing with concept constraints, I've actually been putting like if use concepts, here's the template head with the concepts in it, and then else here's the template head for the unconstrained version. And I will often turn off concepts and then like on the template that's got a problem, and then recompile so that I can get the massive spew of template instantiation crap that I'm supposed to dig through, because that that I understand how to work with. I mean that's that's not what we want to that's not where we want to be, you know. That's not a good state of affairs.

Bryce 55:21

Yeah, that's that's very sad.

Conor 55:24

Yeah.

Bryce 55:24

Can you see my screen? Uh-huh. Wait, am I sharing the right thing? No. Do you see the God Vault link?

Zach Laine 55:32

No. I just see something about the Aspire Lounge.

Bryce 55:35

Oh, I shared the wrong one. Hang on. It looked like it was the right one.

Zach Laine 55:41

I thought you were gonna pointedly tell Connor he should be in a different lounge or something.

Bryce 55:44

I was like, we're just gonna- the reality is Connor probably doesn't have access to any of the better lounges at that airport.

Zach Laine 55:51

Oh, Bryce is fancy. It wants everyone to know it.

Conor 55:58

As soon as Bryce said that, I was like, here we go. Zach's about to take him down a bit.

Bryce 56:04

All right, let's see if GCC is any any better here. We're looking at uh what is the diagnostic that you get from uh from the calling stood ranges sort on uh a list.

Conor 56:16

Usually I wouldn't allow Bryce Bryce to screen share, but this is the holiday special, so we're we're doing we're doing whatever we want today. It's uh I'll allow it.

Zach Laine 56:25

Thank you, Connor. So Bryce, I see you have a lovely Hanukkah Bush in the background.

Bryce 56:30

Yes, yes. Well, I have my uh my my girlfriend's uh mother and uh 12-year-old niece are arriving tomorrow from Poland. Neither of whom speak any English. So it's gonna be and they're gonna be here for two weeks. It's gonna be a ton of fun. Uh on actually.

Conor 56:50

I saw that tweet you sent out, and I love I love that like 10% of people that reply to your tweets are always just giving you a hard time. And my one one person said, look at Bryce breaking up about the fact that he's got a girlfriend subtly.

Zach Laine 57:08

I have a girlfriend, friends NBD, you know. So I suppose my grandmother, blah, blah, blah.

Bryce 57:16

I suppose to be fair, we would need to also look at um what do you get, and maybe we should do that in a separate Godball window. What happens if you uh if you do this without ranges? Yeah, just say std sort, yeah. Yeah.

Zach Laine 57:32

So um I didn't really have time to read it. I was trying to make it bigger. I was too busy laughing at you to uh carefully read the code. What uh what is it saying to us here? So okay.

Bryce 57:39

So GCC tells us um this is working.

Conor 57:44

Also wait, can we exp can we explain for the listener the code we've written first before we look at the code?

Bryce 57:50

Yeah, as much explain that kind of. So we we we've got uh code where we just we create a std list of int, and then we just call std ranges sort on it. And it should not compile because sort requires a random access range, and list does not provides bidirectional iterators. Um so with GCC it tells us um well no no match for call to this function. But of course, the function that you're trying to call is one of these sort customization point objects. So it says no match for call to um, and then there's a call expression for std ranges, colon colon, unders underscore underscore sort underscore function. So the fact that we didn't d that this thing's a function object and that we don't have a better way of doing the customization points um at the time that we shipped ranges um shows in the diagnostic. And then it's got um it it shows us the overload set that it tried, um, which is which shows all the candidate functions, yeah. Yeah. Which is but this is the call operator for this function object. Um so you somebody who's doesn't understand how ranges works under the hood, I think could be quite confused by this.

Zach Laine 59:09

Um like a naive user, I'm I'm being literal here, would look at this and say, like, oh, sort is a macro or something. Yeah. Yeah. Because they see it trans transliterated into double underscore sort fun, and they're like, oh, well that's not what I call it, so this must be like substituting a thing for another thing, and I don't know what's going on here.

Bryce 59:29

So one of these here so so a bunch of them say constraints not uh there's a bunch of these, so it says he didn't match any overload. Here's all the ones I tried. And um I see at least one that says uh constraints not satisfied. Um but it doesn't say why the constraint wasn't satisfied. No, no, no, okay, right here.

Zach Laine 59:51

I think if you go down it does, yeah.

Bryce 59:53

Yeah, so we got one that says um uh requires random access range.

Zach Laine 1:00:00

Oh, that's actually pretty nice. Yeah.

Bryce 1:00:01

Yeah. Um but it's yeah, that way that was in the middle of the diagnostic. It took us a little bit.

Zach Laine 1:00:07

Yeah, you you have to read down several like error and note lines to get to that. Yeah.

Bryce 1:00:13

So there is also down here, it says um this is below the failed the failed call. There's something where it says, I think this is where it's like it's digging into why this requirement failed. So it's a it's a call stack and it starts up by saying required for the satisfaction of something derived from some concept, and then required for the satisfaction of random access iterator. Um and then eventually like the last part of the diagnostic says std random access iterator tag is not a base of std bidirectional iterator tag. Okay. Um the cling one is a little bit better because the cling one, um, it also says no matching call for uh no matching function for call to object of type underscore underscore sort Fn. But then it's got a cleaner list of the overloads that it tried and failed. And the second one there, or maybe it's the first one. Yeah, it's the first one. The first one says um uh candidate template ignored, constraints not satisfied, and then the next line it says because std list int reference does not satisfy random access range.

Zach Laine 1:01:19

That's this is what I was talking about when I said like I think the Clank diagnostics are way better than MSVC or GCC for for concepts right now. Like this is very nice, right? It says uh it just shows you the function, it quotes the line, and then it says this candidate template does not work because of a constraint, uh lack of constraint satisfaction, and then the next line is why in a way that you can understand immediately. There's still the noise of like double underscore sort fun and that kind of stuff, but you know, that's that's fine if if the rest of the experience is that nice. But I gotta say, like this is a pretty, yeah, I was gonna say like write it out um with begin and end instead of just passing an L. I think they get worse. And the thing is that these are both pretty easy cases. Like if you do anything more complicated with concepts where like the failure isn't at like the top level, the identity of the thing, like you know, it has to have like bidirectional range, is like I think what you write instead of uh type name uh range or bidirectional R instead of type name R. And so it's like at the top level you have a failure. But if your failure is like, oh, well, it's like it meets bidirectional range, but there's like a requires that like something about the value type has to look a certain way or something like this somewhere, and then you go finally all the way down into the guts of the thing and you dereference the iterator and then it gives you a value type or a reference type, if you deref if you dereference the uh an iterator, it gives you a reference type that looks wrong, um, then that kind of error message is way, way worse. Um you know, the the sort of the higher in the structural um matching you're doing on the concept, like the higher that it fails, like the better the error message is. The more it has to go down into it, the worse the story is for the diagnostics.

Bryce 1:03:03

So so the the pre-ranges, pre-concepts diagnostic that you get here in in both GCC and Clang, it basically tells you that there's no operator minus for your std list iterator. Which is like and they this is the whole point of concepts is that is that it's meant to check requirements uh before you go and you know instantiate the body of the thing. Um and so like like obviously like the underlying problem here is like, okay, well, the list iterator doesn't have operator minus because it's not a random access iterator. And the algorithm assumes that um that it's a random access that that you you need to have pass a random access iterator to it. So you know, this I think this diagnostic almost certainly is worse because it doesn't at any point tell you that, hey, I needed a random access thing.

Zach Laine 1:04:03

Yeah. The fact that the names bidirectional and and random access never appear anywhere in here. And you just have to know that, oh, operator minus is defined on random access iterators, but not the ones I gave it. There's a lot of inference you have to do.

Bryce 1:04:15

Yeah. It it's also worth noting that in both of these diagnostics, um you you have internal names. Like even though they're not, even though std sort is not a customization point object, it's not like one of these function objects. Um, this diagnostics that we get here, it still shows it the error manifests in std colon colon underscore underscore sort. And it's not, you know, std colon list colon iterator, it's stdd colon colon underscore capital list iterator. So there's you know, there's still a lot of implementation details that get exposed. Yeah. Yeah. I suppose we should we should uh sometime we should uh we should have Eric on on this podcast and ask him uh, hey, what's up? How how how do better?

Zach Laine 1:05:01

Um my understanding is that this is the uh the the language feature itself is is uh kind of to blame for this, not the the ranges implementation, or not the approach that they chose for ranges. That's my understanding. But uh again, I because I don't understand the technical details for why the diagnostics are worse with this um with this implementation of concepts, it's hard for me to say that definitively.

Bryce 1:05:24

I do think that this is a this is a um so so the in this particular case of going um sort, um sort is an overload set. Um uh so you have a bit of extra noise here um because there's some overloads take, you know, the there's an overload of sort that takes two arguments, one of which is you know uh a comparator, um and there's overloads that ranges sort that take iterators. And uh the compiler sort of has to include those other overloads in the diagnostic, because maybe the mistakes that That you made was that you you'd left out an argument. In fact, I I my AI assisted software engineering talk, one of the bugs that I have the like the AI tool try to identify for me from a cryptic diagnostic is one where I omitted a third or iterator parameter to a call that transformed that I should have put in there. So it's not like it can just assume that, oh, you meant to call this overload that the constraint failed for. I should only show you diagnostics for that one. Because that may not be the case. It may be that your mistake was, oh, you meant to call the version that took two iterators. And the reason that your argument doesn't satisfy random access range is because it's not a random access range, it's random access iterator. And you just forgot to provide the second one. And so because of that, like there's a lot of extra noise here. And that is kind of a little bit inherent to the model. There are certainly some cases where you have a function or a thing that doesn't have as complex an overload set as a lot of the standard algorithms. And in those cases, I mean I think you are going to get a much nicer diagnostic because you you call the thing, there's only one overload candidate, and it failed, it doesn't match because of constraint failure. It'll hopefully give you a pretty good explanation of why. But you know, overload resolution is uh is fun.

Zach Laine 1:07:30

Yeah, for some definition of fun. Yeah, it's it's awful, awful stuff.

Conor 1:07:34

Yeah. Yeah. I mean the summary is just that we were kind of promised that this story would be much better than it is right now, especially given this.

Bryce 1:07:43

That's one of the major um like advertised benefits of concepts.

Zach Laine 1:07:49

Is that you would have that name in play instead of operator minus, you would say like, oh, random access versus uh uh bidirectional. That's what I've that's what I'm missing. Yeah, and so um it I I still don't understand exactly how this is way before my tenure on the committee. I don't understand exactly how the original concept stuff got uh the boot, but there's definitely lots of aspects of it that I really like better than what we got, including like concept maps, which are um, if people don't know what that is, it's basically like a uh Rust uh Rust uh trait. It's very similar to a Rust trait, where you say, like, this thing conforms to this concept, and here's some glue code that makes it work, which is a super nice uh language feature. If you use Rust traits, you know what I'm talking about. They're really, really handy. So there's a bunch of things like that that we're missing from from the thing that we got. And I think matching on expressions in general is not as nice as matching on archetypes, which is what we had with the old uh implementation. So you would you know you'd basically write out like this is uh this is how this type should look. And then if it didn't look like that, it's pretty easy to say, like, oh well, this thing is missing like this exact function overload because you wrote that function overload. It's really easy to write that. Like you didn't have this, right? Whereas if it doesn't have some expression, you're like, well, it didn't have anything that that works as this expression, but it those expressions are inherently ambiguous, right? Like, does star X for some value of my type that I'm trying to match? Like star X, like does that mean that um it is uh like can I draw the distinction between like uh an operator star that is like ref qualified for only R values or only L values, right? I can't I can't distinguish those two, right? Whereas I could say in an archetype, like it has to have the ref qualification L value only, or const L value, or R value, or whatever the thing is. I can write it out explicitly, or I can say it has to have two of them, right? But not all three. Something like this, right? And then I can say, like, oh, your type doesn't have the exact requirements I need, and let me write you a diagnostic because it's just like regular overload resolution. It's like I couldn't find overload that that matches this thing that you need. And so it's really easy to write diagnostics like that. That's how we write diagnostics all the time for any regular function call. You know, one of the things I would really like to have is like type erasure in the language. I think that would be really cool. Uh, but there's really no way to write it with concepts the way we have them right now. Because you'd like to say, like, you know, make me uh a type erased version of some concept name, right? But there's not a way to do it because then if you have some expression, you don't know how to go back from that expression to synthesize like an exact function with an exact signature because there's multiple things that could map onto that expression. So, you know, it's problematic in a lot of ways. And and I was um one of the few people that was like, yeah, I don't I don't like this new concept formulation. I think we should not um standardize this. And uh um there was a small group of us that were like skeptical. Uh and um I don't think we were 100% correct, but I think we're onto something that like the old thing had some merit. And again, I don't understand all the technical details, so there could be some like complete deal breaker from the original concepts thing that I'm not aware of. Um but uh I definitely like as a as a user uh facing like what it would be like to write code both ways, I definitely prefer the old model.

Bryce 1:11:05

I I feel that the purported benefits of concepts have not materialized um in the way that they were advertised pre pre-C20, pre-telease of C20. Um I also just found it easier to express concepts in the older model than in this the current model with the whole like where you essentially you write like usage patterns. I find that very um non-intuitive to me.

Zach Laine 1:11:31

Yeah. Yeah, I do too.

Bryce 1:11:35

Yeah. We should we should uh we should have somebody on sometime to talk about the old history.

Conor 1:11:43

Should we get Doug Greger on?

Bryce 1:11:46

I mean, that would be the person to have.

Zach Laine 1:11:49

Yeah, that would be nice.

Conor 1:11:50

Who did uh I think it was you, Bryce, that told me to talk to Doug, and he was at the um PLDI 2020.

Bryce 1:12:02

Yeah, when we were there together.

Conor 1:12:03

Yeah, when we were there together.

Bryce 1:12:05

It wasn't 2020 though, buddy, because 2020.

Conor 1:12:11

I'm trying to remember when that was. Anyways, it was I think it was post-pandemic, quote unquote post.

Bryce 1:12:17

Oh, we have stockings just arrived. Come bring over a stocking. I want to see the stocking.

Conor 1:12:22

Welcome to Oh damn, shit's popping. Take a look at the stocking.

Bryce 1:12:30

So so there's another reason why I would want to have Doc on the podcast, which is that when we met him and uh chatted with him at San in San Diego at uh PLDI 2022, I think, he made the bold claim that uh variadic templates was like a perfect feature. It's like it's perfect, there are no notes, there were no problems. And uh I I just I wanna I wanna chat with him a bit about that because I feel like parameter packs could have had some uh ergonomic improvements.

Zach Laine 1:13:02

Well, the the only deficiency I had with it, I think, was that um you couldn't index arbitrarily into a pack. And you know, he had that as part of the the proposal. I don't know if it was the the the root proposal or proposal proposals um surrounding it, and everyone liked the feature, but everyone hated the different syntaxes that they saw, and everyone's like waiting for a better syntax to emerge, and then it never happened. So like they they acknowledged at the beginning that this was like something that people wanted to do and it was very valuable, but they just couldn't come up with a syntax people liked.

Bryce 1:13:33

So much so so all of my years of painfully having to write all of the little quirky patterns is because of that.

Zach Laine 1:13:39

Yeah, like having to tease out like the front or the you know the suffix or prefix of something around some value you're looking for in the middle, like all that painful code is not strictly necessary.

Bryce 1:13:48

Aaron Powell The perfect is the enemy of the good. But we but we do have pack indexing now. We just sh um added it.

Zach Laine 1:13:57

Uh I don't think it's in yet, is it? Or it's uh I think it's been added to the working draft, but not the first one. Yeah, yeah, yeah.

Bryce 1:14:05

Yeah.

Zach Laine 1:14:05

Not the 23, but 26, yeah. Right, we're gonna go for 26, yeah. Yeah, that's pretty cool. And that's one of those like minor things that when I train people, I'm like, yeah, and there's all this thing, you're probably never gonna use it. And I'm like, I use it every day. Like I'm constantly using it, and it changed my life. Uh, and uh, but it's just a footnote for a lot of people.

Conor 1:14:23

Well, hopefully we'll be able to get him on. He can talk to us about some Swift stuff while he's at it. So Doug, you probably don't listen. But uh if somebody that is close to Doug wants to send him this episode, it's a holiday special.

Bryce 1:14:36

So, you know, it's uh I'm sure that this will get back to Doug somehow.

Zach Laine 1:14:42

So um Bryce, you may be curious to hear this. So we were talking about how long it takes to do stuff in the committee. And something I started working on in I think 2017, 2018, something like that. So it's five or six years I've been working on it, is uh like um Unicode support for a C standard library, right? And I at the last meeting I just decided I am sick of working on this, I don't care about Unicode that much. I'm walking away from just abandoning it entirely. But at the same meeting when I decided that I was mentioning this to people and I dinner with this guy, Eddie Nolan, which you you may you may remember him from the AWG, right?

Bryce 1:15:18

We went to the theater together uh a week or so ago, and I brought close to this.

Zach Laine 1:15:22

Okay, all right. So he he is picking it up and running with it, and I'm so happy that it's not gonna just get abandoned completely, even though I'm the one abandoning it. I'm just like sometimes you reach a point where, especially with a volunteer thing, like you're just so sick of working on it, you can't motivate yourself to do it. And so I was at that point.

Bryce 1:15:38

Yeah, yeah, but Sack, Sack Eddie is a nice guy.

Zach Laine 1:15:41

He's a nice Why do I want to throw him under the bus like that?

Bryce 1:15:46

Why do you have to go on nerd snipe and look like this?

Zach Laine 1:15:50

Well, that's the funny thing is I mentioned that I was I was like, yeah, I'm I'm disappointed in myself too, but I'm just not gonna work on it anymore. And he was like, Well, I might be interested in picking that up. I did not ask him. I was like, I almost I almost thought like I should ask Caesar three times to accept the crown. Like I should now remember, Eddie, I I confirmed with you three times that you wanted to do this before he signed up. Um because it's like uh it's a lot. Yeah, it's a lot of work, it's a lot of uh political stuff. People have very hard opinions about Unicode, and then most people don't know anything about it, and that's a weird and trouble troublesome combination.

Bryce 1:16:25

Yeah.

Conor 1:16:26

Well, he's now he's now a part uh a part of uh aw damn shit's popping lore. So, you know, no turning no turning back now.

Bryce 1:16:35

Yeah. Well, I ha I uh I I think that it is pe people don't realize the toll that it takes, and it is not uncommon for people to decide that they they just you know they gotta take a break or they just can't continue with things. And and the problem is is when we don't have other people pick things up. Um and I think yeah, that comes back to the um we lack a team um mindset. And um it's so much this like you know, I've said it before, we're a collection of 300 individual authors, not a team of uh working in C. In in a if we had more of a team culture, you wouldn't be driving this thing alone. Um and some of these other people who have strong opinions on uh uh Unicode, instead of just giving their opinions, they would compromise and and and not only compromise and give you design input, but actually like come and work and collaborate with you on your design. Um and I think so often on the committee, and I'm I'm not calling anybody in particular here. I I don't even don't even know any of the specifics of Unicode, but so often on the committee we have um competing proposals and we have people bringing their different ideas, which is good. Um but I would like to see more of a collaborative environment where there's less pressure on any individual author to drive a certain thing forward and where people work more and more as teams.

Zach Laine 1:18:05

Yeah. I I get the subtext. It was Quarantine's fault. I understand.

Bryce 1:18:24

I think maybe seven now, that participate on the committee. And um, oftentimes you'll see that their papers have a deep author list. And sometimes the author list will change over time because sometimes if there's one thing, like they get together, they talk, and if there's something that is a priority for the community at whole, you know, they find somebody who can drive it. And if somebody no longer has the time to work on it, then somebody else can sort of come and pick it up. Um, and that sort of team mindset is one of the reasons why we've had so many successful um things in the scientific and HBC space in the committee recently.

Zach Laine 1:19:00

Yeah, I've I've really been impressed by that same thing. That I see them, they're all working towards the same goal. No one's across purposes, they're on the same page. They have a variety of things that think are you know top priority, and that's natural, but like at base, they're like trying uh to reach the same underlying goal, which is really nice. You know, and uh like that's why we're getting you know linear algebra and like multi- multidimensional array stuff, like all that stuff is driven by them and uh real real concrete needs. And um, I think that stuff is really, really good work. And and that includes the SIMD stuff too, right? SIMD stuff came out of a similar uh crowd.

Bryce 1:19:35

Yeah, yeah. So so much of a of a proposal success in the committee um has to do with the merits of the author, not the proposal. To the degree that I can I can almost tell you just if you just tell me the name of who's working on the proposal, I can tell you how likely I think it is it's gonna get into the standard. And it's it's only from like the the qualities that make somebody a good champion on the committee is really the ability to accept feedback and compromise and the persistence to do the work. Um and it's like the the people who who listen, who who learn the culture, who learn sort of the the environment of the rooms that they're in, and then present their thing and get feedback and really take it to heart and and um really know how to listen when the room tells them something that they don't want to hear. Um, those those are the folks who can really drive something through to the end.

Zach Laine 1:20:40

Yeah. Yeah, I completely agree. There's there's a lot of people that uh will stick with something like a bulldog and just won't let go. And and I don't mean that in a bad sense. I mean like they they're rolling with the punches, they're making changes, but they they want to see it through. Yeah. And then there's some people that like um I don't know, I think they're more like uh uh a heel a monster or something. They like they they clamp onto something and they're not gonna let go open in a bad way. Like it where where they're like, this is the only way to do this. I don't like all these all these counterexamples for the way I want to do it, like I don't care about them, they're not important, like this is the only right way to do this, there I there's no compromise. And that's like that just is the fly.

Bryce 1:21:18

I think it's a lot of it, and this is part of like NVIDIA's philosophy to the committee, is we we come to the committee with with goals and with features that we have in mind. We're never wed to a particular design. And like I think that this is the best, like if your goal is like, I want to see, I want to see C support X, um, like that's that's a great, great approach to coming to the committee. Is like I'm gonna work on that goal. Um but if your goal is I want to see this specific design go into C, well, that's that's not necessarily gonna be how things are gonna go. Um, because it may be that in the course of exploring that design, the you learn that there's there's not consensus to do that particular design on the committee. And I think it's it's all it's orders of magnitude easier to sell the committee on this is a goal that we agree on, than to sell the committee on I want this particular design.

Zach Laine 1:22:18

Yeah. Yeah, there's been a a few design elements that I was really fond of, and I had to just let go of them, and it's kind of heartbreaking. Yeah. But at the same time, like uh that's just you know, that's just the way it is, right? I mean, you can't you can't go into a room of 30 people and say, like, it's my way or the highway, they're gonna be like, well, there's the highway right over there.

Bryce 1:22:35

Uh well, it's um, you know, the process of standardizing something, it's the same process of of contributing something to an open source process uh uh uh project where it is it's all about you giving up control and ownership. Like you start off with 100% ownership of this thing and then you bring it to another group of people who you want to seek approval from, and you slowly lose ownership of it and it becomes something that is communally owned.

Zach Laine 1:23:04

Yeah, yeah, absolutely.

Bryce 1:23:06

And that's what you want ultimately. I I am sad that you will not be working on uh on on Unicode, uh Zach, but as long as long as you continue coming to library evolution.

Zach Laine 1:23:19

Well, and I told Eddie, like, you know, it's uh I have I have a lack of motivation to work on it directly, but one thing that I have sort of an infinite um um amount of of uh reserve energy for is like talking about things that that I've done or that um I think are important. And so you know I told Eddie I'm gonna be 100% available. We already had like an two or three hour call where we're talking about all the details and stuff. So I'm I'm very much uh gonna support him and everything. So hopefully, hopefully that's a success. But um I won't be doing it directly anymore. And and there's been a bunch of things where I'm like, look, I mean, if you made that decision, I'm gonna write a paper saying I think it should be a different way. But all these other things, like, hey, uh I don't agree with some of them, but it's your thing now. Like you do it the way you're gonna do it. Like, don't let me tell you like it can't be done that way. That's your thing now.

Bryce 1:24:03

Well, and this this leads me to an interesting question to ask you, Zach, which is what do you view as your greatest successes on the committee? And like what how do you think that you add value to the committee?

Zach Laine 1:24:18

I don't know. So this is, you know, uh uh I've had a few conversations along these lines with other people before, but I mean I think imposter syndrome is kind of um uh like everyone has it, and the people that don't are kind of the people that I think are kind of worthless. Like, like if you think if you think like I'm not sure. Ice doesn't have imposter syndrome, so well, hey, look, the the the comment speaks for itself, but but you know what I'm saying, like you know, like a certain amount of like humility and like I don't know if I'm doing the right thing is required to like sort of you know take feedback and and say like you know if you're 100% concerned, I mean not concerned, convinced that you're like doing it the right way and there's no other right way to do it, then I think um that's problematic. So so to that extent, like I I think like I mean sometimes this is there's a thing I go through, and my wife is very familiar with this because she's the one I talked to about this. But when I'm about to go to a committee meeting, sometimes like, why am I even going to this? I don't know if I I don't know if I I should be doing this. It's like a lot of travel, it's a lot of time, and and then I get there and I'm like super excited to be there, right? But but on the way there, I'm not always excited to go. And so um I think the in-person stuff is really useful. And I feel like I've had uh a bunch of small contributions that I think are useful over the years, but I don't think there's any like big thing that I've done that's like, oh, look, you know, like Eric Niebler can point to ranges, right? And and along with them, Casey Carter, right? They can they could say, like, we did this and this is a that's a real achievement. I don't think I really have anything like that. Um, but you know, that's fine also. Like, I don't, I don't, I'm not like looking for like what's the big thing that I'm gonna make my name with or something. I just like kind of the the approach that I've taken is is there's something that I think we should have, but we don't have it, and I have the expertise to do that thing. If I if I can fill that niche of like, I think it should exist, but it doesn't, and I think I I have the the wherewithal to do it, then that those are the kinds of things I like to work on.

Bryce 1:26:13

See, see, you've fallen into my trap card here because um you're you're one of the people that there's maybe like five or ten people that during my time as Library Evolution chair that I think were the the like the I would call them the regulars, the people who would be in the room who would actively participate in review and really without whom we could not do the work. Um and you're certainly you're like in my top tier of of regular reviewers. And one of the reasons for it is because you um when you're in the room uh participating in a review, you're usually quite vocal and thoughtful in providing feedback. And so like I don't have to worry about like it's like somebody reading this, are we thinking about things like you'll you'll you'll voice your opinion. Um, you know, you think about something like ranges, um, you know, and and Eric and Casey put so much work and effort and you know years of their lives into it, but those features would not have happened without the the thoughtful review and and feedback that they got from the committee. Um and I think that for for people, it's it's funny that often some of the people who I view as the most valuable on the committee are the people who uh get the least praise and the least outward glory and who face the greatest imposter syndrome because they're like, oh, what am I doing here? I'm not, you know, I'm not Eric proposing the next big ranges or something. Um but yet those those folks who who show up regularly, who actively participate in the review, um, they have such a such a huge impact. And it's really it's like you're a force multiplier because instead of driving one big feature, you are helping shape. You know, every big feature that comes through.

Zach Laine 1:28:04

Yeah, well I appreciate that. Thanks. So I wish I had some way to somehow turn this into an insult for Bryce that diffuse the genuineness of this moment, but I can't think of one. But uh so I think that there's a funny thing that you because you say it that way. And when I'm when I'm in the room doing this, I'm like, am I talking too much? I feel like I'm talking too much. Because I feel like when when I when I have lots of things to say about stuff and no one else is talking about it, I'm like, am I dominating the conversation? Should I shut up? Like I, you know, and and and like I I do feel like I still jump in when I think I have something to add. And and there's there's something that is a function of age, I think. I think if I was 20 years younger, I wouldn't be as vocal. Because a lot of times I'll say something and be like, that's not at all the way that works. I'm like, oh yeah, yeah, that's completely stupid, never mind. And but it but it rolls right off my back. And 20 years ago, I would have been like, you know, that night have been like, why did I say that? You know, just been like obsessing over it. So um, so this part of it too, is that even though I sometimes feel like I'm I'm like saying too much, then I just keep going. If I feel like there's uh something I don't understand, I feel like probably someone else in the room does understand it too. Yeah.

Bryce 1:29:08

Well, and one of the pri you know, it's one of the like one of the main reasons to take a poll in a C committee subgroup is because it it allows the people who aren't willing to verbally contribute to express their opinion. Um it's oftentimes 50% or more of the room are um they they don't feel comfortable they uh uh sharing because they're feeling some imposter syndrome, they're like, I don't know if I you know if this question's you know relevant, um uh you know, maybe I'm just you know stupid, I don't understand it, or something like that. Like a lot of people feel that way. Um and uh it's really hard, like even in a room of like world experts in C, or of anything really, it's really hard to get people to be comfortable um uh sharing because every person's like, well, I I'm not the world expert here. It's everybody else is the world expert, you know.

Zach Laine 1:30:10

Yeah, yeah. Well, that's what you know, I've gone out of my way at different times. Like someone, especially someone who's new to the room and they say something that's just like off-based because they didn't they didn't understand something or they lost the thread of the conversation. I've gone out of my way to say, like, hey, you know, like my my phrase for this is like uh ignorance is a default state of being. Like you didn't know that, but that's fine. None of us are born knowing this stuff. That's like I say I say the wrong thing all the time, right? And I will say, I will add that to it. So I feel like you know, we we can do a good job of being really inclusive of people who are newer or or just uh more reticent to speak out, uh, even if they're uh like a regular. There's some people that that show up every meeting, but they almost never say anything. Um and like you said, I think they're an important part of the process for this for the exact reason you just said. Anything that we can do as a group to help people get over that, I think is a good thing.

Bryce 1:30:56

Yeah. I mean, I I and anybody who spent any amount of time in meetings with me knows this. I am constantly confused. And I have I I am completely shameless. Um like I I you know, if there's something I don't understand, I will say I don't understand it, and I'll say like explain it to me. And, you know, like often it is a recurring pattern in my meetings at work where I'll be like, no, no, no, you you're like, you need to show me an example. Like I I cannot, my mind does not work this way. And like I can't, I can't uh I can't count the number of times that I have with great confidence said a thing at a committee meeting while chairing that was like just like a total misunderstanding. I was totally wrong, and then somebody corrected me and I'm like, okay, well now I get okay, I'll you were right, I was completely wrong. Um and I think that's that's my superpower, it's just that like I'm shameless. Like I have I have no qualms about uh appearing and being ignorant because it's it's the only way for me to reach understanding is if I tell people like, okay, like I don't I don't get this. Like expensive.

Zach Laine 1:32:05

Yeah, I mean you're you're now uh like where I am now, but when when I was like you know your age, I'm not sure exactly how far apart we are in age, but I I was not able to do that. I think if it keeps going like this, you're gonna say some truly inappropriate things when you get to be able to like some some really like oof, can we keep this guy in the payroll after saying that?

Bryce 1:32:25

I think that may be true. So so do do you do a lot of code reviews at work too?

Zach Laine 1:32:31

Uh yeah, so we have um a really tiny team. Uh there used to be a larger team uh for uh just a variety of accidental reasons. We have a small team. So we the three of us uh we code review basically everything together. So like anytime someone pushes a major thing from their you know local working repo to the to the uh the GitHub, uh we always review it. Yeah, so that's like part of the culture here. Uh for within my team anyway.

Bryce 1:32:54

Yeah, I mean, how much overlap do you think there is between like the code review and the committee review process? I imagine there's a good bit.

Zach Laine 1:33:01

I think I mean I think there's a fair amount, except that it, you know, it's so concrete with a code review that I think it differs that way. Like there's there's less philosophical, like, well, what are the what are the follow-on, what are the knock-on effects of this going to be down the road? I mean, there's definitely some of that. Like you write you see something, you're like, oof, this is gonna be hard to maintain later. Yeah. Make a comment about it. But you know, I work with pretty conscientious people and we don't really see code like that that much. Um, whereas there could be things um in a proposal where you're like, I see what you're trying to do, but I think this interface has these potential pitfalls, and another comparable interface wouldn't. And so let's talk about that. So I think that the the style of review, the kind of things I'm looking for are very different. I'm looking for like factual errors in the code when I'm looking at code review at work, whereas I'm looking for more philosophical, like, there is no ground truth, but could we do better in uh in committee stuff? So it is different, but fund I don't think it's fundamentally different.

Bryce 1:33:53

Well, what about like design reviews at work or like architectural decision making? Like, do you do any of like that, that sort of stuff? And is that how similar is that to well?

Zach Laine 1:34:03

So we do that, and that's that's a good point, but we don't do when we do that, that's not a code review. Usually we're having meetings and we're coming up with like uh a rough sketch of like this is how we think should things should go, and then we review kind of on the fly. So, like for instance, uh recently we uh implemented this GQL data model. Um, and for people who don't know what GQL is, I was learning about it myself. Uh GQL is this this uh format for um having a data model that can be easily back-ended with like uh a database or like you can read from a flat file or whatever, and you can always change the back end later on, and the and the front end GQL data model stays the same. So um people usually use GQL in like web technology and other things like this, where you run a like all the all the data formats essentially are JSON, I think, by default. So um so we had to come up with like a front end for the data model, like what do the data look like? How do the queries look that was amenable to an efficient implementation on the back end? But there were multiple kinds of uh searches and queries of data you wanted to do, and so we had to have like that discussion about like what do the data need to look like at the API level so that we can write all these efficient backends and then have room to change them out with other back ends later on if we decide to do that, right? So that's the kind of big architectural thing where you have questions like does this limit us in the future? What are the trade-offs, and that kind of thing. So that kind of thing is very much like the same kind of review we do in the committee. Um, but that just tends not to be a code review. So we have this culture of code reviews for like in the form of PRs, but then uh the big architectural stuff tends not to be like that. It tends to be more of a design meeting uh kind of thing.

Bryce 1:35:39

Wait, would you have any advice to people that are seeking to become better reviewers of an any shape like what's your what's your secret?

Zach Laine 1:35:49

Well, I think so. This is a question that I heard um uh uh someone at at C now ask Eric Niebler um when I was right there, uh and I I've had part of the answer that I gave myself. But the question was um how do I become a good library writer? Like, you know, and this is something I've actually specialized in my career. I've like like I'm a library person, like first and foremost. And um, but that's that's a rare thing. Like people don't usually specialize in libraries um for whatever reason. Um and Eric said something uh somewhat similar to this, but but my take on that answer is um read lots of library code and do things along the lines of like when I sit down to write a library, the first thing I want to do is write like the use of the library, not any code or design or anything like notes about how the library should work. So the idea is as a user of the library, I want my code to look like this nice, beautiful thing that is um you know the the ideal. And then maybe when you're implementing the library, you can't um quite get there for some technical reason. You can't have that interface that you started with. But maybe you can find another way to have like a very graceful kind of um thing to work with. So I think essentially a good review of high-level design and a good design of a library are isomorphic in that um you want lots of things to be the same about them, right? Like if it's possible to do so, you want to make it impossible to use it incorrectly. If that's not possible, you make it difficult to use incorrectly. You want to not violate the principle of least surprise. When you return something, it should be the kind of thing you would expect from a function with that name to return. Blah, blah, blah. But there's a bunch of them that people are familiar with. And so the way you get there, I think, is iteration, right? You design uh interfaces or high-level things, and then you see how it works, and then you just do it and do it and do it, and eventually you develop good taste, right? Um, I feel like I have good taste now, and I feel like I started with awful taste, and I had to sort of uh get there by making mistakes over and over again. Um so I really think it's a question of doing it and then seeing what works and seeing what doesn't. And you can short circuit some of that doing it yourself by just reading other people's like APIs and large-level architecture things and understanding why they work and what the try-offs are, and then more examples is is another way of getting reps.

Bryce 1:38:03

I definitely feel like I've I've learned a lot about like what I want to what what good design looks like from uh witnessing bad design or doing bad design and then uh spending years paying the consequences of the bad design.

Zach Laine 1:38:19

Yes. Yeah, and I think you know, there's I I have um what I consider to be a superpower, which is that when I hear good advice, I recognize as good advice the first time I hear it, uh, a large percentage of the time. And what I've discovered is that that's just not what other people are doing. Like I didn't realize this was a superpower until I got experienced enough to see people getting very good advice and ignoring it. Yep. Before I realized, like, oh, this is like a thing that I'm particularly good at. I had no idea it was a thing to be good at. But so, like when someone says when you do it like this, this is the problem, we do it like that, this is the other problem, that's really good advice. That is hard won knowledge that someone went to the experience you just described, where they did it and they had to live with the consequences of it.

Bryce 1:39:02

Yeah.

Zach Laine 1:39:02

And when you hear that, you should internalize that as if you did it yourself to the extent that you're able to do that, right? I think that's a big part of the process. Um, because you know, if you pay for every mistake you make, that's great and you'll learn that way, but you should try to short term with that to the extent you can.

Bryce 1:39:18

Yeah. Hey, that's enough, babe.

Zach Laine 1:39:20

Um I I uh I'm sorry, but I mean, I was just answering what you asked me, and I don't think you should call me babe. Um appropriate.

Bryce 1:39:32

I um somebody said this to me earlier in my career that like the the mark of a really smart person is um the the speed with which they they change their opinion when convinced that uh that they were wrong. Um that like some somebody who's like a really, really, really smart person, like you show that you show them in some way that they were wrong and then just like boom, like 180, they're like in the completely opposite direction.

Conor 1:39:59

Yeah.

Zach Laine 1:40:00

Well I think that's true, but I think there's also some um there's some uh maturity that comes into play there too, because like if you're just like really uh like self-conscious and kind of a raw nerve all the time, some people just double down on something when they know it's wrong because they just can't stand to be wrong. Do you know what I mean? Yeah, even though they they they see what you're saying and they refuse to acknowledge it because they they you know so there has to be some temperament in there too, but I think that's generally true. Like um you've uh maybe read Thinking Fast and Slow, this uh Danny Conan book. It's it's a fantastic book. Oh, it's also good. I have to basically sorry, you have or have not, Connor?

Bryce 1:40:37

I have, yeah. I'm a big uh behavioral economics, you know, pop science fan.

Zach Laine 1:40:41

Yeah, me too. I really love it. So this is a book that about every uh 10 to 15 pages, I was like, oh, that's why my brain works that way. I mean, it's really like a user manual for your head. It's it's really great. But um it's it's based on work done by uh one of the author uh who was Danny Kahneman and his uh his partner in crime, this guy named Amos Toversky. And um, Danny Kahneman writes in not in Thinking Fast and Slow, but another book about their collaboration. He writes this thing that um uh amongst people that knew Amos Tversky, there was this agreement that the best IQ test in the world was how long it took you to realize Amos Tversky was smarter than you. And if you if you just got it immediately, you were amongst the brightest. Amos Tversky was above you, but but you knew where you were. Um and I think uh I think that's really fascinating that there's there's something like similar about that, you know. Like can you can you recognize your own failings and how quickly?

Bryce 1:41:38

Yeah. Yeah, I definitely feel like that's something that I'm I'm pretty good at. Although I don't know. I I still I still retain the stubbornness at some pi some points. Um we probably should start wrapping up because uh I gotta prepare for the arrival of the Polish relatives.

Conor 1:42:00

And I do need to board my flight in like 10 minutes or so.

Bryce 1:42:04

Wait, wait, wait, wait, wait, wait, boarding starts in 10 minutes or the plane leaves in 10 minutes.

Conor 1:42:10

No, no, boarding boarding officially starts at uh in 17 minutes at 12.05 um Pacific time. So I do have to get to the gate though, which is on the other side of the airport, which is why you fly in Air Canada home. And I think actually at one point I was gonna mention, which we can mention it now, is that yes, I'm in San Diego, you're in Austin, uh Zach, and then Bryce is in New York. So we're coast to coast.

Bryce 1:42:36

Uh it is probably the first first time. It's an A220-300. You want the tail number? Jesus Christ.

Conor 1:42:48

Oh, Bryce. I really hope that the audio is is gonna be fine because if you didn't record locally for the first bit, that means we're gonna have to use the audio from this meeting.

Bryce 1:43:00

But you were you were muted for pretty much that whole time.

Conor 1:43:03

Not at the beginning, though. So anyway, hopefully it'll be fine. Because this is and this is this is the holiday gift to the listener is that I'm pretty sure we're we're just gonna release this all in one go. So this is gonna set the record for the longest episode by a long shot. And of course now I've dropped from the meeting again, but I think Bryce and Zach can probably still hear what I'm saying. Anyways, this has been absolutely amazing. Hilo, Rust, Bleeding Edge C, elements of programming, committee stuff. You know, uh, the listener's gonna be having it in a very enjoyable holiday season, thanks to, and most importantly, uh damn, shit's popping.

Zach Laine 1:43:45

I like how that just doesn't sound like it goes with uh hosted by Bryson Connor. It just doesn't go together somehow.

Conor 1:44:00

Quick, quick, and end the podcast now. We shouldn't have started talking about travel. This is gonna be another hour when I'm gonna miss my flight. We're gonna have to wrap up.

Zach Laine 1:44:08

It was a a much smaller demographic that's interested in hearing your guys' travel complaints.

Bryce 1:44:16

All right. Well, thank y'all. That's been fun.

Conor 1:44:20

Yeah, thanks, Zach. This is a blast. Yeah, yeah, thanks for having me. Merry Christmas. Be sure to check your show notes in your podcast app or at adspthepodcast.com for links to any of the topics we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. If you made it this far, consider sharing with a friend or your followers on whichever social media platform you prefer, whether that's Twitter, LinkedIn, or another, as this was a lot of work to edit, but we appreciate all of our listeners and thought we'd do something special because people are constantly requesting that we don't slice and dice these up the way that we typically do. Anyways, thanks for listening. We hope you enjoyed and have a great holiday season.

Bryce 1:45:00

Low quality, high quality, that is the tagline of our podcast.

Conor 1:45:05

It's not the tagline. Our taglement is chaos with sprinkles of information.