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.