Kevlin Henney

And I said, well, you know, there's an algorithm for that. There's a lot of algorithms in C, but not all developers are going to know all of it. We're always on a learning curve. But that whole point of you've probably written almost all the loops you're ever going to need in your life at this point in your career.

Conor

Welcome to ADSP the Podcast, episode 191, recorded on July 11th, 2024. My name is Connor, and today with my co-host Bryce, we continue our conversation with Kevlin Henny. In this episode, we talk about multiple programming languages Fortran, C, Pascal, C, Python, and libraries, algorithms, and more.

Kevlin Henney

So for I presume I must have done something in a past life that was terrible and wicked. But I've ended 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.

Bryce

And uh I which Fortran dialect was the first one that you worked with?

Kevlin Henney

Okay, so the first one I worked on was an extended dialect of Fortran 77. It was not the Vax um extension uh extensions, which kind of like considered normal, um, but I was also working with um uh Fortran 66 stuff as well in that company. I was actually taking some legacy that was written in this kind of prehistoric Fortran.

Bryce

The oldest Fortran code I've ever had to deal with was Fortran 77. And uh was Fortran 66, was that before they had the like the freestyle form was where everything had to be like like 80 characters?

Kevlin Henney

No, no, no, no, no. Fortran 66 didn't even let's put it this way, it didn't even have else. Your ifs were all single. Yeah, you know, for those of you who are watching this through sound, uh Connor, just like what expression. Um yeah, you had single branch ifs. Oh, you had a three-way if the the original, you had the original three-way selection. So for those of you familiar with StraCump, yeah, that's where this all this three-way stuff comes from. It comes from Forge. And you had single branch ifs. Um, you definitely didn't have loops. Yes, the formatting was fixed. Uh it was in 77, it was not properly.

Bryce

You didn't have the for loops.

Kevlin Henney

Oh no, sorry, you had a do loop, which is a for loop, but you didn't have while loops. Yeah, yeah. Sorry. You had do loops, uh, which were uh basically for loops. Oh, but there was a nice gotcha. Um a do loop will always execute at least once. Yeah. Even if its range is empty, it will always execute at least once. In other words, it's as if somebody wrote what should be a while loop as a do while. It will always go through the body once. Yeah, that's a gotcha. It also sets it. So interestingly, as a result of that experience, the first thing even now, even though this is like deep in my past, even now, whenever I look at a piece of code with a loop, the first thing I do is not look at what happens when the loop executes. The first thing my mind reads is what happens when this doesn't execute. And you have no idea how many bugs I found that way. The first thing I do is what happens when this executes zero times. Because normally when people are writing loops, your mental model is I'm dealing with lots of stuff. Okay? You know, I I am sorting things, I am arranging things, I am reading things in, I am sending things out. Your default is, oh, our application deals with much stuff. It deals with millions of stuff, it deals with giga stuff. You you're thinking in the many, but you've got to remember zero is in there as well. So so many cases fall over on the empty.

Bryce

It's like every time I write a function that takes a like a size parameter, my like I think about like, hmm, first thing I want to do when I write this function is think about what do I do when size is zero.

Kevlin Henney

Yeah, yeah. And that that kind of sensitivity there is just like so my brain is kind of fine-tuned to that. But um I and funny enough, the first job I ever did where I was using Fortran, we were not using, we were not doing it for scientific programming or anything that required that kind of efficiency. Uh if you like its historical sweet spot, uh, we were actually doing systems programming. Um it's also the same company where I exactly. You know when people say the right tool for the right job? Yeah. This is what taught me the value of part of at least part of that expression. We don't always know that we don't always know our full tools.

Bryce

Did you say citizens programming?

Kevlin Henney

No, no, no, not citizens, systems.

Bryce

Systems programming.

Kevlin Henney

I don't know. Yeah, the whole citizen thing. That's later. Okay, yeah, that's a misunderstanding. But yeah, but even so, I would say uh 4chan is uniquely unsuited to systems programming.

Bryce

And I remember when why would it have been selected for systems programming?

Kevlin Henney

