CoRecursive: Coding Stories - Chat: Don and Adam discuss folds

Episode Date: February 15, 2020

Today we try a different format. Adam invites his neighbour, Don McKay, over to ask him questions. An interesting discussion on recursion, corecursion and the naming of the podcast unfolds. "John was saying, we conclude that since modularity is the key to successful programming, dah, dah, dah, dah, dah. I think what he means by modularity is okay, we write our fold and it's like three lines long.  Once that exists somewhere, we don't have to have that base case all over our code. We ended up programming a higher declarative level. The other reason is just I really like clean abstractions. There's more to learn but once you do, you're able to kind of have this language where you can talk about these things at a higher level" Why Functional Programming Matters - John Hughes Beautiful Folds - Gabriel Gonzalez

this is co-recursive today we change up the format a little bit my neighbor don is a software engineer he was over last friday for coffee you know we had some super interesting conversations i thought this would be a great fit for the podcast so today he's back for coffee and he has some questions and we recorded the whole thing. I live in a fairly generic suburban house. Don lives a street or two over. He drove over because of the super cold Canadian winter. We set up in my dining room with a couple of microphones and hit record.

Hey Luke, serve him on in. Ready to podcast? Yeah. All right right let me call it the beginning all right so first question what is machine learning so i do not know i know that some machines learn and that's good i think yeah i mean according to what movie you're watching yeah i don't know anything about machine learning so hopefully you brought some other questions. As much as it might be fun to hear me bumble and stumble through machine learning, I'm just going to skip forward to later in our conversation where I get to a more fun question for me to answer, which is what is co-recursion and why is the podcast called co-recursive? What do you think recursion is?

Recursion is a way to harness the power of repetition to get what you need. It's a way to kind of iterate over some sort of data until you get your ultimate goal. Yeah, yeah. I think it's a really good answer. The joke recursion answer is like the dictionary definition where it's like recursion, C recursion and the kind of loop, but like that's actually not, that's a bad function though. I mean,

come on, because that doesn't end, right? Like, yeah. So let's say you want to add up a list. So we're going to calculate the sum of a list of integers. So in C we might have a while loop.

We'll kind of have some variable and then we'll go through the loop and we'll keep adding our element from the list to that kind of mutating that state. And then at the end, we return that as our sum. The recursive way, we have like a function called sum. And then how it's going to work is it's going to take the first element of the list, the head of the list, and it's going to add that to the sum of the rest of the list. And the way I'm describing it is kind of the way your implementation works. So you take off the first element and then you add it to the sum of the rest of it. So that sum is actually recalling itself, right? So if you add one, two, three, you end up with like one plus two, three, which becomes one plus two plus three,

and you get six. That is recursion, right? That's like your basic simple recursion. Where do we go from there? Another thing you could do is like multiply, right? So if you have something called product, it takes a list of integers and it calculates the product. So we'll do the same thing. The product of a list is the first element of the list times the product of the rest of the list.

And you kind of have the same structure where you're always like taking off the first element and then applying something, et cetera. Right? Right. Right. And then you kind of need a base case for both of these to exit for add. You can say like, oh, if my list is empty, then I will return zero. So the empty list has a sum of zero. That might mess up your product though, for your product function. So interesting. Great transition. For product, you obviously can't use zero because you hit the empty list, multiply everything times zero. You get zero, right? Right.

So you need to use one for product, which is actually forms a monoid. That might be a topic for another time. Taking it way off the rails here well also like i think we're constantly in danger of me just saying things that are incorrect but so if you think of these two definitions we have the product and the sum both of them kind of have the same structure so they have like okay here's what we do for the empty case and then for the non-empty case we kind of have some sort of looping call right right and so there was this guy named john hughes not the john hughes who made like home alone oh okay i thought

this was going in a different direction but yeah john hughes is a computer scientist he wrote this paper called why functional programming matters in 1990s in 1990. And actually, here, I'll pull up the paper. Here, I'm going to put you on the spot. It's the abstract of John Hughes' paper. As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write and to debug and provides a collection of modules that can be reused to reduce future programming costs. In this paper, we will show that two features of functional languages in particular, higher order functions and lazy evaluation, can contribute significantly to modularity. We conclude that since modularity is the key to successful programming,

