Eloquent JavaScript: Chapter 7

Heat. Heat. [music] Oh. Hello. Hello. Hope you're doing okay today. Uh we'll get started here in just a second. Um but yeah, I'm uh excited to work through this project together. I have yet to look at it. Um but that's the whole point in coding in public. So we're going to do it together. Just got [music] to get the rest of my setup here working. Hope you're doing okay today. Uh if you could let me know about music volume and stuff like that, that would be great. Just want to make sure that uh yeah, that you can hear okay and stuff like that. All right, let me make sure that this is working. Okay, I think we're set now. Cool. All right, well, we will go ahead and get started here. Um, I'll switch over. Good to see you. Um, it is early morning for me. Um, we're working through Eloquin JavaScript and, uh, we've gotten to number seven, I believe it is, which is, uh, a robot project. That's all I know. so far. So, we'll see uh what happens as we go here, but hopefully you can see okay and hear okay and stuff like that. Okay. Uh well, with that said, let's go ahead and jump right in and uh we will work through this thing together. I don't know anything about it other than the fact that it's a projected by a robot. So, let's read this together. Uh I'm not sure if this is something we're going to be doing, if it's going to be like uh they're going to be holding our hand walking through this project, but uh we'll do it together, whatever it is. All right. in project chapters. I'll stop humbling you with new theory for a brief moment and instead we'll work through a program together. Okay. Well, there's our there's our answer. Uh theory is necessary to learn to program, but reading and understanding the actual programs is just as important, which is totally true. I think that's something you minimize when you're first learning is you feel like you need to know it all. And really the key is can you successfully read code? Like that's almost as helpful as anything else. It teaches you the most. like you can easily jump into open source repos and see how people are architecting things and um and then it also like is most of what you end up doing as a developer. You're reading a ton of code groing kind of what's going on, how things are working and then you write whatever you're doing. Um so totally agree and it's good that we're building this stuff in. Okay. Our project in this chapter is to build an automation, a little program that performs a task in a virtual world. Our automations will be mail delivery robot picking up and dropping off parcels. Okay, cool. Metfield. The village of Metfield isn't very big. It consists of 11 places with 14 uh roads between them. It can be described with this array of roads. Okay, I have a feeling we're going to need this. So, I do have a I do have VS Code open over here. Um, so let's paste this in here if it lets me. Oh, it's unused. Well, yes, I know. Okay. Um, I don't know what this music is. It's supposed to be like relaxing. So, tell me if it's not. Okay. Uh, the networks uh of roads in the village forms a graph. A graph is a collection of points, places in the village with lines between them, roads. This graph will be the world that our robot moves through. Uh, the array of strings isn't very easy to work with. We're interested in is the destinations that we can reach from a given place. So let's convert the list of roads to a data structure that for each place tells us which place can be reached from there. Okay. So they're going to just do this for us it looks like. But we're going to let's kind of walk through this together. We've got this function build graph that takes in the edges. The edges are just the road. So it's going to take in all these right here. Okay. And then we have a graph where we just have an empty object. Um okay. Uh so the function we have a function called add edge we have a from and a to and if from is in graph so the first thing we've passed in is in the graph then we're going to push in [music] so this is going to be yeah an object with different keys where all the values will be where those things can go to. Um yeah. Um so from uh graph from so like this key in this object. So like let's say the key is Alice Bob's Bob's [music] house. All right. So that's one trail. So this is a key and we're going to push in the two whatever [music] it happens to be. Um you'll notice we're splitting these. So it looks like we would take Alice Bob's this is the first one or Alice's house. Bob's house. This would be the from this would be the two. So it's just describing [music] the kind of connections between stuff. All right. So we've got this edge we're adding and we're taking Alice's house and the first one would be Bob's house and we're first looking here and saying does this thing exist and if it does exist then we push into it. Else we basically create it. Yeah. So we have an array where we pass that item in and we just loop over each thing and split them on this uh thing. So let's make sure that this is doing what I think it is. So it should be an object with uh keys for all the names of the places that you can be and then an array of all the places that can connect to that place you can get to that place from. Uh so let's come over here and just double check [music] that that is the case. Um let's see. Let's go ahead and console log this. And can I run this with Quoka? Let's see. Okay. So here we go. Oh, yep. Down here too. Yeah. So, it's got Alice's house, Bob's house, post office, cabin. So, those are the three places you can get to from Alice's house. So, again, what we're doing, sorry that I'm getting all these errors from biome. Let me turn this off so it's not distracting. It's like random Christmas music or something. [laughter] Okay, that's fine. All right, so let's come back over here and let's run Qua for this file. Okay. So, what we're doing again, just so this this is clear, we're passing each of these in. We're splitting it right here. So, we've got Alice's house and Bob's house. And then we've got Alice's house and cabin. Alice's house, post office. So, those are the three places you can go to. And so, Bob's house, cabin, and post office are the three places you can get you go to from Alice's house. Bob's house looks like we've only got town hall here, um, right here. But notice we've got Alice's house, too, because obviously they can go between each other here. So they're not repeating them in the opposite direction. Um Daria's house, we've got one, two there, plus whatever ones can get to her. I don't know where that one's at. Post office. Darius's house. Okay. Yeah. So one, two, those look like the only place you can get to Dario's house from. So hopefully that makes sense what we're doing. Um so they're just mapping those different connections. All right. Given an array of edges. Let me actually make sure that stuff's going okay too on YouTube. I probably should be paying attention to that. Okay, cool. Um, and let me know if you're having any trouble uh watching or audio or anything like that as well. Uh, YouTube is giving me a warning, but everything looks [music] fine. So, I'm going to assume it's okay, unless I hear otherwise. Uh, okay. So, let's keep working through this project project. Hopefully, that makes sense what we're doing. Given an array of edges, build graph creates a map object that for each node stores an array of connected nodes. We've just seen that it uses the split method to go from road strings which have the form start- end to element arrays containing the start and end as separate strings. Okay. The task. Our robot will be moving around the village. There are parcels in various places each addressed to some other place. The robot picks up parcels when it comes across them and delivers them when it arrives at their destination. This reminds me a lot of advent of code uh which you should [music] definitely do uh if you're learning JavaScript. It's fun. Uh the automation must decide at each point where to go next. It has finished its task when all parcels have been delivered. To be able to simulate this process, we must define a virtual world that can describe it. [music] This model tells us uh where the robot is and where the parcels are. When the robot has decided to move somewhere, we need to update the model to reflect the new situation. If you're thinking in terms of object-oriented programming, your first impulse might be to start defining objects for the various elements in the world. a class for the robot, one for the parcel, maybe one for the places. These could hold properties that describe their current state, such as the pile of parcels at a location, which we could change when updating the world. Okay, so they're [music] just talking through like here are some possible situations you might tend to take. This is wrong. [laughter] All right, at least it usually is. The fact that something sounds like an object does not automatically mean that it should be an object in your program. Reflexively writing classes for every concept in your application tends to leave you with a collection of inner uh connected objects [music] that each have their own internal changing state. Such programs are often hard to understand and thus easy to break. So instead, let's condense the village state down to minimal set of values that define it. [music] There's the robot's current location and the collection of undelivered parcels, each of which has a current location and a destination address. That's it. So in other words, like let's keep this thing as simple as possible and break this down. Now they're doing more object-oriented programming right now. I'm assuming maybe we'll do like um maybe not. I going to say I assume maybe we not do object-oriented program next, but maybe the whole thing will be that way. So that's fine. Um so let's read through what we're doing and kind of talk through what what they've decided. While we're at it, uh let's make it so that we don't change this state when the robot moves, but rather compute new state for this situation after the move. All right, so we've got this new class we're defining called village state. Let's actually move this thing over. So we'll come over this way. Let's get rid of this for now. All right. So we have this new class called village state. It has a constructor where we have to pass in the place [music] and the parcels that it attaches here as properties on the class on the instance of the class. Now every single village state will have this function called move and move asks a question if the row.graph this.place okay so if this exists and it includes the destination. So if it doesn't, it returns. So in other words, if we pass in a destination, but the place can't go there, then we say it doesn't work. Assuming it can go there, then we grab the [music] parcels, which are place, the items at that current location, and we loop over that array because it should have an array of parcels, and we ask if the place does not equal this place. Okay, let me track that. Okay. If the place we're if the parcel that we're at the parcel's place, so each parcel is going to have a place and the place it's supposed to go. Current place it is and the place it's supposed to go. So if the current place it is is not this place, then we return because we can't obviously move the parcel. Uh otherwise, we return the place which is the destination now and the address which is the P.S. Where's this destination coming from? Okay, it's the place we want to go to. All right, that'll make sense. And then we're going to filter if place does not equal this current address. So, um, these are the only ones we want, which we kind of already did [music] this check up here, right? P.Place equals this. Press. Oh, no, we didn't. Okay. And then we return the new village state. And this right here has two things on it. the destination and the parcels. Okay, so I think that makes sense. Um, so we're going to pass in in this once we create this class, we would then come down here and have like a first. That's fine. And we'd have a yeah, a new village state. And we're going to pass in two things. The original destination. I didn't know I had autocomplete on here. Um, so the place itself, the current place that we're looking at. over each place will have its own like instantiation of this class. So, and we'll pass in the place and then the parcels as well. So, we'll let it fill that in. But hopefully that made sense kind of walking through that together. Okay. The move method is where the action happens and this exists on every instance of the class. It first checks whether there's a road going from the current place to the destination. If not, it returns the old state since it's not a valid move. Next, the method creates a new state with the destination as the robot's new place. It also needs to create a new set of parcels. Parcels that the robot is carrying that uh are of the robot's current place. I kind of wish we would have done this ourselves without like walking through this together, but maybe it's more helpful for me to walk through and like talk through what they're saying uh in case that's difficult to to gro. Um okay. All parcels that are addressed to the new place need to be delivered. That is they need to be removed from the set of undelivered parcels. The call to map takes care of moving and then calling to filter does the delivering. Okay. So when we filter, we were saying like we've delivered to that place. Parcel objects aren't changed when they're moved but recreated. The move method gives us a new village state but leaves the old one entirely intact. Oh, okay. Interesting. Yeah, I was actually kind of curious about this. The returning a village state because you're declaring a new instance here with destination parcels. And basically what we've done is remove the one parcel we delivered and return a new one. But now we have a two different instances. So yeah, let me meant to do this before and I always forget. Okay, so it's not quite so dramatic when I change screens back and forth, right? Um I only have like 20 more minutes, so we're going to go as far as we can, but personal objects aren't changed when they're moved, but recreated as we just saw. So here we're going to pass in okay move first first move next.place place. Okay. So, here is the location and then here are all the different parcels. The place [music] the parcel is the place is the post office and the address is Alice's house. So, we're going to move that first which we've just done. And then next place, we just want to grab the the new place and then there are no more parcels. That makes sense. Okay. Okay, so move the move causes the parcel to be delivered which is reflected the next state but the initial state still describes the situation where the robot is at the post office and the parcel's undelivered. So yeah, that's what I'm curious about like why they did it this way. Um but I'm sure that's what they're about to say. Persistent uh data data structures that don't change are called immutable or persistent. They behave a lot like strings numbers and that they're in that they are who they are and stay that way rather than containing different things at different times. In JavaScript, just about everything can be changed. So, working with values that are supposed to be persistent requires some restraint. Uh there's a function called object.freeze. That's true. We I don't think we've talked about that yet in this book. That changes an object so that writing to its properties is ignored. You could use that to make sure your object aren't changed if you want to be careful. Freezing does require the computer to do some extra work. And having updates ignored is just about as likely to confuse someone as having them do the wrong thing. I usually prefer to just tell people that a given object shouldn't be messed with and hope they remember it. I kind of feel the same way. Um, like this ends up being kind of confusing to freeze an object. Um, but you can. So, uh, if you do this and you try to write to it, it doesn't change anything. So, you can see we've frozen it here. And even though we've tried to update the value, when we console log, it's still five, which is what it was originally. So, why am I going out of my my way to not change objects when the language is obviously expecting me to? because it helps me understand my programs. This is about complexity management. Again, when the object is in my system are fixed and stable things, I can consider operations on them in isolation. Moving to Alice's house from a given start state always produces the same new state. When objects change over time, that adds a whole new dimension of complexity to this kind of reasoning. So in other words, we can expect like this particular [music] instance only moves from the post office to Alice's house or whatever the two destination was um or and the state is always returned the exact same way for a small system like the one we were building in this chapter. We could handle that bit of extra complexity. But the more important limit on what kind of systems we can build is how much we can understand. Anything that makes your code easier to understand makes it possible to build a more ambitious system. Unfortunately, although understanding a system built on persistent data structures are easier, designing one, especially when your programming language isn't helpful, can be a bit harder. Thanks, JavaScript. We'll look for opportunities to use persistent data structures in this book, but we'll also be using changeable ones. Um, I think there's something really important here when you're learning, and that is you tend to think of at the beginning, you try to think of clever answers and like, oo, I could do this thing super cleverly and like compact all this, but it's really hard to read. And most developers I know, the longer you go, the more you're like, I don't care how clever this looks. Can somebody pick it up quickly and see what's going on? Are the patterns I'm picking common ones? Am I doing things kind of the normal way people do things? Um, and it's a lot of times you are that developer. You might think, oh, I designed this thing. It'll be easy to pick this thing back up, but just a few months away from code, you come back to it and you're like, what was I doing here? Like, why did I do it this way? And why did I not do it this way? So comments can help there, but most of the time if you write a clear program, you shouldn't need a bunch of comments to explain it. [music] Um, so anyhow, all right, simulation. A delivery robot looks at the world and decides in which direction it wants to move. So we can say that robot is a function that takes a village state object and returns to the name of the nearby place. Because we want robots to be able to remember things so they can make and execute plans, [music] we also pass them their memory and allow them to return a new memory. Thus, the thing a robot returns is an object containing both the direction it wants to move in and a memory value that will be given [music] to the next time it's called. Okay, so we're going to have a function called run robot. We pass in some kind [music] of state, the robot itself, and the memory. Uh, so we're going to say turn equals zero. Um, we're not okay. It's weird that they use the normal for loop here, but that's fine. If state.parals.length length equals zero. Uh, you're done in however many turns this took. Okay, so um, action robot state memory. I'm just trying to grock what's going on here without copying it over, but we might just need to do that and run it. Action, we have the robot with the state and the memory. State is state.move action direction memory. All right. So let's let's let them talk us through this because I'm not following this in the context of the program. Consider what a robot has to do to solve a given state. Must pick up all the parcels by visiting every location that has a parcel and deliver them by visiting every location to which the parcel is addressed, but only after picking up the parcel. [music] What is the dumbest strategy that could possibly work? Great question. The robot could just walk in a random direction every turn. That means with great likelihood it will eventually run into all parcels and then at some point reach the place they should have been delivered. So here we just like pick a random one and go place to place to place. Math.random returns a number between zero and one if you're not I think we've covered that before. Um so you have to multiply use a floor. So that way you're getting like the lowest value there and multiply times the array of the length. So if it's like a array with 10 spots in it, you'd multiply math out times 10 and then take the floor of that the instead of taking like 1.043 043 or whatever you would take one or instead of taking 4 point whatever. So hopefully that makes sense. Since the robot does not need to remember anything, it ignores its second argument um and omits the memory property and the returned object. So they're saying like a dumb way to do this or perhaps like a unsophisticated way to put this sophisticated robot to work. We'll first need to create a new state with some parcels. Um a static method written here by directly adding the property to the constructor is a good place to put that functionality. Okay, so here we got village estate.random where we're going to add a function. So this will randomize things um where we loop over our parcels or parcel count however many parcels we have and just randomly select addresses and move around. It looks like yeah, I would not write it this way at all, but that's fine. All right. So, we don't want any parcels to be sent from the same place that they're addressed to. For this reason, the d loop um keeps picking new places when it gets the one that equals the address. Okay, let's start with the virtual world. We don't want any person to be sent from the same place. Okay, we just read that. Let's start with the virtual world. Rone robot. So, we have a village.random and then a random robot. So, let's go back up here to this run state right here. Run robot. So [music] this is the state and the robot. We're not passing in memory for now. I'm not sure why they did this like more complex thing and then ignored it. But maybe I'm not following. So state and robot. Okay. So we've got a random robot. I'm not sure where we're getting that from. Okay. I guess right here. Um where we have whatever state we pass in and it has a direction where we use a random pick. Like this is way too [music] complex I think. Um but we basically take the road graph that we created and we pass in whatever the state is [music] and its place. So down here the state and the place would be um wait where's the random robot direction random pick. Oh it's just going to randomly select one. Yeah. So it's going to randomly select a place and that's where it's going to start. Okay. So that's what we've got here. And then we've also we're using the village state.random for the initial it's getting complex moving back and forth state. I should have copied this over instead of doing this. All right, so that one will basically randomly select a location and deliver the parcels there. All right, so we move to market town hall, move to town hall. It's done in 63 turns. So it has to go to every single location. All right, so let's copy this over just uh so we can actually see this run in real time. So I'm going to have this down here. We run the robot. We've got these two functions, random pick and random robot. All right. Finally, we're going to attach [music] this village state.random. Adding to [music] prop to constructor. It's a good I'm not sure why they're doing it this way. Like they could just write it directly on [music] here, right? Am I missing something? because they're they are attaching it to here basically. I don't know. All right. Uh so let's run this like this. Okay. So let's see how many turns. Oops. [snorts] So it's showing all the places we've moved to. It's done in 51 turns this time. Now I think if we refresh it will be different. [music] Let's see if we can rerun it because it's random, so it won't always be there. 81 turns that time. So, it just basically is randomly going to places, dropping off the packages there um in a random order. So, not the smartest way to do it, but it technically gets done. This works because we only have so many locations. Obviously, this doesn't scale, and that's usually a good place to start. You start with what is like easy to gro mentally for you, which I think this is way too complex, but that's fine. And then you kind of make it more performant after that. Okay, it takes a lot of turns, so we'll address that soon. A more pleasant perspective on the simulation. You can use run robot animation function that's available in [music] the chapter programming environment. Well, why don't we just you just tell me that was there in the first place? This runs the simulation, but instead of outputting text, it shows you the robot moving around the village map. What do we do with this? Oh, look at So, it's showing it's going to each place and dropping them off where it needs to. Nice. So, that one's 30 turns. This one might be a lot longer cuz it's just randomly going to locations. So, instead of actually going to the spot it's supposed to go to, it's just going to randomize until it happens to drop them all off. 48 turns on this one. That's why like sometimes they take longer and shorter. The way run robot run robot animation is implemented will remain a mystery for now. But after you've read the later chapters of the book, we'll discuss JavaScript integration in web browsers and you'll be able to guess how it works. All right, mail trucks route. We should be able to do a lot better than a random robot. Yeah, an easy improvement would be to take a hint from the real the way real world mail delivery works. If we find a route that passes all places in the village, the robot could run that route twice at which point it's guaranteed to be done. Here's one such route starting from the post office. All right. Alice's house, Kevin, Alice's house, Bob's house, town hall, Daria, Ernie's house. To implement the following um route, following robot, we'll need to make use of a robot memory. The robot, in other words, we're the reason we're going from here to here and then back here is because this one can deliver to Alice's house, and then Alice's house can deliver to Bob's house, etc., etc. All right. Uh, so the robot keeps the rest of the route in its memory and drops the first element every turn. All right. So, uh, route robot, we have the state and the memory. If the memory.length is zero, then the memory equals whatever that current mail route is. Okay. So, if there's nothing currently in the memory otherwise, we're going to take the direction and we'll take the first memory. Memory slice one keeps the rest of its route in it memory and drops the first element every turn. Okay. The robot is faster already. Takes a maximum of 26 turns. So, let's run this. usually less. So if it's been to a place, it knows it's been there before. And if it picks up a package, it can return there. And I think they combine this with the earlier function. Um, so this right here, they're not actually showing how they integrate that into the code because I don't think there's, but I think it's in this run robot thing. [music] This memory is connected to that if I'm understanding it right. I wish some of this was a little more connected. Anyhow, okay, it's still slightly random, but it has a memory at least at this point. Okay, so still I wouldn't really uh call blindly following a fixed route intelligent behavior. The robot could work more efficiently if adjust its behavior to the actual work that needs to be done. So in other words, it realizes I don't have a package to that place, so it doesn't go there. to do that has to be able to deliberately move toward a given parcel or toward a location where a parcel has been delivered. Doing that even when the goal is more than one way will require some kind of route finding function. The problem of finding a route uh through a path is through a graph is typical search problem. Um sorry just a sec. All right. Um, I do have to be done. So, I'm going to go ahead and just quickly kind of read through the rest of this code. I don't know. This wasn't as helpful as I thought it would be. I think mostly because I wouldn't write stuff this way, but um, and I felt like they chose like a more confusing setup by using a object-oriented programming, but maybe that's just because I'm mostly a functional programmer uh, here. But they're now they're creating this they're taking the graph the from the two. Um like they're combining different routes. If there's some work to do then go ahead and do that thing. So they're just isolating by what you can actually do. Um [music] all right I'm going to scoot down here too. Like this is where I would have started [music] is writing like a goal oriented approach. Um, so it looks like their code doesn't handle a situation where there are no work items on the worklist because we know that our graph is connected, meaning that every location can be reached from all other locations. We'll always be able to find a route between two paths and the search can't fail. Um, all right. So, we can use its memory. So, you just have like state in this particular robot. So, let's run this last one. that I probably do need to go. Um, so it does it in like the minimal amount of turns. Okay. I just feel like this whole setup was way too complex. Like it didn't you could have broken a lot of this out instead of having multiple if statements and else statements and like I would have broken a lot of this into single functions. But anyhow, measuring a robot. So it looks like we've got a couple exercises we can run ourselves if we want to as well. So you can compare different robots in their memory. I think if I were to do this chapter again, I would kind of have read it ahead of time and then I would just do my own thing with you um instead of reading through this because I don't know that this was like a very normal way of doing this. But again, maybe it's, you know, this person's way smarter than I am. So anyhow, hopefully you found that helpful. Um yeah, thanks so much for following along today and uh yeah, I will catch you in the next one uh when we do chapter eight, whenever that will be. probably maybe sometime next week, I think. Um, so we'll shoot for that at least. All right, thanks so much. I'll catch you in the next one and uh, happy coding.