Um something you said, familiarity. Because that was the language the boss who set up the company knew. So what's the first thing you do? You use the thing you know, don't you? Even if it's uniquely unsuited. What sort of platform is this on? Oh, this was uh back in the days when there were mini computers. Um this was uh data general. And we also did stuff on PCs, um, and we were transitioning to PCs at that point, and so but somebody, some bright spark had the idea that we should learn C. And the sensation of learning C was like stopping hitting your head against a wall. Um, you know, it's just that I suddenly realize, oh yeah, with Fortune, I've been wrestling with all these concepts that were not present in the language, and suddenly I learned C. It's just like, well, this is easy. This is absolutely I can say what I yeah, linked lists, trivial, dynamic memory management, done. Oh, it's even got proper control flow structures, and I don't have to worry about dialects. Because C has the one normalizing, so we talk about culture. One of the normalizing aspects of C originally was the value of portability, the idea of a standard, the idea that that's actually a first-class value. Which was the same.

Bryce

Although Fortran did by that that case that point have a standard.

Kevlin Henney

It did, but the point is that what had happened is that Fortran had splintered, and that's why there was a call for a standard. It had splintered. Um so the motivation in that standard was actually originally uh quite different. And we still had dialects. People would be sitting there going, like, yeah, it's Fortran 77 subset. You know, it's kind of all relevant. We're using VAX, and so therefore, it was a de facto standard that kind of helped drive Fortune.

Bryce

It's funny because this is this is still true today. Um if you look at modern Fortran compilers, there's not really any that implements everything like even just now we're starting to see them implement all of like Fortran 2008. But uh there's things like Corey Fortran that only a few compilers support, and it it's like it's still very, in a way, dialect-y.

Kevlin Henney

Yeah, it's and and and that notion of portability, an idea that has now, if you like, become very normal in younger languages, was not a val not part of the value system. And we also see it with uh historical languages like Pascal. A lot of people you'll get a lot of people saying, you know, of a particular generation when they were taught um uh Pascal at university, um, was their first language, they go, Oh yeah, yeah, I really like Pascal. Scratch the surface, and you'll find that if they actually programmed in what was standard Pascal, they would have hated it. Because it was just like, yeah, what it turns out a lot of people say, Oh, I really like Pascal, and then you scratch the surface, it's like actually it's object Pascal, it's it's Delphi, it's it's this, it's it this extended. Pascal is one of the most extended languages historically. Academics used to love extending it. The number of papers I used to read through is just like, oh, here's another extended Pascal. It's just like you just it it's a very different way of thinking. Now, these days with languages, we've taken a very different the philosophy that C came uh came along with. So like when people sat around extending C, you kind of look at them going like being really cautious. It's just like, are you sure? This is this feels very abnormal. And only ever only a couple of C extensions have ever escaped into the wild with any kind of popularity, one of them being C, the other one being Objective C, which is now on the decline. As a result of, we were talking about Swift earlier, as a result of that, because there was only one company really championing uh it. But that that notion there is that extensions are viewed with some suspicion. Um, and uh, you know, there's there's occasionally you get, oh well, you know, here's a kind of like a built-in magical keyword on this platform that does something very pragma-ish, and and so on, but it's very light dusting rather than oh, yeah, it's the core of the language that you're actually messing with. And so C has inherited that um idea that, yeah, there is a uh uh of itself, um, this is a value. And other languages have different foundation concepts, and others rather than ISO standard. There is the idea of like what other versions of Rust or Python? You know, there's a couple of variations of Python by platform, but people again are a little bit suspicious if you step too far from what is considered the core. That's just like, yeah, okay, I can see what you're doing there, but you know, come back to the center, come back to the light. Um, it's a very different value. Whereas in Fortran, it's just like, yeah, this is the way we do it, and whatever, the the value system is very, very different. But curiously enough, yeah, we're we're so we're romping across the ground here. Let's let's actually try and find the road again. Because the reason I mentioned Fortran is I work the other job I did, not systems programming, actually did involve doing um actual computation, um, proper number crunching. It was uh modeling, um, uh modeling a system of water flow. So I used to work in the water, I worked in the water industry and I then worked in the electricity industry, and hindsight suggests that you don't want to mix electricity and water.

Bryce

So, you know, but water flow through what?

Kevlin Henney

