Algorithms + Data Structures = Programs - Episode 190: C++, Python and More with Kevlin Henney

Episode Date: July 12, 2024

In this episode, Conor and Bryce chat with Kevlin Henney about C++, Python and more!Link to Episode 190 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the GuestKevlin Henney is an independent consultant, speaker, writer and trainer. His software development interests are in programming, practice and people. He has been a columnist for various magazines and websites. He is the co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series, and editor of 97 Things Every Programmer Should Know and co-editor of 97 Things Every Java Programmer Should Know.Show NotesDate Recorded: 2024-07-11Date Released: 2024-07-12When zombies attack! Bristol city council ready for undead invasionACCU Conference97 Things Every Programmer Should Know (GitHub)97 Things Every Programmer Should Know97 Things Every Java Programmer Should KnowC++Now 2018: Ben Deane “Easy to Use, Hard to Misuse: Declarative Style in C++”When to Use a List Comprehension in PythonIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Particularly when you're dealing with a language like C++, where it doesn't have guide rails or guard rails. In other words, there's no implicit guidance in the language design. You can do anything you want, but let's go back to the axe conversation. Yeah, cutting your hand off is also an option, you know, and we talk about foot guns and things like that. You know, blowing your foot off, why stop at the foot? You know, just take out the whole limb. Welcome to ADSP, the podcast episode 190, recorded on July 11th, 2024. My name is Connor, and today with my co-host Bryce, we interview Kevlin Henney,

and we chat about C++, Python, zombie apocalypses, and more. Note that this is part one of what will probably be a four or five part series. Well, the listener really just missed out on some, I mean, I had props even. Yeah. We will, I mean, we'll start with our introduction now. But we just spent, what's the time stamp? 20 minutes? So, I mean, technically we might be able to piece together half of an episode from just Bryce's side of the conversation. But then you'll miss out on everything that Kevlin said. We were talking about, what are the topics we covered we covered ai apocalypse zombie apocalypse wait wait we

covered how training neural nets is hard yeah data acquisition especially in the form of videos uh your son's admiration and aspiration for axes and more i'm not sure the the the henny plan the henny family zombie apocalypse plan yeah we we have it all um you know and and that all kind of connected together um with uh we then ended up with talking about forests and different population density. And English whack thereof. I insulted the cities of Cambridge and Oxford. That's right. And Cambridge just accidentally.

Yeah, Cambridge accidentally. And then we went back and made sure that, you know, and actually tied that together with zombies. But also, yeah, there was a little bit in there about you've got iodine tablets for radiation. Yes, I do. Actually, Bryce initially said, opened with, I'm not really a prepper, and then revealed actually that perhaps he was and just had not yet acknowledged it and it was masking. I'm the Manhattan version of a prepper because Manhattanites have no space. And so if you're a Manhattanite prepper, you can't have a bunker. You can't like stock up on like lots of stuff. You have to be space

efficient about it. And I have the space efficient prepper things. Yeah. So, you know, there's all of these things that we talked about. The relative efficiency that the LLM model, you know, you need a lot of training data. That's the thing that we see. LLMs are the modern, this paradigm of AI is thirsty for data and for power. But maybe humans, that's one thing. That's a trick that we might want to think about in terms of optimization is that humans do an awful lot with far less training data and a lot less energy consumption. So that's potentially an interesting direction. And that all related back to your girlfriend learning Swift, bizarrely enough.

Yes. Learning Swift and wanting to create a tennis app that recognizes the type of tennis shot that you're making. And this is the point where a conner can insert earlier audio. So, and of course, when we were talking, when the zombie apocalypse thing was also related to the fact that we ended up talking about, we started off with robot apocalypse or the AI apocalypse. And then I said, actually, we might be strangely prepared in Bristol, because Bristol City Council, over 10 years ago, actually issued a plan for

the event of a zombie or undead invasion. And you can actually find it if you Google Bristol City Council zombie plan. I do wonder, like, why did they do this? I think it was somebody was bored you know sitting in the council office they kind of put together two or three pages just brief um and uh you know but that that and we do actually that for a number of years and i don't think it's restarted since the pandemic but there was a there's a zombie walk kind of once a year um uh and you know honestly the difference between the zombie walk and a standard Saturday night

in the center of Bristol, difficult to distinguish, I have to confess. But, you know, there's a kind of thing there. So there's a kind of an association there. And, you know, Bristol marches to the beat of a very different drum sometimes. But having a zombie plan was kind of cool, I have to admit.