functional programming offers important advantages for software development. This paper is great. You can find it free online. And it just goes through some basic stuff about writing recursive functions. The thing you'll notice about these two that we described is kind of they have the base case, and then the second case. What John shows in his paper is like, oh, hey, in a powerful programming language with higher order functions, where functions can take functions, you can just pull that out. We can take away that logic, put it in a common place, and that gives us the ability to handle this form of recursion all the time using just something built into the standard library. Right. So a functional approach using recursion

would enable us to kind of like take that piece of looping code and anywhere you need to do that is now in a function somewhere. Is that what you're talking about? What John is saying is, hey, I made this function called fold. Fold does this work for you. Fold takes in two things, right? The first thing that it takes in is your base case. What do you do when you hit your empty list? The second case that you have is just the working case so in my sum function instead of being this calling itself i can just say like list dot fold now for my base case i want to give it one and then for my function i just give it the addition sign so that's just saying hey fold over my list and kind of put plus signs between each comma. I imagine it like visually, like if I have this like one comma, two comma, three folds going to like take out those

commas and just put in plus signs. Does that make sense? Yeah, it makes sense to me. The previous part we were talking about, I would call that manual recursion. I'm manually calling myself. Right. Yeah. Often when you see manual recursion, you can like replace it with a fold. So instead of having to call yourself, you can just say, oh, maybe a fold should go here. And I think that's cool. So this concept. It's like folding steel. You just, you keep folding the steel, right? To make it stronger. I don't know. I'm reaching for an analogy here. Yeah, like where does the name fold come from?

Yeah. So interestingly, if you think of the structure of the fold, these examples we're talking about, we're starting with a list of something. And then at the end, we're getting like a single value, right? Right. We're sort of like taking each value and folding them all together into each other.

So that's kind of how I think about it. But a lot of languages have folds because they're super useful. So Scala has like fold left and fold right. Basically, that's just which direction you start from. It also has just a fold. It also has something called reduce, which is the same as fold, except you don't apply your base case. Haskell has Fold L and Fold R, that's left and right. JavaScript and Java and Python all have Reduce. And actually, to your question, I think Reduce is maybe even a little bit more descriptive of how you were thinking about it. Yeah, if you think about Reduce in the context compared to just the regular Fold. Yeah. So Ruby calls it Inject, which is a weird name. And I don't know why, if you think about reduce in the context compared to just the the regular fold yeah so ruby calls

it inject which is a weird name and i don't know why but i'm thinking maybe it has to do with what i was describing where it's like if you have this one comma two comma three and it's like oh inject inject another yeah a thing between all of these to me that i don't know the word inject means a lot of different things to me yeah yeah so scalasala's got Fold, Haskell Fold, JavaScript, Java, Python. They all have reduce. If you want to sound really smart, there's a category theoretic term for this. It's called a catamorphism.

Oh, okay. I'll add that to my lexicon. So less commonly used, right? That would be a really long function call. Like list.catamorphism+. Okay, so that's Fold, right? We were trying, I guess you asked me what co-recursion is. I'll get there. I promise. Yeah. So that's a fold. We're taking like some collection of things and we're kind of like reducing it. We're folding it down. Right. So here's a different recursive thing. Have you ever worked in a retail environment? I have worked in a retail environment,

though, disclaimer, it was very limited. I worked in a computer store for high school co-op and I had to work the till, among other things, fixing computers and stocking shelves and things like that. Nice. So you're at the computer store, somebody comes in, they buy something, they give you

$20 and their changes like $1.57. How do you make change? I guess. Well, I mean, how I did it is I put it into the till, right? And it was calculator and I figured it out. But then how do you decide like what dollars and coins to give them? Oh, I see. Yeah. Yeah. Yeah. So the trade comes out. Yeah. And you're like, what do you grab? Yeah, exactly. What do you grab? Well, first you would grab a dollar, right? Because that's the largest denomination of what you owe them. And then I would grab two quarters and a nickel. And because we still have pennies back when I worked retail, I would give them two pennies. You could give them change by giving them just 157 pennies, but you...

