SEAN WALKER: Hello
everyone, good afternoon.
This is CS50, week 1,
slash week 0, part 1,
depending on how you're counting things.
I'm Sean Walker.
I'm a senior in Hopper, and I
am your head teaching assistant.
JANA VRANES: Hi everyone,
my name is Jana.
I'm the head course
assistant for CS50 this year.
SEAN WALKER: So yeah, we'll be
seeing you guys in office hours.
I'll be maybe seeing
some of you in section.
Can't wait to start the semester.
We're very excited.
There's so much cool things in
store for you this semester,
including this Saturday,
there is a great event--
one of my favorite of the year--
which is called Puzzle Day.
And maybe Jana will tell you
a little bit more about that.
JANA VRANES: So every year,
CS50 partners with Facebook
to organize Puzzle Day.
Puzzle Day is this really
fun event we put together.
It's basically just like a
fun afternoon slash evening
that you can spend solving
puzzles with your friends.
This event is-- of course, all of you
are invited and encouraged to come,
but it's also open to anyone from Yale.
So please feel free to bring your
friends, bring your roommate.
And the puzzles aren't
CS50 or CS-related.
So it's really open to everyone.
And we will have super-cool prizes
for the winners of the event,
as well as a raffle.
So yeah, make sure to come.
It's this Saturday.
It's going to be in Hillhouse 17, which
I'm sure most of you know where it is.
Yeah, it's right up there.
And then one more announcement
we have is that, next week,
in the same time slot, Benedict, who
is our professor of CS50 here at Yale,
will be holding a--
he's right over there--
he'll be holding a hot takes CS50
tutorial right here in this room,
from 4:00 to 5:15.
So if you can come, please do.
It's going to be just a lot
of helpful advice, things
you should know about the course.
But it also should be recorded and
available online if you can't come.
Thank you, everyone.
Have a great semester.
[APPLAUSE]
DAVID MALAN: So good
to see everyone again.
So this is a continuation of
where we left off last week.
Which, recall, was a look
at computational thinking,
where we tried to more methodically
start thinking about problems,
and start to leverage
some of the intuition
that you might have had with things
like phone books and the like,
to start solving more
interesting problems.
And in fact, Puzzle Day is ultimately
about exactly that-- problem-solving.
And indeed, as Jana said, it's
not about computer science.
There's no computers even
required, or programming required.
It really is just about taking
input and producing outputs.
And in this case, the inputs
are the puzzles themselves.
The outputs might very well
be some fabulous prizes.
But it really is meant to be
an opportunity to bring you
and some of your classmates together
right at the start of the term,
whether they're taking
or not taking CS50,
and really just think hard about
some interesting, fun problems,
and then sort of delight at the end as
to who got as many of them as possible.
But you'll recall that when we started
framing problem-solving like this,
it first required that we
represent those inputs and outputs.
And there's any number of ways we
can represent inputs to problems.
Like the number of people
in this room, that's
an input-- each of the
bodies in this room.
And we could count them sort of
old-school like we did last time,
or perhaps a little more methodically.
We might think of the
inputs, though, not as being
physical as much as they are digital.
Right?
Recall, we introduced
binary, which really
is just an abstraction
on top of electricity--
either being there or not being
there, one or zero, true or false.
And so we came up with a
number of ways last time
to represent information and
recall this theme of abstraction we
had the electricity sort of
literally at the ground floor,
then we had this layer of binary--
zeros and ones-- above it.
From there, we could represent decimal,
and another base system if we wanted.
We could represent
letters through ASCII,
or we could represent
emoji through Unicode.
If we just thought about
those bits in a different way,
we could actually use the same
zeros and ones to represent colors.
And from colors, we get pictures.
And from pictures, we get movies.
And so there is this sort
of hierarchy, this layering
of one concept on
another, so that we can
start thinking about
problems at this level,
and just take for
granted that someone else
before us figured out how to
actually map it to physical things
like computers.
So where does that leave us?
Well turns out abstraction can
be both useful and not so useful.
And I thought we could explore this
by way of just a couple of problems.
The first of these requires that we take
advantage of the white pieces of paper
that hopefully you're
holding in your hand.
If you don't, any piece
of notepaper suffices.
Or just raise your hand, or one of us
can run over with a piece of paper.
You just need that plus a pen or pencil.
And if we could ask for
one brave volunteer who's
comfy appearing on
stage and the internet,
we need you to come on
up for just a moment.
Can't distinguish hands
asking for paper or hands
asking for volunteer-- volunteer?
Yeah, OK, come on up.
What's your name?
AUDIENCE: John
DAVID MALAN: John, nice
to meet you, David.
All right, so John here is going
to see in just a moment a picture.
And John is then going to take on the
role of a programmer, if you will,
an expessify, step-by-step, how you
all, as the computers, if you will,
will execute that program by
applying pen or pencil to paper.
And the goal is for John to be as
precise and as explicit as possible.
You can say anything you want, but
you can't make any physical gestures.
And the goal is for all of us to
transcribe, perfectly, exactly what it
is that John is describing.
So let me go ahead here and just
temporarily mute my image, if I may,
so that John and only John and
I know what the picture is.
And I'm going to ask that you draw
this for the audience, verbally.
Execute.
And go ahead and right it into here.
OK, just don't hit the keys,
or this will spoil something.
AUDIENCE: So start with the
vertical line down the middle.
DAVID MALAN: OK, a little louder.
AUDIENCE: Start with the
vertical line down the middle.
Then two lines jutting
out from the bottom--
well, start with one line at
the right side, at an angle,
about 30 degrees up--
30 degrees from the horizontal.
Just draw a line from
the right, and then do
the same thing on the left side.
All the lines should be equal length.
DAVID MALAN: By the way.
[CHUCKLING]
AUDIENCE: Yeah, after the fact, yeah.
Then, at the end of those
two lines that you drew,
draw two more vertical lines,
going straight up, yeah.
Then, draw lines that will connect
those two previous vertical lines,
and connect them at a point.
Then, draw a line that connects
the three vertical lines together.
DAVID MALAN: Good?
All right, end program.
So a big round of applause for
John for coming on up, if we could.
Thank you.
[APPLAUSE]
Give me just a moment
to plug back in here.
All right.
So, if the staff wouldn't
mind, could we just
collect a random-ish sample of the
answers here, just grabbing a few.
We don't have to grab them all.
No, OK, you're refusing.
OK, who's willing?
No?
OK.
Over here, thank you.
Sorry for reaching.
OK, thank you.
OK, thank you.
OK, little shy.
Thank you.
OK, sure.
Thank you.
OK.
And let me get one more
from the right-hand side.
Thank you.
All right.
Thank you very much.
So suffice it to say,
at quick glance, it
looks like there's been a
number of interpretations
of what John was prescribing.
And that's fine.
Thank you, Sean.
Let me go ahead and lift
up just a few of these,
and then consider how
we got to this point.
So here is one that I'll project.
Maybe it goes this way.
Let's see.
OK, here's one that's maybe
a little more kite-like.
OK.
This one's pretty similar.
This one got a little frilly,
or a little on undo, undo, undo.
[LAUGHTER]
Maybe.
OK, so this one looks a little
more house-like, perhaps.
OK, but it looks reminiscent of
the same length line someone was--
that John prescribed.
This one looks three-dimensional--
very nice.
This one, less so.
[LAUGHTER]
And let's take a look--
actually, it looks
like we got one more that
has a bit of 3D to it.
So let me go ahead and go back to
what John alone was looking at.
And in fact, what he
was describing was this.
So it looks like a few of you.
So a round of applause for
those of you who did get the--
who did get, frankly, the cube,
which was a word I noticed you
didn't actually say.
But that's fine, because John
was trying to be ever-so precise,
like a computer might need to
be, in specifying exactly what
line needs to be drawn, and
where it needs to be drawn,
how long it needs to be.
But notice just how much harder
that problem was without John just
indulging in the luxury of
saying, hey everyone, draw a cube.
Now, there's some ambiguity, to be
fair, in just saying, draw a cube.
Because which way is it
rotated, at what angle?
So he probably would
have had to specify.
But that's all an abstraction is.
We all know, intuitively,
what a cube is, in this room.
But when you really
start to think about it,
well, a cube is really like
a diamond shape on top,
and then two more on the
sides, and everything lines
up with equidistant lines.
So there's a specificity required,
where you really get into the weeds,
so to speak.
And I'm sort of painting
a picture down here,
because those are the
lower-level implementation
details, like when we discussed binary.
So in this case, maybe
abstraction would have helped.
It certainly is how we
would think about this.
But how would a computer do this?
Odds are a computer would paint
this picture quite like John
was prescribing, putting down the
equivalent of a pen or a marker,
and then moving up, or down, or left,
or right, maybe going up at one point
to then move that pen or ink elsewhere.
And that's the level we're going to
start thinking about in just a bit
today when we introduced Scratch, the
first of our programming languages,
via which we'll program by dragging
and dropping puzzle pieces.
And some of those pieces
very well could do
exactly what John was doing by drawing.
But we'll see we need to actually build
some of these abstractions ourselves.
Now in the reverse direction,
let's flip it around
so everyone can rather partake.
Can we get one more volunteer
to come on up on stage.
Let me look just a little farther
back this time, a little more--
OK, right here.
OK, come on-- yeah, sure.
What's your name?
AUDIENCE: Chloe.
DAVID MALAN: Chloe, come on up.
So this time, no one else needs paper.
Because Chloe, you're the only
one who has to draw this time.
And you're the only
one in the room who's
not going to see what the picture is.
AUDIENCE: All right.
DAVID MALAN: So, and the
only rule is you may not
turn around at any number of screens
that show you what everyone else sees.
And I'm going to project it over here.
So if you want to go ahead
and now just take on the role
that you did a moment ago, but all
of us will now program you verbally,
step by step, to draw without looking.
Just look that way, please.
A little to the right.
To your right.
OK, good.
Who would like to offer step 1,
from the audience, for Chloe?
Yes.
AUDIENCE: Draw a circle in the
upper half of the chalkboard.
DAVID MALAN: Draw a circle in
the upper half of the chalkboard.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: OK.
OK.
Step 2.
Yes?
AUDIENCE: From the middle of
the middle of the bottom part
of the circle, draw an upside-down Y.
DAVID MALAN: From the middle of the
bottom part of the circle, drawn
an upside-down Y.
OK, step three?
Step three.
No one?
Yes, in the middle.
AUDIENCE: From the point at which
the circle connects to the line,
draw the line in a 90-degree
angle, with the point facing down.
[LAUGHTER]
CHLOE: Is the point facing [INAUDIBLE]
AUDIENCE: The point of the angle.
DAVID MALAN: All right,
let's be more precise.
I think she's at the
right starting point.
So let's go from there.
Your--
AUDIENCE: Draw a line at
a 45-degree angle down.
Draw a line 45--
CHLOE: [INAUDIBLE]
[LAUGHTER]
DAVID MALAN: OK.
Took some liberties there, but OK.
Step 4.
Step 4.
Someone else?
Step 4.
Yes, in back.
AUDIENCE: Complete the
triangle on the left side.
DAVID MALAN: Complete the
triangle on the left side.
OK, nice.
Step 5.
Yeah, right here, in the middle.
AUDIENCE: On the right.
So that line that's sticking
out of the intersection
of the circle and the other line--
OK, that one.
[LAUGHTER]
[INAUDIBLE] draw on the
right, at a 45-degree angle.
DAVID MALAN: Draw a 45-degree angle up.
OK, nice.
Step 6, almost home.
Yeah, in the front.
AUDIENCE: So bring your chalk to the
top left of the circle, and then go--
without touching,
hover like one inch up.
Yeah, OK.
Now touch the chalkboard, and
draw a one-inch line to the left,
up, like at a 45-degree angle.
So you're like one inch away
from the circle on the left.
Yeah, but move-- yeah, that's fine.
[LAUGHTER]
And draw a line 45
degrees up, to the left.
[LAUGHTER]
CHLOE: Left or right?
AUDIENCE: Oh, sorry.
So start on the right, then
you're moving up to the left.
[LAUGHTER]
DAVID MALAN: Yes, OK.
Very nice.
And finally, step 7.
Yeah.
AUDIENCE: To the left of that
line, just move [INAUDIBLE]
DAVID MALAN: Anything you want.
AUDIENCE: All right, [INAUDIBLE].
OK, right edge [INAUDIBLE]
CHLOE: Right--
AUDIENCE: Right edge [INAUDIBLE].
DAVID MALAN: An abstraction
you could also just call, hi.
[LAUGHTER]
And if we could, I think--
Chloe, you want to take a look at what
you were being prescribed to draw?
I think a round of applause.
That's pretty good.
[APPLAUSE]
Thank you.
Thank you.
So there, too, it actually felt
like everyone, including you,
were kind of resisting the
tendency to provide abstractions.
But clearly, they're useful, right?
It's a lot easier to have said, draw
"hi," or even slightly lower-level
draw, an H and an I,
then frankly, it would
have been to tell Chloe, well,
put your chalk at the top left,
then draw down an inch, then lift it
up, and move it up a half an inch,
and then move it to the right.
I mean, that's what an H is, a
capital H. But when we think of H,
you don't think about it as
really being three lines that
are sort of mathematically defined.
But a computer ultimately will.
And thankfully, once we,
or one person in the world
has decided how to draw an
H on the screen, odds are,
you and I don't have to bother with
that low-level implementation detail
anymore.
Because you could imagine programming
could get super tedious if literally
every time you want to do
something interesting graphically,
you had to implement all of
that low-level logic yourself.
And we're not going to have to do that.
In fact, because of this
language and other scratch,
you have at your disposal a whole
toolkit, so to speak, of puzzle pieces,
or as we'll start calling them,
functions-- verbs, actions--
that someone else wrote, that
we can use to actually achieve
the effects, graphical or
otherwise, that we actually
want to perform in the computer.
So let's see what other
building blocks are going
to remain in this toolkit for us ahead.
So problem-solving, recall, was
defined as this, inputs and outputs.
And inside of that proverbial
black box were what?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Say once more.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: I sort of.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Algorithms was the
keyword we proposed last week,
is inside the black box.
And an algorithm is just step-by-step
instructions for solving some problems,
but sounds fancier than that.
And so these algorithms
we began to introduce
by way of a few of those
step-by-step problems,
like counting the number
of people in the room,
finding Mike Smith in a phone book,
sorting the humans on the stage.
All of those were algorithms.
But only one of them did we really
start to refine a little more precisely
using something called pseudocode.
And arguably, that's our
first language of CS50--
pseudocode, which has
no formal definition.
It just means, in English, or
whatever your native language is,
just write short, succinct instructions
that gets your point across.
And the point we wanted
to get across last time
for finding Mike Smith in a phone
book looked something like this.
And recall what we did was call out
a few of the key operative words
in this pseudocode that kind of fit a
pattern, all of the highlighted words
here, did we call what?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Say a [INAUDIBLE]
AUDIENCE: Commands.
DAVID MALAN: Commands,
or functions, we call
them, technically--
commands, actions, verbs.
And we're going to just start, across
the board, calling them functions,
if only because that's what a lot
of programming languages call them.
Functions provide you
with functionality.
You can think of it like that.
They are really among the
building blocks of a program.
A program-- a computer program,
or a piece of software,
is just a collection of one or more uses
of functions and other building blocks.
And among those other building
blocks, for instance, are these.
So highlighted in yellow now are
keywords like "if," and "else if,"
and "else," which we described
as examples of what last tie.
Yeah.
AUDIENCE: Conditions.
DAVID MALAN: Conditions.
So these are questions-- very well done.
Questions that you can ask
in a computer to decide
whether you're going to do this,
or that, or this other thing.
It's sort of like the
proverbial fork in the road.
Go left, go right, or
maybe somewhere down
the middle in a forking of the road.
Now in yellow here--
slightly fancier term--
but these were the actual
questions to which we had or wanted
yes/no or true/false, or 1/0 answers.
And we called these what?
AUDIENCE: Boolean.
DAVID MALAN: Boolean expressions.
Boolean expression is just an expression
that evaluates to true or false.
That is, it is true or false,
yes or no, 1 or 0, however you
want to think about those two opposites.
And you use Boolean expressions
as part of conditions
to decide on what basis
to go left or right
or somewhere else when deciding
what to do in a program.
And then lastly, we had
these, which we called what?
AUDIENCE: Loops.
DAVID MALAN: Yeah, loops.
They were cyclical in nature.
And we're going to see them in different
forms today, and next week, and beyond.
But in this case, it's
a loop in the sense
that it's literally telling you,
go back from these steps to step 2,
and that induces the cyclicity.
Do this again, and again,
and again, thereby achieving
the same functionality, hopefully until
we find, in this case, Mike Smith.
So this is just a few of the
building blocks in this toolkit,
if you will, that we're also going
to see now in another language,
called Scratch.
And Scratch, also, like
other languages, provides us
with a few other
ingredients, too, things
called variables, which you might
recall from algebra-- x, and y, and z.
But these are more general
purpose, not storing just numbers,
but really storing strings of text--
words and paragraphs.
You can store colors, and images, and
videos, just variables or placeholders.
And then we'll talk a little fancier
about terms like threading and events.
These are more technical
terms, but they provide us
with very useful and very
straightforward features in a program.
But to do that, we need to
actually introduce a language.
So what is a programming language?
It is typically a set of English-like
words that some humans in a room,
years ago, decided can be used
to express yourself precisely
and methodically to get a
computer to do something.
And some other people,
typically, then took
that language, a sequence
of English-like words,
and they figured out how to convert
those English-like words to the zeros
and ones that our computers
actually understand.
So when you hear the
slogan, "Intel inside,"
that refers to a computer
having Intel hardware.
Intel, a big, popular company,
for hardware, they make CPUs--
Central Processing Units.
And those are chips that might be yay
big, or even smaller, or even bigger,
that just know what to do when it
sees certain patterns zeroes and ones.
And what might the CPU, the
brain of the computer, do?
Well, sometimes it might do addition.
Sometimes it might do subtraction.
Sometimes it might save something
for you-- information, sometimes
that might load information for you.
Sometimes it might print
something on the screen.
So Intel Inside means that every Mac
and PC and other device these days--
or there's other brands, too, can
do certain very simple operations.
And when we humans
want to program, we're
not going to want to
program in zeroes and ones.
We're not going to want
to program, necessarily,
in the same way Intel might
have designed that chip.
We want to program in something that's
as close to English as possible.
And we can actually go even further--
it would be nice if we could
actually program more pictorially.
And that's where Scratch enters.
This is a programming language
that someone else figured out
how to convert effectively
to zeros and ones,
but that allows us humans to write
software with loops, and conditions,
and functions, and more, by
just dragging and dropping
little graphical icons.
We use it just for a
week in the class, just
for one homework assignment, just
to give everyone a sense of what
you can do with the language.
And those of you who have
programmed before-- not to worry,
even if you find it more
readily accessible--
odds are, you'll find yourselves
pushing yourselves, trying
to figure out how to do
something in this language
because it might actually be non-obvious
if it's not quite like the languages
you've seen before.
So what is Scratch?
That is not Scratch.
At the moment, it is a website.
So this is a programming
language that is implemented
in the confines of a web browser.
Because that just makes it very
accessible to people around the world.
It's targeted generally
at younger students
who use it in afterschool
programs to just learn
how to do more computational
thinking in a fun way.
We're going to use it to explore
some of those very same building
blocks of programs, and then
next week, translate, literally,
those graphical puzzle
pieces to the more
technically-looking but
conceptually identical keywords
in different language called C.
So what is it we're looking at here?
So you'll see in the
first homework assignment,
ultimately, what URL to go to, and
how to log in, and all of that.
Today, we'll focus more on
the ideas, and the features,
and the programming we can do with this.
On the left-hand side or all of those
puzzle pieces I keep referring to.
And those little circles
that are colored just
categorize the puzzle pieces into
different modes of functionality.
So you have collections of functions,
you have things related to conditions,
you have things related to variables.
And even-- because it's a fun
environment-- things like sound,
sensing--
so you can sense your
environment-- colors, and the like.
So there's some more
aesthetic stuff in there, too.
On the right-hand side,
way up there on top right,
is Scratch, the default cat that
you get with any program you write.
So you can very quickly change him into
a dog, or to a person, or to nothing
at all.
That's just an implementation
detail, ultimately.
He exists on a so-called stage, that
rectangular or square-like region
in the top right-hand corner.
And very simply, he's going to
be able to minimally move up,
down, left, right, and
do other things as well.
That is his world.
And then lastly is this big middle
region that's currently blank,
a blank slate, if you will.
That is where we'll be able to
drag and drop puzzle pieces,
have them interlock
together, and then command--
just like John did to
you, and we did to Chloe--
them to do something on that stage.
So most simply, for
instance, might we do this.
I'm going to go down to Control,
because I want to control--
rather, I want to control
what this program does.
And you'll see some familiar keywords.
Let me zoom in.
You'll see things like "if," which
we note already to be a condition.
We see some new words, like
"repeat" and "forever."
But odds are, those
are examples of loops.
They just kind of say what they mean.
And if we scroll a little higher,
there's something called events.
And it turns out, there's
some helpful events here,
the first one being
when green flag clicked.
Because it turns out-- you might
not have noticed- that just
above Scratch's stage,
up here, is a green flag,
like in a race, that
means go, run the program.
And then a little red stop
sign icon that just means stop.
So that's how we're going
to run and stop the program.
So what does this mean.
Well, I have a puzzle
piece that literally says,
when the green flag is
clicked, that's kind
of the way to start running a program.
Because when I click the green flag,
the following is going to happen.
At the moment, nothing
is going to happen,
because there's no puzzle pieces
snapped onto the bottom of this.
But let's go ahead and do that.
Let me go ahead and--
let me go down to Looks.
And let me go ahead
and quite simply say,
the very canonical computer
science-ey term, "hello, world."
And notice, I've provided
input now to this puzzle piece.
So this purple puzzle piece,
say, is an example of a function.
It's an action, clearly.
It's literally a verb.
And it actually takes
an input, the words,
or a word, or number, or whatever,
that you want the cat to say.
And because it's now attached
to the one green flag clicked,
just logically, that is
literally what's going to happen.
So just in case this
is a little small, this
is the program we've written thus far.
And notice it's indeed attached.
I can detach it, and move it over here.
But they're rather magnetic, and
they kind of want to go together.
And now, if I zoom out
and click the green flag,
I'm going to indeed play this program.
And that's it.
Kind of underwhelming, certainly,
with what we can do here.
But if we could, can
we get one volunteer?
And let's quickly fast-forward
to the end game here, something
you can really do once you
start connecting these blocks,
from a former student.
Someone like to come on up and
play a game, just a few seconds?
Yeah, come on up.
What's your name?
STEVEN: Steven.
DAVID MALAN: Steven?
STEVEN: Yep.
DAVID MALAN: OK, nice
to meet you, David.
All right, so this is a
game by a former student,
called Pikachu's choose Pastry
Catch, that at first glance
is probably going to only impress,
but perhaps overwhelm, that you go
from "hello, world" with two puzzle
pieces to the interactive game.
But over the course of
today, what we're going
to do is distill programs
like Pikachu's Pastry Catch,
and think about, well, if you actually
focus on one piece of it at a time,
you can actually build
it, step by step by step,
until you're really impressed with
yourself some number of hours later.
Let me go ahead and fullscreen it here.
Let me go ahead and click the
green flag, and hit the space bar.
PIKACHU: Pikachu.
[LAUGHTER]
DAVID MALAN: That was one
puzzle piece to do that.
So you want to--
[VIDEO GAME MUSIC PLAYING]
--there we go, left and right, and up.
That was bad, bad.
OK.
OK, a round of applause for Steven.
[APPLAUSE]
OK, let's do it once more.
AUDIENCE: Let's do it.
What's run, and what's [INAUDIBLE]?
DAVID MALAN: OK, so let's go back
to the-- let's stop and restart.
So here we go.
I'm going to hit the space
bar for the instructions.
PIKACHU: Pikachu.
DAVID MALAN: Catch the
food, don't catch the bombs.
STEVEN: I see.
DAVID MALAN: OK.
[LAUGHTER]
PIKACHU: [INAUDIBLE]
[VIDEO GAME MUSIC PLAYING]
DAVID MALAN: Nice.
So notice, as Steven plays--
that's a bug.
Notice, as Steven
plays, there's some kind
of counter keeping track of how
many cookies and cakes he's caught.
And so we're going to
call that a variable.
It's just a number, like x or y, that's
getting incremented-- added to again
and again.
Notice that this time he
still has three lives left,
per the icons in the
top right-hand corner.
Just so we can see, do
you mind throwing a game?
Can you just let a bomb hit you?
And watch the variable.
Now he's down to two.
You can also jump, I think, with up.
So let's consider what some
of these building blocks are.
He's clearly moving left, right, and up.
Left is the result, clearly, of
him hitting a key on my keyboard.
So apparently, in a computer program,
you can listen for specific keys.
Notice, if he hits up--
hit up once more.
Notice, when he hits up,
it's not just up, down.
There seems to be a bit of animation.
And now it's a loop.
Here's an example of a loop.
And you'll see that sometimes things
fall more quickly than others, which
is making the game arguably harder.
So if you've ever heard of, back in the
day, AI, or artificial intelligence,
this is often what it typically
meant, just make things
harder, don't necessarily
understand what the user is doing.
And we'll see now, it looks
like Steven has 16 seconds left.
And everything's falling faster.
10 seconds-- so that, too, is
probably just a variable that's
being decremented--
decreased again and again.
Very nice.
One second.
And you still died, I guess, at the end.
All right, a round of applause for real.
[APPLAUSE]
Thank you.
So most of my voiceover
there was just trying
to justify spending that
much time playing the game.
But there are indeed these
various building blocks.
Because think about all of the
various components on the screen.
A moment ago, we just saw
Scratch say, "hello, world."
Now, we clearly see
so much more going on.
And indeed, the programs look
a little scary at first glance.
It's lots of puzzle pieces.
But the student who
wrote this did not just
start dragging and dropping all of
these puzzle pieces, and voila, thus
was born the game.
They focused on individual
building blocks.
What might some of those
building blocks have been?
Well, when the game first
started, the cakes and the bombs
were falling somewhat slowly,
and not all that often.
And each of those cakes
and each of those bombs
is just what we're going to call sprite.
It's some kind of object in the
program that you can associate
scripts or puzzle pieces with.
And just as Scratch is a
single sprite, this game
had at least a dozen or
more sprites moving along.
So this middle area where
all your scripts are actually
associated with each of the
characters or sprites in the game.
This, for instance, because
Pikachu is highlighted,
are all of the scripts associated with
Pikachu, who Steven was playing as.
Then there is a separate
sprite for the cupcake.
And these are apparently all the
puzzle pieces that govern just
what the cupcake was
doing, again and again.
If we keep clicking, here's
what the bomb was doing.
And if we actually really
looked closely at this,
we could understand
why was the bomb moving
so quickly, why was the cake
starting from the location it did.
And we're not going to go into
those weeds with this game.
But realize things escalated
quickly, but not before we'll
take these step-by-step
approaches to building
some of these pieces of functionality.
So what do I mean by that?
Well, let me go ahead and actually just
write a slightly different program.
Let me clear the stage here.
And you'll see, at the
moment, Scratch is in beta.
So you might have to dismiss some
of those warnings, but it works.
And what you'll see here is
just a clean slate again.
So let's do something that actually
takes some input this time,
and specify something like this.
Let me go down to Events,
because many of my programs
are going to start with just this one
puzzle piece, when green flag clicked.
And now I'm going to go ahead
and let's look for, say, Sensing.
Notice this block here.
It turns out you can actually
get input from the user.
You can ask the user questions.
So ask, what's your name and weight?
That's just a placeholder
in the white box there.
So I'm going to go ahead and drag and
drop this, under that puzzle piece.
And literally, it asked the user that.
And then once I get his or her
name, you know what I'm going to do.
I'm going to go ahead and say something.
Previously, I said "hello, world."
But it would be kind of
cool if I could actually
say the name of the user who
just typed in his or her name.
So how do I do that?
Well, let me go back to Sensing,
which is the category of blocks
where I found this ask block.
And notice, right below it is
something that's apparently related.
It turns out that this puzzle piece
functions in the following way.
When the user is asked
what his or her name is,
the answer is actually stored
in a variable called Answer.
And a variable, again,
like in math, x, or y,
or z, you can give them
more descriptive names.
Because it would be a little
misleading to just call it x.
So they called it Answer.
And notice what I can do.
I can drag and drop Answer.
And just notice, as I hover over
there, it's a little magnetic as well.
I just let go, and voila, it
grows or shrinks to fit the block.
So now, if I go ahead
and click Play, notice,
Scratch is asking me what's my name.
I can go ahead and type
in, David, and hit Enter.
And now it says just, David.
That's not exactly how you're
supposed to greet someone,
by just saying, Benedict.
It would be nice to say something
like, hello, comma, Benedict.
So how do we do that?
Well, I only figured this
out by futzing around myself.
But it turns out, under Operators, down
here, there's some other puzzle pieces
that I got curious about.
These are just placeholders, apple and
banana, but Join does exactly that.
It takes not one input but two inputs.
Or, as we're going to start
calling them, arguments--
two arguments to a function that
somehow control its behavior.
And what I'm going to
do now is actually this.
Let me go ahead and remove Answer,
and just drag it over there.
If it's disconnected, it's
not going to do anything.
But I don't have to
throw it away just yet.
I'm going to drag one
of these join blocks.
Notice it magnetically
clicks into there.
I don't want to say, apple, banana.
I want to say hello, comma, space,
and then move answer right there.
So now I'm passing two inputs to join.
But if you kind of
think through the logic,
how many inputs am I then passing
into Say to control its behavior?
There's kind of this nesting approach.
And the fact that I literally put
one puzzle piece on top of the other
indicates what the
order of operations is.
This is going to join the two words--
"hello," comma, and then "answer," and
then it's going to pass whatever that
answer is-- otherwise known as a return
value, but more on that next week--
into Say as its argument.
So functions can take arguments,
whether it's one, or two, or even more.
Now let me go ahead and
hit green flag again.
What's your name?
David, Enter, "hello, David."
So now it's a little more interactive.
And I can type in any name,
and it will just work.
So it's not hard-coded anymore.
So I have a dynamic program.
And notice, the key takeaways
here is not so much what it does
but how it does it.
But this is a little underwhelming,
certainly on the heels
of the game Steven was just playing.
So let's actually take
things up a notch.
I'm going to go ahead and start over.
And I can do this by just dragging
all of my puzzle pieces away.
They just get deleted.
Now I'm going to go ahead and do this.
I'm going to go ahead and start
with the same puzzle pieces
before, when green flag clicked,
and then go under Sounds.
And Scratch is a cat.
Turns out he actually
comes with some cat sounds.
So let me go ahead and
play this game now.
[CAT MEOWING]
Aw, it's kind of cute.
[CAT MEOWING]
It's a little annoying that I
have to literally click the button
every time I want to hear this play.
But that's doing literally what it says.
What if I want the cat
to meow three times?
How might I do this?
Well, I see I have more of these,
sort of an infinite supply.
So I could just do this.
Let me go ahead and hit play.
[CAT MEOWING]
Hm, that didn't seem to work.
Let's do it again.
[CAT MEOWING]
Hm, doesn't quite sound right.
But there are three puzzle pieces.
Feels like a bug.
My mistake, MIT's
mistake, what's going on?
I kind of wanted to hear "meow, meow,
meow--" though not quite like that.
Yeah.
AUDIENCE: The time in
between three [INAUDIBLE]
DAVID MALAN: Yeah.
It turns out that Macs
and PCs are pretty fast.
But this sound, of course, is
stretched over a second or so.
And the puzzle piece literally
just says, start the sound, meow.
And it doesn't say,
wait for it to finish.
It doesn't say anything about time.
It just says, start the sound, start
the sound, start the sound, three, one
after the other.
And so they're just kind
of tripping over themselves
because I've not waited.
So--
[CAT MEOWING]
--they're there, they're just
all overlaid on each other.
So I can fix this in a few ways.
Let me actually go
ahead and go to Control.
Notice here, there's a weight block,
which might actually help me fix this.
So let me go ahead, and notice, you can
kind of snap things inside if you want.
So let me wait one second there,
let me wait one second here,
and now click Play.
[CAT MEOWING THREE TIMES]
OK, the cat's a little agitated.
So that doesn't sound quite natural.
I can change the input to wait to
maybe be two seconds, and now play it.
[CAT MEOWING THREE TIMES WITH WIDER
 INTERVALS]