Even if done just in jest. I do have to ask, we had this really nice dinner when we were in bristol and it was on like a tuesday or wednesday and it's a very nice restaurant there was nobody else there and this and there were a bunch of restaurants where like they were just like closed during the weekdays do people not like eat out in bristol the weekdays? Is that just not a thing? It is, but it depends where you were because the, so that would have been the OCCU conference, the ACCU conference.

Yes. And I'm going to guess you were within five to 10 minutes walk of the hotel. 15 minutes or so, yeah. 15 minutes, yeah. So it depends on the direction that you went, but the chances are in the center of Bristol, you've got, and that's April, early, middle of the in the center of bristol you've got um and that's that's april early middle of the week center of bristol you're not likely to find as many people in fact it's a great time to go for a dinner um you're more likely to find people eating out later in the week or elsewhere in bristol so the center bristol is more likely to empty out and particularly

certain parts particularly those near um uh the conference hotel uh tend to be much more business district and so you don't tend to have people hanging around as much um whereas thursday onwards in the center it tends to get a lot busier um but generally later early in the week if people are going out uh it tends to be much more local so you're going to be in different parts of bristol so yeah in other words, if you're visiting Bristol and you want to make sure that you can get somewhere nice for dinner, then go into the center because people aren't going to be there if it's early in the week. That clearly doesn't work for December. There are Christmas parties all over the place, but that's actually quite a good strategy.

Go to the places that people don't go in the evening. So we should. What is the big business? Pause, pause, pause. Before, we still haven't introduced Kevlin. I mean, 98% of our listeners know who you are, Kevlin, because I think you've come up, I don't know, a handful of times. I like to mention your talks now and then. But a brief introduction. Writer, speaker, independent consultant. You are probably most well known for

both some of your books, all of your books and your talks. I mean, I, for a while, used to gift 97 Things Every Programmer Should Know whenever I would leave a company, which I've only done twice, I guess. But I would, for the people that, you know, I wanted to say goodbye to, that was the go-to book that I would give people. I would love to say that, like, these are my top five favorite things from it. I have to admit, I've never, I've never,

I've never even heard this book. You're famously not a book or podcast person, though, so you don't listen to podcasts, you don't read books. See, I know Kevlin for his excellent talks and, of course, his famous witty humor but yes 97 i was gonna say i'd love to rattle off the top four or five uh but it was like i want to say a few years ago oh please well no i was gonna say i can't because it was like 20 i want to say it was like 2016 that i read the book. I'm not sure if that lines up with

roughly when it came out. I had like a few of them that I really, really liked, but now it's been like close to a decade that like I've internalized that stuff. And it's just like a part of the way that I program. And I know that a lot of them overlapped with my favorite talk of yours, which I told you when we met in craft conf back in May, which was declarative thinking, declarative practice. There's a ton of stuff in that talk that like really influenced the way that I was writing C++ at the time, because C++ famously is not, I mean, you can code any way you want in C++, but a lot of this stuff that you get out of the box doesn't, you know, it's not immutable by default, like Rust or some other language, right?

Anyway, so we will link some of the books. There's also i i think the java version of the 97 things book yeah that that we're talking about the pandemic um earlier on and um in fact during the during pre-conversation um bryce in his non-prepper mode was basically saying he had a whole load of n95 marks masks before the pandemic and that was actually air quality in california influencing that um uh and uh so therefore that gets to talking about the pandemic the the java version of the 97 things um but was finished in the first wave of lockdowns um uh because what else are you going to do um so it's me and Tricia G. Tricia used to work for JetBrains. And kind of after that, I got a call.

I got a message from Peter Somerlad, who may be known to some of the listeners. Peter's been involved in C++ forever. And particularly some committee work, unit testing, stuff that he's done, refactoring work that he's done. But Peter was interested in, oh, maybe there'd be interest in doing a C++ version.

And unfortunately, O'Reilly weren't quite on board with that at that particular point, which is a shame. But the 97 Things thing, that book actually came out in 2010. So yeah, it predates 2016 by quite a way. And it is the thing I quite like about that, although I like the Java one, and the same if I did a C++ one or a Python one or whatever. The funny thing about choosing a specific technology is by definition, the technology is going to date.