Yeah. I mean, I think you would be fired. Yeah, this is going somewhere, I promise. You can express this as an algorithm, right? I'm going to have a function called make change. I'm going to pass into it 157 for $1.57 expressed in pennies. And then I want it to return the change that it should hand out right in a c program i'm just going to loop while there's still change left to give find the largest denomination and then return that and keep

while looping subtracting away as we return it we can change this into like a recursive function our base case is if somebody calls the function, I would like change for $0. And you're like, okay, here you go. You're like, get out of my store. Yeah. What you actually do in your little function is you just return an empty list.

So that's like your base case. It stands for get out of my store. Oh God. I think I may never make it through the explanation. But besides the base case, if it's more than zero cents, then you just look at your denominations, right? And you say, okay, we have one that's 100 for 100 pennies, and that's less than the amount owed. So I return 100 plus I return the change for whatever's left. So that's my recursive call. I'm saying I return the first amount. And as long as there's still change to recursive call. I'm saying I return the first amount,

and as long as there's still change to give, I just call the function again. The first loop will return a dollar, second loop will return a quarter, and then a quarter, and then a nickel, and then two pennies. It's like you're continuously refactoring what you're owing them. Yeah, this is recursion again.

We're calling ourselves to get work done. But if you think about it, it has a different a different structure before what we were doing is taking a list of elements and we were reducing them to a single one we're here we're kind of doing the opposite we're being given a single value and what we're returning is a list so if i give you 157 you return a list that's like 100 25 25 5 1 1 5, 1, 1 or something, right? I guess in my brain, I went to like, I'm reducing it until I don't owe you any more money. Yeah, yeah. There is a reduction and you have that remainder and the remainder keeps carrying on until it's zero. But like from the outside caller...

You're creating a... Yeah, I see where you're going with that. It's exactly the same, except it's the opposite, if that makes any sense. So earlier I said, hey, you can use this fold so you never have to manually do this call where you're calling itself. Well, you can't actually make this change thing by sticking it into fold because the fold is always working down, taking a list and working down to a single value, right? Right. And you're going to have multiple values at the end of this. Yeah. And we're going to start with a single value instead of like having this list and taking the first element.

Like we're starting with a single value and traveling the remainder down. So this is called co-recursion. Okay. I see. You've finally gotten around to answering the question. I got it. I got there.

I got there. So this is called co-recursion. And the reason that they use the word co comes, I think, from category theory, because co is used to indicate that it's the opposite. Yeah, like sine and cosine. Yeah, exactly. Like sine and cosine. So recursion is taking these values and reducing them down.

And the co is taking single value and producing some. It's the reverse direction at the type level. Co-recursion. So we're getting someplace. All right. You can do this same trick, right? The fold trick is we don't need to manually do this call. Let's just make something. We'll put it in our standard library. This generalization of co-recursion is called unfold. It makes sense. I mean, naming things is one of the hardest things in programming but i think they nailed it what i would like to know though is how many other candidates there were for the name of that function yeah yeah before they were like you

know the first guy came in and said well unfold and well i don't know maybe and there was probably like a three-hour meeting about the alternatives yeah yeah somebody from ruby like proposed unjacked i don't think that's a word but yeah the fold is called a catamorphism the term for a unfold for a co-recursive function is called an anamorphism if you look this up in wikipedia so it says in computer programming an anamorphism is a function that generates a sequence by repeated application of the function to the previous result i think you can picture how the change making you apply it and then with what's left you apply it and with what yeah you have like you have like a make change yeah and you just apply it and then uh it goes through

comes back with the remainder and then you apply it you say make change again and you just keep making change until there's no more change to make. Yeah, exactly. Right. What did I explain so far? Why don't you give me the summary? Let's see. Let's see if I've been listening. Is this a death? This is a death. All right. So what we have covered so far is the fact that co-recursion is the opposite to recursion, where you will start with a single value and end up with multiple values, whereas in recursion, you will start with multiple values and reduce them down to one. And then we've just went into polymorphism and anamorphism, and I think that's where you left

off, is you explained anamorphism is where you take a function and apply it repeatedly until you get your result? Yeah, yeah, I think it's pretty close. So yeah, the anamorphism is just another way. It's just an unfold. It's just another term for it. And a term for fold is a catamorphism. So this topic is like super deep. Beyond the scope of one podcast? Yeah, yeah, yeah.