OK, a little more realistic.
But this is getting a little tedious.
But it turns out, if I
look a little more closely,
Scratch actually came with something
a little more straightforward.
Which puzzle piece should I probably
have just used in the first place
to solve the same problem?
I'm currently using start sound.
Yeah?
AUDIENCE: Play sound, meow, until done.
DAVID MALAN: Yeah, I mean,
that just kind of says
what it does-- play sound meow
until done, thereby eliminating
the tripping over of the sounds.
So let me try that.
I'm going to throw all of these away.
And now let me just grab three identical
copies of this, and see what happens.
[CAT MEOWING THREE TIMES, QUICKLY]
All right, so it's kind
of the agitated cat again,
but at least I didn't
have to do as much work.
It's three puzzle pieces instead of
six, which just feels a little cleaner.
It's twice as fast to write.
But I bet I can do better than this.
I'm asking the cat's meow
again, and again, and again.
What's the concept that comes to mind?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: What's that?
AUDIENCE: Repeat.
DAVID MALAN: Repeat in some form.
So a loop more generally.
So we saw one of those earlier.
If I go down to Control--
and notice here, repeat 10.
So let me detach these.
Let me grab a repeat block.
And it doesn't look very big,
but that gap in the middle
will actually grow to fill.
Let me just grab one of these
now, throw the other two away.
And now, even though it's
still three puzzle pieces,
it just feels like it's a
little more maintainable.
Because now I can just change how
many times I want it to run there.
[CAT MEOWING THREE TIMES, QUICKLY]
OK, not quite natural.
But again, how do I fix this problem?
Yeah, I should probably wait.
So let me go back to Control,
and grab Wait One Second.
This will snap to fit.
And now--
[CAT MEOWING THREE TIMES AT ONE SECOND
 INTERVALS]