And I'm not saying that the general programmer one is timeless. But because it was trying to, because I told people, okay, what do you want to tell other people? This is the idea. People volunteered things, you know, it was a very kind of open submission type of approach. By definition, they're not anchoring on, well, here you are, you're using, you're currently using C++98, this is what you're going to do. Or you are currently using Java 6, and this is what you're going to do. So I'm just rescaling the timeline, trying to get my versions right. Or you're considering using Python 3, 2010, probably weren't. You're using Python 2.3 or 2.4. The point there is that that wasn't the goal of the book. It was like, I don't know who I'm speaking to, but they code. What can I tell them? So what the interesting thing is that only four years after the Java one's come out, it's probably dated more in some ways than the 97 things every programmer should have.

Because the Java one is specifically talking about this version, this framework, this whatever. And a C++ one would have a similar issue because you'd probably have somebody submitting saying, hey, you're going to program modern C++. Let's pretend that we started developing that book this year. That means that you'd have some people saying, oh, well, maybe we should be pushing C++ 23. But other people say, oh, you've still got to get on board with 17 and 20. But if I'm reading this in five years time, 17 and 20 is looking much further in the rearview mirror and i'm thinking well that's over a decade ago and suddenly it's become dated and the notion of modern has shifted and there's that constantly moving window so the curious thing is that the

2010 book if you read in 2016 doesn't seem that doesn't seem that old But even less than six years after the Java one came out, you can already see a gap opening up because it's trying to speak to a specific technology. So there's kind of an interesting thing there. And I think it appeals to, and you were saying that you kind of internalize things. And I think that that's the thing, is that it is intentionally about the underlying principles rather than some of the technical specifics that i could go and easily look up in the read me or online somewhere so there's they the books i guess have slightly different goals but they also have different aging properties yeah no it's it's super interesting uh and i i haven't read the java one but i would definitely think that the 97 uh like the original one it has

just like a lot of the advice given is timeless advice it's not like you said attached to any version or uh is gonna you know 10 years from now be no longer like some of it's uh very generic but like i remember too at the time like you sort of go through at some point in your career like you are learning the style that you like to code in. And at the time I was reading it, like I hadn't fully, uh, you know, concretize the way that I like to write code, but then like you start to read books like that and that talk as well, declarative thinking and declarative practice. And there's another one by Ben Dean, uh, that covers a lot of the same stuff, uh, called,

uh, what is his called it's easy to use hard to misuse uh like applying declarative thinking or something like that and like both of those talks it just showed a way to write c++ that is not like the default and it makes it more robust and uh and anyways like a few years after that though i had kind of like settled on like you know you've seen enough code you've reviewed enough prs and like i very quickly can be like look at a pr and code someone's written and be like this is i really really like this this is high quality code and then this other stuff it's like even if it's it's written but just formatted a certain way it's like instantly gives you like chills or something i'm sure both of you have

had that experience when yeah yeah everything is possible but you don't necessarily have a quality filter in that sense you don't or you don't know why something is good and and i think particularly when you're dealing with a language like c++ where it doesn't have guide rails or guard rails in other words there's no implicit guidance in the language design right you can do anything you want but let's go back to the axe conversation yeah cutting your hand off is also an option um you know and we talk about foot guns and things like that you know blowing your foot off why why stop at the foot you know just just just just take out the whole limb the point there is this but you see see there's that one person who has that very important use case where cutting their foot off gets them an extra 5% performance.

And so, you know, we have to have the axe. And we have to have that. So therefore, yeah. And so there is that issue that because there isn't – and it's interesting dealing with different kind of language, programming language cultures. And I think that's actually one of the really interesting things is that when you you look at how people use language is often a cultural thing yeah it's not a national culture but it is there are um so one of the things uh early in my career i worked uh i think most yeah initially my c++ was under windows uh was under windows then i went and um and then i was working on unix and um x windows and it was really and therefore you know um posix standards and all kinds of stuff and it was really

interesting just looking it's like okay here's the same language but already the influences and the way that people think about their just just everything from naming to error reporting conventions and things like that was already shaped by the context they were in. So it was one language, but two very different cultures already well-defined. And these days we have an even larger spread. And there is quite the normalizing characteristic.

Anything is possible, but that also is a real challenge for anybody working. And particularly anybody working with code that has been developed over many eras. Because you've got all these different eras of language and what is received good practice, and then you've got the individual preferences or the backgrounds of the developers who came in. Whereas when you look at the Java space, I'm not going to say all it's uniform but there's a much stronger uh core culture and again you kind of get the thing i think python's interestingly um caught between a couple of extremes there's a very strong core sense of pythonic but python is also everybody's favorite second language and there and a lot of people that are python tourists so sometimes you stumble