So it's funny. I was on this podcast called Programmer Throwdown, I think. It was super fun. But yeah, their first question was like, is your podcast about recursion? And I mean, I guess that could be possible. Is that why you're doing this podcast? Is like you went on to Programmer Throwdown

and then you came and you're like, well, I have to do. Now, yeah. I have to do one about recursion because I've been made a fool of on this other podcast. Exactly, exactly. So it is a deep topic. I couldn't pull off making a whole podcast series out of it, but maybe somebody could. And there's other things besides catamorphisms

and anamorphisms. Like it goes deep. There's like combining them. And it turns out that like a lot of complicated things can be expressed in terms of these topics. So yeah, I guess going back to, I like to relate everything to practical applications. So, I mean, in day-to-day work, I've done this a lot when I've worked in C-sharp. I haven't worked in C-sharp in a very long time, probably five years or six years or something. But when I did, for loops were kind of like what you did, right? Like if you had to loop over a collection of something, you just did a for loop. And I guess we kind of stayed away from recursion. It was like a mysterious monster, right? Where you only hear about the bad things, right?

You'd hear horror stories about a recursive function that went off the rails and had like a memory leak or looped infinitely and destroyed something. So why would I use recursion over the, what did you call it? The imperialist? The imperious approach. I like the imperialist approach. I called it imperative, but I like imperialist. It's an imperialist. Yeah. Yeah. So, the imperative approach, I think, is mainly a lot of people are comfortable with.

Yeah, yeah. And these more advanced topics are kind of, definitely from my perspective, interesting to learn about because I'm always looking to improve myself. Yeah. I mean, I want to unpack some of that. So I like this idea that like a for loop is like, oh, that's so simple and I can understand it. But like recursion is this monster that can like run out of control. When I was in college, it was right. Like I was new and, you know, just learning all this stuff for the first time. And recursion is hard to wrap your head around if you're like a programming student that's

just like walking in and being like, computers, I like them. I want to write programs. And your first thing is a recursive function. It's going to throw you a little bit right where it's more convenient to be able to see everything it's doing at face value in like a for loop. You can see it's easier to follow, right? Whereas in recursive, you have to recursively process it in your brain. And I think that is hard for different types of people, right? Yeah, yeah. So I think it's totally valid, right? Earlier when

I was describing how some works, it's actually kind of declarative, the recursive approach. Like if I try to describe the code for doing the kind of imperative for each, right? I'm like, okay, I'm going to make a var that's like sum equals zero and then for each and then da da da da. There's just a lot going on there. It's very verbose. Yeah, yeah. It's very verbose. And it has all these details that don't seem entirely relevant, right? Like, why do I even care what that variable at the beginning is called that I have to like mutate? And what if, I don't know, like something else changes it or, but like the fold sum definition, you take a list and fold over it, you know, adding the elements together.

When I describe it that way, that's like almost what the code will be, right? If I use the reduce, which you like better, it'll be like list dot reduce plus. You can just see that and think like, okay, in my head, all those commas become pluses. I think it makes sense to sometimes trace it through in your head, like this calls this calls this, but you can also just think about it definitionally. The function product, we take the first element of the list and we multiply that times the product of the rest of the list. I think once you get used to that way of kind of declaratively understanding things, it's really nice.

Once you understand kind of what fold means, then when you see the code, you're like, oh, that's easy. Exactly. Yeah, I think that's the word I was looking for. It's like, it's a pattern. And a lot of the times, if you haven't been exposed to the pattern in the past, it can seem mysterious. Yeah, totally.

So a lot of these methods are kind of like a um they're very ambiguous to somebody who hasn't seen the pattern before whereas if it's a for loop right yeah everyone's seen that you've seen that from the first day of like taking a programming course you know and if we go back to what john was saying we conclude that since modularity is the key to successful programming da da da da da and like i think what conclude that since modularity is the key to successful programming, and like I think what he means by modularity, right, is okay, we write our fold. It's like three lines long or something. And it has that standard, here's my base case, here's my other thing. Once that exists somewhere, we don't have to have that base case all over our code,