OK.
So it's getting better.
And now we're sort of making a
cleaner program, if you will.
Because consider the alternative.
If I wanted the cat's to meow 10
times, if I took that first approach,
and dragged and dropped 10 play-sound
blocks, that just gets messy.
It feels like you're just
wasting time and effort.
Why not just grab one
block, the repeat block,
as you proposed, and just
sandwich in one or two
related blocks, like
"play sound and wait,"
in order to achieve the same result.
Well, let me go and do
something a little fancier now.
Let me go ahead and get
rid of these, and let
me demonstrate how we might have Scratch
actually count itself in a program.
Let me go ahead and go
down to Variable here.
And notice that there's a
whole bunch of blocks here.
But by default, I actually get
one variable, called My Variable.
But that's not very descriptive.
Let me go ahead and make my own
variable by clicking this box.
That pops up this window.
And I'm going to go ahead and
make a variable called Counter.
I just want a counter that
just counts from one on up.
I could call it x, or y, but Counter
is more descriptive in English.
Now notice I have a new puzzle
piece in orange, Counter.
And let me go ahead and drag--
let's go ahead and drag
this one, Set Counter to 1.
So this is a command
in Scratch that just
lets me do exactly that, initialize this
variable to having a specific value.
Then let me go to Control.
And let me go and
forever do the following.
I want Scratch just to demonstrate to
me that he can count up to, say, as
high as he can go.
We'll see how fast he counts.
So let me go ahead and have him say--
not a word this time, so
not "hello" for two seconds.
Let me go down to
Variables, and let me drag
Counter where the word
"hello" is, and have him
just say the counter for one second.
And then after that,
what do I want to do?
I'm going to go ahead and
change the counter by one,
and then let him repeat.
So these programs alone-- let me
go ahead and zoom in on the program
that I just wrote.
This program, composed of
these five-or-so puzzle pieces,
would seem to set a variable,
called Counter to 1,
and then show it on the screen.
Then add one to the counter--
So hopefully it's up to two--
and then just say that on the screen.
And repeat, and repeat, and
repeat, and just do this forever.
Because of that block, literally
forever, an example of a loop--
1, 2, 3, 4--
so it's going to go
pretty straightforwardly.
So what are the building blocks here?
We have a loop, we have some functions,
and we have, now, a variable.
Now this gets very
underwhelming quickly.
Let's see if we can't make Scratch
count a little more quickly.
What would be a faster way
of counting than by one?
AUDIENCE: 10.
DAVID MALAN: By 10, we could do.
Or even more so--
20 is more.
So we could obviously
play this for a while.
So why don't we just have
scratch double what he's doing
on every iteration and every cycle?
So how do I do this?
Well, instead of changing the counter
by one, you know what I'm going to do?
I'm going to go ahead
and set the counter--
let me stop the program.
I'm going to go ahead
and set the counter.
And if I dig into Operators down
here, Multiplication, I feel,
is going to add up pretty quickly.
So let me go ahead and set
the counter equal to itself,
times, say, two, and get
rid of this altogether.
So now, on every iteration,
after starting at one,
it's going to go two,
four, eight, 16, 32, 64.
And that would seem to grow--
technically,
exponentially-- much faster.
All right, so we're already counting
pretty much higher than we did before.
But this is still kind of tedious.
What would happen if we instead do this?
Let me go to Looks.
And let me not say the counter for
one second, why don't I just go ahead
and say it by stealing this--
oops, let me get rid of this
block, and just do this.
So let's stop waiting.
Now the cat can count pretty high--
10 to the 70th, 80th, 90th.
Now it just can't even
fit in the speech bubble.
So he's counting pretty high.
This is times 10 to the 160,
10 to the 200 is coming up.
This is kind of inviting the
question, how high can Scratch--
or more technically-- how
high can a computer count?
Yes, last week we only counted
up to, like, eight on the stage.
Now we've already passed that.
And at some point, Scratch
appears to have just given up.
Why?
What's the intuition here, beyond
a 12-year-old not really needing
to count this high
anyway, with this program?
Why does Scratch just kind
of say, that's it, infinity?
What would be the implication of
counting up, actually, forever?
Yeah.
AUDIENCE: You could go back past
the amount of space that you have.
DAVID MALAN: Yeah, you might, right?
Because think about these abstractions
we've built up over the past week.
We know that there's
electricity in zeroes and ones,
and from there, we get decimal numbers,
or any number of other types of data.
But we always, always, always had
a finite amount of battery capacity
in our laptop.
We had a finite number of bits or humans
on the stage or on the chalkboard.
We have a finite number
of zeroes and ones.
And you can only permute--
that is arrange-- a fixed number
of zeros and ones in so many ways.
Eventually, you're going to get
all ones-- one, one, one, one.
And you can't just carry the one again,
because you don't have more hardware.
You don't have more bits.
And so you have to decide what to do.
Scratch decides to just say,
that's it, I can't count that high.
Because MIT has decided to only
allocate Scratch some number of bits
to count super high, but no further.
But if you didn't have that boundary.
And you had, in your memory, a whole
bunch of ones, ones, ones, ones, ones.
And it turns out you can't spend
any more space because you just
don't have the hardware.
The next number after this
value on the board, guess what?
It becomes what?
This is 31, if we actually did the math.
What comes after 31 if
you only have five bits?
Zero, zero, zero, zero,
zero, because the only way
you can change the pattern is
to just change them to zeroes.
So long story short,
there's an implication
for computers of what
they're even capable of.
You might think that they have this
infinite capacity beyond us humans,
but that's not actually the case.
And we're just seeing a tiny
bit of evidence of that here.
Well now let's actually
make Scratch more of a pet,
and demonstrate some
other building blocks
with which we can
navigate a program here.
Let me go ahead and grab
a one green flag clicked.
Let me go under Control,
and go to Forever again.
And let me go ahead now and ask
a question for the first time.
Under Control, I'm going
to go to this If block.
And I'm going to say
something like this.
I want to kind of take scratch for
a walk, if you will, on that stage.
I want him to move around and interact
with me or my cursor on the screen.
So it turns out there's this
category of blocks called Sensing.
And notice this one at the
top, Touching, mouse pointer.
It's kind of a funky shape, with diamond
shapes on the ends, left and right
here.
And so this is actually a
category of Boolean expressions,
questions you can ask that have
yes, no, or true/false answers.
So if I drag this, notice it's the
right shape but not the right size.
That's OK.
It's going to grow to fill it.
And now what I'm going
to go ahead and do
is go ahead and play the
sound, meow, only if Scratch
is touching the mouse pointer.
So now if I go ahead and hit
Play again, nothing's happening.
But notice my cursor is
in the top corner there.
Let me zoom in.
My cursor is now above Scratch.
But now, if I move to pet him--
try this again.
[INAUDIBLE]
[CAT MEOWING]
OK, that's a bug in Scratch, I think.
So logically-- we'll pretend the
last 20 seconds didn't happen.
The program is indeed
working as expected.
All right, so what's going on?
If the mouse pointer is
actually touching Scratch,
we're noticing it in that If condition.
But it's super-important that I have
wrapped it in that Forever block.
Why?
Scratch doesn't seem to be
doing anything forever, does he?
Why is there that forever, Chloe?
AUDIENCE: If you don't
put it in forever,
then there won't be [INAUDIBLE]
DAVID MALAN: Exactly.
If you don't put the Forever, it's
just going to ask that question once.
And honestly, I don't think
I can hit the green flag
and move my cursor quickly
enough to pet Scratch
before it's already asked the
question, if touching mouse pointer.
And so odds are, what's going to happen
is, he's just never going to meow.
But if I instead use
a Forever, he's just
sitting there patiently, waiting
and waiting, without doing anything,
seemingly.
But really, he's listening, if you
will, or waiting for an actual touch
of the mouse cursor.
So now the key here is
that we've embedded,
within a loop, a condition, asking
it again, and again, and again.
And now let me go ahead and
open up another example.
And we'll post all of these
sample programs on the website
later today so you can play with
them if you'd like, or use them
as pieces to your problem set.
I'm going to go ahead and open up
another program here , called Meow 1.
Oops, no, I'm going to
recreate it really fast.
Let's go ahead and do this.
Let me go ahead and Forever, Control--
so do I want to do that one, Meow--
oh, let's do this.
Let me go ahead and open
this one, called Pet 1.
So this one-- notice--
is going to work a little differently.
This one--
[MEOWING]
--is meowing endlessly,
with just enough pause.
But what's going to happen, apparently,
when I do move to pet this cat?
Yeah, he's going to roar.
So in this case, the logic
is a little different.
Let me zoom in on the
puzzle pieces here.
So Forever, if touching mouse
pointer, then Roar, apparently.
Else, just meow.
And at the moment, I'm
not touching the cat.
Notice my cursor is not even near it.
But if I do move it closer and
closer while it's still running--
[MEOWING]
Bug.
There we go.
OK.
Sorry for the bug.
All right, so the reason is I
needed to click on the white stage
so that he would know
my cursor was nearby.
So here we go again.
And now if I move to touch, there we go.
All right, so let me open up
a different one altogether,
to demonstrate some
actual movement here.
Let me go ahead and open up
what's called Bounce Zero.
And this example here--
come on, upload.
Notice what's happening here.
So now we have the ability to
start making something that's
kind of a puzzle-- a
building block for the game
that Steven was playing earlier.
It's just bouncing and
bouncing off the stage.
Why?
Well notice, it's forever doing this.
Every time that Forever loop executes,
he moves 10 steps, apparently.
But if he's touching the edge,
he turns around 180 degrees.
And you can kind of see him
quickly doing that just over there.
And if I zoom out, we'll
see that he's still moving.
But it's not exactly like
real movement, right?
His feet are just--
I can't even do it physically.
But his feet are just
in some fixed position
as he's sliding across the stage.
So let's breathe a little more life,
so to speak, into this program.
What does it mean for
an image on the screen
to give you the illusion of walking?
What would need to happen
to his feet, probably?
Right now, they're just
kind of fixed in place.
Yeah, they need to shift somehow, right?
Like when you walk, let's
consider what happens.
You kind of lift one
foot, and it goes up,
and you could imagine kind of taking
one, or two, or three photographs of me
or whoever while they're
walking on the stage,
and just using those
photographs as examples of where
their feet should be at points in time.
And in fact, we can do this.
I'm going to go ahead and pull
up a slide, if you will, here.
This is the original version of Scratch.
And the subsequent slide
actually looks like this.
Legs are just a little different--
heads mostly those same,
bodies mostly the same.
But there's a little bit of movement.
But notice, this is
just my PDF of slides.
If I go back, forth, back and forth,
back and forth, it kind of looks like--
let me do it with two hands--
it kind of looks like he's walking now.
It's pretty primitive, right?
I kind of need a third,
or fourth, or fifth frame
to make it really look fluid.
But that's all animation is.
Recall from last time, when we talked
about an image, and from images,
we get videos.
Videos are just like 24 or 30 images
per second flying across the screen,
thereby creating the
illusion of movement.
This would be two frames per
second, maybe, just one snapshot,
two snapshots, again, and
again, and again, and again.
But we can go pretty far with that.
So it turns out that Scratch
has this other feature.
It's purely aesthetic.
But it allows you to
have multiple costumes.
So by default, you get this one costume
for Scratch, per the icon at top left.
And you can actually draw any
important GIFs and JPEGs from online
if you want to make things look
differently, like the student did
for the Pikachu game.
But by default, we just
get this one costume.
Well let me go ahead and instead
open up a follow-on example here,
this one called Bounce 1.
And notice this one, if I go back to
Costumes, actually has those two--
that one and that one.
And again, it's just two points in time.
But if I add one puzzle piece here,
in purple, called Next Costume,
if you read the documentation
for Scratch, all that does
is change the costume,
change the costume,
change the costume again and again.
It's saying, next, because it just
toggles among however many there
are-- in this case, two.
So now if I hit Play, it's cute.
It's not really that natural.
But now he's kind of
legitimately sort of walking.
How could we make it a little more fluid
by changing the program, do you think?
Why is he kind of moving so quickly?
Was that a hand in back?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Wait a little
longer before it changes.
Yeah, I can do this in
a few different ways.
Let me try just waiting a
second after he moves 10 steps.
So now he's like tiptoeing.
So that's probably too much.
So rather than wait a second, let
me try waiting 1/10 of a second--
better.
Let me wait a little
less than that, 0.05.
OK, it still looks a
little jittery, but that's
only because we have two
costumes to work with.
But it's a little more realistic, too.
And 10 steps, too, was
how many he was moving.
What's going to happen if I
have to move 20 steps at a time,
or maybe 20 pixels on the screen?
What's the effect going to be?
Bigger steps effectively.
So let's try that.
20, Enter-- now he's
moving quicker again.
So now the wait really
isn't helping because we're
overwhelming it by movement.
How about 30 steps.
Now he's really moving.
Let's go ahead and do
100 steps at a time.
And if we do this enough--
500?
I mean, now he's just jumping
back and forth on the screen.
But again, that's all animation is.
And frankly the game that we
saw played, the Pikachu game,
is really just a fine tuning, in
parts, of those kinds of principles.
Well let's make this actually
more interactive again.
Let me stop that, let me just reload
to get back to a blank program.
And let me go ahead and grab
a when green flag clicked.
And let me go ahead and, under
Control, let me get a Forever block.
And now let me go ahead
and do this, motion.
It turns out that there's
bunches of blocks here.
And we don't honestly
care about all of them,
per se, because they do what they say.
We don't need to sort of exhaustively
explore, I think, all of them.
But this one sounds interesting--
point towards mouse pointer.
Let me go ahead and grab that
inside of my Forever block.
And then let me have it move,
just like one step, not 10.
That's it, four puzzle pieces.
What is this program going to
do once I play the green flag?
It's going to follow the mouse.
So actually, that's kind
of a funny, unintended pun.
The cat is going to follow
the mouse, if you will.
But notice, that's
exactly what he's doing.
He's moving slower and
more smoothly, but that's
just because he's moving
one step or pixel at a time.
As my mouse moves, he's
following it exactly.
I mean, we can really kind
of mess with him here,
because he's just going to
literally do what I say,
depending only on the
speed of my finger.
But now we have the ability to do a
more interactive game, not even using
the keyboard, but using the mouse.
So what more can we do with some
of our building blocks here?
Well this one, let me go
ahead and open in advance,
because it's a whole
bunch of puzzle pieces.
But let me go ahead and open this.
I changed the costume
for this one to be a--
let's see, upload here,
let's call this Bark.
Notice this one actually
has a seal icon.
And let me move the puzzle pieces--
there's actually two scripts here.
And here, we can introduce
the notion of threads.
So it turns out that computers are so
fast that they can kind of sort of do
multiple things at a time.
And that's sometimes a white lie.
But sometimes computers have
multiple cores, so to speak,
or really multiple CPUs.
If a computer has two
or more brains, then it
can literally do two
or more things at once.
One of those might be to
run the program on the left,
the other might be to run
the program on the right.
And we'll see what those programs do.
But also, even in a computer that
just has one brain, one CPU or core,
as they say, computers are so darn fast
and we humans are so relatively slow,
a computer can give the illusion
of doing multiple things at a time
by spending a split second
doing the work over here,
then doing a split second of work
over here, then over here, then
over here, and over here.
And because our CPUs, those Intels
Inside, are moving at 1 gigahertz--
1 billion operations
per second, we humans
don't even notice that it's splitting
its time across these tasks.
It just looks like things
are happening in parallel.
And so when a program is multi-threaded,
so to speak, like threading a needle,
that just means you can have
two things happening-- or more--
at once.
And that's useful here, because
notice, both of these programs
start when the green flag is clicked.
Let me go ahead and hit Play.
[SEAL BARKING]
And then let me lower the volume.
[SEAL BARKING]
Come on.
OK, a little lower volume.
So what's going on now?
How can I make it stop?
If you can read this program,
even though part of it's a little
chopped off.
[SEAL BARKING]
Hit the space bar, and that's going
to mute this program, apparently.
Let's say-- OK, I didn't
hit the Stop icon.
I hit the space bar.
I'll do it again, if you trust me--
space bar, space bar.
So what's going on?
Well, this is an example, now, of
an even more interactive program.
Notice on the left that
I have the following.
I created, in advance, what
apparently is orange and a variable.
I called it Muted this
time instead of Counter.
And again, just good choosing
good words for variables
that say what they are, just to help you
think about what your program is doing.
And I set it equal to literally False.
I couldn't have set it equal to
zero, but I just chose, literally,
the word, False, per last week.
Then, forever, what am I doing?
I'm asking a question.
If the space bar is pressed,
then what do I want to do?
Well, if muted equals
false, change muted to true.
Else, implicitly, if muted is
true, change muted to false.
So it took a few puzzle
pieces there, with the Ifs.
But if the space bar
is clicked, I'm just
checking, well, if this
variable is true, make it false.
But if this variable
is false, make it true.
So it just toggles the value.
Meanwhile, what's the purpose of
this program on the right-hand side,
apparently?
It's a little cut off.
Let me move it over slightly.
What's this program on
the right-hand side doing?
It's making noise.
It is forever barking.
It's playing the sound, Sea
Lion, unless muted is true.
Because before it barks and plays that
sound, it's saying, if muted is false,
then play the sound.
So if it's not muted,
false means no, or zero.
So if it's not muted, play the sound.
Otherwise, what does it do?
Is there an else?
There isn't.
There doesn't need to be.
It can just be a one-way fork in the
road-- either go down it or don't.
You don't have to do something else.
And then it just waits
one second and repeats.
So threading refers to the process
of both of these programs running
at the same time.
And notice that they're sharing
state, if you will, as we'll say,
eventually, sharing a
variable across them.
And that's another way for two
sprites in this case-- or rather,
one sprite, but two scripts, to
actually interact with each other.
We can see another form of this, too.
If you ever played the game in a
swimming pool in the US, growing up,
Marco Polo, where one kid is
blindfolded, or closes his or her eyes,
and then everyone else swims around him
or her, and then you just yell, Marco.
Everyone else is supposed to yell, polo.
And with you eyes closed,
you're supposed to, in a pool,
very dangerously, go find someone, and
tag them, until they then become it.
So in other words,
one human says, Marco.
The other humans say, polo.
How might we actually simulate
this in a program here?
Well, let me open this program,
this one using two puppets.
And notice how this works.
I'm going to hit Play.
And as before, if I hit the space
bar, something's going to happen.
Orange puppet says, Marco.
Blue puppet says, Polo, but only once
the orange puppet has said something.
Marco, Polo-- so why is that?
Well, it turns out that this puppet
is using a different building
block altogether.
This puppet is saying this--
forever, if the space is pressed, say,
Marco, and then broadcast an event.
So it turns out the two
sprites can't see or hear
what the other one is doing.
Just because the one on
the left says, Marco,
doesn't mean the other on the right can
actually see the word, Marco, appearing
on the screen.
To talk to another sprite, you need
to do something a little more secretly
in programming, known as
broadcasting an event.
And this is just a simple
example, but there's literally
a puzzle piece in
Scratch called Broadcast
that literally sends a secret
message to any one other sprite
that might be listening.
And if that other sprite is
expecting it-- and notice this--
I'm currently looking at
the orange puppet's scripts.
If I instead click on the blue puppet,
notice, all he's doing is this.
He's not waiting for the green flag.
He's instead waiting for
a different type of event,
literally the word, event, to be
secretly uttered to him, if you will.
So when he receives that broadcasted
event, then and only then
does he say, polo, for two seconds.
And that word event could
be anything in this case.
It's just the result, now,
of using two puzzle pieces.
The broadcast event to sort of secretly
send a message to all other puppets,
and then "when I receive" instead
of "when green flag clicked."
All right, let's actually now take
a look at one final sequence here.
Let's take a look at how you might
design, now, your own puzzle piece.
It turns out that you're not limited
to only what Scratch provides.
You can actually do this.
Let me go ahead and say this.
If I want to go ahead and, when the
green flag is clicked, let me go ahead
and say something like "cough."
I want Scratch, unfortunately,
to have a bit of a cough.
And then, after he coughs, I'm
going to go ahead and have him, say,
wait for one second.
And I'd like him to do
this a few different times.
It turns out if you
control-click or right-click,
you can start duplicating blocks
to save time, even though that's
a little lazy of me right now.
So all this program does
is, instead of meowing,
it has Scratch coughing,
again, and again, and again.
Now we already know that we can do
better with a program like this.
This is bad design.
The moment you start copying and
pasting, and in Scratch, the moment
you start duplicating, odds
are you're taking a shortcut,
and just making more work
for yourself than you should.
What puzzle piece should
I have used instead?
Yeah, Repeat, as before.
So let me quickly clean this up.
Let me go ahead and detach this.
Let me go ahead and repeat, three
times, just two of these blocks.
So now we have a tighter program.
And it's tighter in the sense that
now, if I wanted him to cough 10 times,
I literally just change one value.
I don't have to go and
copy, and paste, and update
a whole bunch of things-- which, at
the moment, not a big deal for three.
Once it gets to be 10 or
more, you're literally just
creating work for yourself, and making
it harder to maintain the program.
But you know what?
The notion of coughing is
kind of a nice verb, right?
It would've been nice if Scratch
just came with a puzzle piece,
called Cough, that literally
displays cough on the screen
so I don't have to
reinvent this all the time.
Maybe I want a whole
bunch of animals to be
coughing in this particular
game, or animation, or whatnot.
So let me make this code reusable.
I want to never ever again write
code for making a sprite cough.
So it turns out you can do this by way
of your own blocks or puzzle pieces.
If I click on My Blocks at the
bottom, and I click Make Block,
I get this little interactive
window, where I can give it a name.
I'm going to go ahead and
name this block, Cough,
and then I'm going to
go ahead and click OK.
And what I'm now going to do is this.
Now I get this pink puzzle piece.
I'm going to actually move all
of this code from inside there,
to over to that puzzle piece, so that
now I have this new pink block that I
just created, called Cough.
So now, if you look at my
program, this is really
how you want to think about the program.
I want to abstract away from those
lower-level implementation details,
and just say, repeat the
following 10 times, Cough.
And only if you actually
care what it means to cough
do you need to bother
scrolling to the left,
and actually look at the implementation
details, so to speak, of Cough.
So it's a nice abstraction.
We never again need to bother thinking
about how do you make something cough.
You just use it on the right.
But I can take this one step further.
How could I improve the
program on the right,
and in turn, this function
I've created, called Cough?
What would be a nice new
feature to add to it?
AUDIENCE: Add a sound.
DAVID MALAN: Do a count.
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Oh, OK.
We could actually add a sound.
As as an aside, do we have--
OK, we can do this.
Here we go, real quick.
Turns out there's a non-academic
feature here, known as recording.
If you allow your mic--
[COUGHING]
OK, that is what a cough
looks like when you graph it.
We'll call this, Coughing.
Let me go back to my code.
This was not the point of this exercise.
But so be it.
Let me go ahead and say cough and play--
not meow, but coughing.
[LAUGHTER]
OK, so be it.
But I was thinking of something else.
How else can we improve the
functionality, give a little more--
AUDIENCE: Motion.
DAVID MALAN: Give more emotion?
AUDIENCE: No, no, make it move.
DAVID MALAN: Oh, make it move, too.
[COUGHING]
OK, we could do that.
Also not what I have in mind.
Let me-- go ahead.
AUDIENCE: Not a variable
to cough, but [INAUDIBLE]
DAVID MALAN: Yeah, so this was
actually what I was thinking up to.
But those are all great decisions, too.
So Cough right now is just a verb.
It doesn't take any inputs.
But it could, right?
I don't strictly need
the repeat block there.
I could make Cough
just a little fancier.
So let me do this.
I'm going to go ahead and right-click
or control-click on it, and just edit.
I'm going to go back
one step to redefine it.
And I'm actually going to click this
button, Add an Input, number or text.
And I'm going to go
ahead and just call it n.
Computer scientists tend
to call arbitrary numbers n
in the absence of something else.
And then just a label that
says, no functional [INAUDIBLE]..
I'm just going to say cough n
times, just so that the puzzle
piece has some words on it.
So now notice, what's nice--
now, my puzzle piece is fancier.
I can actually get rid of this
repeat block, just attach this,
and say, cough 10 times.
And now this repeat block, if you will,
can become part of the abstraction
such that it repeats not 10 times
here, but I can drag and drop this.
So notice now, the notion of coughing,
if I zoom in, got a little fancier.
You now have a custom puzzle
piece, called Cough n times,
where you, the user or
caller of this function,
specify how many times
you want it to cough,
then you let the code
therein do that for you,
so that now your program
on the right, which
is all you cared about
at the end of the day,
doesn't have to get into the
weeds of all of that complexity.
You can instead just
say, cough 10 times,
and never again think about the
lower-level implementation details.
So this is an abstraction on
top of what that actually is.
Well, let's go ahead now and tie
all of this together if we can,
in some more sophisticated
examples, another one implemented
by a recent student.
Let me go ahead and
open up, not Pikachu's
Pastry Catch, but this one
here, the Gingerbread Remix.
So this one is not a game per se--
although it sort of is--
it's more of a story.
Let me go ahead and hit Play,
and I'll play this one up here.
[MUSIC PLAYING]
All right.
Shall we have an apple?
Let me go ahead and type, yes.
And consider what's happening.
Yes, is probably now my input.
It's probably getting
stored in a variable.
And then that variable
with an equals sign
is probably being compared against
the word, yes or no, in a condition.
Here we go, yes.
[SOUND EFFECTS PLAYING]
OK, bad decision.
So let's play again.
Here we go.
Green flag.
[MUSIC PLAYING]
OK, I'm going to say, no.
Ooh, cupcake-- yes.
[SOUND EFFECTS PLAYING]
OK, poor choice again.
But again, a condition
is probably at play.
Let's play a third time.
No, no.
[WICKED LAUGHTER]
[CRYING]
[STUDENTS LAUGHING]
OK, surprise ending.
So that's a simple
game, now, to give you
a sense of the range
of capabilities here.
And I thought, why don't we take a
look at one final example as to what
you can do with these
various building blocks,
but consider exactly how it
got to this point of complexity
in each of these programs, from
the simplest to the fanciest.
There was not a student sitting
down at his or her keyboard,
and then immediately starting
to program by trying this,
or let me do this, and this, and this.
They thought about a
simple problem there.
So for instance, with the gingerbread
game a moment ago, odds are,
the student just had the princess
come on the screen first-- one
sprite, no witch, no house, no
complexity, and just saying words
on the screen.
Then maybe the witch came into play, and
the witch actually used that Ask block,
and the witch asked a
question, yes or no.
Then, the student probably
wrote some more code
that said, once you get an answer, that
special puzzle piece to that question,
then use a condition.
If the answer is yes, then game
over after a bit of animation.
How did the animation work?
Probably quite like the cat,
bouncing across the screen,
but this time, just one
direction, no bounce.
Then as soon as the witch's apple or
cupcake got close to the princess,
turns out there's a block that says
if one sprite is touching another--
like in the vicinity of the other--
then something else can happen,
and thus something came
on the screen there, too.
And so with problems that zero,
ultimately, the homework is going
to be quite simply, make almost
any Scratch project of interest
to you-- a game, an interactive
art, an animation, or the like.
But the key is to think about
it from the ground level up.
Make just one feature at a time--
one cupcake, one apple, one witch,
one princess, and begin to
layer on top of that complexity.
For this last example, made just a
couple of years ago, as CS50 at Yale
was just getting off the ground--
could we have one final volunteer?
Yeah, OK, come on up.
What's your name?
AUDIENCE: Alvin.
DAVID MALAN: Alfred.
AUDIENCE: Alvin.
DAVID MALAN: Alvin, Alvin.
Come on up, Alvin.
All right, this is Ivy's hardest game,
pitting not just Yale and Harvard,
but other Ivys against each other.
Nice to meet you.
We're about to see the
instructions on the screen.
And odds are, we'll muster some
support of the audience here.
Here we go, just a keyboard-based
game-- up, down, left, right.
[MUSIC - MC HAMMER, "CAN'T TOUCH THIS"]
Very nice.
So now second level--
crimson's in the way.
Level three, two crimsons.
And again, think about
the building blocks.
Now we're up to what, five
sprites on the screen?
But each of them is operating
independently, and bouncing.
MIT's a little smarter.
[LAUGHTER]
Nice.
Very similar to that cat
following the cursor.
Nice.
Second-to-last level.
[CLASS OOHING]
[APPLAUSE]
[CLASS GROANING]
Try a couple more times.
Two more lives.
OK, no, round of applause
would be good for Alvin.
[APPLAUSE]
OK, so that's it for today.
The first homework assignment will
be posted on the website tomorrow.
We'll stick around for
one-on-one questions.
A pleasure to have you in the course.
See you all soon.
[APPLAUSE]