So uh uh a water network, distribution network, so reservoirs, your house, the pipes outside your house, that kind of stuff. Um, pumping stations and this kind of stuff. So that this is a water modeling network, and the idea is one of the things we want to do was model the propagation of impurities through a water network. Um, you know, maybe a factory um accidentally, or accidentally on purpose, dumps um uh some waste into uh a river upstream. How does that affect uh the reservoir and how does that affect um uh what goes out of the houses? So, you know, uh how does this dilute and uh uh over time and thin out over time? Uh, where do we end up with concentrations and so on? So, very interesting problem at that level. Um, so I was working on on this kind of code, it was built onto an existing system, um, and uh so therefore we were dealing with legacy code already, but the person I was working with, um, she was a mathematical modeler. The language, the only language she'd ever learnt at that time was Fortran. So when she's writing out the specification, so she's sitting there going, like, okay, how do I turn partial differential equations um into something that can be coded up? Um, her world view is immediately shaped and solely shaped by her programming language experience, which is Fortran. So I ended up when I remember reading this, I remember reading her specification, you know, uh, you know, her requirements document, and my code ended up being shorter than the requirements document, because her pseudocode was huge, um, because it was written in this very, very procedural style of Fortran. So the point that she was, you know, she said, oh yeah, you need to initialize, you know, you you've got a uh a two-dimensional matrix, you know, you've got a 2D matrix, so you need to initialize that. So she would write, rather than you know, the the value of pseudocode is you can say what you want. Yeah, nobody's gonna compile it. You can say, I've got a matrix, set every element to zero. Or set every element to whatever value you want. No, she would set up a nested for loop or nested two loop and initialize everything to zero. So what could be said in just a few words and one line was now five lines. Um, and uh yeah, so there was this expansion from what you could say. So that idea of like here's something I can say very directly and very simply. So getting back to your point, yeah, you can write, you know, we can write incomprehensible code uh in any medium, you can write some crazy comprehensions, um, you can write uh comprehensions that wander off the right-hand side of the screen in search of the horizon and never stop, and you know, are just treacherous. But the point is that for some of the simple stuff is you just want to say, I'm I'm done with this. You know, it's it's I don't need to set up a loop and append things and do the work. And I feel the same as well when I look at some C. And I was uh funnily enough, something I was looking at just um last week. I was running a workshop for a company, and it was somebody had gone through a very long process of saying, uh, and I said, Well, you know, there's an algorithm for that. You know, it's you know there's a lot of algorithms in C, but so you know, not all developers are gonna know all of it. We're always on a learning curve. But that whole point of you've probably written almost all the loops you're ever gonna need in your life at this point in your career. Yeah, you've written the loop that does everything, does one thing to everything. You've written the loop that searches for a thing. You've written after a few months of programming, you've probably written all the shapes of loops you're ever gonna need. What you want is somebody to commodify that and say, it's okay, I've got the loop handling, you just plug in the bits that I need to do. Yeah, the loop, all the loop management's done in the background. We we've got this for you. You know, this is this is fine. Just tell me, just tell me over what you want this done and the thing you want done, or the value you would like to do. And that idea I think is is a really important one that sometimes a language feature will help us, but sometimes it is a library or the support there to say, you know what, we've already seen this, everybody's seen this a thousand times. And most most legacy code, there are lots of reasons code becomes legacy and treacherous. Um, but a lot of it, one of the things you can always guarantee is that um uh almost without fail is that when you look at something that somebody's called legacy, you see control flow, you see a lot of control flow. Um, you you don't say this is legacy because it's compact, and the uh you know, it's not it's not that it's so compact it's unreadable, it's it's actually mostly spread out. You know, I'd say that it's kind of almost a 10 to 1 ratio, and I'm really making the numbers up here, but it's certainly it's it's uh there's more of an extreme. You're you're you're getting the sense that most legacy code is characterized by lots of stuff making decisions about things. Oh, I'm gonna if on this, I'm gonna while on that, I'm gonna switch on the other thing, and I'm gonna record a condition and I'm gonna put it in a bull, then I'm gonna come back to that later, and then I'm gonna do something else, and I'm gonna revisit the bull later, and then we're gonna change, you're changing flags and revisit, and uh that it just grows. It just it just continues growing. And that's one of the things you open up, uh you open up a uh a code base, and it's just like, yep, lots of control flow. And I'm not saying you don't want any control flow, but I'm saying that if that's the main feature that strikes you, it's just like, yeah, there's probably some of this stuff that's been done before and lives in a library, or that if doesn't live in a library, then think of yourself as the library builder. Yeah, we do this all the way through the code. Oh, can modify it, factor it out. What can I use? Can I use a class? Um, can I use can I use a function? Is there templating opportunity here? Could you can I just extract this and you toss me a lambda and we're all good? What is the bit that I can pull out? Um, either because somebody else has done it in a library that is standard, that is available, or because we can do it ourselves, because it's so such a common shape in our code that perhaps we should pull that one out. And I think that's the thing that trying to encourage people to think like that. But by default, we don't. We always work with the the raw tools that that we have, which is often, as you say, very imperative.