across code that you go like yeah this is this is elegant, this is Pythonic, this is kind of like the received wisdom. And then you step outside that and you're looking and it's just like, okay, this person is definitely a tourist. They've obviously got the code. They're thinking from, in a scripting sense, they're using a common subset of the language and they're kind of just making something work.

But it's not their primary language and that shows. And they're kind of making do. And they've got a very kind of imperative style, even though Python actually allows you to be a lot more expressive than that. Going back to Connor's observations about the kind of declarative style of thinking, you can be highly economic in Python, but you can also be staggeringly verbose. And that's the, you know, and that's, it's from where people are coming from. And that I think is really interesting and is a challenge. I think for anybody coming into any language is what is the received culture there? And how well is it supported as being considered normal? But then also how much, how does time affect this? Younger languages have less variation over time. But if I picked up a book, you know, I'm just looking over at my C++ bookshelf,

and it's kind of like, if I pick up one of those books, I've got... So if I pick up a book from the early 90s, then its idea of good is going to be really different from the stuff that's coming out in the early 2000s. It's going to be different to what is coming out now. And it's like any legacy code base, that's a real challenge for anybody, isn't it? They're coming into it. It's going like, okay, the file started in the late 90s, and here I am in the 2020s, and I've got everything in between. And I think that's a challenge for people working with C++ when they're learning it because it's such a large language. It's a case of like, well, what do

you teach? You almost have to ask the person, where are you coming from? Because if you are writing code for yourself or you're writing code for a new project, actually, my response may be very, very different to somebody saying, yeah we're working on uh you know drivers that we've been maintaining since the year 2000 then you are low level you are historical you're probably not much past c plus you know it's just like it's kind of like it's kind of it's tidy c with a sprinkling of a few c plus plus features um but it's probably quite imperative and it's quite low level and it bears more it has more in common with c coding style than it does with what somebody would be saying hey guess what you can do this with c++ 23 and so you're it's kind of like am i learning old am i learning anglo-saxon

am i learning modern uh modern english um you know it's the variation to be that huge and knowledge of one doesn't necessarily gift you with ability in the other yeah the this idea of languages have a culture having a culture is actually very interesting i i've been doing more python stuff at work recently and in particular trying to to figure out how do we go about doing things in a pythonic way and it's so fascinating to me that in Python, they have this term, they've coined this term to mean like the way that we do things, you know, like the proper way. And it's really like Pythonic is their culture. And I was talking to my girlfriend the other day about this and I was telling her, like,

it's like, we don't have a term for that in C++. We just say, like, modern C++. And she suggested, and I think this is a great term, C plus C. And I kind of like that because C plus plus C doesn't sound so good, but C plus C sounds good. It's interesting where a lot of the people at NVIDIA that do Python stuff, they are not like 20 or 30 year veterans. I don't know how old Python is, but they're not 20 year veterans of Python. They're people who were C++ people until they started out in C++. They have a background in C++ people until, or they started out in C++. They have a background in C++. And then they became Python people.

It's not true of all of them, but some of the folks that I work with in a certain engineer I was having a conversation with are more like, I feel like I don't know what the proper way to do things in Python is. And some of them are like, I don't feel like I necessarily know that either, but we just sort of figure it out as we go along and then it's like we look at how we write python code for uh gpus and we look at it and like is this

is this really the pythonic way or is this just sort of a way of writing C++ style code in Python? And is that what we really want? Yeah. I have to make a timing note for Connor, which is Connor, about five minutes ago, I captured some audio of Henri the clock chiming. And I think I got up real nice and close. I didn't capture the entire chiming sequence, but you'll want to go edit that in maybe for the intro i don't know if it shows up i'll i'll do something with it

back back to you kevlin yeah i but that idea that particularly where you have this kind of like mixed culture, people come from one, they go to another, I think is interesting because it shapes the way you think. It shapes the way you phrase stuff. And, you know, different people respond in different ways to it. And it's about how you want to learn and integrate knowledge from one language into another or how you work. And sometimes you compartmentalize things and go, oh, I'm definitely – this is – you know, sometimes people go, oh, I've got one way of programming and I'm going to use that in all languages. And sometimes that pushes the limits of what is considered normal in the other language. And your colleagues are looking and going, well, that's pretty weird. That's, you know, oh, I'm using a C++ idiom here.

