Algorithms + Data Structures = Programs - Episode 191: Algorithms & Libraries with Kevlin Henney

Episode Date: July 19, 2024

In this episode, Conor and Bryce chat with Kevlin Henney about algorithms, libraries and many programming languages!Link to Episode 191 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-19FortranCoarray FortranPascal LanguagepytestNumPyPython pipRust cargoRust crates.ioIntro 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

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. 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 Henney. In this episode, we talk about multiple programming languages, Fortran, C, Pascal, C++, Python, and python and libraries algorithms and more 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. Which Fortran dialect was the first one that you worked with? Okay, so the first one I worked with was an extended dialect of Fortran 77. It was not the VAX extensions, which are kind of considered normal. But I was also working with Fortran 66 stuff as well in that company. I was actually taking some legacy that was written in this kind of prehistoric fortran 66 the old the oldest fortran code i've ever had to deal with was fortran 77 and uh right it was fortran 66 was that before they had

like the freestyle form was where everything had to be like like 80 characters oh no no no no fortune 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, you had a three-way if. You had the original three-way selection. So for those of you familiar with Stracump, yeah, that's where all this three-way stuff comes from. It comes from Fortran. And you had single branch ifs.

You definitely didn't have loops. Yes, the formatting was fixed. It was in 77. It was not properly until. Wait, you didn't have loops? You didn you had a do loop which is a for loop but you didn't have while loops yeah yeah so you had do loops uh which were basically for loops oh but there was a nice gotcha um a do loop will always execute at least once yeah even if it 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 sends a time 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 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'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 it's like every time i write a function that takes a size parameter, I think about like, hmm, the first thing I want to do when I write this function is think about what do I do when size is zero? Yeah, yeah. And that kind of sensitivity there is just like, so my brain is kind of fine tuned to that. But 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're actually doing

systems programming um this is also the same company exactly you know when people say the right tool for the right job yeah this is what is what taught me the value of at least part of that expression. We don't always know our full toolkit. Did you say citizens programming? No, no, no, not citizens, systems. Systems programming. I don't know. Yeah, the whole citizen thing, that's later.

Okay, yeah, that's a misunderstanding. But even so, I would say 4chan is uniquely unsuited to systems programming. And I remember when... Why would it have been selected for systems programming? 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 was this on? Oh, this was back in the days when there were mini computers. So this was a data general. And we also did stuff on PCs. And we were transitioning to PCs at that point. 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. It's just like suddenly realize, oh, yeah, with Fortran, 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 want. You know, 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 one normalized. so we're talking about culture one of the normalizing

aspects of c um originally was the value of portability the idea of a standard the idea that that's actually a first class value although fortran did by that point have a standard. 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. So the motivation in that standard was actually originally quite different. And we still had dialects. People would be sitting there going like, yeah, it's Fortran 77 subset. We're using VAX.

And so therefore it was a de facto standard that kind of helped drive. It's funny because this is still true today. 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 there's things like caray fortran that only a few compilers support and it's like it's still very in a way dialecty yeah it's and and that notion of portability it's an idea that is now if you like become very normal in younger languages, was not part of the value system. And we also see it with historical languages like Pascal. And a lot of people, you get a lot of people saying, you know, a particular generation,

when they were taught Pascal at university, was their first language to 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 Delphi. It's this. It's this extended. Pascal is one of the most extended languages historically.

Academics used to love extending it. The number of papers I used to love extending it the number of papers i used to read through it's just like oh here's another extended pascal it's just like you just it's a very different way of thinking now these days with languages we've taken a very the philosophy that c came came along so like when people sat around extending c you kind of look at them going like being really cautious it's just just like, are you sure? This feels very abnormal. And 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 it. But that notion there is that one company really championing uh but that that

notion there is that extensions are viewed with some suspicion um and uh you know there's there's occasion you get oh well you know here's kind of like a built-in magical keyword on this platform that does something very pragmarish and so 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 idea that, yeah, there is a, of itself, this is a value. And other languages have different foundation concepts and those are rather nice and 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 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 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 so you know

but water flow through what so uh a water network distribution network so reservoirs your house the pipes outside your house that kind of stuff, pumping stations and this kind of stuff. So this is a water modeling network. And the idea is one of the things we want to do was model the propagation of some waste into a river upstream. How does that affect the reservoir? And how does that affect what goes out of the houses? So, you know, how does this dilute and thin out over time? Where do we end up with concentrations and so on? So very interesting problem at that level. So I was working on this kind of code. It was built onto an existing system. And so therefore, we were dealing with legacy code already. But the person I was working with, she was a mathematical modeler.

The only language she'd ever learned at that time was Fortran. So when she's writing out the specifications, so she's sitting there going like, okay, how do I turn partial differential equations into something that can be coded up? Her worldview 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, her requirements document, and my code ended up being shorter than the requirements document because her pseudocode was huge because it was