Bryce

Yeah, it's interesting because I I actually uh I was writing a Python list comprehension the other day uh where I needed to do a Cartesian product, a multidimensional Cartesian product. I needed like a tuple of like integers from zero to n in all of the different um dimensions. And and as I was writing it, I was thinking like somebody who knows Python better than me, there surely must be some function I can call, where I can just call like you know one for four in the comprehension, and like it gives me like an iterable of tuples. Somebody must be written. But like I don't I don't know who what this thing would be called. Um I don't know what the proper way to this is, so I'll just write you know for K in range zero, and for K in range zero, and and like it's pretty readable, but um but uh I I think one of the problems that uh you people may have coming into a language where they don't know the culture is you don't know what these patterns are spelled. Like you don't sometimes you don't even know like where would I go to find these things, like the common ways of doing things. And uh and it tends to be different from language to language.

Kevlin Henney

Yeah, and in fact that might be the that's also one of the issues going back to this idea of like um core culture or received culture, is sometimes these things aren't common, but they were put there with intention. In other words, you you know, it's it we it you know, so we might say, you know, standard library, the STL, I mean the STL, when was that kind of introduced? 1994. Okay, that that was kind of uh um Stepanov and Lee, that was when I think when they made their proposal originally to the committee, so 30 years ago. And we'd like to say that that's common. I don't think it's necessarily common if I look across a lot of um C code bases. It's more common in some companies, in some groups, but it's been available for a long time and it was put there with intention. And the problem is that people sometimes don't recognize that that's there, particularly the larger a language and its library gets, the harder it is to accidentally stumble across something or to even know to ask the right question. And that that is an issue. I was I was running a workshop for a uh a company um a few months ago, and uh actually it was basically uh it was it was Python and it what it was Python-based, and I although the workshop wasn't, hey, here's Python, I spent a lot of time saying, Oh, you know you can write this more compactly, you know, there's a thing in Python for this, there's a thing on that. Uh and that's simply because my experience has been different to their experience, but I I kind of look for this. Whenever you look into a language, you kind of there's kind of a thing you want to say, probably somebody's already done this and solved it, and it should be there. We're in an era where we don't, you know, uh so going back to one of the key differences, so Fortran and C versus so we're talking about standardization. I think one of the interesting differences between say the Fortran and C side of things and the C and non-ISO languages, say Java, Python, and so on, there's a really interesting difference between these, is that those languages always were defined around a really small kernel of features. You know, the uh the uh the the original C89 standard, uh half the standard is library, half the standard is language. Um I haven't I haven't actually looked to say I haven't looked in terms of page numbers and certainly not in terms of printouts, because I think that would be forest forest destroying for C23. But what proportion would you say of the C23 standard is library?

Bryce

So I actually know the answer to this. Um, let's say it's um I think twenty I think C20 was I think twenty-three was like twenty-two hundred pages. I don't know what it's gonna be for twenty-six. But out of those twenty-two hundred pages, like eight hundred pages were um language and the rest was library.

Kevlin Henney

Okay.

Bryce

