[ROCK MUSIC]
[MUSIC - "HAPPY TOGETHER" THE TURTLES]
DAVID MALAN: Today, we begin our exploration of the
fundamentals of computer science and our introduction,
now, to the art of programming, of which that is
just one example.
But in the same vein of problem solving, know that
CS50's traditional Puzzle Day is tomorrow.
If you've not yet RSVPed for this event, you can go to
cs50.net/rsvp.
You can bring teams of two or three or four.
You will be challenged with problems like the one you saw
up there in the beginning.
All new problems this year if you partook last year, and you
will have a chance then to win some fabulous prizes.
Among them, a Wii and some gift certificates and like,
all while hanging out with CS50 students and classmates
and pizza and Facebook.
So more on that tomorrow if you would like.
>> This then is CS50, for those of you joining us for the
first time.
And know that this course is particularly determined to get
you through this course to its final end, at which point you
will have not only an understanding of these
fundamentals of computer science, but you will have
this very practical skill set that you can then take back to
your own department, whether it's engineering sciences,
applied mathematics, the physical sciences, natural
science, or the like.
Indeed, what's so exciting about computer science these
days is that it is just so applicable to
all sorts of fields.
And even though today, we will only scratch the surface of a
very traditional programming language known as C, we'll
instead look at something called Scratch, something with
which that cookie love story was implemented by one of your
predecessors in years past, to tell stories, to create games,
to create interactive art, and to actually start to wrap our
minds around some of the fundamental constructs that
underlie programming but in a context, as you'll see, that's
much less scary, that's much less arcane, than you will see
before long.
And realize, too, for those of you just joining us this
semester, the phrases on which we ended Wednesday's lecture,
it is not so important where you end up relative to your
classmates in this class, but where you, by semester's end
in week 11, end up relative to yourself right this very day.
>> So without further ado, this is also worth noting that
those less comfortable, those somewhere in between, are
also, by design of this course, not at any disadvantage
vis-a-vis those more comfortable
coming into this class.
As you'll see over the weeks to come, we have different
tracks for disparate back background, sections for those
less comfortable, more comfortable, those somewhere
in between.
As you'll see this weekend and next week, two versions of
most problem sets in both standard and hacker edition so
that you all can self-select down the path with which you
are most comfortable.
>> So today, we dive into this programming
language called Scratch.
It's a graphical programming language, and yet it has the
same features of some of the higher level languages we'll
explore later in the semester, among them C and
JavaScript and PHP.
But it's going to allow us to avoid some of the distractions
early on of syntax, things like semicolons, parentheses,
and other arcane details that, at first glance, are just not
at all intellectually interesting and tend to get in
the way from some fundamental understanding.
In terms of now the support structure ahead, realized this
tool, CS50 Discuss, which will be linked on the course's
website later today, is the online discussion forum in
which you'll be able to ask questions of each other and
staff, and it's also a tool, as we'll see next week,
that we'll use quite integratedly in
office hours as well.
Indeed, office hours begin on Monday, and frankly, the first
week of office hours is fairly low key.
>> I don't think you'll find Scratch all that inaccessible.
It's rather self-explanatory, as we'll see, and so what
we'll use it for today is to extract some of the
fundamental ideas that will, then, persist throughout the
rest of the semester.
But starting Monday, at 8:00 PM through 11:00 PM will be
office hours in Annenberg over brain break.
Sectioning two will begin this evening, so sometime this
weekend, go to cs50.net/section, and you'll
be asked a number of questions.
Among them, how would you describe your
comfort level as of today?
There's no hard, fast rule as to who's in which bucket.
It's just the sort of thing that you probably know if you
are among those the less comfortable or otherwise.
>> And now, walkthroughs.
The problem set specification for this week, both standard
and hacker edition alike, is online at cs50.net as of now.
And you'll see that the first of these editions, the
standard edition each week, is accompanied by something we
call a code walkthrough, a session led by one of the
course's teaching fellows to guide you through, provide
tips on, and get you down a particular path when it comes
to starting these problem sets.
So with each of these problem sets, if you're ever wanting
for yourself where do I begin, you begin with these
walkthroughs.
And in fact, allow me to introduce Zamyla Chan, this
year's teaching fellow who will be leading each and every
one of these walkthroughs.
Zamyla?
>> [APPLAUSE]
ZAMYLA CHAN: Oh, hi, everyone.
My name is Zamyla.
I'm a junior studying engineering in Winthrop House.
But I try and fit in as many computer science courses as I
can, which is why I'm really excited to be leading this
year's walkthroughs.
Walkthroughs, for me, were an essential part of my CS50
experience.
During the walkthrough, for every p-set, we'll go through
the problem set together, look over the problems, kind of
divide them up into manageable bites.
I'll give you tips, techniques, for getting
through and getting started.
I hope to see you all at the walkthroughs.
If you can't make it in person, then
please do tune in online.
>> DAVID MALAN: Excellent.
Thank you, Zamyla.
So realize that walkthroughs are, indeed, on a Friday
afternoon, but this is deliberately by design so that
even if you'd rather not attend class on a Friday
afternoon, the videos will be up all the more quickly over
the weekend.
So realize that cs50.net will be all of Zamyla's
walkthroughs.
And that there is today's date and time, 3:00 PM,
Harberd Hall, 104.
And some of the teaching fellows have also prepared
some remarks for you in absentia to give you a bit of
perspective as to what their experience coming into and
going out of CS50 was like.
So if we could dim the lights for just a moment, I give you
some of CS50's staff.
>> JACKSON STEINKAMP: I took CS50 last year as a freshman in the
fall, and it absolutely blew my mind.
I had never taken any programming classes before,
and never came in with any computer science
experience at all.
And just, I heard the buzz about the class and
decided to take it.
>> JULIA MITELMAN: It was really fun, really engaging.
I still, to this day--
I just recently saw I have the floppy disk that David gave us
on our first day of lecture.
I had hung it on my wall.
This is probably a little nerdy, but I hung in on my
wall during the class as a reminder of how cool it was.
>> TRAVIS DOWNS: It's so embarrassing.
>> JACKSON STEINKAMP: Computer science is something you
should try even if you're not one for
the traditional sciences.
It's its own experience, and CS50 will make sure you're
supported well through it with its veritable army of TFs.
>> ALI NAHM: I took it as a freshman, and so I made a lot
of new friends.
I also got introduced to this entire concentration and
entire school of engineering, and so I highly recommend it
and welcome you to our CS50 family.
>> YANIV YACOBY: CS50 just teaches you how to use tools
that are widely accessible.
You just need a laptop, you need a web browser, and you
need to learn to write some code, and you can really build
neat things.
>> KAREN XIAO: It's just so cool to be able to make something
and have people use it and have people see it, and that's
what I really love about it.
>> TIM MCLAUGHLIN: --a sense of community, I think, in this
course more than any other course I've taken so far.
You're not just taking another--
you're not filling another requirement.
You're not just going to lectures and going to section.
But you're doing tons of things that are all about
programming and all about technology, but it doesn't
really feel like a class most of the time.
>> TRAVIS DOWNS: And on the first day, they handed out cake, and
I was instantly sold.
>> JACOB PRITT: Free candy and pizza.
>> ZAMYLA CHAN: --regardless of your interest level, I think
that CS50, you'll have fun, and you'll be intellectually
stimulated.
>> MARK GROZEN-SMITH: It's always a party in class, and it's a
party every night working on your p-set.
>> JACKSON STEINKAMP: Each time you finish a problem set, you
will feel like you've finished a project.
>> MELISSA NIU: It was freshman year, and I was done shopping.
I had my four classes ready, and I was in Annenberg.
And I bump into a friend, and he says, hey, I'm shopping
this class called CS50, and you should come with me.
Ended up taking it that fall, and after that class, I
thought maybe I'm going to minor in CS.
But here I am, three years later, still studying computer
science and actually doing it as a major, and I loved every
moment of it.
>> ROB BOWDEN: I have no idea.
>> ALI NAHM: Let's see.
>> MELISSA NIU: Craziness.
>> SPEAKER 1: I feel like I'd be very cliche.
I'd just say, like, awesome.
>> YANIV YACOBY: Accessibility.
>> JACOB PRITT: Free candy and pizza.
>> TRAVIS DOWNS: Can't turn down a class that hands out cake.
>> TIM MCLAUGHLIN: Energetic.
>> VIPUL SHEKHAWAT: Essential.
>> ROB BOWDEN: Let me think of an answer.
I think I got something.
Oh, god.
Yeah, my name's Rob Bowden, and this is CS50.
>> [APPLAUSE]
DAVID MALAN: All right, so let's start to paint a picture
of the direction in which we can go, and let's introduce
this concept here known as pseudocode.
So pseudocode is not a programming
language unto itself.
It's nothing technical per se, but it's just sort of a
general way of expressing yourself fairly precisely,
fairly algorithmically, fairly procedurally, but without
having to worry about what language you're expressing
yourself in.
It's some model of English and programming languages with
which you happen to be familiar, so we can start
writing this sort of thing as we go.
And in fact, Joseph, could I borrow you up on stage to be
scribe here?
I've gone ahead here in advance and forgotten to put
on some socks today, and this'll be among our more
ridiculous examples.
>> Now, I need you over here.
I'll do the socks part.
So here we have a little scratch pad.
This is literally just TextEdit in a Mac.
We're not actually going to write a runnable program, but
we're just going to start sketching out pseudocode based
on some of the counsel you provide to me here.
So here is my pile of socks at home.
I have no socks on when I wake up in the morning, and we now
need to write a program, an algorithm of sorts, with which
to get these socks on my feet.
And along the way, let's see if we trip over, or encounter,
some of the ideas that you're going to have to start
thinking about much more seriously when programming
lest your programs don't behave quite as intended.
>> So I sit down here.
I've got my pile of socks.
What's the first thing a reasonable human being would
do when the goal is to put on a pair of socks?
Someone give me one step, and only one step.
Yeah?
AUDIENCE: Bend down.
DAVID MALAN: Bend down, Okay.
Step two.
AUDIENCE: Pick up your sock.
DAVID MALAN: Pick up your sock.
Okay, so slight ambiguity here, and this is one of the first
stumbling blocks that we're supposed to deliberately
encounter here.
It's a little ambiguous, so pick up your sock.
Fine, I'll take this one, but a computer, realize in just a
bit, is not going to have that sort of human instinct to just
pick the nearest one.
We're going to have to start, before long, expressing
ourselves more precisely.
>> All right, so step two is pick up your sock.
We'll take it.
Step three.
In the back.
AUDIENCE: Find a matching pair.
DAVID MALAN: Find matching pair.
Okay, so this is good.
I had to choose this sock.
So the goal is to find a matching sock, now, but what
does that mean?
A reasonable human being, much like on Wednesday when I just
knew how to find Mike Smith in a phone book, just kind of
went with their instinct.
But here, it's obviously this sock here, but a computer's
not going to be so instinctive.
A computer is going to have a collection of bits, as we
discussed on Wednesday, and those are
organized somehow in memory.
But the point is that a computer has only the ability
to look at things one at a time, and in fact, even we
humans-- even though it feels like I glanced down and a split
second later I know where the sock is, my brain and my eyes
presumably did a quick skim of those socks, and then latched
on to the one in question.
>> So if we be all the more deliberate now as a computer,
how do I find this matching pair?
Well, we have to iterate.
We have to perhaps loop over this mess of socks on the
floor whereby I say something like FOR EACH sock, pick it
up, AND IF the same shape and size as the other one, THEN
dot, dot, dot, we'll continue the story.
So for each sock, so I pick up this one.
I check is this equal to this one.
It's not, so I put aside side.
Then I iterate again.
Is this one equal?
No, it's not, so I put it aside.
Is this one?
No.
This one?
No, and so forth.
And then finally, hopefully, I will encounter this sock here.
So if it's the same shape, size, take it.
>> And now, what would be our next step here?
Yeah?
AUDIENCE: Identify right from left.
DAVID MALAN: Okay, identify right and left, so
fortunately, that kind of works.
A little symmetric, or I've just worn them that way.
All right, so I've identified the right.
And now, before we proceed, let me point out what Joseph's
been doing here as sort of a versed programmer.
So again, there's no one way of doing this, but beyond just
numbering the lines, Joseph has already started to do this
sort of indentation.
Indeed, this is a very common convention in programming,
whereby when you do something iterative, looping style, as
we're implying with the English phrase "FOR EACH
sock," the convention in pseudocode and, as we'll see,
normal programming languages, is to just indent.
Hit the space bar a few times, hit the Tab key or the like,
so that nested underneath "FOR EACH sock" is the chunk of
stuff that you need to do as a result of that loop.
So that's all that's conveying semantically.
Now meanwhile, the "If it's the same shape and size," the
fact that "Take it" is indented further just means
that's the only thing you should do if that condition,
if that branch, that fork in the road, is in fact true.
>> So now here, we're on step four, identify right and left.
I've identified right.
Give me step five.
And technically, we could really call
the FOR EACH thing--
you should probably number all the lines if
we're going to do this.
JOSEPH: [INAUDIBLE]
DAVID MALAN: [INAUDIBLE]?
Okay, fine, all right, we'll do it your way.
All right, so step five, how do we do the right sock?
How do we proceed next, here?
Yes?
AUDIENCE: Lift up right leg.
DAVID MALAN: Lift up right leg, Okay.
Step six?
Quickly.
Yeah.
AUDIENCE: Find an open end of the sock.
DAVID MALAN: Okay, find the open end of the sock.
So good.
So here, honestly, a very common instinct would just be
put on right sock, but that too is fairly ambiguous.
Unless the computer or human knows exactly what that means,
it's not going to be to execute that, so here, I've
found the opening of the stock.
Step seven?
AUDIENCE: Touch your toes.
DAVID MALAN: Touch toes.
Okay, so now we go--
All right, I'm going to take some liberties here.
Thanks.
Step eight?
Put on sock.
Okay, so now I, think we're close enough to sort of take
this one at home.
All right, so this goes up.
I'll take some liberties with what it means, actually.
Put the sock on.
All right, now step nine?
AUDIENCE: Put foot down.
DAVID MALAN: Thank you.
Step nine, put foot down, and now, we can repeat.
So presumably, we can now go into step 10 and say identify
left sock, but that's presumably already done.
>> And so then, I can sort of repeat these steps.
But this sort of begs the question.
Before, the last time we wanted to repeat something, we
did it iteratively, again and again, a FOR
EACH loop so to speak.
Would it make sense to use a loop in order to handle both
the left and the right sock?
Because it feels like these operations are pretty much
identical except for the fact that one starts here and one
starts here?
Do we loop, or do we just keep writing steps
10 and 11 and 12?
AUDIENCE: Loop.
>> DAVID MALAN: Okay, so loop.
I actually might have said just keep going.
So why is this the case?
Well, this is actually the first of our non-obvious
design decisions, and in fact, one of the metrics with which
we'll begin to evaluate, for ourselves and for you, the
quality of a program is just how well designed it is.
Have you done the minimal amount of work necessary to
get the job done the most quickly, either in terms of
your time or in terms of the computer's running time?
How many operations does it takes to execute?
So arguably, this is an opportunity for a loop because
as soon as I start copying and pasting, as Joseph effectively
would start doing in a moment, you're kind of wasting your
time, and you're being doubly expressive.
>> But at the same time, these are really just two special
cases, left and right.
And whereas before, I might have 10 or 20 or more socks in
a pile, it definitely makes sense not to have 50 lines of
code saying check this sock, then the next one,
then the next one.
Here, it's a little less obvious, and I would proposed
that we could go either way.
We could either have that loop, although it only loops
twice, or we could simply copy and paste just a little bit
here in order to get the job done.
But this program is buggy, so to speak.
It might have some mistakes, errors, or corner cases, so to
speak, that we didn't really anticipate.
Nothing went wrong this time, but what could have gone wrong
while executing this program?
AUDIENCE: You don't have any socks.
>> DAVID MALAN: So there could be no socks there whatsoever.
So let's consider that corner case.
So if we could scroll back up to step one, so step one was
bend down, so that checks out.
Step two, pick up your sock, but then find matching sock,
identify right.
We kind of made a whole bunch of assumptions, and this is,
frankly, why program sometimes crash.
If you, the programmer, have made certain assumptions, like
surely there's going to be socks or surely there's going
to be memory left in the computer, surely there's going
to be disk space left on the hard drive--
Well, if you make these assumptions, and that's not,
in fact, reality, who knows sometimes what the computer's
going to do?
And sometimes, when you get the spinning beach ball or the
frozen Windows or the like, that's precisely because some
programmer did not anticipate those so-called corner cases.
What else could have gone wrong in this program?
Yeah?
>> AUDIENCE: You don't have a right leg and a left leg.
DAVID MALAN: Okay, might not have both a right leg and a
left leg, and so this program might not be universally
applicable.
Others?
AUDIENCE: You might have picked up an orphan sock.
DAVID MALAN: I might have picked up an orphan sock, so a
non-matching sock that just has no siblings because I've
lost it, it's torn, it's in the wash still, or the like.
So that, too, hasn't really been handled.
Yeah?
AUDIENCE: You might already have socks on.
DAVID MALAN: I might already have socks on.
I didn't actually check.
IF you don't have socks on, THEN proceed to do
line one and two.
And that could happen.
You fall asleep with your socks on and the like, so
that, too, a very reasonable corner case.
And maybe one other?
AUDIENCE: The sock is inside out.
DAVID MALAN: So the sock is inside out, so we did no error
checking, in short.
We didn't check if the state of the world is as we expect.
We didn't check if we actually found what we're looking for.
>> And even though this is sort of a ridiculous example
involving socks, at the end of the day, this is exactly the
sort of mindset you need to have while writing programs,
even in Scratch as well as in C, in JavaScript, in PHP,
because otherwise, your programs will exhibit the
equivalent of that spinning beach ball or just yield
inaccurate results.
So many thanks here to our scribe Joseph.
[APPLAUSE]
>> DAVID MALAN: All right, so what is, in
fact, a computer program?
Well, let's take a quick glance at a
representative one here.
So this is a program written in a language called C. C is
fairly old these days, but many newer languages are built
on top of it.
Indeed, PHP, one of the web-centric languages we'll
use toward term's end, itself has what's called an
interpreter, a program that's written in C, but more on that
in many weeks from now.
But this program, and this is what it means to write a
program, albeit a very simple one.
We have some fairly cryptic syntax here, but you can
probably guess, even if you've never programmed before, what
this program does.
Indeed, I don't know what printf is, but print certainly
conjures up the idea of printing something out.
And so yes, this program is ultimately going to print out
the words "Hello, World."
>> Now, whether you have a Mac or a PC or a Linux computer, odds
are, at least if you downloaded some freely
available software, you could have been writing programs on
your own laptop for quite some time now.
On Mac OS, for instance, there's this program called
Terminal that comes with a Mac, that's usually in your
Utilities folder, and it generally opens a black and
white or a white and black window at which you have a
prompt at which you can type commands.
So this is actually reminiscent of what computers
used to be before graphical user
interfaces, GUIs, came along.
Now, in Windows, you have a similar mechanism in the form
of the command prompt.
>> But what I'm going to do here is open up, let's say,
TextEdit again, so the same program we were using for
pseudocode a moment ago, and I'm going to go ahead and
write my first program.
Include stdio.h, whatever that means, int main
void, whatever that means, and then in the middle here,
printf("hello, world."). And then close quote,
close paren, semicolon.
Now I'm going to go ahead and just hit Command-S. I'm going
to go ahead and save this as hello.c, so the convention in
the world of C programming is name the file dot c.
I'm going to just put in John Harvard's Home directory,
here, click Save, and now I'm going to go over to this
terminal window, which again is this black and white prompt
where I can execute commands.
>> I can run programs by typing their name, not by
double-clicking icons in the usual sense.
But the thing is about C is that a language like C first
comes in this form, something called source code.
Something that looks a little like English but is
definitely less like English than Joseph's pseudocode a
moment ago.
It's a little more arcane.
It seems to follow some patterns or rules.
The fact that I have curly braces, semicolons, quotes,
angle braces, feels like a computer came up with this
sort of language.
But if I go, now, to this terminal window, I can run a
command that's going to convert that source code is
something called object code.
That's going to convert English-like syntax to zeros
and ones, the same sorts of zeros and ones we
talked about Wednesday.
Now, I'm going to run a command called Clang.
More on this in the weeks to come, but it's a program with
which I can convert hello.c into a whole bunch
of zeros and ones.
>> Now, I've run this command.
I've run Clang, and then I said run yourself on this file
called hello.c, which I created a moment ago, and
nothing seems to happen.
But indeed, if I poked around my home directory, I would see
that this stupidly named program a.out now exists.
This is just the default name for a program when writing in
C. We can override this eventually, but a.out is the
name of the program I just converted into zeros and ones.
And now that it's zeros and ones, my Mac, in this case, or
your Windows PC, can understand those bits, those
zeros and ones.
And so when I hit Enter, I see "hello, world!"
>> But it's a bit buggy.
I didn't quite say "hello, world!:air:- jharvard." Air is
the name of my computer.
Jharvard's the name of the account, so what did I clearly
omit from the program?
Some kind of line break.
I didn't hit the equivalent of Enter or the carriage return,
and this is, again, testament to the fact that computers can
only do what you tell them to do.
And the fact that I didn't tell the computer move the
cursor to the next line--
well, it's certainly not going to just do it
presumptuously for me.
So if I go back to my program, and I say \n--
So \n, as we'll soon see, is the way of
representing weird things like new line characters, things
that would otherwise be the result of
hitting the Enter key.
But for now, just know that hitting the Enter key would
just make our code look odd, so the world decided, you know
what, to keep things prettier, to keep it on one line, let's
just say \n represents a new line.
Let me resave my file, go back to the terminal window, and
re-run a.out, Enter.
Still buggy, but why?
>> AUDIENCE: [INAUDIBLE]
DAVID MALAN: Yeah, so I need to recompile it.
So to compile a program just means convert it from source
code to object code, source code to zeros and ones.
Now, the mere fact that I hit Save in this TextEdit has no
bearing on those zeros and ones because I first need to
tell Clang hey, I've changed those lines of code, the
source code.
You need to regenerate a.out.
Nothing appears to have happened, but in a computer,
at a command line, so to speak, when nothing happens,
that usually means all is well.
When something does happen, it means
you messed up, generally.
>> So let's now go to a.out, and indeed now, I have "hello,
world."
And now, what about these zeros and ones?
Where, in fact, are those?
Well, I can't really just kind of poke around very
effectively.
Let me open up TextEdit.
Here's a.out.
Let me go ahead and open this, and this is apparently what my
program looks like.
So I've opened, not hello.c, but a.out.
But this is actually not what my program really is.
Clearly, this is some kind of alphabetical characters.
I see no zeros and ones, but this is
because a.out is a program.
Zeros and ones-- but TextEdit, as the name suggests, it's
just like Notepad on Windows, is just a text editor, so it's
confusing all of those zeros and ones as
though they were, what?
ASCII characters.
>> So recall on Wednesday, we just came up with this
arbitrary mapping of numbers, or bits, to letters of the
alphabet and punctuation symbols and the like.
So TextEdit, that it's a text editor is misinterpreting
those patterns of zeros and ones that are supposed to be
printing words, like "hello, world." It's displaying them
as ASCII, and that's why it looks a little messy.
Now, there are some hints of correctness in here.
Notice if I highlight, there is a hint of actually "hello,
world," so somewhere in that program is
the sentence I wrote.
But let's go ahead and now see with a different program.
This is not one we'll use that often, but it also comes with
a Mac and will be inside of the CS50 appliance.
Let me go ahead and open with a program called XXD.
>> Back in the day, most programs were named fairly cryptically,
and so the trend continues.
But -b means spit this program out as binary.
Don't run it.
Display it to me as zeros and ones, and this is the C
program we just wrote.
Now, I, as a human here, I honestly have no idea what
these various patterns of zeros and ones represent.
Back in the day, I, with my punch cards or the like, would
actually have to look up what these various patterns of
01111000, actually represent.
Or worse, I would need to do the punching or the creation
of these patterns of zeros and ones.
But for now, take on faith that a CPU, Intel inside, so
to speak, inside of all of our computers these days, knows
how to interpret these zeros and ones.
And some zeros and ones mean print.
Some zeros and ones mean play a sound.
Some zeroes and ones mean take user input from a keyboard.
There's all sorts of different patterns, but we thankfully,
as humans, only generally need to worry about programming at
this fairly higher level.
And in other CS classes can you delve down deeper and look
at things like those zeros and ones, or yet
other things still.
>> So now let's convert this.
Let's move very quickly away from C and move to something a
little more comforting, a little more exciting, in that
we can get back our animations and sounds and the like that
clearly have escaped us in this
fairly primitive interface.
So this same program in C can be represented now in this
programming language called Scratch as follows.
This is the equivalent of this hello world program written in
this puzzle piece style language called Scratch.
So let me go ahead and open up this very program.
It's again called Scratch.
It's freely available, and this is the same thing we
started today on.
>> So this here is Scratch, and it's broken up into a few
different pieces.
On the very top right, we have the so-called stage, and
indeed, that's where the cookies
performed just a bit ago.
And on that stage are things called sprites, characters, or
objects, or entities.
It doesn't really matter how you think of them, but they
are programmable, movable things, and in this case, this
program that our student wrote has a couple of gingerbread
cookies, a couple of circular cookies, a whole bunch of
hearts, a whole bunch of eyeglasses.
Because of this, he or she is able to program each of those
individual characters separately.
>> Now, what does it mean to program these characters?
Well, let me go ahead and click on this left hand cookie
and scroll over to the top left here.
In the top left of my screen now is the
so-called scripts area.
This is sort of a blank slate, initially, onto which I can
drag and drop puzzle pieces that, frankly, do
exactly what they say.
At the very top of this stack of puzzle pieces is the word
When Green Flag Clicked, and if you didn't notice before,
the way I started that cookie song was clicking, literally,
a green flag.
So that puzzle piece at top left there means when the
human clicks the green flag, proceeded to do
the following things.
>> Now, what did they cookie proceed to do?
I don't really know how to interpret this yet, but the
cookie apparently set its groove to zero, then it waited
three seconds, then it changed its group to one, then it
waited a second, then it changed its
groove back to one.
And then this actually looks like a bit of a bug, shouldn't
have to change its groove again and again unless it's
being changed elsewhere, but this series of steps is what's
dictating the behavior of this particular cookie.
So let's actually scroll back and not look at something
quite so complex yet.
Let me go ahead and go to File, New,
and get a clean slate.
>> So now, I indeed have an empty script area, an empty stage,
with our default sprite Scratch, and at the top left
on my screen do I have the pallet of all of their
available puzzle pieces.
And we won't go through nearly that many of these things
today because, again, most are self-explanatory, but we will
try to categorize them and point out the similarities
with these future languages to which we will dive.
And at top left here is the first When Green Flag Clicked,
so let me drag this over here, zoom out a bit.
And if I click the green flag, nothing really happens because
I haven't attached any logic, any statement so to speak, to
that green flag, so let me go up to the
categories over here.
I'm currently in the Control category.
I'm instead going to go down to the Looks category, and
there's a whole bunch of things here that say Say,
Think, Change Color, Switch Costume.
>> So you can do silly things with costumes and
sounds and the like.
Let me go ahead and just say Say, and now notice as I drag
and drop this puzzle piece, it's going to want to latch
into the corresponding shape.
So when I go ahead and let go of my mouse, they lock
together, and now if I go over here and click the green flag,
the cat does in fact say hello because that's what is inside
of this white box.
We'll soon see that this white box is what's called an
argument, or a parameter.
It's a way of changing the behavior of, in this case, a
puzzle piece, but if I want to say exactly what I said
before, say hello, world, I can now go back over here,
click play, and "hello, world" is what's said.
>> So we are literally programming now.
It's not all that compelling of a program, but at least
it's a little more compelling than something that looks, at
first glance, like this.
And we can very quickly get all the more expressive
because in Scratch, like in other languages, there's all
sorts of statements, not just Say or printing something, but
you can do things like waiting, as we just saw with
the cookie, some number of seconds.
You can play sounds in the environment of Scratch just
like you can in a normal computer program play sound.
You can check what are called Boolean expressions.
So now, let's start to add to our toolkit some terminology
that actually relates to the example that Joseph and I did
here with the socks.
So statements are just statements of fact.
Do this.
A directive for the sprite, or me the human, to do something.
A Boolean expression is something that has a value, a
so-called truth value, that's either a zero or one, false or
true, off or on, no or yes.
Doesn't really matter how you think of this, but it's a
binary state.
As Nate discussed in Wednesday's video, two
different things.
>> So in Scratch, Boolean expressions happen to look
like these blue objects here, and in this case, the question
mark implies that you're asking a question.
Is the cat, or the sprite, touching the mouse pointer?
So this is just one example of a Scratch block that's going
to allow us to check yes or no, is the mouse touching the
sprite on the screen?
And this can be useful if you actually want to do things
with your mouse.
In addition to Boolean expressions, we have things
like is the mouse down, so you can detect that kind of
question as well.
We can do mathematics if you actually want, and there's
actually more compelling uses for this than just pure of
arithmetic, as we'll see.
Pseudo randomness and making your program appear to think
or behave differently based on some seemingly random values,
and then we have things like Boolean expressions like AND.
So if you actually want to check two values, we'll see in
Scratch that we can actually test if this is
true and this is true.
For instance, in the case of my socks, I could've at the
very end asked the question if left sock is on and right sock
is on, quit.
You're all done for the day, so that would be an
opportunity for that.
>> So let's go ahead and try to piece some of these together
and go into a couple of examples more
compelling than this one.
So let me go ahead here and open up some of the examples
that will always be on the course's website as well, and
open up hello2.
So in hello2 here, we have a program that's doing a few
things, but it's not doing it as effectively as we might.
So here it says "hello, world" for one second and then waits
for a second.
And then does it again, and then does it again.
So if I click the green flag, Scratch says "Hello, world.
Hello, world.
Hello, world." And this is obviously candidate now for
improvement.
>> What's the marginal improvement, hopefully, we can
now make if Scratch supports the concept?
Some kind of loop.
Some kind of repetition, now, would be nice, so let me
actually try that.
Let me actually go and move this.
So notice can detach blocks as easily as you can add to
attach them.
Let me go under Control, scroll down here, and indeed,
there's this puzzle piece here, Repeat and Forever and
Forever If.
So there's a number of ways of expressing looping constructs
in Scratch.
The one I probably want here is not Forever because I only
want this to happen three times, but probably Repeat.
So let me drag Repeat over here, drag and drop it, and
now instead of saying "hello, world" three separate times,
let me drag this puzzle piece in here.
And even though it doesn't seem to fit, the program is smart
enough to realize it will grow to fill, so it's the
shapes that matter and not the absolute size.
Let me change the repetition to three, and now let me go
ahead and drag Wait One Second in there as well.
It's going to snap in as well, and so now I'm going to drag
these guys over here and just throw them away because I
don't need them anymore.
Let me zoom out and click the green flag now, and we have
the same program but, as I predicted before, better
designed because you can imagine how bad this program
would get, certainly aesthetically, if you had to
start copying and pasting, copying and pasting, or
dragging and dropping the same darn things again and again.
>> Now, simply saying stuff on the screen, printing to the
screen, really all not that exciting, so let's open a
third variance here.
And now, as you'll see, this'll quickly get annoying--
[MEOW]
DAVID MALAN: --but it's also kind of cute.
[MEOW]
DAVID MALAN: Okay, so better, and we can certainly use that
same transition of chunking this up into a looping
structure, but let's make it more interesting still.
>> Let me go ahead and open up a fourth variance here, where I
take things one step further.
So according to this, silly though this is at first
glance, what is this program going to do?
It's going to meow once.
Why?
Well, one is, as far as I know, always less than two.
There's no notion of randomness here.
I've literally hard-coded one and two, but this is an
example now of actually using a Boolean expression.
Much like as Joseph did in his pseudocode, the indentation IF
you find matching socks THEN do the following, here we have
an expression IF one is less than two THEN--
and in fact we even have a little bit of indentation,
where the purple is slightly indented to the right--
THEN you're going to play the sound meow.
Now, in this case, that one is always less than two, so this
is kind of a waste of a condition.
But we'll be able, as we'll see, to plug other things into
these placeholders where one and two now are.
So let's now advance to example five of these several
hellos and look at what this program's going to do.
>> So now, in an English sentence, how does this
program behave?
AUDIENCE: Meows half the time.
DAVID MALAN: Meow's half of the time, so this is a way of
conveying a very simple idea.
Even though we happen to be using some inequalities here
in some numbers, this is really just a programmatical
way, a precise way, of saying if the coin comes up heads, go
ahead and meow.
Or conversely, if the coin comes up tails, don't meow.
And in this case, how do we express that?
We'll pick a random number from 1 to 10, and if that
number is less than 6, go ahead and meow.
And how did this get in here?
Well again, notice just the dragging and dropping and
things latches into place.
>> So now let's see if this randomness works.
Let me go ahead and click the green flag.
[MEOW]
DAVID MALAN: Okay.
[MEOW]
DAVID MALAN: Okay.
Okay, good, so we got heads, heads, tails effectively.
Tails.
[MEOW]
DAVID MALAN: Heads.
[MEOW]
DAVID MALAN: Excellent.
It's always awkward when just statistically you get a bad
run, and it's all heads, and the program actually doesn't
work as you'd hope.
But this time, it worked, and we seem to have, if we did
this an infinite number of times, 50% odds.
Now again, not all that interesting, just making cats
meow, so let's see if we can't advance this a bit further
here in version six.
So now, we have really annoying version--
[MEOWS EVERY FEW SECONDS]
DAVID MALAN: --and this is what's known, general, as an
infinite loop.
>> So infinite loop in this case feels bad.
It's definitely going to start sounding bad, and yet infinite
loops aren't always bad.
Can you think of context in computer programs where you'd
actually want an infinite loop?
Yeah?
AUDIENCE: When you want to check a condition.
DAVID MALAN: Okay, when you want to keep checking a condition?
Like what?
AUDIENCE: [INAUDIBLE]
DAVID MALAN: Okay, good, so if you had some program, some
kind of home automation thing, where you want to constantly
monitor is something the case.
Are the lights on?
Are the lights on because maybe you have a timer, and
you want them to go off, you might need to do something
again and again.
And in fact, speaking of timers, any of you who have
clocks on your computer or digital watches, that's an
infinite loop.
It continues to update the time because it's constantly
checking and checking and checking has the time changed,
and if so, oh, my god.
The clock's finally changed.
It needs display that value to you.
So whereas most of the time infinite loops are a mistake,
or at least a poor design decision, sometimes they do
have their value.
>> Well, let's advance further here to hello7.
So now the program will get a little more interactive.
Let me zoom in here, and again, this is what's nice
about Scratch.
And we'll use it to be clear, Scratch, just today and into
next week's problem set.
But on Monday, we dive into C. In this program here, it does,
forever, the following.
IF touching the mouse pointer-- now, who's the
context here?
Well, and notice that who's selected down here at bottom
right is the cat, sprite one, so these scripts, this
program, applies to him specifically.
So if that cat is touching the mouse pointer, then it's going
to play this down and wait two seconds, and
then repeat ad nauseum.
>> So let's go ahead and hit play.
Nothing happens, but if I want to pet the
cat now, I can simply.
[MEOW]
DAVID MALAN: Adorable.
[MEOW]
DAVID MALAN: Okay, less annoying, but also gets dull,
so let's move on and see if we can't inject
a little more logic.
That was example seven.
>> Here in example eight, we're going to
introduce an ELSE condition.
So much like a literal fork in the road, in which you can go
left or you can go right, a condition in a programming
language like Scratch, or as we'll see C, can allow you to
go in one direction or another via an IF ELSE construct.
So quite literally, IF touching mouse pointer, this
will play some sound, ELSE it's going to play this other
sound, meow.
Now, if you can infer from the name of these sounds, you can
probably guess what this program's meant to conjure up
the idea of.
This cat is meowing happily.
[MEOW]
DAVID MALAN: Happily, but doesn't
quite like to be touched.
[ROARS]
DAVID MALAN: So now we have a cat who will yell at you.
>> All right, well, one last example with cats here, and
let's open version nine of this here.
So now, we have the next most annoying sound that I could
find, so we have a walrus or sea lion here who's going to
do the following.
[SEAL BARK]
DAVID MALAN: Okay, so this will go on until you figure out how
this program works.
So this time, this animal has two scripts, and what's
interesting here is that these scripts are going to execute
in parallel.
So because they both start with one green flag clicked,
it's like going like this, and both programs start running it
once even if they're looping forever.
So in the top script, I have some logic.
What features does that provide up there?
[SEAL BARK]
AUDIENCE: [INAUDIBLE]
DAVID MALAN: If it's what?
[SEAL BARK]
AUDIENCE: If muted to zero, it's going to keep playing the
sound. [SEAL BARK]
DAVID MALAN: Okay, good.
So IF muted, whatever this is, this orange thing is zero,
THEN play the sea lion sound and think "Oh,
hi," for two seconds.
Now, I don't know what muted is, but zero conjures up the
idea of false or off.
So if muted is false, so if not muted,
keep playing the sound.
All right, well, how do we disable this thing?
>> Well, let's look at the second script down there.
The second script says set muted to zero.
Notice it's also orange, so what Scratch does is it colors
blocks in the same shade if it's sort
of logically related.
So just as muted up top was orange, so is muted down here
mentioned in orange block.
But this is a variable assignments, so just like in
algebra, you have x and y and z, in programming you have
variables, but they're generally--
let's pause for a moment and figure how
to stop this barking.
How do I do this?
[SEAL BARK]
DAVID MALAN: Okay.
It stopped. Okay.
>> So just as in algebra you have variables x, y, and z, but in
programming, having variables like x, y, and z is generally
frowned upon because they're not at all expressive.
They have no semantic meaning whatsoever, so in most
programming languages, variables can have full
fledged names or words or phrases, like muted, to say
what they do.
So this second script also was listening forever, and it said
if the key, the keyboard key Space, is
pressed, question mark.
So there's a condition with a Boolean expression that's
going to answer a question either truthfully or false,
then I have inside of it IF the space key is pressed AND
IF muted is zero, set muted to one, ELSE set muted to zero.
So this other fork in the road, and notice how I've
nested the two IF conditions, is a way of checking is the
Space Bar pressed because if so, I either want to go this
way or that way.
And how do I invert the value of muted?
I have to check is it zero?
If so, make it one, else make it zero to therefore toggle
its two states.
>> All right, so we have then some of these fundamental
constructs.
We have Boolean expressions, and realize, too, these are
not all that unfamiliar.
In fact, here's a quick screenshot of Harvard course's CS50
shopping tool, and any website out there that has checkboxes
and drop downs have really, all this time, been using
Boolean expressions.
In this case here, if you click the checkbox next to
course greater than or equal to 4.5, or the same next to
faculty, you're specifying a Boolean expression.
Show me courses for which that expression is true.
Or to the right, doesn't conflict with courses I'm
taking, if that is checked, then yes, you want to check
that condition, else you want to ignore it.
So Boolean expressions are sort of all around, but when
we put them in conditions, whether IF conditions, IF
ELSEs, or we can even simulate deeper
levels, IF ELSE IF ELSE--
so that's sort of a ternary state.
You can go this way or this way or this way.
We can keep nesting things to go in different directions.
>> So Scratch has these loops, like Forever.
It has these features like Repeat 10, some
finite number of times.
We have the ability now to set variables, so in this case
I've declared, for instance, a variable called socks.
I've initialized to 0, and that's yet another direction
we could have taken up here with Joseph, whereby maybe I
just keep track of how many socks I have on and terminate
the program when that variable's value is 2.
That would be another way of sort of generalizing that
problem and doing something again and again.
Well, let's go ahead and now introduce a couple new things.
So those of you with prior programing experience will
know that a lot of languages have arrays, or vectors or
lists, and indeed, Scratch has something like this, too.
So let's see if we can't take things to the next level here.
If I have the ability, now, with these puzzle pieces to
add something, like a word or number, to a variable, I can
start to accumulate things.
And this is actually pretty apropos for things like games,
role-playing games where you're kind of walking around
some fantasy world collecting things, picking things up,
earning points, or the like.
You might want to keep track of some kind of inventory, and
indeed, that's what one of our former students here did with
something called Fruitcraft RPG.
>> So let me go ahead and open up this thing here, and in
Fruitcraft, we have this world up at top.
So let me go ahead and click the green flag.
Notice at top left is some kind of inventory.
That's implemented in Scratch as what we'll call an array or
a list, and now we have this little animation.
So just as we started earlier with this cookie love story,
and then we advanced to cats and sea lions, now we can have
things that are even more interactive.
And this little blue guy, I can start to move around his
little home here.
So it looks like he's got an exit down here, so I'm using
the arrows keys, up, down, left right.
And now I'm outside, so let's what I've got here.
Looks like an orange, and indeed, as soon as I touch the
orange, it gets plopped into my inventory.
If I go over here to the cherries, now I have something
else in my inventory.
And this is all nice and cute, but think about how, now, this
is implemented.
Well, we have this notion of a list, and that's apparently a
puzzle piece that you just say what you want add to it, add
orange, add cherries.
Now, what is this little blue guy doing?
Well, he's a sprite.
And presumably, the orange and the cherries--
they themselves were separate sprites.
And using conditions in Boolean expressions, the
student was probably able to express IF blue guy is
touching cherries THEN add the word cherries to his
inventory, and then also hide the cherry sprite.
So underneath the hood, there probably still is a cherry
sprite there.
We've just told it to become effectively invisible.
>> Now, if I keep walking over here, we can also do this
proximal thing, where I can go and read the sign.
So if blue guy touching sign, we can have this Say block
just like the cat spoke to us in words, hello, earlier, "Got
some fruit?
Bring it to the fruit place." All right, so now, apparently,
I have my directions.
I can go over here to the fruit place, line myself up
with the door.
Now, I'm in here.
I can go up to the man at the counter.
He detects that I'm close to him, so it doesn't have to be
quite identically touching, and I have won the game.
So there we have Fruitcraft RPG.
>> So we can do things even more advanced than this.
We can add sounds.
We can add pseudo randomness.
We can add complexity.
Let me go ahead here, and rather than do this myself,
let me show you one of the more sophisticated submissions
we got last year from a certain someone named Blake.
Can we have one volunteer who is comfortable appearing on
camera and is up for playing a game?
How about right there?
Come on up.
All right, so the game that you have just unknowingly
volunteered to play--
[APPLAUSE]
DAVID MALAN: --is something from yesteryear called
"Frogger." What is your name?
RENDA: Renda.
DAVID MALAN: Redna?
RENDA: It's like Brenda with a b.
DAVID MALAN: Okay, Renda.
David.
Nice to meet you.
>> So here in "Frogger," and if we could raise the volume just
a little bit, you are this little
green frog on the bottom.
You can use left, right, up and down, and your goal is to
cross the street, cross the river, and touch the lily pads
at the top.
Aw.
One more t--
redo, all right?
Let's hit stop.
No one saw that.
[APPLAUSE]
DAVID MALAN: Yeah.
Very well done.
Excellent, thank you.
>> So that there was Frogger. Now that you know what you've
gotten yourselves into, one more volunteer for a different
game submitted by another student.
You want to come on up?
What's your name?
RICHARD: Richard.
DAVID MALAN: Richard.
All right, Richard, come on up.
[APPLAUSE]
DAVID MALAN: You have something that'll sound
familiar soon, so here are your instructions.
So in a moment, some puzzle pieces are going to scroll up
from the screen that look either left
or right up or down.
You're going to have to hit the arrow keys in such a way
that it corresponds to those puzzle pieces lining up with
the placeholders at top.
So when you see a left arrow, and it lines up with the left
arrow, hit the left arrow.
You may begin.
[MUSIC - "STRONGER" KAYNE WEST]
DAVID MALAN: All right, big round of applause for Richard.
[APPLAUSE]
DAVID MALAN: Very well done.
Thank you.
[APPLAUSE]
>> DAVID MALAN: So fun and, seemingly, sort of
intimidating as it might be to implement something as
seemingly sophisticated as this, realize that the student
didn't set out and just write this all at once.
Rather, you can break down a problem as seemingly complex
as this into much smaller pieces, and this, too, is
going to be a theme.
The worst thing you can do in writing a program in most any
language is to sit down, get really excited, write the
whole damn thing, and then just hope that it works by the
time you're finished writing.
Rather, the process of programming should generally
be very deliberate, very iterative, whereby you just
set very small steps for yourselves, bite-size pieces
do you want to bite off, and so that you have these sanity
checks, little milestones you can meet.
And then you build on top of those to create more
sophisticated things still.
>> So for instance, how could we go about
implementing a game like this?
Well, frankly, I would certainly start by just
supporting one key at a time.
Let's just implement support for the left arrow.
So the student had to somehow create in Photoshop, or in
Scratch itself using the little graphical editor, an
arrow key that looks like the one at top left there, just
the gray placeholder.
Then the student had to figure out what x, y coordinate to
put it, where to put it in the window.
0, 0 is up here, so you have to figure out the number of
pixels, or dots, to offset that arrow from
the top of the screen.
And then once that's in place, your program doesn't actually
do anything yet, so you then need a second sprite, for
instance a green arrow that's also pointing left, and you
then need to start writing some scripts for it.
>> And you notice, perhaps, that these things started coming at
different speeds, and the colors were in different
locations, and that's because the student used a bit of
pseudo randomness.
And by pseudo randomness, I just mean pick a number
between something and something because you can
start to map things, like if the number is between one and
five, well, let's make the thing green.
If it's between 6 and 10, let's make the puzzle piece
red instead.
So long as you have a way of generating some kind of
randomness, you can then make decisions based on that
randomness.
And I keep saying pseudo random because there's a
little dirty secret.
Computers can't come up with random numbers.
They can only do what they're told because
they're man-made devices.
They can't just guess a number like we humans
feel like we can.
A computer has to do something mathematical to conjure up the
illusion of mathematical number, sometimes using the
current day of time as an input to figuring out what
number to return, but more on that another time.
For now, just know that we can generate pseudo randomness.
>> So once I have the ability for the left arrow to start
appearing at different times and at different speeds, then
I can go back and add some of these IF conditions.
IF this sprite is touching the other one, AND the left arrow
key has been pressed--
so three conditions in that case.
I can use that AND block perhaps, in that case--
THEN I want to go ahead and increment the score.
And at top, we have a score, we have Awesome,
Cool, Good, and Boo.
So there's apparently five variables that this student
used to keep track of these various metrics.
So in short, the end result is amazing.
It's fun, it's fun to play, it's engaging, but this is not
where the student began.
He or she started at a much smaller set of steps.
>> So what are some other building blocks that we can
weave into these programs?
Well, there's this other concept in most languages,
Scratch among them, known as threads.
So a computer can actually not really do multiple things at a
time, at least not usually.
Rather, a computer generally has just one CPU, and even
though computers are super fast and can, therefore,
create the illusion of doing multiple things at once--
checking your mail, getting an instant
message, printing a document--
really, a computer is just jumping from printing to IMing
to emailing, back and back and back and forth so fast that we
slow witted humans just don't realize that it's actually
running those programs a little bit at a time.
Now, this a bit of a white lie these days because, nowadays,
many our computers are what are called multi-core, so you
have one CPU but multiple cores, which is kind of like
having multiple CPUs.
>> And so sometimes, computers can truly do multiple things
at a time, but generally within a program, programs
rely on these things called threads.
So a thread is sort of like a miniature program that can
exist alongside another miniature program and can run
in parallel, or at least can run under the illusion that
they're running simultaneously.
So Scratch supports these things called threads.
You can have multiple scripts executing at once, just as we
did with the sea lion, and this allows us to actually
then have interactions among these sprites.
Let me go ahead here and pull up, let's say, threads, and
play this as follows.
We have two sprites, each of whom we'll see
has just one script.
And you notice there seems to be some intelligence in the
cat in this one because he's getting closer--
[ROARS]
DAVID MALAN: --and closer to the little bird.
>> So how is the bird operating?
Well, let's take a look at the bird first.
The bird script said when the green flag is clicked, go to x
equals negative 115 and y equals 150.
So I just figured out a random location where I wanted the
bird to start, and I just plopped him there by default.
Then Forever IF not touching cat, so this is a different
kind of looping construct, but same idea, do this again and
again and again.
So long as you're not touching the cat, move three steps, and
if you're on the edge, bounce, where it's sort of a
reflection in the billiard sense.
So that's how the bird is moving around kind of
seemingly randomly, but it's just because it's bouncing off
the walls in this case.
>> Now the cat, meanwhile, is kind of cheating.
The cat, when the green flag is clicked, yes, starts in
some location, a random location--
at least in part as per the pick
random green block there--
and then Forever IF touching the bird, play the lion sound,
and then stop script.
So when I said terminate, or exit before, there's a puzzle
piece in Scratch that will just kill the program at that
point because it's kind of logically done.
But otherwise, here, notice what's going to happen.
Point toward the bird and move one step.
So this point toward bird is kind of an advantage the cat
has in that it's homing in on the moving bird, and we can
now make this program all the more interesting.
Instead of moving one step at a time per CPU cycle, per
strike toll of the bell, so to speak, let me go ahead and
move, let's say, five steps at a time as the cat.
Click run, and now he really finds him quickly.
If we double this further to 10 steps, it kind of goes
right for him.
Now, we can give the bird,
perhaps, a bit of an advantage.
Let's go to the bird and say instead of moving three steps,
let's move him 30 steps.
But he still got caught in the end.
>> So here, we have two threads.
It's incarcerated in Scratch with two scripts and two
sprites, but the idea in other languages is that you can
write, essentially, too many programs like this and have
them run truly, or imaginarily, in parallel.
>> Now, there's also this concept in programming known as
events, and this is something we won't see in C, the
language known as C. We will see it towards semester's end
in web programming, when we introduce JavaScript and the
notion of building web pages that are dynamic and interact
with users.
So in this case, we have a very simple example of two
sprites, boy and girl, each of whom have their respective
threads, but somehow these two are inter-communicating by way
of something called events.
So let me go ahead here and zoom in on the boy's script,
which looks like this.
When green flag clicked, forever do the following.
If the key Space, or the Space Bar, is pressed, say
Marco for two seconds, that's purely aesthetic on the
screen, a little speech bubble, but then broadcast.
>> So broadcast is another Scratch piece that's
representative of a class of functionality in programming
that allows different programs, different threads,
to inter-communicate, to somehow send
messages, one to another.
Passing a piece of paper in class is sort of the low tech
equivalent.
So broadcast event.
I can send this message, and the word event
is completely arbitrary.
Scratch sometimes has these drop downs, so I just came up
with a random word like event because now, what the boy does
when I press the key is he broadcasts this event.
And if I look now at the girl's script, her script is
super simple because all she needs to do is not act when
the green flag is clicked.
She is designed to action when she receives quote, unquote,
"event", and at that point, she's listening therefore for
the so-called event again and again.
As soon as she receives that event, she's going to shout
Polo for two seconds.
>> And so you can perhaps infer from this exactly what the
next result is going to be.
Let me click the green flag.
Nothing happens because I need to do what?
AUDIENCE: Space Bar.
DAVID MALAN: Space Bar.
Boy says Marco, girl says Polo.
But that's not hard coded per se.
That's inter-communication between scripts, so now we
have the ability to make even more complex programs where
these two are somehow inter-communicating.
>> So in what directions can we take this?
Well, in problem set 0, really, the objective is to
have fun with Scratch.
For the hacker edition, you'll instead have fun with a more
sophisticated version of Scratch called BYOB, Build
Your Own Blocks, but the idea is the same.
You'll be able--
Yes, that was deliberate.
It came from Berkeley.
BYOB is the hacker edition version of this, but both
demographics, standard edition and hacker edition alike, the
goal at hand for the coming week is really just to dive in
deep, get your hands dirty with programming, and make
something interesting, make something interactive, make
something artistic, make something fun to actually
demonstrate, so that by week's end, you'll have a project,
not only for your first CS50 pset, but you'll have a
little something that you can show off in Annenberg to
friends or even family by uploading it to MIT's website.
And so as I said on Wednesday, we expect 90% of the class,
generally, to do the standard editions.
Realize that there's also this outlet for those of you who
might otherwise find yourself a bit bored with the basics
and really want to dive in and craft a vision you already
have with prior background in this more friendly
environment.
>> So let me pull up one other example that one of our former
students here did and tell a little something through song.
That similarly, as this plays, think about how you go about
implementing this program using precisely these same
building blocks, a little bit of pseudo randomness, and a
bit of familiar song.
If we could raise the volume just a little bit?
[MUSIC - "IT'S RAINING MEN" THE WEATHER GIRLS]
>> DAVID MALAN: That's it for CS50.
We will see you on Monday.
[APPLAUSE]