we end up programming at kind of like a higher declarative level. Like you do, Scala, whenever I have this kind of like pattern matching and I'm like case none and then case sum, I should just use fold for that. The other reason is just I really like clean abstractions. There's more to learn. Like you have to learn what a fold is and what an unfold is. But once you do, you're able to kind of have this language where you can talk about these things. Let's take it beyond lists. Let's talk about a tree. So let's say we write a for loop that traverses a tree. You have elements and they each have children. You can write something that kind of traverses it, that kind of recursively walks through each element and prints them out or something or adds them up, right? And then you can do the same thing instead of having to have some complex code

to add up all the elements in a tree, you just do like tree.fold plus, tree.fold product, and get the same thing. So once you have the subtraction, you can just talk about these things. Like we don't work together now, but if we did and we jumped on a Zoom call and you're like, I'm trying to figure out

how to multiply all the elements in the tree, I could say like, oh, just fold over it with the, maybe this isn't an actual question that comes up. I mean, probably not, but I think we understand where you're going with it. I've had like several times where I just have some really ugly code. There's just like some complicated logic that I'm working on. It has a bunch of cases and it just ends up seeming super complicated. And then like you kind of look at it and maybe this is a fold or maybe this is a map and there's these higher order functions. Maybe this is a flat map and you start to pull it apart. And I've had this

happen where you start with this big gnarly thing, you start reducing it and it gets simpler and simpler. And then it ends up just being like, poof. And instead of having my own function, I just call this built in. But I raised the pull request on some change I want to make to something. And then Adrian, who's on my team and really has deep kind of functional programming knowledge. He's like, oh, it looks good, but there's like a couple of nitpicks I want to make. And then he's like, you could change this to a fold and like this could be a flat map. But basically, he would be able to point out places where the logic that I was doing could be abstracted into some of these higher order components. I mean, what actually happens is I get kind of grumpy and I'm like, oh, I don't want to

change all this. But I do. And I learned something and I learned this new concept. And then as a team, we have these higher order concepts to talk about. I think like all programmers kind of like enjoy that a little bit. Yeah. I don't know if it's something that's like common to the type of people attracted to our profession, but there's something about taking refactoring, right? There's something about taking something that, well, it works. You need to see if there's a better way to do it. And that like need or drive

to improve the existing code that while it may work, you just need to see if it can be better. Yeah. And I find when I was first getting into Scala from C sharp, that's something that I was constantly doing because I was, well, Scala will work. Like you can apply concepts and how you program in C sharp and you can apply them directly into Scala andala will work. Like you can apply concepts and how you program in C sharp and you can apply them directly into Scala and it'll work, but you're not familiar with any of those higher order functions. And you look at code after you've learned some of them and you come back and you're like, Oh, I could change this whole thing and reduce it down to like, maybe even a few lines where it used to be like, you know, a dozen or something. Right.

And I have a strong opinion that this is a useful, pragmatic thing to do, but also I just really like it. So if you want to give Adam a present, just give him some gnarly code and send it to him and be like, can you clean this up? And that would be a present for you. Yeah, right? Don't actually do that. No, maybe. But if you think of somebody's learning functional programming

and they write something, it has like a while loop. And then like the next step, maybe they're like, oh, I can do this without mutating this variable that I'm adding into by doing like a recursive function. And you can be like, well, I can use a fold, right? So now I don't even have to write the recursion myself. It just becomes this like one liner. When you get down to this fold, the fold's going to work. It's being used in other places. It's not broken right so like i mean like that's the advantage of of using some built-in functions

to the languages you know that they probably work yeah we had this other example at work i'm making a request to this web server that and it's going to return to me large amounts of binary, 100 megabytes or something, maybe more. And sometimes for certain servers that we were interacting with, it would start sending binary, and then partway through sending, the connection would die. So it would send you like 10 megabytes and it would die. Somebody quick hacked in a fix, the server's like under load, or the other server has something where it just shuts down

if it kills connections that are open for too long. Who but we have to deal with this we need to get this data somehow so there's range headers when you make a request you can actually say in the header give me from this offset to this offset in the data this is how like it's kind of like paging yeah yeah it's also how like youtube works like if you skip to the middle of the video it just starts asking for data from that point right so we get like our 10 megs and then something dies then we have some complicated retry logic that says okay how far do we get let's ask for more and then that'll die and we'll ask for more and we keep yeah i think i think a lot of modern implementations of that kind of method you can see in almost anything that's streaming, right? Yeah, totally. We had this kind of gnarly code to deal with that.

