CHRIS: Welcome to the Elixir Outlaws hallway track of the elixir community. CHRIS: Coming in hot. AMOS: Oh man. So, uh, I found, uh, sucky bug in Absynth the other day. CHRIS: What was it? Tell me about it. I want to know. AMOS: Okay. So, uh, if you have a few attributes in a row, and I know it works with a backslash at the end of it, so you get quite a bit of escaping going on. And if it's the last attribute that has like a backslash at the end of it, um, which turns into like, I guess there's like four back slashes or whatever - it parses just fine. Uh, the graph QL query, if the, if an attribute before that has backsplashes, then it airs out, even with like the exact same code and only, also only if the attributes are on the same line. Like if you have no return after your comma. CHRIS: Interesting. Oh, no. So what did you do? AMOS: Uh, well, I wrote test. CHRIS: As you do. AMOS: Yeah. Put in a, put in a bug report and, um, I don't really know, uh, leakserr leaks or right. Is that what it's called? L E X E R the Erling lexer Erlang lexer. Yeah. Yeah. So I don't really know it very well. Um, leakser, yeah, just enough to be a pain, just, just enough to like kind of follow what's going on. Um, somebody from the Kansas city elixir group is like, it's probably one of these four lines. This is the second time I mentioned them. So I'm just advertising for them. Uh, so I, uh, his name's Shawn, uh, I forget his last name. Um, but thanks, Sean. So he pointed out kind of where it would be. And I, I dug in a little to the documentation and it may not be the most perfect fix in the world, but it ended up that I just needed to add a backslash character. CHRIS: Oh. To escape something. AMOS: to the lexer. Yeah. There's, there's a poll request out there on absence. Um, no real feedback yet, but we'll see, they may come in and be like, that's not how it should be fixed, but at least it'll point somebody in the right direction. Hopefully. So, yeah. Yeah, that was cool. And it was, it was causing the current client some pain. Uh, I actually had decided that I would try to just bandaid it and put things on different lines, but I I've found out that you can throw some stuff into a field and, and like, cause I was just splitting on commas and adding, adding a return in there. And then if you throw a comment into the middle of the field, of course it blows everything up. Which I knew would, would happen, but was trying to figure out a way around it. And without using a real parser, that's pretty difficult just because you have to like match quotes and raw and stuff. AMOS: Yeah. Yeah. The, the parsing rules need some amount of history. CHRIS: Right, right. They need state. AMOS: And so there's not like a, there's not a quick fix there, so yeah. I moved on. CHRIS: But you've acknowledged the problem, which I think is the important part. AMOS: Yeah. I would really like to make property tests for the parser and put in like any valid attributes string, including escape characters and stuff like that. CHRIS: I'm surprised they don't have that. Actually. AMOS: I did not see it anywhere in there. CHRIS: Decent amount of work. Um, I think, I mean, but there's probably, I mean, the grammar is probably already predefined by the graph QL spec, right? Like typically for specs like that, they'll give you the BNF rules, which probably pretty reasonably translate into, uh, leaks and yeck, or whatever the, the, the, the early compiler, uh, thingy is called or the parser generator. AMOS: I think it's yak, Y E C C and it's based off ofThe C parser, you're not parser a parser generator. CHRIS: It's actually a parser generator, a streamer. AMOS: That was a perfect voice that you use there. CHRIS: That's my internet voice. Well, actually it's a parser generator. AMOS: Oh, I think that might be a show title right there. That's my internet voice. CHRIS: It's too early in the show. We can't pick a show title already. It has to be later in the show. There's a five minute rule. It has to be after the first five minutes. AMOS: Oh man. So that's what I I've been up to chasing this absent thing. Um, and I don't know a whole lot about absence of very, um, cursory knowledge of it. I've used it just a little bit. CHRIS: There's a lot of stuff in absence. When you say you don't know much about it, do you mean that you don't know much about graph QL generally? AMOS: Yeah. Yeah. Generally, I, I, I know a little bit, um, but not, not a ton. I've, I've written a few of the back end pieces mutations and stuff like that, but I've needed. But as far as the full, um, I want to call graph QL is like a, it's a pretty, pretty big system. Um, but as far as the whole system goes, there's a lot of stuff in there. Yeah. I don't really, I don't know. CHRIS: It's, it's, it's, uh, it's a big boi. There's a lot of stuff inside of that, inside of that, uh, that document. Yeah. Yeah. AMOS: Uh, I, you know, I've heard some people recently, um, suggesting to use graph QL for embedded development and pulling data from multiple sensors and, and organizing it together. Uh, so am I, that's the way the team is that I'm, I'm working on the, the way they're using it. And I had never, ever really tried it that way before. CHRIS: Sorry. I had to grab this. I had to get a seltzer, AMOS: A seltzer, or you, are you European? CHRIS: No, this is like, off-brand L'croCH. AMOS: Oh, I like l'croCH. CHRIS: Yeah. AMOS: My son was just talking about that the other day. He said he went in to have three dogs. He wanted to name him. Sprite, Dr. Pepper and L'coCH CHRIS: Coming in hot this week. Yeah. CHRIS: Sorry. It was really working. It was really working. Yeah. AMOS: I have, uh, four bottles of scotch in here. I can just take a poll off of one of them. We'll see where we go. CHRIS: I really even it out. AMOS: So I, I had, uh, at a locker at a, at a local tasting room here. And since I'm moving, I had to close it out and I haven't really been in there in like four months. And I'm in a scotch club that every quarter they put a bottle of scotch in there. Right. And I don't, I don't drink enough to drink a bottle of scotch, even in a quarter, unless it's at my house. Cause at sometimes right after putting children to bed. You just want alcohol - Do we got any of that rubbing alcohol? CHRIS: Depends on how many magic tree house books you had to read. AMOS: We're past that age now it's just the fight to no, it's actually bedtime. Now. That'd be fair. Most of the time I'm fighting my kids when they're trying to stay up, they're staying up and reading books. Right. So you can't complain a whole lot right that they're, reading books. Uh, I remember my oldest would like pretend to be asleep for an hour. I don't know how the heck you can lay still for an entire hour and then not fall asleep, but maybe that's my age. And then I would catch her reading a book like an hour after bedtime. Her light would come on and she'd start reading. CHRIS: My daughter is very similar to that. She's about she's six and she'll lay in bed and then she'll turn the light back on and she'll keep reading and stuff like that. And, um, yeah, it's bad. I mean, I feel some amount, I don't know. It's, it's a tough parent parenting decision of, do I tell them that they can't do this or do I, Uh, do I need to like put some limits on this in keeping with tradition when Anna's not here? It's just full on dad cast. AMOS: Let's talk, let's talk about parenting. Um, and our borderline alcoholism. CHRIS: Oh man. I mean, so how are you finding, um, graph QL. to be like, do you feel like that's a good solution to the problems that you're trying to work on? Do you feel like it was a good fit? Um, do you like using it? What are the things that you've run into so far that you are into? AMOS: So that's hard for me to answer because I am so little into that part of the system that, that I'm almost, uh, I almost never touch it. Like I, I don't really, the front end is all kind of one person doing some reacts. I don't, I don't know anything about it really haven't touched it. Um, I mean, I've done front end work multiple times before, but not on this project. Um, and so, so really it's the graph QL part is pretty abstracted away from me. Uh, I mean, I liked that writing mutation is, is pretty simple, but as far as how that works from top to bottom I'm, I don't know enough yet to, to say, um, in some ways in looking at it from, from the perspective that I've seen it, I'm not seeing a ton of the advantages and it feels very over-engineered. Um, but, but again, I'm not utilizing it enough to realize the benefits because I'm not writing the part that's actually using the graph QL clients or whatever it needs to be talking with that thing. Right. Um, but the people who are doing that portion seem to really appreciate the power that it gives them. So to me, it's, it's still worth putting in that, that, and instead of them asking me to write custom stuff constantly, it's kind of helpful. CHRIS: That's my problem with rest in general is everything becomes, one-off like, are all of these end points become one-off end points that have this massive payload of things that have this specific business logic behind them? I mean, they become, they become so much less about, Completing crud and rest here, but to become so much less about resources and so much more about arbitrary RPC calls made over HTTP to An end point, uh, where you get some payload that's not specified very well back. And there's all these sort of ad hoc, uh, things that you put on top of, of resting points like Jason APIs, or swagger, all these like pseudo conventions to try to make these APIs documenting and try to explain what they do. And all of it sucks. All of it is not fun. Um, and, and I've never used a rest API where I thought everybody was getting the best experience that they could have. It's like a mediocre experience across every single client, across every developer who has to use that thing. And you have to write all the dumb clients for these things. Like I, if I never write another HTTP client, as long as I live, it'll be too soon. I don't want to have to care about timeouts for all this stuff. And I don't want to build circuit breakers into it, and I don't want to build caching into it. And I don't want to build like back off into it. I'm so sick of writing clients, but then you have to maintain and keep up to date with all these endpoints and that pull back and go, ah, it's just a giant pain. It's a waste of time. AMOS: And everybody wants a slightly different piece of data set and then they want it all in one call if they can get it. So I mean that, that power of graph QL, I definitely see. And it's, it's a far cry from soap. CHRIS: Well, there's so many good. There were so many good ideas and soap. I mean, soap was one of these things that failed because of implementation and not because it had, well, it had a couple of fundamentally bad ideas inside of there. And it grew to encompass a whole lot more things than it ever needed to really encompass. But there's lots of very good ideas at the heart of soap. Self-documenting APIs. That's a huge one. You want self-documenting APIs. AMOS: I tried to do that with rest APIs in Jason API, like you said, right? So that you could request back like an example object or something like that. Right. CHRIS: Um, you want clients that are smart out of the box and like, you don't want to have to generate those things. You just, or you don't want to have to write those things rather. Like it would be nice to just be able to generate clients that behave in a specific way that have specific configurable tuneable fields, but that have trade-offs that, that have characteristics about them that you can opt into. So, um, for instance, being able to say, all clients do back off and this is how they do back off and here's the jitter and here's how it works. And here's how many failed requests we'll go through and that just built it. And then you can like tune it to make sense for your application. Um, that's a huge benefit, you know, there's, there's all these sorts of things that actually were make coordination services between systems useful and easy to reason about, I don't know. I, I think that's, I think that's a major point and graph QL is favor. Um, because you can start to reason about what is this thing going to return to me, it's introspectable, you can pull down, you know, you can hit that, uh, whatever the, the, the metadata end point is for our graph QL service and retrieve all the type information. So you could theoretically construct a client, uh, from that type information. Um, it doesn't do it. Doesn't go as far as to include back-off logic, retry logic, uh, circuit breakers. Like you have still have to build all that into the client, but for a lot of things, grab fuel handles a lot of the self-documenting stuff. A lot of the, the type algebra is a lot of checking to make sure you've rippling back stuff, uh, correctly. And it handles the problems of, I just don't want to request this many fields and have an, you know, expand my, the blob of data. I need to send over the network. I want faster payloads or whatever. AMOS: I, I do. I mean, speaking of fast, really, like I do worry about it seems like graph QL could be pretty abused by pulling back, like pull back everything in the entire system. Uh, and. I have a tendency in the past to have seen how other APIs are being used and people really do want all their data in one call and I get that, but, but that can be really hard in a system and graph QL really gives them that ability to a point right now. Now there are things in there that, that mitigate that. Um, but it, it just, then people are like, well, why can't I do this? Why can't you just back that time out off of just a little bit, so I can get that one more piece of data that I need. So there's, there's that slippery slope, because the cost of adding that, um, program programmer time-wise is, is so little that people expect it to be able to do more. So it's like nearly too powerful, CHRIS: Right? Well, yeah, you practically need a query planner for some of these things that some of the requests that people want to make to graph QL points. I've definitely seen that in different clients, you know, they're requesting, I want this user, all this data about the user, and then I want their followers, their followers, followers, and their followers, followers, followers, and then get all their names of those people. And then, you know what I mean? It's like, you just expands without bound. If, when you give people power to do that, um, there was a really good paper that came out recently and I'll find it. I think it was covered on the morning paper about detecting complex graph QL queries. So, uh, that's a good read and I'll find that and put that in the show notes. AMOS: Wait, what's the morning paper. CHRIS: Oh, you don't know about the morning paper? No. Oh yeah. I did that thing that I hate when people do when the hipster, I was that feign surprise that you, AMOS: well, actually, CHRIS: Well, actually, uh, the morning paper is a great website. There's all kinds of, write-ups about different papers. I can't believe you don't know about that. AMOS: You see, you kind of sound like a Muppet. CHRIS: Yeah. It's, it's transitioning between, um, between Muppet and and internet. AMOS: Oh man. Okay. So you're gonna have to send me a link to the morning paper. CHRIS: I'm sending you a link to the morning paper right now. Yay. Uh, the morning paper is fantastic. It's probably the best thing you can put in your inbox every morning. And, uh, it's by a guy named Adrian Collier and, uh, he just takes papers and does write-ups on them that are in very human readable. Uh, very nice sort of like cliff, almost like cliff notes to say their cliff notes is almost a little bit demeaning to the work that he's doing. He breaks these papers down and explains them in context of other papers and explains them in context of other sources. And he makes all this stuff really, really, uh, accessible. Um, and it's, it's a fantastic, fantastic resource. Um, just totally check it out and, uh, subscribe to it. AMOS: That means I have to read less papers. Cause right now I read a paper and then I got to go read 10 more to figure out that paper and then, then read five off of each of those. And by the time I read all the papers about it, I'm like the hell was that first paper. I don't even remember right. That, and I never remember what the papers are. I start telling people, Oh yeah, I read this paper and it was about this. And, and they were like, what did, what's the name of it? I don't know. CHRIS: Somebody gave me a great piece of advice when I started reading a lot of papers. And they said, you, the one key thing to keep in mind when you read papers that are all sort of about a specific topic is that these papers are part of a bigger, ongoing conversation that a very small group of people is having. And this is the official way that they have a communication with each other. Like this is how they hash out ideas and how they have a discussion. And so you often need to look at the references and figure out what context you're missing, because you're probably missing an important part of the conversation, the overall conversation about this topic. Um, so, you know, for me, when I read these distributed systems papers, you often have to like find the references and go back a bit to understand what they're talking about, why they're talking about things, you know, assumptions that they're making, uh, because they expect to know that stuff as part of the larger ongoing conversation, AMOS: Right? They expect that you've read some paper somewhere about X that they're utilizing. Right? CHRIS: Well, because at the end of the day, The the paper isn't for you, the paper is as a part of this bigger conversation. So you have to be aware of it. You can't just drop into the middle of the conversation and then start to understand what all is going on. And to start to have really have informed opinions about it, because you're not aware of what else is happening. What other things have been said, what other discoveries have people made? What other context is there AMOS: Or that kind of stuff? Oh, it's like logging IRC in the middle of the conversation. Yes. It's exactly like that, man. If they only had a forum, Chris. CHRIS: You're out of your element, Donny, you're like a child who just wanders into the future. AMOS: The great part of this is nobody knows exactly what we're talking about here. When we talk about IRC and forums. So I think we should let that go and just let people wonder about it. Yeah. CHRIS: But yeah, that's a good that's, that's always useful. Well, I'm glad that you're, I'm glad your, um, your graph QL, you're solving your graph. QL problem. AMOS: Yeah. Yeah. I mean, I still don't understand the full thing, but that's, that's the great thing I find about open source and solving a little problem. If you have like a little bug like this, you don't have to necessarily know everything in order to solve a problem. Now it might help you. It might help you a lot. If you understand the full system and maybe somebody comes in and sees my fix and says, Oh, that's not actually how we should probably fix it because of this other thing in the system that I just don't know about. Right. But it gets the conversation going. And if, if not, Hey, great. I might just say, have saved a lot of people a lot of time by adding a character. Now, it took me all day to figure out that I needed to add that character, but Hey, you can contribute to open source without having to know everything. So get out there and do it. Cause you will learn. That's where you learn everything. Right. Oh man. I didn't mean to go into that with the lesson. On, on contributing, but, uh, man, what else is going on? CHRIS: Um, you want to talk about purely functional data structures? AMOS: No, I hate this book. CHRIS: Why do you hate that book? So good. AMOS: Cause I, I, I still am not quite understanding this amateurize time thing. I really do think that we should do a Screen cast of, of, uh, exercise five one. CHRIS: Okay. So for, for reference, you leaving out a lot of context. I realize that this conversation is really just for you and I, but there are also people on the internet who listened to us have this conversation. So for their benefit, I think you ought to explain what you're talking about. AMOS: Okay. So, uh, a long time ago we talked about how we were going to do an episode on purely functional data structures because the book came up in conversation and uh, we really want to read it. It has been a difficult read for me. Um, I think that I'm, I'm missing some, some fundamental, uh, things in here that the book assumes that you have or if it's not assuming, uh, it's just not explaining in a way that I quite get it. So it's taking way longer for us to get, to read this book or to, to talk about this book than I expected. I thought, Oh yeah. Get the book in mid June. And at the end of June, we'll we'll do an episode on it. Yeah. Not for me. Yeah. I don't feel so bad because whenever I had dinner with James, he was like friends with Chris said, yeah, James Edward Gray friend of the show. Uh, when, when James said that, you know, when you said side on the show, Chris, that this is a book that you keep on the shelf and that it's good reference. James is like the hell is he talking about That book is hard. It's not just me. I'm not dumb. I just am missing something. Um, okay. So, so the exercise five when we were talking about amateurize time and the two different methods, uh, I call it, I called it the farmers method, the bankers method. There's a long story behind that. So, uh, we'll do that some other time. CHRIS: Um, so there's, there's the, the bankers method and the physicist method, this myth bankers and physicists, bankers, and physicists. I'm gonna, I'm gonna let you, but let me, AMOS: Um, let me, let me finish, CHRIS: Um, um, title of the show anyway. We're talking about amateurize time, which is a way of modeling, uh, the time costs of a data structure slash algorithm, uh, that is a little bit different than big O notation or, or as we would say, uh, as some tonic time. AMOS: So, so for me it feels like, you know, big O notation is more about an individual function and how long that takes and in reading it, amateurize time is more about the overall all of the functions time, right? The possible things that you can do with this data structure, like an, a rating for the whole data structure and all of its functions. Right? Right. So Instead of saying like inserts big O of in and, um, Uh, pop is big, Oh one instead you would say, Hey, this, this entire data structure is, I dunno, five. Right? Right. CHRIS: So with the asymptotic time, ask them, ask them tonic acid, tonic time. You would, uh, you're what you're measuring is worst case scenario. That's this is the thing that many of us who are familiar with big O uh, who learned about data structures and algorithms. That's, that's how we talk about things is worst case time. AMOS: And a lot of times, just for people who haven't done, this is That you're looking at how many Comparisons you have to go through frequently. That's one of the things. So it's like if you have to step through a four loop to go over an entire list, right. It's big O of N, if you have to do that, like a list of lists, then it's N squared or N times N, CHRIS: And it's, and that's the worst case because if you have a linked list, meaning you start at the beginning and you always have to diverse all the way through the beginning to the end. Uh, the worst case scenario in terms of operations that you need to do is in operations. Where in is the number of elements in the list. Uh, this is, and that's, that's how you would find stuff, right? There's other ways to solve a searching problem, let's say, but if you have a list, if that's the data structure you've chosen to use, then your worst cases Oh. Event. And like you say, if there's lists of lists and we need to find something inside of the deeper list, then you know, and then it changes the complexity in some way, right. Exponentially, right. Well, yeah. In some way, depending on whatever the structures are, depending on the algorithm using plus the data structure you're using, we'll tell you how, what the worst case scenario is. And that's often what we're using to determine, uh, to measure data structures against each other, because that's, you know, there's, there's math behind that. Um, we can, it, it starts to make, it's an easy way. It's an easy way to talk about, uh, data structures. Now this presents a lot of problems when you have immutable data structures, because immutability by necessity means that we have to copy things, right. We cannot mutate it. We can't go into the, you know, you can't, if you have an array, you can't just go into the middle of it and change things, uh, at that point in memory and maintain immutability. AMOS: Since, since it's implemented as a linked list in, in functional languages, If you wanted to change something in the middle, you actually have to copy everything all the way back to the Beginning to point to that one in the middle, and then the one . In the middle complaint to the old copy of everything after it. So you only have to copy the first part of it, right? CHRIS: Well, at bare minimum, you have to copy everything, right? So that's the real takeaway is that the bare minimum, you know, if you do it in the most naive way possible, you copy everything changing. Just one, just changing, just the element you want to change. Now, if you want to optimize that. And one of the ways you can do that is by creating a persistent data structures and these data structures, aren't persistent in the sense that they're persistent to a database, which is often how we use the word persistent these days. But what it means is they're persistent in memory. You can copy them, but reference the old value still, or the old utilize, the old reference, I should say, and see the original data before it was changed because you're not actually changing it. You're just creating a new version of a new reference, which happens to point to some of the old data. So that's using a concept called structural sharing. You're you're sharing pieces of data in order to craft new data structures. So in your example, with the list, you need to copy all the, the elements leading up to the list, but all the old elements after the list, you can change, or rather you don't have to change. You can just have your pointer and your linked list, point to the old element from the original list. And it shares those structures and you don't have to pay the cost of copying all the other stuff. So you don't, you, you save yourself on like memory and that kind of stuff. But what this means is that in immutable data structures, often our worst case scenario, uh, the worst case scenario times for immutable data structures and algorithms is much worse than with the mutable variance of these data structures, right? AMOS: Why would you want to use these? CHRIS: I'm so glad you asked that and we, but this is why high-performance, you know, languages like, uh, I would, I would lump like rust and I would lump, uh, definitely, uh, pony Lang, which is a really, really interesting language. And people should check it out. It has a lot of really cool stuff in there. Also the worst name for a language ever, but, uh, you know, pony lang really cool, but it has, it uses, it uses mutable data all over the place, because that's the thing that you need at really, really high performance shooting levels AMOS: You think that this is a worst name than like C plus plus as far as Googling goes, It's pretty rough. Sorry. Anyway, I digress. CHRIS: So, so often we use these worst case scenarios and immutable data structures just perform worse in a worst case, uh, in worst cases, this isn't always true, but often, uh, because we do all this extra copying, we have to go through these lists in this way. We end up in worse off scenarios. However, Ima tries time is not the ER, sorry, asymptotic time is not the only way to look at data structures. And in fact, a potentially better way, uh, depending on who you talk to, uh, or a more realistic way to look at them is called ameturize time. And the idea, the fundamental idea of ametruize time is that it takes into account all of the different operations that you actually are performing on this data structure and gives you back a much more holistic picture of how the data, the structure performs under what I would refer to as like a more real world scenario. And you do this, there's a couple of different ways to do this. Um, but they basically involve applying, uh, incrementing some sort of credit or counter, and then decorating some sort of credit or counter, depending on the operation that you're doing. And you can use that counter to determine what the cost is of any given operation. AMOS: So, um, let's, let's say that you have some foo data structure, uh, and you write to it and it costs, well, it normally I'm just going to throw a stupid number. It, it takes one to insert, right. And it takes any time you want to read the data structure it takes n, right. Okay. Or the size of the data structure. Right. So, so, and when you insert, you would get some kind of credit because it's fast, right? Is that? CHRIS: Well, so let's, let's talk specifically about, um, about one of the two methods, there's two different methods that are used to, to model ameturize time. One is called the banker's method, which involves using a system of credits and debits and the act. And often the credits and debits have to do with the location in the data structure that you're placing the element, et cetera. Uh, and then there's the physicist method. The physicist method is based on this kind of concept of, uh, of potential energy, right? So the idea that, you know, if you raise an object up a certain height that increases its potential energy, and that's kind of what is being modeled when you use the physicist method with ameturize time. So let's take a list AMOS: That's a good analogy. Thank you. CHRIS: Did that make, did that help that make more sense a little bit? AMOS: I, I don't think. It helped me understand why it's called that. And, uh, and might have helped me a little bit in coming up with how to decide that potential energy equation, but right. Uh, but I still am not quite sure how to pick it, so let's, let's keep going. CHRIS: Well, so what you're doing with the physicists method is you're basically picking a potential, a potential energy function, and each operation, uh, changes that potential energy. So let's pick a list, right. Um, inserting into a list is, Oh, one, a lot of linked list putting something in. Let's just be specific about what we're saying, the head, putting something like colonizing onto a list is, Oh one, right? Uh, because it's, you're putting it on the head of the list. So it's very fast to get things, to, to get things from the head of the list, either inserting or getting things off the list, it's very expensive or linear time, uh, asymptotic time to get things at the end of the list, right? No matter how, AMOS: How many things are in the list, every time you insert, it takes the exact same amount of time. Oh one. Yeah. Right. CHRIS: Well, if you model this in, uh, if you model this with the physicist method, what we might do is we would say that the insert is, Oh one, but it increases the potential energy or the, the potential time cost by one. So every time that we actually run through that, every time we insert something, we're increasing the potential by one, if we want to pop from the, the head of the list and like take the element off, then that's an Oh one operation and it reduces the potential energy by one. But then if we want to find something in the list, then what we can do is we can say that it is the cost of the potential energy. So the potential energy costs is what, because if you can think about it, you have to run through the whole list. Right. But the list is only as big as the potential energy of the list, right? So amateurize costs, it's actually based on whatever that potential function is. And there's more math involved. Like you can, uh, you can model like A-list is kind of a weird example, but you can model different data structures this way. And you can determine that. Well, in fact, uh, amateurize time, there's not really many operations that need to take place in order to search a list or search these data structures. And when you look at amortize time, what you end up finding out is like one that it provides a much more realistic view of the world. Uh, but two, you can open yourself up to much more interesting design problems and you can design algorithms that have better amateurize times, which still, which means that they perform well in a theoretical sense, at least, uh, compared to their, you know, mutable, um, uh, asymptotic time counterparts. Does that make sense? Where this gets really, really, really fascinating. It's like, once you understand these and the math is a little bit interesting, like it's really basic algebra actually. Uh, and so it's, you know, it's pretty reasonable To like kind of walk through and see what they're doing with the algebra. Like most things in programming, this is tricky in, in concept, right? Like you have to, you have to figure out how to model this in your head, but once you can hold the model in your head, it actually does make sense, like in it. And then you're sort of like, Oh, okay. Yeah. Then the math actually just kind of works out, but learning how to model it in your head is what's hard. AMOS: All right. So my, my biggest thing that when I'm reading this book is how so, so that potential energy function is called fee, right. Or five or however you want to say it. My friends says it's pronounced fee, um, fee. So how do you choose fee? How do you choose the potential energy function? Right. And that's where I keep running into like great. They showed me what they chose in the book, but how do I decide what that is? And maybe it's further in the book, but it's stressing me out where I am in the book. Um, and I started the book over thinking, I miss something multiple times, which is why I've only made it to like page 50. But, um, so, so how do you decide where to choose that? Because it seems like I could get very different amateurize times, depending on what fee I choose. Right. So if I get very different amateurize times there has to be a proper way of choosing this, or we're just bullshitting ourselves here. And the numbers don't mean anything because I chose one fee and you would choose a different one and we would come up with different, different numbers, I guess. Right. CHRIS: So I think you have to look at your data structure, number one, and then figure out what it is, what operations are moving, those potential energies and how they're moving those potential energies. Right. You have to think about like enlist example. You have to think about the fact that Well, when I add something it's moving that potential for these Other operations up, but because Yeah, if you just pick it arbitrarily or pick something that's nonsensical, then it doesn't Then yeah. You you've you've, you haven't gotten any value out of that. Um, but I think, you know, if you can, uh, if you can figure that stuff out, then it opens up this whole design space to be able to think about other Ways of constructing data structures. And honestly, too, to some degree, this stuff is, it's very, very interesting. And it gets very, very interesting when you start talking about laziness because laziness by its nature, doesn't always, it interacts very, in very, very interesting ways with your potential energy function. Let's say, because if you're not actually creating the data, you know, it didn't really move the, it didn't actually move the potential energy. Right. Great. Uh, so there's very fascinating kind of interactions with laziness. But the one thing to keep in mind through this book is that you should seek to understand these things and you should seek to understand how they work with laziness and, and those things are good to understand on their own, but all of that discussion about amateurize time about modeling these functions about laziness, et cetera, they're all justification. They're all used to justify the rest of the book, right? Like he's this, these are his proofs on why his immutable purely functional data structures are worthwhile and why they should be taken seriously. He's just got two to three chapters worth of, you know, of context building and justification for why his stuff matters and why it works. AMOS: But I feel like I really need to, I really need to understand that part, that justification before I move forward, otherwise I've, I, I'm not getting it. CHRIS: Right. Sure. And that's fair. And I think you should, you should learn about those things for your own edification, but I also want to encourage people, like if, if this math-y stuff is less appealing, I don't want to say that you can skip it because it's good stuff to understand, but you can jump to the back and find the data structure you need and build that data structure, because it is, he's basically rationalized for you already in three chapters, in the three chapters prior why his data structure is worth considering and his implementation of it works and it is fast and it et cetera, et cetera, AMOS: The computer science scientists part of me is like, Hey, I really want to know how to do this. Because when I look at two different data structures, I want to figure out the inventory as time to before I pick which one I'm going to use or anything like that. And then the pragmatist in me is like, just freaking pick one, move on. And if, and we can CHRIS: Hash or a map try that is the, that's the correct data structure. Ah, It's a finger tree or a hash RA map try. So it's, it's one of the two, AMOS: I don't need to read the book, just put that away. We'll move on. CHRIS: Both of which not covered in that book by the way. AMOS: Which book are they covering? CHRIS: Well, hash Ray map tries. I mean the, the original Bagwell, Uh, there, those are just papers, but they weren't, uh, They weren't built with persistence or immutability in mind. Yeah. And, uh, I mean, it was rich Hickey. No, it was closure that took those, those, uh, Bagwell papers and made them immutable and persistent. AMOS: And then everybody's just copied those since then. And if you're looking hash array map, try up on the internet, it's often referred to by the acronym Hale much easier. Hey, hampt, hint, it's much easier to type into Google and you'll probably find it. CHRIS: But I mean, Erling, a bunch of Erling structures are based on hazard maps. Right? AMOS: look how smart, rich hickie is. He's really, really, yeah. With kids, CHRIS: The kids call it thought-leading, AMOS: He's a thought leader. CHRIS: It is. But yeah, those data structures, I mean, as far as I know, I think people have taken those data structures out of closure And then publish them like since then. Yeah. Yeah. AMOS: That's I I've, that was my impression when reading about it too. I mean, I don't, again, this is, this is a lot of, this is new stuff to me, like within the last year, two years. Um, so I, I might be a little late on this train, uh, but I'm, I'm super excited. I don't know. I don't even know what else to say about it. CHRIS: Well spend some time learning about amateurize time. And then if you get too frustrated, you can move on a little bit and then come Back to it. AMOS: I really do think that, um, sitting down and so, so the 5.1 exercises is implement a version of DQ and then prove that each operation takes big O one amateurize time using the potential function, absolute value of minus R. CHRIS: And you want to do this as a, as a, like a screencast. You think we should pair together and screencast it and then put it on the internet for people to judge us. AMOS: Yeah, I do my, I mean, we already do a podcast. We have put ourselves out there to be judged. And CHRIS: Given this difference between people judging the way that I talk and judging Our intelligence, AMOS: That's the same thing. Uh, I mean, we don't have to put our faces on there. At least that'll help Throw some code up AMOS: And, and implement this thing in elixir. And you can, maybe we can maybe just show how to do it. And we could probably even use some property testing, prove that our DQ works. We could probably do this. This could be a whole fun thing, a whole thing. Yeah. And then just throw it up for fun. And I think, I think going to the exercise and showing the amateurize time and how we come up with that after we implement it, uh, could be really beneficial, but at least for me, so maybe it'll help some other people out too. Okay. All right. I mean, I don't know when we're going to do that. My life is pretty much crazy until September and with the house moving and everything. So we'll see how that goes. The good thing is I won't have any distractions because all of our stuff will be packed. So I'll have plenty of, maybe I'll have plenty of time for us to sit down and do this coming up soon. CHRIS: Hey, there you go. I'm gonna have an office soon. AMOS: Sweet. So you're moving out of the house? CHRIS: no, I'm not moving out of the house, but, um, uh, we I've been building, like I've been building, I've been paying good currency to build me an office downstairs. Oh yeah. All that construction that we've had over the last few episodes in the background. It should be over now. Sweet. It's done later today. Yup. AMOS: Nice. Congratulations. CHRIS: I'm so excited. AMOS: I know that's like a big, big deal when, when construction is finished, feels so good. Feels so good. CHRIS: Well, congratulations. Oh, is there anything else that we should hit up before we go? Or we were supposed to talk about this a whole short maps, RFC proposal thing, but I don't want, yeah, I don't, I don't know enough. I don't have much of an opinion either way on that at this point. CHRIS: I don't have well formed thoughts about it. Yeah. There was a whole, there was a whole thing on the forum about adding a adding features to maps, to powder match on maps that are similar to JavaScript. That's led to just some thoughts about RFCs, but maybe we'll save it for another show. Yeah. Yeah. Maybe give the community a little time to talk about maybe we should put a link to, to that discussion. AMOS: People will find it if they want CHRIS: LinkedIn. Tell me I don't need any more people talking in their leaks. Yes. Hell Yeah. We've had so many, uh, new words today. Yeah. The word of the day is hampt ham. AMOS: The kids are calling it hampting. AMOS: When you are using a hampt it's hampting actually it's uh, a hash has arrived match try, but uh, CHRIS: It's not try it's tree, uh, in the original Greek. AMOS: Oh man. Well, I think, uh, I probably shouldn't get, get back to trying to move my house. All right. CHRIS: How would you think we've given, uh, given, given them enough? Speaker 3: I think we've given them enough. We've helped them. We probably giving people too much, uh, hope not. You want to leave them wanting more? Alright. So that's it, everybody. Uh, there's going to be some really cool stuff next week there. Now you can want some more. Bye!