As I mentioned before, programs are 
always changing. 
Or put it this way, if you're fortunate 
enough to design a program that other 
people really want to use, they're 
going to want you to change it. 
They're going to want you to make it 
better and better and better. 
In this video, what I'm going to do is 
make a change to the cat program, give it 
some better functionality. 
And what you're going to see is that that 
careful design that we did is going to 
help make that change easy to manage. 
What we'll do is we'll run the change 
right through the whole recipe, starting 
with the analysis and then going on to 
the code. 
We've got a cat program, and we can run 
it as we solve, by saying main of zero, 
where zero is the initial state of the 
world. 
But there's something about this cat 
program I don't really like, which is the 
cat is moving a little bit too slowly. 
I just don't have time to wait for it to 
get there. 
So, let's see about revising the program 
to make the cat move more quickly. 
As I mentioned in the last video, if we 
think about this program and we think 
about the analysis that we started with. 
One of the things we worked very hard to 
do, was to make sure there was a clear 
correspondence between the analysis and 
the program. 
So, the constants in the program 
correspond to what we identified in the 
analysis. 
The data definitions in the program 
represent the changing information that 
we identified in the analysis. 
The big bang in the program has the big 
bang options identified in the analysis. 
And the handler functions played their 
roles with respect to the changing 
information and the interaction with 
big-bang. 
The fact that we've kept this clear 
correspondence between the program and 
the analysis, means that we can use the 
analysis as a kind of abbreviation, where 
the technical term would be a model of 
the program. 
We can think about what we need to do to 
the program by starting doing it with the 
analysis. 
So, let's do that. 
The problem we have is that the cat's 
moving too slowly. 
Some sense, what happened here when I 
look back at the analysis is we can say, 
hey, the cat's speed was an unidentified 
constant. 
There is this constant called the cat's 
speed. 
The cat's moving one pixel per clock 
tick. 
If we identify that as a constant [so, if 
we add speed to the analysis here], then 
we're going to have to change that speed 
to something more than one. 
And if we use that speed over here in the 
on take handler function, then changing 
that constant value will change the speed 
of the cat. 
So, now that we have updated the 
analysis, let's just go through and do it 
to the program. 
Well, the first thing is, there needs to 
be a speed constant. 
So, I'll go right here and I'll add the 
constant speed. 
And one was too slow, so, let's say 
three. 
The great thing about it being constant 
like this is if we think later that three 
is not enough, we can change it again. 
So, I've checked off this part of the 
analysis, where I was supposed to add the 
speed constant. 
And in the notes I made on the analysis, 
it says I also need to go look at the 
on-tick handler. 
So, I scroll down here to big bang, and 
the on-tick handler is called advanced 
cat. 
And if this was a big program, then I'll 
show you a Racket has a tool I can use, 
which is I click Check syntax, I click 
right on Advance-cat, and I can jump to 
the definition of Advance-cat. 
Now, it wasn't a big program so, I didn't 
need that help. 
But if it was a big program that would 
help. 
Another way to do it is you could go 
right up here, and search through all the 
definitions. 
Jump right to advance-cat. 
Now, I'm going to quickly replay the how 
to design functions recipe with this new 
constant in mind. 
The signature doesn't change, the purpose 
changes. 
We're going to produce the next cat by 
advancing its speed pixels to the right. 
So, let's see. 
The stub didn't change. 
The check-expects changed. 
Now this is, instead of being advance-cat 
3 produces 4, this should be advance-cat 
of 3, and you might be tempted to put a 6 
here. 
But that's not what I'm going to put 
here, I'm going to put plus 3 speed. 
That way when I go change the speed 
constant, this check expect will 
automatically be the right thing. 
In this way, this check expect really 
corresponds to the purpose. 
It says, whatever the speed constant 
happens to be, that's how much we're 
supposed to advance the cat by. 
So, let's see, advance-cat the template 
doesn't change. 
Here's the body of the function. 
And this one just becomes speed. 
I can run my test pass, and now I can 
say, main of 0, and I have a speedier 
cat. 
So, the important thing to take away from 
this video is programs always change. 
I said that before: Programs always 
change, because people want them to be 
better all the time. 
And so, that means we want it to be easy 
to change programs. 
And in the case of these word programs 
where we have this analysis, working hard 
to make the structure of the program 
match the structure of the analysis made 
it really easy to go back and make this 
change, because the analysis became kind 
of a model of the program. 
And we could think about what we needed 
to do to the program. 
First at the model level; first, using 
this analysis picture, and then quickly 
run through the program, catching it up 
to the new analysis. 
This ability to work on programs by 
reasoning about them at the model level 
is one of the things that really 
separates program designers from people 
who write code that just happens to work. 
And we're going to talk about it a lot 
more in the course as we go forward.