And then somebody, let's just say it was me, realized that this is unfold. What's happening is you have this function that takes in this request, and it's either going to return like 100 megabytes, or if something dies, it's going to have to keep requesting. It'll the first 10 and then oh let me request the next 10 and then let me request the next 10 until it's kind of like your change remainder case until we've actually gotten everything that it said was the length of the document right so now instead

of our like while loops then we can just turn this into an unfold and kind of carry this through and so this like gnarly server access and code got simpler these concepts are everywhere and they're super cool to me i mean that's a lot of people i'm sure that people listening to your podcast will also have some kind of affinity yeah maybe who knows yeah i recently implemented something similar and i have where i needed to fetch a large data set and you can't just can't do it all at once i think we all kind of run into that where the data that you're fetching is just too large for either the the database or the processing like you want to be efficient so you page it you take it chunks at a time so you just stream it in in chunks i did it with recursion though so maybe i'll go

back and see if i could do it with a fold yeah yeah with an unfold unfold yeah if you were going to grab the results of some page and it only showed 10 at a time and then you had to go to the next page you can write an unfold where it's like grab the first page and then if it has a next link right then call with that. And you keep on calling until there's no next. There's no next link. So the next is your remainder from the change example. It's another example of an unfold.

Happens all the time, man. I don't know. So there's a guy that I had on the podcast, Gabe Gonzalez. He wrote a bunch of things about folds. Like he went really deep on it. He showed all kinds of things can be written in terms of folds. Once you understand the definition of these terms, you're able to write some really concise code. Right. It's all of these languages share some of these operations. They just call them different

things because when we're executing systems, we're all facing the same problems, right? We're all coming to the same solutions just in different syntax syntax. Yeah. Do you know what code golf is? No, but seeing how I don't like golf, I don't know if I would like that. The golf aspect of it is you're trying to do it in as few characters as possible. I feel like I might've done something similar using some of the other types of websites that are like HackerRank. The problem with code, like I think it's something fun that people do, but the code is it ends up just like some horrible mess of symbols. But I think it's an enjoyable process. What I'm talking about here, like using fold, using unfold, using

some of these kind of FP concepts, I think it scratches the same itch because you're like, how can I simplify this? But in a practical way, right? Like using fold is actually practical using some series of pearl symbols to do a complicated thing. And I think that might be a topic for another podcast is at what point does brevity sacrifice clarity? Yeah. Yeah. Right. A lot of what we're talking about here, it's actually more concise, but at what point is it, is it so concise that it's hard to understand? Yeah, totally. I don't know the answer. I think that if you don't know the concepts, certainly if you don't understand what unfold is, even if it's shorter, you may not find it to be a more understandable solution. Yeah. I mean, you might have to consider the audience. So your team, for example,

and all their different expertise levels because if you have if you have some people that are more junior and you're trying to get them onto things dumping them into something that you've refactored several times until it's only a series of symbols and and things might kind of be a little bit above their it might scare them they might think that it's a monster that they want to avoid. The more concise solution is more declarative. There's less saying what's going on in individual steps. There's less that can go wrong because there's just less code. The other thing I would say, it is more dense, harder to learn.

But once you learn Fold, that concept is not just for that piece of code that you're learning. It's everywhere. You can build a complicated thing to solve this individual problem. Or you can find this global concept. You're going to have to learn about this global concept. But that learning you get to take with you. Yeah, you're going to encounter this a lot. When I learned it in college, they were teaching me to be more verbose.

So that it was more understandable, right? And they wanted everything very long names. They wanted everything very clear so that anybody could read it. And I think maybe that might have been more to the benefit of the instructors that were reading everybody's assignments. Right. They just wanted everything to be clear. But when you get into the workplace, you learn that that's not the case. Yeah. And you don't necessarily want to be verbose anymore. You want to be clear,