So we are almost at the point where that's yeah, it's important to note that that the way that the library s section is uh structured, um we the way that we specified like library functions in the standard, we have all this like front matter where we say like, you know, like we have this returns clause that means this, and we have this equivalent to that means this. Whereas in the language, um so that basically there's a template for stamping out the library definitions. If you wrote if you wrote it out for the language itself, we don't really do that because there isn't as much of a uniform shape of things for the language. So if you didn't templatify how you specify the library, it would probably be a good bit longer.

Kevlin Henney

Yes, and I I think I I agree with you that because I remember because I was uh I was a member of the standard, uh old standard stuff just pre just pre-98, and uh member of the uh BSI panel on that. And it was really interesting when the STL came in, because the STL had kind of introduced this slightly more compact and let's pull out front matter, and you know, here's the things everything has in common to stop us doing this repetition. Whereas prior to that, everything had been specified very much the way the C standard does, which is and there's no there's no effective templating, as it were, much more long form. And and that was the the language was very minimal, very, very, very small. Whereas C are saying actually the language is going to be bigger, and then that became very definite with C11. It was like C98 was putting its, was just like move, it was halfway between these two worlds. But C11 onwards has been like, oh no, no, no, we library's a thing, it's a really important thing, it's a separate, um, you know, it's a very it's it's that's where a lot of the value lies. Whereas historically been, oh, it's it's about the language, and the library is almost an appendix. It was, it's actually no, the the whole the whole value structure is like. flipped on its head. And then when we look at other languages, you know, Python, a standard Python distribution, I have no idea how many modules there are. It's just like there's there's just loads of stuff. And that's the thing.

Bryce

Well and in like like what even who even like cares what the the line between like like what's standard in Python and what's just like a pip package that you can install like is very blurry. Like what even is standard? Like in like in my in my sector of Python, like NumPy is like standard. Like you know everybody uses numpy. You can just if it's there's something in numpy like it's no big deal to depend upon it. It's just such a different bar than C because in Python Python has a packaging story and has its shit together with regards to dependencies. Well okay it they have their own problems but more so than C. They have a different class of problems than C.

Kevlin Henney

Yeah and that that and that's the point is they have a different class of problems because the shape of the the tooling and the history and the culture of language what they value and what they want is going to be different. And the point you make about um about PIP I think is important because it is there is a uh it allows you to blur the line a little bit between de facto standard, something that is agreed on by a body so the Python Foundation who you know rub a stamp and say yeah we've agreed this here's you know and we have a PEP number for this and all the rest of it. And the de jure you know the day you know sort of the de sorry standard and the de facto standard which is this is what people use the de jure is like we have we have decreed this is the case. De facto everybody's doing it this way. And we see that um for the fact that Python comes with actually two unit testing modules that are considered standard uh unit test uh which I generally always caution people away from and doc test which actually most people don't even know exists. And the majority of people um in in the larger Python world typically the the standard is PyTest.

Bryce

And that's because of the I was just about to say I've I've heard of neither of those because uh the projects that I'm familiar with just use PyTest.

Kevlin Henney

Yeah and that's and that blurred line between the de jure what has been decreed as standard and what is normal at standard.

Bryce

And actually that's the way that some libraries made their way into the core Python distribution because oh look everybody seems to be relying on this and using this all the time so why don't we bring it you know why don't we just redraw the boundary line and and isn't that isn't aren't there like also like two standard like argument parsing thing as um there's like app sparse and then argument yeah yeah they're gonna let them do them out you know it's just like let's have a fight see who wins or oh we'll have both you know that so the the notion there is is very different and so nobody's gonna sit down and document the whole of Python except you know over time python.org will will aggregate um this stuff the the system within C ⁇ is in is is very very different but that recognition of oh the library is where the library is a lot of where the value is um is something that any new language immediately any any new kid on the block has to accept that you've either got to say I'm a new language and I'm really cool what do you integrate with?

Kevlin Henney

