 We're learning how to program, so the class is about, and it's based on modeling. So two questions I want to look at, what is modeling, and how is programming an example. I'm really going to take a sort of extreme view, which is more than you might see in some treatments, that programming, the essence of programming, really is all about modeling. You know, if I'm completely honest and I try to imagine it from a fresh perspective, I would probably think modeling is what Heidi Klum does. I don't know, many guy, red pit, I don't know. I saw him next to perfume in the paper the other day, I guess that's modeling. What else? Lionel trains, model trains, model planes. That's obviously modeling. Modeling clay, modeling. All things that we will say that's what modeling is, I want to add programming to the list. So overall, we're talking about the elements of a model, reality. And reality doesn't actually have to be real, that's why I put it in quotes. It's just the thing that we are making a model of that could be just about anything. We're going to focus on discrete models, there can be models that don't have this, but usually there's some objects and rules of behavior that govern what happens. And it's easy to think about this as being like a game. You have cards and you can only put a red card on a black card and vice versa, whatever it is. This is the stuff of the model. And then, crucially, you have a mapping between one and two. A mapping between reality states getting mapped to model states. Okay, so that's the real key. And so we can look at, you know, we have a real train. We have the road runner sitting outside Placidus, getting ready to head to Santa Fe in my model. When I had trains, when I had Lionel trains, I had O-Gauge trains which were scaled down 48 to 1. So 4 feet, 1 inch. And they have the rules of behavior, how they interact. Lionel trains are all electric, they rolled down the tracks, they did whatever they did. Then we have the mapping. And in the case of the trains, the mapping superficially seemed to just be a spatial scaling down. It turns out that they're not really literally just 1 to 48 in all ways because it wouldn't really work. The little hooks that hold the wheels onto the tracks have to be bigger than they ought to be, or else the model trains wouldn't stay on the tracks. So there's some mapping, something to say, if this is the state out in the world, then this is what we get in here. And then what we're trying to find out is this model predictive. There's lots of things we can do with a model. One of the main things we do, at least with scientific models, is we try to make predictions. So let's look at the master picture. We have the mapping, which takes us to objects and rules. And we can then run the model. We can then, it's rules saying, if the objects are in this particular state and you ask for time to pass, then you get to a new state of objects number two. This is object number one. This is reality number one. And then the idea is, is we ought to be able to take the mapping backwards. It's called the inverse mapping. And come up with a new state in reality. And you notice that whereas reality number one was all kind of raggedy and jaggedy, I've drawn reality number two with kind of boxy, because we've lost all of the little nooks and crannies of reality when we abstracted it, which this step is called abstraction. The step is called instantiation or other things. We have no basis. We have this very simplified model just has trains and tracks and rules that says, if you turn the knob on the thing, the train will go. And it gets to another state where the train crashed into another train and they both fell off the tracks. When we do the inverse mapping, we do not get all of this extra stuff of reality back. We just say, well, there should be two trains and one ought to be falling this way and one ought to be falling that way. And if we did this all right, if we made a good abstraction that had objects that were naturally separable objects and the rules for the objects to do things were rules that corresponded to the things that tended to happen in actual reality. And then when we do the inverse mapping, we will come up with a state of affairs that is similar to if the real reality happened to be, and this is life stuff, that we'd go from one state of reality to the next state of reality. And if this really works, if what's in state reality number two is similar in a useful way to what starting with state number one in reality and letting life happen, then we say the model is predictive. It's a good predictor. All right, so we talked about what that might be like in the case of trains, in the case of modeling, like fashion modeling. Is it really very predictive? You be the judge. Clay is just like modeling trains. We can take modeling clay and we can make it into just about any shape that we want. It just doesn't have very good rules of behavior. Once we've finished putting the clay into the shape that we like and we just let time pass, basically it just kind of shrinks a little as it dries out because clay is good for modeling a moment in time, but not so good for modeling things changing over time. And that's in fact where programming comes in. Programming a computer is in fact like active digital clay. Just like clay allows you to very flexibly make shapes, programming allows you to very flexibly make behaviors. When you first start out programming, it's really just, you know, there's so much stuff and the computer doesn't like what I said and it's terrible. But after you get past the hump of learning how to talk to the computer and we're using a language, we're using NetLogo, which as languages go is really pretty gentle. It's still confusing. The computer is still a complete jerk and you have to get everything exactly right or else, you know, nothing happens. But once you get over that hurdle, then things that start happening wrong, happening wrong for sort of interesting reasons. It's like you've learned to speak to the computer, but what you said didn't do what you thought it was. The goal of the programmer, the real goal is to figure out what is the model that, what objects do I want to have and what rules of behavior do they want to have between them so it captures what is important for reality in this particular problem. And you can take the exact same reality and have two different problems and you'll have totally different objects and rules of behavior. Okay, so the ultimate effort, the ultimate creativity that really goes into programming is into taking what's out there and some purpose or goal and figuring out the objects, figuring out the rules of behavior and the mapping, the input and output between the model and reality is what it's all about. So in Solitaire the entire world becomes cards and you can put red on black and the numbers have to go down whatever sort of rules you're playing. And everything else goes and hangs and in particular the actual act of you shuffling the cards is not generally modeled in the Solitaire game. You have a good model in the sense that if you had a particular stack of the deck and you laid it out in a computer and you played it and you won in a certain way that with very high probability if you stacked a physical deck the same way, laid it out you could make all the same moves and you'd win or lose in exactly the same way. So the Solitaire game, very predictive. Similarly the bank account, now totally different objects, now there's accounts. Now I, me, I am represented in a bank account by an account number and a balance and the rules of behavior are if I deposit a penny I have a penny more if it's finally weather prediction the same idea. Now we're taking, you know, cubic kilometers of atmosphere and saying what temperature they have, which direction is the wind going and then making rules like if the wind is going this way and this cube of air, well then the wind probably ought to be going about the same direction in the next cube of air unless it's being pushed by other forces coming in on other edges of the cube and so on and you can grind through that using all of the data that you have well in Albuquerque it's 43 at 6 a.m. and so on and you come up with a prediction. Programming is modeling. The essence of programming is not the if and the then and the while and the for loops although that's what you do to express the dynamics that's what you do to express the rules but the essence of programming is what are the objects, what are their relationships and once you get to that level it takes some time but it's a mess.