but you want to be concise. And that was, I think, a learning experience coming out of college for sure. You just made me think of like a pet peeve, right? What people would say, always use long descriptive variable name. And you'd be like, okay, well, what about that for loop where it's like for I, like, why isn't the I named? Yeah. Why don't I call it iterator or whatever? Like, well, we all know what the I means. Like, don't worry about the I. Okay, well, here we have 4i, 4j, 4k. Well, yeah, no, like i, j, k, those are fine. G, h, past h, like, no, don't do that.

No, then we don't understand. Yeah. Then somebody explained to me that there's actually just like a larger rule that that always use descriptive names misses, which is the length of your name should correspond to the length of its scope, which describes all these scenarios, right?

So the reason that an eye is fine in a for loop is it only exists in that little for loop. It doesn't need a long descriptive name. Its scope is very small. You're never going to be like, I have this eye here and I don't know what it means. Like, no, it's right there. Yeah.

You know what it means by the context in which it exists because that scope is so small. Yeah. Yeah. Descriptiveness is actually costing you clarity. Okay. So, what did I explain so far? Like, hopefully you understand what unfold is now and you might understand what it is for the rest of your life, right? I think there's a point at which you start, at least at my age, things start leaving your brain as they enter them. So I might now know what fold and unfold do, but I've forgotten something. I guarantee it. I guarantee something that I did know before we started this podcast is now gone.

Okay. Well, that might be a problem. It is. It's a constant problem. But it's probably something like to do with calm components or something horrible. Yeah, maybe it's something that's irrelevant. But I can bring this all back around to the core concept you asked me at the beginning. What is co-recursion?

We got that. Why is your podcast called co-recursive? How about that? That's a good question. The very dumb answer is because I was reading a book explaining some of these concepts when I decided to make a podcast and domain names are hard to find. So I just put in some concept names and came up with that. So that's kind of the throwaway answer. But an equally true answer is like, imagine that the

podcast is some sort of function and it takes into it my interests, like when I started the podcast, right? So I was interested in whatever Scala and Rust and types and functional programming. So it takes in this list and then it has the step function, which is basically me talking to people where I just pull down one of these interests, find somebody and talk to them.

And I produce an episode. If you think back to the type of the unfold, it takes in like a single thing. In this case, it's a list of my interests and then it just keeps on producing elements until it's done, right? Which is, and the elements for me are the various episodes. And it will probably never end because there must be a bug in the algorithm where like new things keep getting added to the interest. I think in the, in this example, like the interest is one giant element of things that you're interested in and you keep, you keep, it's the change, right? It's the change that,

that you're trying to make and you just keep coming out with the denominations of currency, which is the podcast. It also sounds like you just came up with a name and then really tried to figure out what the explanation was. That may also be true. Yeah. Did I answer your question? I don't know. I think I just went on a long tangent. No, I think you did. I think I learned some things. I learned some things about full. I might actually go back and look at some of my previous code. You can go back and be like, this code is all crap. It's crap. I could pull this. I think anybody who's ever written code goes and looks at things they wrote three months ago and they just look at it and disgust. And they're like, I can't believe I wrote this. Yeah, like if you haven't done that

or if you stop having that, then you're probably not learning and progressing. Yeah, so this has been fun. I mean, keep bringing me your questions. I'll keep going on rants. Oh yeah, no, I have lots of questions. Okay, I forgot the most important part. So let's validate your learning.

You came here and you were like, what is co-recursion? And why do you use that name in your podcast? So what's the answer? I think the answer is co-recursion is the, I wouldn't say so much the opposite of recursion. It's just the opposite result, right? So what goes in and what comes out is the opposite to what you would normally recur so if your recursion is turning one to many the co-recursion is turning many to one and why is your podcast name co-recursion as far as i understand it sounded cool and you liked the idea

and it wasn't taken the domain name was available and then you thought about it and came up with a reason i think that's valid yeah i mean that's completely that's completely acceptable there's nothing wrong with that yeah not every name for everything has to be a eureka moment that somebody comes up with while they're in their kitchen or their shower or something like that's the name like it can just be like i think that's cool domain's available it's very practical yeah that's true so is co-recursion. Co-recursion is very practical. All right.

That was the episode. Thanks to Don, Don McKay, for being such a good sport. Hopefully this turned out all right and me and Don can keep doing this. Maybe sometimes I'll even bring him questions. He is an expert in many things that I know nothing about. Until next time, thank you so much for listening.