We integrate with nothing oh show me your standard libraries they're kind of minimal okay well you know I think it's an interesting intellectual exercise but that's not going to make any impact. And you have to have either one or both of those attributes. You've got to come along and say I'm a new language and I'm building on top of this I integrate really well with this language this environment this ecosystem whatever it is or you say I come with all these goodies and these will solve your problems. These are your problem shaped goodies this is what I'm offering you. It's not in it's not just the language I'm offering you a bit of ecosystem which libraries all the way through to build systems and package managers. That's where the value lies that's what that's what people want to what people now look for in a language so although they say I am using language language X what they actually mean is they're talking about the tip of the iceberg they're they want the rest of the iceberg and that's what they expect. And I think that's what sometimes people find frustrating when they move from one language to another that has is radically different historically so if you grew up with Python or um you know if you grew up with Python or you've grown up in the .NET sphere working with C sharp, Microsoft Tools.NET and all all these integrations these are normal or you've got used to package managers like Pit and then you suddenly come into C. It's just like you know there isn't quite that I think would be an understatement and you kind of go oh okay um you know what am I looking at? Oh we've got a really cool language and there's some library and then we look at the library and go oh there's a lot going on here. And that's where a lot of the value is but we still find a few gaps missing that have become normal in other languages but are still um from an outsider's point of view oh why isn't that in C don't we all do this? Don't we all have UI needs and and uh and and networking needs and so on and these have been relatively late arriving so so outsiders arriving in is just like oh okay and you're telling me about boost and other things oh what's the standard package manager for like yeah so people stumble across this have you heard of CMake another language first go learn that then we can talk about yeah yeah and you know the the that that whole that whole idea of like yeah it almost embarrass and there's almost a hesitation when people say CMake.

Bryce

It's just like oh okay this is the dirty secret can I buy you a drink and we'll we'll have a conversation to be fair if you're going to um like like yeah CMake has its problems but like uh Python setup tools has its problems too like I was trying to I was trying to do like to change some part of how like you know this Python package I was working on like built and like you know it it it was as painful as as it would have been to learn how to do something in CMake. And then like when I was I was starting you know to do some Python stuff and I wanted to patch a thing in like I tried to do something with like one of the libraries at the company and I was trying to patch a thing in in uh in that library and um so I was trying to set up a development environment and like I know about the I know that there's like this conda stuff and then there's like this whole like virtual environment ecosystem in Python and then there's like all these things, all these words that I'd heard and I was like oh this sounds complicated. And so I asked like the main maintainer of this I'm like hey look like I I've just been like like what I've been doing is I just like I I I created like a virtual environment like using this like like the simplest the thing that seemed like the simplest thing and it's like kind of clutchy but it seems like it does what I want like do I need to go like learn these other things? And he was like look like other people may tell you differently but like I think what you're doing is like fine because it's like the simple way for like somebody who's new to the ecosystem to get started and like then you don't have to learn like what conda is what anaconda is why there's a snake here. But just like there even in a language that has a good like package ecosystem like Python like there is like a lot of stuff there. I will say like you know it was pretty easy for me to get like up and running but like I I I run on like a Debian system and like if I try to like pip install something on that system like it pip yells at me it's like hey whoa like you should have installed that with like the Debian packaging and so then like then there's that whole clash between like like if you have like an OS package manager and then you also have like a language package manager. I think that the the the the ecosystem is still a lot better than C because um the the one thing that was like relatively painless was like once I figured out how to properly use the package management system. Like it took a little bit of time to figure out how to create the development environment and use the package management system. But then once I'd done that like getting the dependencies was just like very easy. Whereas in C, if I had to start working on some new C project that had like five dependencies, then I'd have to go and build one of them and like one of them would have like you know like a build tools script and like one of them like just wouldn't build on my system and it would just be it would just be a whole thing. It would be a whole day thing to get set up.

Conor

The problem is Bryce is you're comparing C's lack of a package management like cohesive or comprehensive one to Python's which like Python was created in the 90s. I don't know when their package manager and Pip showed up but like this is a solved problem now. Like you're comparing a a language that doesn't have a solution to a language that has a bad solution. Rust, Swift, Go, like name a modern language this is a solved problem.

Bryce

Okay, but but um but people use Python.

Conor

I know but like we're sitting here comparing two bad things saying like oh you know we shouldn't give C such a bad time because Python's not that great either.

Bryce

But um but Rust doesn't have the install base that Python has. So like like I I I'm Python is another language that is exists and deploys at the scale of a Java or C. And like look like the the reason that I'm doing stuff in Python and not in Rust and Swift and other things they're all great languages but the reason I'm doing stuff in Python is because like we have a lot of users who want to do things in Python because people use Python. And so like because like yeah it's like an old established thing and like it's crufty but like it's crufty it's crufty because people use it, right?

