Programming is Modeling
[Title Screen] Learning how to program is what's the class is about. [Slide 1] It's based on modeling. 2 questions we'll 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.
[Slide 2] If I'm completely honest, and I try imagine it from a fresh perspective, I would probably think modeling is what Heidi Klum does. I don't know many guy,
Brad Pitt, I don't know. I saw him next to a 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 we would say, that's what modeling is. I want to add programming to the list.
[Slide 3] Overall, we're talking about the elements of a model. Reality. 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. It 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 is some [02:00] objects and rules of behavior that govern what happens.
It's easy to think about this as being like a game. You have cards and you have, you can only put a red card on a black card, and vice versa. Whatever it is. This is the stuff of the model. Crucially, you have a mapping between 1 and 2. A mapping between reality states getting mapped to model states. Like that.
Okay?
That's the real key. We can look at, you know we have real train, we have the road runner sitting outside Tacitus, getting ready to head to Santa Fe. In my model, when I had trains, when I had Lionel trains, I had O gage trains, which were scaled down 48 to 1, so 4 feet, 1 inch. They have the rules of behavior, how they interact. You know, Lionel trains were all electric. They rolled down the tracks. They did whatever they did. We have the mapping. In the case of the trains, the mapping superficially seems 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. Little hooks that hold the wheels on the tracks [04:00] have to be bigger than they ought to be, or else the model trains wouldn't stay on the tracks.
There's some mapping, something to say, "If this is the state out in the world, then this is what we get in here." What we're trying to find out is, we're trying to find out is this model predictive? Okay. There's lots of things we can do with a model. One of the main things we do with it, at least with scientific models, is we try to make predictions. [Slide 4] Let's look at a master picture. We have the
Programming_is_Modeling-Ackley Page 1 of 4

mapping, which takes us to objects and rules. We can then run the model. We can bend it's rules, saying if the model is in, if the objects are in this particular state, and you ask for time to pass, you get to a new state of objects. This is objects number 2, this is objects number 1. This is reality number 1. All right?
The idea is, is we ought to be able to take the mapping backwards. It's called the inverse mapping. Whoops, and come up with a new state in reality. You notice, that, whereas reality number 1 was all kind of raggedy and jaggedy, I've drawn reality number 2 as 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.
[06:00] Step is called instantiation, or among 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. It gets to another state, where the train crashed into another train. 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 2 trains and 1 ought to be falling this way and 1 ought to be falling that way.
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, 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. This is life stuff, happens, right. We go from one state of reality to the next state of reality. If this really works, if what's in state reality number 2 is similar, in a useful way, to what starting with state number 1 in reality and letting life happen, then we say the model is predictive. It's a good predictor.
All right. [Slide 2] We talked about what that might be like, in the case of trains.
In the case of modeling, like fashion modeling, was it [08:00] really very predictive? You be the judge. Clay is just like modeling trains since 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 shrinks a little, as it dries out. Clay is good for modeling a moment in time, but not so good for modeling things changing over time.
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. [Slide 3] When you first start out programming, it's really just, ah there's so much stuff. the computer doesn't like what I said. Eh, it's terrible. After you get past the hump of
Programming_is_Modeling-Ackley Page 2 of 4

learning how to talk to the computer, and we're using a language, we're using
Net Logo which, as languages go, is really pretty gentle.
It's still confusing. The computer is still a complete jerk. You have to get everything exactly right, or else nothing happens. 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. What you said, didn't do what you thought it would. The goal of the programmer, the real goal, is to figure out what is the model, what objects do I want to have? What rules of behavior do [10:00] they want to have between them, so it captures what is important for reality, in this particular problem.
You can take the exact same reality, and have 2 different problems. You'll have totally different objects and rules of behavior. Okay? 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. The mapping, the input and output, between the model and reality, is what it's all about.
[Slide 5] In solitaire, the entire world becomes cards. You can put red on black and the numbers have to go down, whatever sort of rules you're playing.
Everything else goes and hangs. 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 played it out in a computer. You played it and it won in the certain way, that, with very high probability, if you stacked a physical deck the same way, laid it out, you can make all the same moves. You'd win or lose in exactly the same way. The solitaire game, very predictive.
Similarly, the bank account, now, totally different objects. Now there's accounts, see now I, me, I am represented in a bank account by an account number and a balance. The rules of behavior are, if I deposit a penny, I have a penny more. If it's, weather prediction the same idea. Now we're taking cubic kilometers of atmosphere and saying, "What temperature do they have? Which direction is the wind going?" Then making rules [12:00] like, well if the wind is going this way, in 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 other edges of the cube, and so on.
You can grind through that, using all of the data that you have. Well, in
Albuquerque, it's 43 at 6 AM and so on. 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 4 loops, although that's what you do to express the dynamics. That's what you do to express the rules. The essence of programming
Programming_is_Modeling-Ackley Page 3 of 4

is, what are the objects? What are their relationships? Once you get to that level, it takes some time. It's a blast.
Programming_is_Modeling-Ackley Page 4 of 4