I hope you're already beginning to see 
some of the power of working with a 
systematic design process. 
One piece of that is that you always know 
what to do next. 
There's always the next step of the 
recipe. 
And that step of the recipe tells you 
what kind of thing you need to write and 
where you should be looking to figure out 
how to write it. 
So when it's time to write the examples, 
you know that you can look at the 
signature, and the purpose, to help you 
figure out what the examples need to be. 
You've also seen the benefit of producing 
uniformly structured code. 
Code that's easy for other programmers to 
read, and code that has an appropriate 
number of tests. 
But in this next part, you're going to 
see the power of systematic design really 
start to step up. 
What's going to happen is that because 
the design method itself, in other words 
the metadesign, in some sense. 
Because the design method itself is 
structured so that the How to Define 
Functions recipe is orthogonal, which is 
kind of a $10 word for, means mostly 
independent. 
Because the functions recipe and the data 
recipe are orthogonal, it means that as 
we learn more forms of data, the 
functions recipe is going to continue to 
work unchanged, or mostly unchanged, with 
those forms of data. 
So now we're going to begin to cover the 
ground a lot more quickly, because of 
this property of the way the recipes are 
designed. 
In week one, and particularly at the end 
of week one, we learned about primitive 
data, including types like String, 
Number, and Image. 
And we learned the How to Design Function 
recipe, and we used it to design 
functions like double, which consumed a 
number, and yell, which consumed a 
string, and area, which consumed. 
A number, and image-area which consumed 
an image. 
And what started to happen this week is 
we've started to learn about other forms 
of data. 
And in particular we've learned about 
non-primitive data, data where there's a 
type that we design with the How to 
Design Data definitions recipe. 
And what we did in the last two videos 
was we learned about atomic non-primitive 
data, and we designed the type CityName, 
and then we designed the best function 
that consumed a city name. 
And earlier in the week you actually saw 
a preview of a form of data called 
enumerations which we haven't explicitly 
covered yet. 
We'll do that shortly. 
But you saw another type called Traffic 
Light Color, and a function, next-color. 
And what's going to happen the rest of 
this week, is we're going to learn about 
some other forms of data including 
intervals, enumerations, itemizations, 
and a special form called distinct. 
And we'll see examples of those types. 
And you'll be able to design functions 
that operate on them. 
As I said before the HtDF recipe is 
largely orthogonal to the form of data. 
So HtDF works the same way with different 
forms of data. 
And what that means in this week is we're 
going to focus most of the lecture time 
on designing different kinds of data 
definitions. 
And we're going to have to spend much 
less time on designing functions that 
consume that data. 
In some sense what's happening is we did 
this little piece of the y-axis, How to 
Design Functions, and now we're working 
out the x-axis. 
And all of this space in the middle, the 
cross product of the two axes comes very 
cheaply. 
We won't have to spend much lecture time 
talking about these kinds of functions. 
Instead, we spend most of the lecture 
time talking about forms of data. 
And designing these kinds of functions 
comes almost for free. 
And what's great is the power of having a 
design method in which the individual 
recipes are orthogonal to the form of 
data is only going to grow from there. 
Next week, we're mostly going to focus on 
two things. 
One new form of data, compound data, and 
also a recipe that helps us design 
interactive programs, like games, and 
animations, and things like that. 
And again, because of this orthogonality, 
most of the lecture time will be on 
compound data, and on a How to Design 
Worlds recipe. 
And we'll do some examples in the cross 
product, some examples in the green box. 
But we won't have to do all of them in 
lecture, because once you know how to 
design worlds and once you know compound 
data, you can do anything in the blue, 
red, or green boxes. 
Beyond that, when we do lists and trees, 
lists and trees are complicated 
structures. 
But because of this orthogonality, again, 
they're going to be much easier to learn 
in this course than they are in some 
other courses. 
Orthogonality is always great in design 
when you can get it. 
Here you've got orthogonality in the 
design of the actual design method, and 
it's giving us some wonderful properties 
here. 
We can learn HtDF, and HtDW, and we can 
learn forms of data, and we get the cross 
product for free. 
That's going to be a big benefit in terms 
of using this method. 
And later on in the course we'll see some 
other examples of where we work 
orthogonality into our own designs and 
get some similar benefits.