written in this very, very procedural style of Fortran. So the point that she was, oh yeah, you need to initialize, you've got a two-dimensional, you've, she said, oh, yeah, you need to initialize. You know, you've got 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 value of pseudocode is you can say what you want. Nobody's going to compile it. You 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 for 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 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 going back to your point yeah you can write you know we can write incomprehensible code in any medium. You can write some crazy comprehensions. You can write comprehensions that wander off the right-hand side of the screen in search of the horizon and never stop and are just treacherous.

But the point is that for some of the simple stuff is you just want to say, I'm done with this. I don't need to set up a loop and append things and do work. And I feel the same as well when I look at some C++. And funnily enough, something I was looking at just last week, I was running a workshop for a company and it was somebody had gone through a very long process and saying, and I said, well, you know,

there's an algorithm for that. You know, there's a lot of algorithms in C++, but so, you know, not all developers are going to know all of it. you know there's a lot of algorithms in c++ but so you know 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 you've written a 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 going to 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, all the loop management's done in the background. We've got this, you know, this is fine. 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 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 legacy code, there are lots of reasons code becomes legacy and treacherous. But a lot of it, one of the things you can always guarantee is that, 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. You don't say, this is legacy because it's compact. It's not that it's so compact it's unreadable.

It's actually mostly spread out. I'd say that there's kind of almost a 10 to 1 ratio, and I'm really making the numbers up here, but there's more of an extreme. You're getting the sense that most legacy code is characterized by lots of stuff making decisions about things. Oh, I'm going to if on this. I'm going to while on that. I'm going to switch on the other thing. And I'm going to record a condition, and I'm going to put it in a ball. Then I'm going to come back to that later. And then I'm going to if on this, I'm going to while on that, I'm going to switch on the other thing. And I'm going to record a condition and I'm going to put it in a ball, then I'm going to come back to that later. And then I'm going to do something else. And I'm going to revisit the ball later. And then we're going to change, you're changing flags and read it. And that it just grows, it just it just continues growing. And that's one of the things you open up, you open up a code base, 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 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 it doesn't live in the library, then think of yourself as the library builder. Yeah, we do this all the way through the code. Oh, commodify it, factor it out. What can I use? Can I use a class? Can I use a function? Is there templating opportunity here? Could I just extract this and you toss me a lambda and we're all good? What is the bit that I can pull out? 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 such a common shape in our code that perhaps we should pull that one out. And I think that's the thing that I'm trying to encourage people to think like that but by default we don't we always work with the raw tools that that we have which is often as you say very imperative yeah it's interesting because i i actually uh i was writing a python list comprehension the other day uh where i i needed to do a cartesian product a multi-dimensional cartesian product i needed like a tuple of like integers from zero to n in all the different uh dimensions and and as i was writing 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 1, 4, 4 in the comprehension and it gives me back an iterable of tuples somebody must have written this but I don't know who, what this thing would be called I don't know what the proper way to do this is

so I'll just write 4k in range 0 and 4j in range 0N, 4J in range 0N. And like it's pretty readable. But I think one of the problems that 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 it tends to be different from language to language.

Yeah. In fact, that might be the, that's also one of the issues going back to this idea of like core culture or received culture is sometimes these things aren't common but they were put there with intention in other words you know it's it we you know so we might say you know standard library the stl i mean stl when was that kind of introduced 1994 okay that that was kind of uh um steppenhoff and lee that's 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 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 is an issue. I was running a workshop for a company a few months ago and actually it was basically, it was Python and it was Python. And it was Python-based. And 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 in that.

And that's simply because my experience has been different to their experience. But 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 in an era where we don't, you know, 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 the standard is library, half the standard is language.

I haven't actually looked in terms of page numbers and certainly not in terms of printouts, because I think that would be forest destroying for C++23. But what proportion would you say of the C++23 standard is library? So I actually know the answer to this. Excellent. I was hoping. Let's say it's, I think C++20 was, I think 23 was like 2,200 pages. I don't know what it's going to be for 26. But out of those 2,200 pages, like 800 pages were language and the rest was library okay so we are almost at the

point where that it's important to note that that the way that the library section is uh structured um we the way that we specify 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, so basically there's a template for stamping out the library definitions. 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 yes and i i think i i agree with you that because i remember because i was a i was a member of the standard uh old standard stuff just pre just pre 98 and uh member of the 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++ i was saying actually the

language is going to be bigger and then that became very definite with c++ 11 it was like c++ 98 was putting it was just like move it was halfway between these two worlds but c++ 11 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 you know the whole the whole value structure is like flipped on its head and then 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 what people get like what even who even like cares what the line between like like what's standard in python and what's just like a pip package that you can install, like it's very blurry. Like what even is standard? Like in my sector of Python, like NumPy is like standard. Like, you know, everybody uses NumPy. You can just, if it's like 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, like Python has a packaging story and has its shit together with regards to dependencies. Well, OK, they have their own problems, but more so than C++. They have a different class of problems than C++. Yeah, and the point is they have a different class of problems because the shape of 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 pip, I think, is important because it allows you to blur the line a little bit between de facto standards, 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, we have a PEP number for this and all the rest of it. And the, you know, sort of the de jure standard and the de facto standard, which is this is what people use. You know, the de jure is like we have decreed this is the case. De facto, everybody's doing it this way. And we see that for the fact that Python comes with actually two unit testing modules that are considered standard. Unit test, 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 in the larger Python world, typically,