It's like, well, we call that bad Python where I come from. So you end up with what might be considered good in one case actually ends up being weird or bad in another. But at the same time, having something from another place can also offer you a solution that you simply wouldn't have come across. That's just a way of thinking. It's just like the kind of the grooves and the grooves were not aligned that way. That's not the way your thinking worked. But if you were working in Python, you go, well, hang on. I would do this like this. I would use a comprehension here. Now, what would that mean if I'm working in C++? Well, actually, maybe if I think in terms of ranges and lambdas, that gets me close. But

that's a very different way of approaching the problem. so you've got these these ideas of um differences of expression but then you have the idea of why what's the normal culture here um i was talking funny i was talking yesterday to um uh mike luchides um he's um an editor at uh o'reilly given that we were talking about 97 things earlier and And myself and Mike have, we have a call like every two or three weeks. We've been doing that since 2020. We originally started as a pandemic thing. We just kind of kept it going. And we talk about all kinds of stuff.

We talk about AI, programming language trends, you know, what's really happening in the workspace. You know, is the metaverse a thing that people are genuinely you know where's this going to go uh you know cyber hype all this kind of stuff yeah so we were talking about various things and he was saying well i he said i've been looking at a whole load of python code and he said i'm not seeing a lot of use of comprehensions um and so a comprehension is basically a very tidy it's a a mathematical concept. Ultimately, it comes from set intentions. And so set theory and predicate calculus and stuff like that. And you find comprehension forms pretty much pick a functional programming language, and it'll do that elegantly and directly.

But that's not something that we see in our more imperative languages. It's kind of been brought in later in Python. When they introduced it in Python, it's become very much part of the core language. It integrates with the syntax nicely. It feels like it was always there. It hasn't always been there. But other languages, when we look at c++ it kind of we're having to sort of nudge around and sort of approach it and say well you can do this like this but there's no kind of core concept there and so there is this idea that suddenly it's become very present in the core python style well yeah maybe it has maybe hasn't. It's the received or the communicated wisdom on Python. But what Mike was saying is, yeah, when I look around a lot of open source Python, I don't see a lot of uses. I see a lot of imperative style coding. Everybody's firing up their for loops and their variables rather than going like, you know, I've got a simple expression that just like initializes this the way you want it.

And then we can get on with our real work. Whereas instead, what you've like oh actually four lips that's our real work and you've got all of this stuff that's set up and it distracts from the main purpose of the code which goes back actually to what connor was saying in terms of the declarative style the declarative is just like i just want to say this and i want to know that there's machinery or library behind the scenes that gets this done um i don't need to say it again i don't need to be more explicit about how i'm setting up that's this. And I want to know that there's machinery or library behind the scenes that gets this done. I don't need to say it again. I don't need to be more explicit about how I'm setting up. That's not my main goal here. There's a clear narrative, a simple message, and I want to get that across and use abstraction mechanisms that are available. But what Mike was saying is he says, yeah, when I go out into the wild and look at Python in general, I'm not seeing people using these constructs that allow them this economy and this direct expression.

It's direct expression, but I would argue that list comprehensions in Python, I think, are more complex and not as newcomer friendly as just writing some for loops um like like the the the syntax especially if you've got like you know like a list comprehension where you've got like a um like an if else in there too. Like it gets to be, it can get to be pretty, I think unintuitive maybe. Yeah. It's possible to make these things more complex. I'm never going to debate that.

But I think it depends on where the new color comes from. Yeah. I was going to say the same thing. But most of them come from, most people come from imperative comes from. Yeah. I was going to say the same thing. But most of them come from, most people come from imperative programming background. Yeah. And so their instinct in that, and that's the point is they reach for that tool. So it's,

it's not that it's not beginner friendly. It's just that the grooves of their thinking are aligned on a slightly different way. But when you kind of show, oh yeah, actually this is a really, in fact, let me give you an example.

There's not Python, not C++++ but actually fortran um i uh so for i presume i must have done something in a past life that was terrible and wicked um but i've been but early in my career i am old enough that i've ended up actually you know programming fortran and being paid to do it and uh i which which fortran dialect be sure to check it. And I... Which Fortran dialect? Be sure to check these show notes, either in your podcast app or at ADSPthepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion

where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. It's not the tagline. Our tagline is chaos with sprinkles of information.