Kevlin Henney

Yeah. Yeah you can have you can have the perfect language that nobody uses or you can have something that you're not gonna you're the the the I think the the debate when we come down to these things um is normally we're always looking for perfection and I think actually we should just be comparing degrees of imperfection. I think that's a much more honest way of doing it. It's like what kind of imperfections does this have because it's gonna have them and the question is do they get in the way? So Python has accumulated imperfections I mean it's been around since 1990 that was its first release. So yeah it's it's quite it's it's quite an old language. You know it's it's uh slightly older than me. It's yeah it's pr it's pre-grunge you know um it's it's a 90s kid you know so yeah basically um uh python is a millennial um so there we go this I I've recently started classifying languages according to uh uh uh uh human generations so python's a millennial but it's it's pretty you know it's it's it's one of the older ones but that means it's been around a lot it has accumulated um uh it's gonna accumulate a lot of craft it doesn't have it's not it's not gonna be perfect in any way shape or form but it's imperfect and therefore we know that of any language but C is imperfect in different ways and the idea now again is that idea of if we think about it and you pick up on Connor's point it's just like it's a solved problem. If you were to introduce a language now and you said we're not going to address these things people kind of look at you and go, oh it's a research language then you know it's you know it it's a it's a toy you know you it these are things that people would expect as normal but they would forgive for an older language. You know we were talking about Fortran earlier on I I have no idea what these things are in the Fortran space.

Bryce

Is it a solved problem? Because you look at Rust which has great package management ecosystem but as Rust starts to great to grow um we start to see pain points like you know building like Rust thinks lots of dependencies because everything gets built from source can take a lot of time and because Rust's model is like everything needs to be built from source um when you have like closed source things in the ecosystem like it's not so clear how those integrate and like if you look at 10 years down the road I think Rust is clearly going to be uh a top five language um but by the time it gets to that point for all we know Rust's package management ecosystem could look as as complex and and grungy as uh Python I don't I don't know I disagree isn't isn't building from source like orthogonal to package management is is just that um as Rust grows in scale and like it it will over the course of the next 10 years I think grow in scale by like an order of magnitude it will take on uh new use cases and as it grows in age it will take on um uh legacy and that you know like over time that will lead to additional complexity it's inevitable yeah it'll it'll certainly become it'll certainly become potentially craftier um rather than rustier but it is a case of um it's it's there's that heni without that there is a difference there in the sense in going back to the idea of idea i these things are solved problems but it doesn't mean that everything is trivial it just means oh yeah somebody has done this and our challenge is is you know what what are we going to do about it and how are we going to make this standard now the thing is the Rust Foundation is the is effectively the the the the clearinghouse for this kind of stuff so whatever solution we see we we are able to uh transport ourselves in time see see what happens ten years in the future and for those of you who are listening in um uh 2034 uh let us know um uh but whatever happens in the future the chances are that it will have been done in a way that not again it won't be perfect because the language goals and it's uh um and its users will have shifted but it is likely to have been explicitly addressed and probably in a way that's a bit tidier than well you know if we were just talking about Python it's probably going to learn from that in other words they have the benefit you know future us it's just that it's it's one of those classic things you've always got to remember about being forgiving about legacy code um uh uh uh is a case of like well whoever was writing this probably was doing the best they could they didn't have your knowledge because guess what you've seen this stuff you've got some other benefit you've already the problems they were initially struggling with were perhaps new to them and you've got this gift of time and you have a pos you have an ability to use it.

Kevlin Henney

So the the point there is that you couldn't build a perfect package manager back in 1990 because it wasn't even recognized as a thing as a problem so in 10 years' time they've got the experience of the last quarter century for example to build on. So it won't be perfect but it's probably going to be you know halfway decent at least and agreed upon.

Conor

I think that's the other thing. Be sure to check these show notes either in your podcast app or at adspthepodcast dot 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.

Bryce

Thanks for listening we hope you enjoyed and have a great day low quality high quality that is the tagline of our podcast.

Conor

That's not the tagline our tagline is chaos with sprinkles of information