the standard is PyTest. And that's because of... I was just about to say, I've heard of neither of those because the projects that I'm familiar with just use PyTest. Yeah, and that blurred line between the de jure, what has been decreed as standard

and what is normal as standard. 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. Why don't we just redraw the boundary line? And aren't there also two standard argument parsing things? There's like op-pars and then argument.

Yeah. Yeah, they're going to let them do what they want. It's just like, let's have a fight, see who wins. Or we'll have both. So the notion there is very different. And so nobody's going to sit down and document the whole of Python, except over time, python.org will aggregate this stuff. The system within C++ is very, very different. But that recognition of, oh, the library is where,

the library is a lot of where the value is, is something that any new language immediately, 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? We integrate with nothing. Oh, show me your standard libraries. They're kind of minimal. Okay. minimal okay well you know i think it's an interesting intellectual exercise but that's not going to make any impact um yeah and you have to have either one or both of those uh 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 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 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 yeah that's they're talking about the tip of the iceberg there 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 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 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, 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 there's a lot going on here um 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 networking needs and so on? And these have been relatively late arriving. So outsiders arriving in, it's just like, oh, okay. And you're telling me about Boost and other things. Oh, what's the standard package manager for that?

So people stumble across- Have you heard of CMake, another language? First, go learn that. then we can talk about yeah yeah you know the the that that whole that whole idea of like yeah almost embarrassed and there's almost a hesitation when people say cmake it's just like oh okay this is the dirty secret can i buy you a drink we'll have a conversation to private. To be fair, if you're going to, like, yeah, CMake has its problems, but, like, Python setup tools has its problems, too. Like, 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 was as painful as it would have been to learn how to do something in CMake. And then, like, when 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 that library. And so I was trying to set up a development environment. I know that there's this conda stuff and then there's this whole virtual environment ecosystem in Python. And then there's all these things, all these words that I'd heard. And I was like, oh, this sounds complicated. And so I asked the main maintainer of this, I'm like, hey, look, like I've just been like – like what I've been doing is I just like – I created like a virtual environment like using this like the simplest – the thing that seemed like the simplest thing and it's like kind of kludgy 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 a 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 um 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 um but like i i run on like a debian system um 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 debian packaging and so then like then there's that whole clash between if you have an OS package manager and then you also have a language package manager. I think that the ecosystem is still a lot better than C++ because the one thing that was relatively painless was 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. The problem is, Bryce, is you're comparing C++ is lack of a package management like cohesive or comprehensive one to pythons 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 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 okay but but um but people use python 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 but um but rust doesn't have the install base that python has so like like I'm, Python is another language that is exists and deploys

at the scale of a Java or C++. And like, like 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 cruft

it's crufty because people use it right yeah yeah you can have you can have the perfect language that nobody uses or you can have something right yeah you not going to you're 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 it's a much more honest way of doing it it's like what kind of imperfections does this have because it's going to 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, you know, it's quite an old language.

You know, it's... Slightly older than me. It's pre-grunge, you know. It's a 90s kid, you know. So, yeah, basically, Python is a millennial. So there we go. I've recently started classifying languages according to human generations.

So Python's a millennial, but it's one of the older ones. But that means it's been around a lot. It has accumulated. It's going to accumulate a lot of craft. It doesn't have, it's not going to be perfect in any way, shape or form, 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 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, these are things that people would expect as normal, but they would forgive for an older language. We were talking about Fortran earlier on. I have no idea what these things are in the Fortran space. Is it a solved problem? Because you look at Rust, which has great package management ecosystem, but as Rust starts to grow,

we start to see pain points, like building like Rust things, 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, 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 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 grungy as a python i don't i don't know i disagree isn't isn't building from source like orthogonal to package management uh my my point is is just that um as Rust grows in scale, and it will over the course of the next 10 years, I think, grow in scale by an order of magnitude, it will take on new use cases, and as it grows in age, it will take on legacy. And that, you know, like over time, that will lead to additional complexity. It's inevitable.

Yeah, it'll certainly become potentially cruftier rather than rustier. But it is a case of... There's that Henny wit. There is a difference there in the sense sense and going back to the idea of idea 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

clearinghouse for this kind of stuff so whatever solution we see we we are able to transport ourselves in time see see what happens 10 years in the future and for those of you who are listening in um 2034 let us know um but whatever happens in the future the chances are that it will have been done in a way that again it won't be perfect because the language goals and its 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 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 like it's one of those classic things you've always got to remember about being forgiving about legacy code 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 position you have an ability to use it so the the point there is that you couldn't build a perfect package managed 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. I think that's the other thing. Be sure to check these show notes either in your podcast app or at ADSP the podcast.com for links

to anything we mentioned in today's episode, as well as a link to a GitHub up 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.