>> [MUSIC PLAYING]

>> -Alright!
>> -This is CS50.
>> -This is CS50.
>> -This is CS50.
[MUSIC -- IGGY AZALEA, "FANCY"]
>> -My favorite memory from CS50 was when I went to Puzzle Day.
>> -Probably just the time spent working on problem sets
with my friends and people who wold eventually become my blockmates.
>> -My best memory from CS50 is the Hackathon.
-The CS50 Hackathon.
>> -Hackathon.
>> -Hackathon.
-Hackathon.
-The Hackathon
-Rob Bowden.
Just everything about him.
>> [MUSIC -- IGGY AZALEA, "FANCY"]
>> -My favorite memory is when I was on stage and I played the prestigious role
of a node [? in the Linked ?] [? List. ?]
>> -When we all got free Dropbox space and David was like, look under your seats
.
And it was like, space for everyone!
>> [MUSIC -- IGGY AZALEA, "FANCY"]
>> -My advice for any incoming student would
be to really work on P-sets with friends.
>> -Office hours is very much your friend.
>> -Make the most of your experience and meet as many people as you can.
>> -Don't be afraid to ask for help.
-Start the P-sets early in the week.
-I think the biggest thing is to take advantage of all the resources
that CS50 has.
>> -Go to office hours early in the week.
>> -Definitely watch the shorts.
>> -Don't procrastinate on your P-sets.
-Make sure you find a great group of people to work on P-sets with.
You can have a lot of fun and get work done together.
>> -Don't be afraid to push yourself.
Go for the hacker edition sometimes.
>> -Write things on paper before you ever touch your computer.
>> -CS50 is really great at providing ways to get help.
>> -My one piece of advice is sleep.
Has anybody said that?
Sleep, for sure.
It's easy not to do, but you've got to do it, I think.
>> -I would say really be mentally prepared because you're going to love it.
[MUSIC -- IGGY AZALEA, "FANCY"]
>> -This is CS50.
>> -This is CS50.
>> -This is CS50.
[MUSIC -- IGGY AZALEA, "FANCY"]
>> -This is CS50.
>> [APPLAUSE]
>> DAVID J. MALAN: So this is CS50 and this is the end of Week 0.
And that was just some of CS50's staff who
await you not only in sections and office hours, but,
also, this coming weekend at CS50 Puzzle Day.
Which, again, is not all about programming.
Indeed, it's expected that you won't have to program anything,
but rather solve problems using wits and friends alongside you.

>> We will be joined by some of our friends at Facebook-if you register here-- who for the past several years,
have actually been writing these challenges with us.
And so, they will be the ones ultimately running Puzzle Day.
And so, you will be challenged with precisely the kinds of things
and problems that folks at Facebook like to think about.
So that is tomorrow.
Register at cs50.harvard.edu/register.
>> Now a word on a couple of staff in particular.
This here is Ansel Duff, who is actually one
of the co-authors of these binary bulbs that we saw on Wednesday,
in addition to CS50's own Dan Bradley.
Ansel Duff was also a former freshman advisee of mine 3 years ago
and he actually even built this lectern.
He's gone on to do engineering sciences and more.
Now, his picture here is actually Ansel 3 years ago at the CS50 Hackathon
when he borrowed one of our balloons, stuck it to his laptop,
and, for the next 12 some odd hours, focused on his final project,
taking breaks only to open bags of candy at the Hackathon.
>> But he went on more recently to spend this past summer with us,
since CS50 for its staff, and now students this semester,
has its own 3D printer.
And in a nutshell a 3D printers is a device that looks quite like this.
You fill it with a plastic spool that is melted down by the device
and you build things literally from nothing.
Much like an inkjet printer, you start spitting out little dots of plastic
that form together to form whole objects.
And so Ansel for instance, earlier this summer, has an iPhone 5
and decided he really wanted to prop it up on his desk.
But he didn't want to go out and buy something
from the Apple store or the like, so he sat down and started drawing something.
He took a few measurements as to how thick
and how wide his iPhone was, he drew this image here,
he decided that he wanted to have a 75 degree tilt
as it was staring at him on his desk there.
He then turned this, using software, into a 3D CAD model
that looked a little something like this.
And then he proceeded, ultimately, to actually create it.
So in fact, if any of you here, perhaps in a row that I can throw to, have
an-- there we have folks with iPhone 5 , and here we have two more.
>> Now, not to be outdone, CS50's own Cheng Gong also set out this summer
to build quite a few things and, in fact, for reasons that are still
unclear, has been slowly printing an army of elephants
with articulating arms and trunks.
A couple of which are actually here if anyone would now like-- an elephant.
All right, . but what Cheng also did for us is he very kindly set up a camera
because that elephant, believe it or not,
takes some two and a half hours to print.
Even the iPhone stand took an hour and a half to print.
And what Cheng went ahead and did was set up a nice camera in front
of this 3D printer, filmed for an hour and a half as Ansel's design printed.
We overlaid some sexy music to it in order
to give you this to look at how 3D printing works.
And even though this is actually in plastic,
realize that if this is an area of interest to you academically,
there are folks, among them Jennifer Lewis here
at the School of Engineering, who are actually
working on 3D printing of plastic objects.
But even, increasingly, biological materials to solve
physiological problems for humans.

But here is a little something from CS50.

>> [LOUD MECHANICAL NOISES]
DAVID J. MALAN: It doesn't sound anything like that in reality,
but it's much cooler to watch it at that speed, and with that sound.
>> Now, on Wednesday, how did we first get here?
We started talking about computer science and we asked what it was.
And it's about a number of things, and there's so many different directions
in which you can head after a course like CS50.
In fact, if you picked up one of those unofficial guides
to CS outside, the booklet that we've provided, whether you're
thinking of taking just CS50, or maybe doing a secondary,
or maybe even concentrating in CS, do flip through that.
And you'll see a diagram toward the end that
shows you the many different directions in CS that you can go off in.
>> But for today, we'll focus, again, on really one of the fundamental views,
perhaps, where you have inputs to problems,
you have outputs from problems, and you have
algorithms with which to create those outputs from those inputs.
And one such example, was of course, this phone book here.
And we used as an example to go through an algorithm that was correct.
And then another one was correct, but a little faster.
And then another one that was a little more dramatic, but fundamentally
faster.
>> Right, this phone book we claimed had about 1,000 pages.
And how many times did I have to tear the phone book in half
to find someone like Mike Smith, maximally, in 1,000 page book?
So, 10 give or take.
And so once I tore this thing in half, or simply, more maturely,
divided in half, it's only 10 pages out of 1,000.
And if you extrapolate, a little unrealistically for a phone book,
but if this phone book had some 4 billion pages in it, so completely
unwieldy physically, how many times do you divide a 4 billion
page phone book in half?
So it's actually 32, give or take.
And so 32 times only, out of 4 billion pages, can
you find someone like Mike Smith.
And that's efficiency.
That's a good algorithm, daresay.
>> But then we moved from that to try to formalize it.
And I proposed this pseudocode code.
Pseudocode code is not anything formal.
It's not something you memorize.
It's just something you express fairly intuitively using English,
or any language really, that conveys your ideas succinctly.
But what's key about pseudocode code is that you
try to anticipate all of the possible cases that might happen.
And indeed, in this pseudocode code, there were really three cases
every time I divided the phone book.
Mike might be to the left.
Mike might be to the right.
Or he might be right on the page I'm on.
Or a fourth corner case, so to speak.
A bad scenario might be one which-- what is happening?
Mike's just not in the phone book at all.
>> And when programs crash-- when Mac and PC software that you guys run
on your computers sometimes hangs or quits unexpectedly,
that generally means that some programmer, some human like you soon,
just screwed up and made some mistake.
Maybe didn't anticipate that maybe there is no Mike Smith in the phone book.
And if you don't actually write code to handle situations like that,

generally unpredictable things can happen.

Your machine can freeze.
It can reboot.
The program can quit.
And so all of these stupidities that you may
have encountered in your actual life just using computers,
will increasingly be just explained away by this intuition
and this understanding of what is actually going on underneath the hood.
>> Now let's try to take a look at a more general problem.
Rather than take attendance in a place like
this, which would be quite slow to do one, two, three, four.
Or maybe two, four, six, eight.
Let's focus, instead, on how we might formalize
the algorithm of the process by which we could take attendance.
And along the way, let's start to apply some nomenclature
that we'll use today when we actually start programming in a language.
So I give you now, a four minute video that we put together with our friends
from TED, the organization.
Whereby we supplied a script and they brought their animators to bear,
and actually created a 2D animation of what an algorithm is.
If we could dim the lights.
>> [MUSIC PLAYING]
NARRATOR: What's an algorithm?
In computer science, an algorithm is a set
of instructions resolving some problem step-by-step.
Typically, algorithms are executed by computers,
but we humans have algorithms as well.
For instance, how would you go about counting
the number of people in a room?
Well, if you're like me, you'd probably point at each person one at a time
and count up from zero.
One, two, three, four, and so forth.
Well, that's an algorithm.
In fact, let's try to express it a bit more formally in pseudocode code.
English-like syntax that resembles a programming language.
>> Let n equal 0.
For each person in room, set n equal to n plus 1.
How to interpret the pseudocode?
Well line one declares, so to speak, a variable
called n and initializes its value to 0 This just
means that at the beginning of our algorithm,
the thing with which we're counting has a value of 0.
After all, before we start counting we haven't counted anything yet.
Calling this variable n is just a convention.
I could have called it most anything.
Now line two demarks the start of a loop,
a sequence of steps that will repeat some number of times.
So in our example, the step we're taking is counting people in the room.
Beneath line two is line three which describes
exactly how we'll go about counting.
The indentation implies that it's line three that will repeat.
So with the pseudocode code is saying is that after starting at 0
for each person in the room we'll increase n by 1
Now is this algorithm correct?
Well let's bang on it a bit.
>> Does it work if there are two people in the room?
Let's see.
In line one we initialize n to 0.
For each of these two people, we then increment n by 1.
So in the first trip through the loop, we update n from 0 to 1.

On the second trip through that same loop, we update n from 1 to 2.

And so, by this algorithm's end, n is 2, which
indeed matches the number of people in the room.
So far, so good.
>> How about a corner case though?
Suppose that there are 0 people in the room-- besides me, who's
doing counting.
In line one, we again initialize n to 0.
This time though, line three doesn't execute at all
since there isn't a person in the room.
And so n remains 0, which indeed matches the number of people in the room.
Pretty simple, right?
But counting people one at a time is pretty inefficient, too, no?
Surely we can do better.
Why not count two people at a time, instead of counting one, two, three,
four, five, six, seven, eight, and so forth.
Why not count two, four, six, eight, and so on?
It even sounds faster.
And it surely is.
>> Let's express this optimization in pseudocode code.
Let n equal 0.
For each pair of people in room, set n equal to n plus 2.
Pretty simple change, right?
Rather than count people one at a time, we instead count them two at a time.
This algorithm's, thus, twice as fast as the last.
But is it correct?
Let's see.
Does it work if there are two people in the room?
In line one, we initialize n to 0.
For that one pair of people, we then increment n by 2.
And so by this algorithm's end n is 2, which
indeed matches the number of people in the room.
>> Suppose next that there are zero people in the room.
In line one we initialize n to 0.
As before, line three doesn't execute it all
since there aren't any pairs of people in the room, and so n remains 0.
Which indeed matches the number of people in the room.
But what if there are three people in the room?
How does this algorithm fare?
Let's see, in line one, we initialize n to 0.
For a pair of those people, we then increment n by 2.
But then what?
There isn't another full pair of people in the room,
so line two no longer applies.
And so by this algorithm's end, n is still 2 which isn't correct.
Indeed this algorithm's said to be buggy because it has a mistake.
>> Let's redress with some new pseudocode code.
Let n equal 0.
For each pair of people in room, set N equal to n plus 2.
If one person remains unpaired, set N equal to n plus 1.
To solve this particular problem, we've introduced in line four a condition,
otherwise known as a branch, that only executes
if there's one person we could not pair with another.
And so now, whether there's one, or three,
or any odd number of people in the room, this algorithm will now count them.
Can we do even better?
Well, we could count in threes, or fours, or even fives and tens,
but beyond that, it's going to get a little bit difficult to point.
>> At the end of the day, whether executed by computers or humans,
algorithms are just a set of instructions

with which to solve problems.

These were just three.
What problem would you solve with an algorithm?
>> DAVID J. MALAN: So deliberately, a very simple program,
a very simple algorithm, for achieving something
very simple, counting the number of people in the room.
>> But let's tease apart some of the representative
features here that are actually going to be useful even when
implementing the most complex of software.
So for instance, in this first line, we have what we call the variable,
and from algebra, you're generally familiar using x and y
and z sometimes, and so forth.
But in programming, variables are still, at the end of the day,
very similar to that.
But it's perhaps simpler to think of a variable as just a container.
And, in fact, it's some number of bits implemented somehow in your hard disk
or in your computer's memory, but more on that in the future.
It's just a container.
And if you say something like let n equal 0,
well that's like calling this glass bowl here n, just an arbitrary name,
and putting nothing in it initially.
So the value of this bowl right now is zero.
And of course if you perceive in a subsequent line,
to actually increment some line of code, as in this third line here,
by 1, that's like saying what's the current value of n, it's 0, plus 1,
put something like a ping pong ball in here.
Now the value of this variable is quite simply 1.
And you could very quickly extrapolate, but now it's 2, now it's 3, and so on.
So that's all a variable is.
It's a piece of storage to actually store some data.
For now it's a ping pong ball.
There it's a number.
But it could be words in a dictionary, like the spell checker
I alluded to on Wednesday for one of last year's problem sets.
>> Now another key idea, that similarly is pretty intuitive I would claim,
is that of a loop.
And the loop in the process of counting everyone
is, of course, doing the same thing again and again-- either one
at a time or two at a time.
And you can express this in English, or pseudocode code, in any number of ways,
but using this preposition "for" is a very common way of doing that.
For each person in the room, do this.
Again and again.
And the fact that it's indented, line three,
just means that what you're supposed to do
is the stuff that's indented below the line two itself.
Just a human convention, but a common one
as we'll see in actual higher level programming languages.
>> Now little more interesting is when you get in a corner case.
For instance, a corner case was when there
were three people, or five, or seven, or any odd number of people in the room,
because doing that by twos brakes eventually because your going
to miss someone, either at the very beginning or the very end
depending on how you do it.
And so, now, I have this branch, or condition, if one person remains,
then go ahead and handle that one lonesome person who didn't get
paired with someone else.
So that's what we would call a condition, or a branch.
>> Now pseudocode code more generally can be
written to solve any number of problems.

And what I thought we'd do here is take a moment

to invite shall we say CS50's own Rob Bowden on stage
to be joined by two volunteers, who have no idea what awaits.
A hand went down as soon as I said that.
How about you on the end here, come on up.
And how about from farther away, how about way in the back.
Back row, come on up with your hands up.
Alright, and what's your name?
>> ANITA: Anita.
>> DAVID J. MALAN: Anita.
Okay, nice to meet you.
Let me introduce you to Rob Bowden.
This is Anita.
And what is your name?
>> KIERSTEN: Kiersten
>> DAVID J. MALAN: Kiersten.
Kiersten, come on up and meet Rob Bowden and Anita.
Nice to meet you.
KIERSTEN: Nice to meet you.
DAVID J. MALAN: Alright, Rob.
ROB BOWDEN: Nice to meet you.
DAVID J. MALAN: Anita.
KIERSTEN: Hi Anita.
DAVID J. MALAN: And your several hundred classmates.
So, now let me go ahead and pull up just a simple program here
on Mac OS that'll let me actually jot some notes down.
And if you guys want to each take a position at one of those schools there,
let me go ahead and starts a list of pseudocode code, if you will.
And what I want to do here, ultimately is type for you
some instructions that our audience members are actually
going to recite for us.
Let me go ahead and just change this to a numbered list
to match what we were doing up there.
And what I'm going to do with your help, is write a program
in pseudocode, with which these guys are going
to implement a peanut butter and jelly sandwich.
So it's perhaps apropos to show something some of you
might have seen on the internet for just a brief annoying moment.
>> [MUSIC BUCKEWHEAT BOYS, "PEANUT BUTTER JELLY TIME"]
DAVID J. MALAN: OK.
That's enough of that.
So here meanwhile, I have a pair of Google Glasses which
we'll put on CS50's own Rob Bowden to see the world through his eyes.
And we'll do our best in post production to actually weave
the footage of what Rob is seeing now, into this actual lecture
video with our two volunteers beside him.
So what I'm going to do is, I'll be the typist.
We have the goal here of actually writing a program
with which to make, ultimately, a peanut butter and jelly sandwich,
but these three are going to behave as though they are computers.
And computers, at the end of the day, are actually pretty dumb devices.
They're super fast, but they can only do, literally, what they are told.
You can't just say make a peanut butter and jelly sandwich.
You have to program them to do that.
You have to tell them with precision what to do,
less things go horribly and, hopefully, amusingly awry.
>> So with that said, we need one call-out from the audience
for what should step one be, if the goal here
is to make a peanut butter and jelly sandwich.
Yes?

>> AUDIENCE: [INAUDIBLE] the bag of bread.

DAVID J. MALAN: Open the bag of bread.
So if the three contestants would like to proceed to do that literally.
Open the bag of bread.
>> [AUDIENCE LAUGHING]
DAVID J. MALAN: So let's work on that.
All right.
So step two, how-- let's take this further.
Yeah, in the front.
>> AUDIENCE: [INAUDIBLE] the bread.
>> DAVID J. MALAN: What's that?
>> AUDIENCE:Remove the bread.
DAVID J. MALAN: Remove the bread.
Similarly succinct.
Thank you.
>> [APPLAUSE]
DAVID J. MALAN: That's it?
OK, so step two is going to be remove the bread.
Alright, someone want to write us a longer sentence?
Someone else?
A little more [INAUDIBLE].
No, nothing now.
Yes?
>> AUDIENCE: Place two slices next to each other.
>> DAVID J. MALAN: Place two slices next to each other.
>> [AUDIENCE LAUGHING]
>> DAVID J. MALAN: Place two slices next to each other.
Step four.
Yes?
>> AUDIENCE: Take your hand and set it lightly
on top of the peanut butter lid.
>> [AUDIENCE LAUGHING]
AUDIENCE: [INAUDIBLE] next to the peanut butter.
DAVID J. MALAN: What?
Say that again.
>> AUDIENCE: Unscrew the lid and put it gently next to the peanut butter.
>> DAVID J. MALAN: Put it gently next to the peanut butter.
OK, progress.
Step five.
Excellent.
Yes?
>> Pick up knife.
DAVID J. MALAN: Pick up knife.
OK, step six.
Yeah?
>> AUDIENCE: Hold knife by the handle.
DAVID J. MALAN: Hold knife by the handle.
Hold knife by the handle.
Step seven.
Yes?
>> AUDIENCE: [INAUDIBLE] knife in peanut butter and as little out [INAUDIBLE].
>> DAVID J. MALAN: Put knife in-- I heard "put knife in peanut butter
and take as little out as possible."
By the way, remove the paper first.
All right, step nine.
Step nine.
Step nine.
We haven't actually made a sandwich yet.
Yes?
AUDIENCE: Using knife in peanut butter, apply peanut butter on said bread.

>> DAVID J. MALAN: Using knife in peanut butter, apply peanut butter on
said bread.
>> [AUDIENCE LAUGHING]
DAVID J. MALAN: All right step 10.
Step 10.
Yes?
>> AUDIENCE: Taste peanut butter to ensure quality.
>> [AUDIENCE LAUGHING]
DAVID J. MALAN: Step 11.
Step 11.
Step 11.
Come on.
Yeah?
Right there.
>> AUDIENCE: Carefully pick up jelly.
>> DAVID J. MALAN: Carefully pick up jelly.
OK, and then another hand was up.
Right behind you.
Yeah, in blue.
>> AUDIENCE: All right, remove lid from [INAUDIBLE], yeah,
remove lid from the jelly.
>> [AUDIENCE LAUGHING]
>> DAVID J. MALAN: From jelly.
Ha ha.
>> [AUDIENCE LAUGHING]
DAVID J. MALAN: And?
AUDIENCE: And barely sweep any [INAUDIBLE].
[AUDIENCE LAUGHING]
AUDIENCE: Of course, before [INAUDIBLE], remove the paper from jelly.
DAVID J. MALAN: Remove paper from jelly.
Step 14.
We're almost there.
Yes?
>> AUDIENCE: Invert jelly bottle before everything falls out.
>> DAVID J. MALAN: Invert jelly bottle before jelly falls out.
Step 15.
>> AUDIENCE: Replace the cap.
>> DAVID J. MALAN: Replace the cap.
Step 16.
Yeah?
>> AUDIENCE: [INAUDIBLE]
DAVID J. MALAN: Say that again.
AUDIENCE: Take cap off of your jelly.
DAVID J. MALAN: Off your jelly.
So really-- Oops.
Come on.
Replace the cap.
Put cap-- You said remove cap from jelly.
Feel like we're in a bit of a loop.
Step 17.
Yes?
>> AUDIENCE: [INAUDIBLE]
DAVID J. MALAN: Say that again.
AUDIENCE: [INAUDIBLE]
DAVID J. MALAN: Go back to step-AUDIENCE: [INAUDIBLE]
DAVID J. MALAN: Remove cap from peanut butter.
Yes?
>> AUDIENCE: Drop all the jelly on the bread.
>> DAVID J. MALAN: Drop all the jelly on the bread.

DAVID J. MALAN: We're almost there.

Step 19.
>> AUDIENCE: Remove excess jelly.
>> DAVID J. MALAN: Haha, jelly.
>> [APPLAUSE]
DAVID J. MALAN: Why don't we-- one more step to take this home.
One more step and then we'll serve sandwiches.
Yes?
>> AUDIENCE: [INAUDIBLE]
>> DAVID J. MALAN: While any sandwich remains-- let's indent this-- eat.
>> [AUDIENCE LAUGHTER]
>> DAVID J. MALAN: All right, thank you to our volunteers here.
>> [APPLAUSE}
>> DAVID J. MALAN: We have some nice parting gifts for each of you.
Your own peanut butter, jelly, and bread to bring back home.
Thank you.
>> KIERSTEN: Thank you.
DAVID J. MALAN: [INAUDIBLE] welcome.
[APPLAUSE]
DAVID J. MALAN: So, this is, of course, a ridiculous example.
Right?
But it does kind of reveal how we humans just take clarity for granted.
And the fact I've been talking to another human,
he or she just knows what you mean.
>> Computers are not going to know what you mean,
even when using, as we're about to do today,
programming something in Scratch, a drag and drop, puzzle piece style language.
Even designed for young children, you have
to be so explicit and so literal with what you want your program to do.
Now ultimately, we're going to be programming
not in pseudocode code, English like syntax,
but code or, more properly, source code.
Source code is just the fancy way for describing code you actually
write with a keyboard that's not in English per se.
It's in C or Java or C++ or something like that, as we'll soon see.
>> And in fact, just to scare a few of you, at first glance,
this is a program written in a language called C. But to un-scare a few of you,
you will completely understand what's going
on come next Monday when it comes to something like this.
Frankly, this is an older language.
It's fairly arcane, but it's representative
of a lot of languages these days that have lots of parentheses and curly
braces and quote marks and semicolons.
And a lot of this syntactic stuff that is not
at all intellectually interesting.
Indeed, it's an utter distraction from the very simple ideas
that are staring us in the face.
This program, as you might just guess, prints to someone's computer screen
the words "Hello comma world."
That's it.
So clearly, there's a lot of stuff that's
getting in the way of some obviousness there,
but it's going to very quickly slip away and be completely intuitive.
>> Indeed, what we're going to do today is distill this fairly complex
looking program, which again you'll come to understand quickly, but to something
much simpler.
Let's just say what we mean.
Let's draw a picture of what we mean, by way of these puzzle pieces here.
>> So this is a programming language known as Scratch.
It was developed by MIT's Media Lab.

And what you'll see in problem set zero, which will be released later tonight,
we'll have you go to this URL here scratch.mit.edu.
And they have a web based interface via which
you will write your first program.
Or those of you with prior experience, your second programs,
but in an environment that's probably a little unfamiliar and that
will push you to create something using this very visual environment.
>> Now, what I'm going to do here is open up the program itself.
It exists not only as a web browser, but also as a downloadable program
so that you can actually use it if you don't have internet access.
And I'm going to do that in here, in Sanders, just
in case the Wi-Fi doesn't cooperate super well.
And what I'm going to do is point out a few features of this program.
So, to be clear, I have just double clicked the icon on my desktop,
or equivalently gone to scratch.mit.edu, and it's pulled up this window.
This is a programming environment.
It's a piece of software that some of our friends at MIT
wrote that let's us and you write programs in a language called Scratch.
>> Now this happens to be a cat who's also named Scratch
and this is his world in which he lives.
This is the stage, so to speak, that rectangle on the top left hand corner.
And he doesn't have to look like a cat.
You can make him look like anything and you
can have many such sprites, or characters, in a program.
Meanwhile, over here on the far right, is a big blank slate.
And this is where, in a moment, we are going to start programming
by dragging and dropping these graphical puzzle
pieces that are right here in the middle.
And there's way more of them than we'll spend time on here in class
because you'll find that they're all fairly intuitive.
Again, it's designed for children, but we
use it to tease apart some of those fundamental ideas of variables, loops,
conditions, and, soon, things like functions and events
and threads and other fancy things we'll get to before long to actually create
something from Scratch.
Pun intended.
>> Now, what I'm going to do here is click on not motion, but control.
And this is just a categorization of here-and I see a different color set of blocks.
But notice a few familiar words.
"If" and "else if" and "repeat."
And you can probably guess that's reminiscent of the branch,
or the conditions we saw, and even the looping construct.
So we have similar blocks here.
But the most interesting one is this one here.
When this green flag is clicked, this, for those with prior programing
experience, is equivalent to a main function.
But for those unfamiliar, this is the puzzle piece
that will kick start our entire program.
It literally means when I go, in this program, and click a green flag-which you can see up here in the top left hand corner of the UI,
so see the green flag next to the red stop sign?
When I click that, my program is going to run.
Now, I'm going to do something super simple with Scratch.
I'm going to go ahead and go to the looks panel
here, where I have a bunch of purple puzzle pieces,
and I'm going to go ahead and do something super simple like, say.
And then-- notice this text in the white box
is editable-- I'm going to say "Hello world," just like we
did in that textual version a moment ago.

And now if I go and click this green flag, I have now programmed.
It's not a particularly interesting program,
but I made the computer do something.
I started a program and it did what I told it to do.
Now, I can continue to drag and drop more and more of these puzzle pieces
and they're going to interlock, but let's slap some terminology on here
that we'll see recurring throughout the course,
and really throughout computer science and programming more generally.
>> This "say" block, in purple, let's just start calling a statement.
It's like a statement of fact.
Do this.
So, it's a category of instructions that you
might feed a computer as part of a program or an algorithm.
And to be clear, you've probably taken for granted
that you have programs on your computer.
And they're kind of algorithms, but a program is really a bunch of algorithms
that some humans wrote.
They packaged it up and they sold it so you,
or they posted on a website for you to download.
So, a program is just a whole bunch of zeros and ones
that, somehow, humans created.
And those patterns of zeros and ones represent things, ultimately,
like "say hello world" or "play this music" or "play this video"
or "send an email."
But we'll come back in way more detail what
a program is when you, yourself, write them.
>> Here's another statement-- "Wait for one second."
I didn't use this yet, but if I want my program to pause for a moment
to do something, I can tell it to do so.
Wait one second.
Now another one might be "play sound."
So, this is unique to Scratch, it has the ability to play sounds.
So, a statement I might use is, here, "play sound."
Meanwhile, Boolean expression, so this is a fancier word
named after just a guy named Mr. Bool, and this is all about a question.
True or false-- is the mouse down?
A Boolean expression is just some expression in English
that is either true or false.
Either on or off.
Either one or zero.
You can think of it in any number of ways,
but it's either true or this false, ultimately.
So "mouse down question mark," that would be a Boolean expression.
And you can think of others, perhaps.
For instance, "is the left number less than the right number?"
That, too, would be a Boolean expression.
"Less than" is a Boolean expression.
>> This one, too, "touching mouse pointer."
I'm not sure why they called it mouse pointer.
It just means, is the cursor, is the arrow on the screen, touching the cat,
for instance.
Or some other aspect of the screen.
And it's a question, again, and that denotes a Boolean expression.
Something that you might want to use in a condition.
So we'll come to that in just a moment.
You can "and" things together.
So, if you want to check if this is the case AND that is the case,
you can use an "and" block like this.
And here's that condition.
Notice the shape of the little opening in the top of this yellow puzzle piece,

it's reminiscent of the shape that we just saw a moment ago.

Each of these Boolean expressions have these pointed edges
on the left and right.
And that's because MIT folks decided that by visually conveying shapes,
you can kind of help people, students and children alike,
to kind of fill in the blanks literally.
>> Now that puzzle-- that opening is a little small,
and as we'll see in the program, in Scratch, it will grow to fit.
It will maintain its shape, ultimately.
So a condition let's you decide "should I do something or not?"
A Boolean expression is the actual question
you're using to decide do I go to the left OR do I go to the right
when I encounter this so-called fork in the road?
You can have two branches.
IF something is true, do this, else go that way,
or you can just do nothing at all, as this block implied.
Similarly, we can nest these things.
So if you want to triple fork in the road, either do this or this or that,
you can just nest these things together.
And it starts to get a little ugly, eventually, for sure,
but the logic is still the same.
You can literally read this top to bottom
and it says what it means-- if this is true, do this, else if else.
>> A loop doesn't get simpler in Scratch.
Forever do the following.
Now you might not think you can do much because there's not
much space between the top and the bottom of this puzzle piece opening.
But you'll see Scratch is going to grow to fit as many puzzle pieces
as you want to cram in there.
Another loop might be expressed with repeats.
If you know in advance, "I want to do something 10 times,"
you can just tell Scratch to do something 10 times.
And, meanwhile, we can have variables.
So here's an arbitrary one, it's orange in this case,
and this is a whirlwind tour.
Again, you'll find this very accessible once you start pointing and clicking.
I've named my variable n, but I could have named it anything I want,
and I'm setting it here, in this arbitrary example, to zero.
>> Now seeing a program like hello world is not all that compelling,
so let's actually open up something that a former student made.
Let me go ahead and open up, for instance, this one here,
for which I would love to have a volunteer.
All right, how about-- let's go farther.
Yes, come on up.
What's your name?
>> ABBY: Abby.
DAVID J. MALAN: Abby, come on up.
So have you ever played this game before?
ABBY: No.
DAVID J. MALAN: All right.
David, nice to meet you.
Come on over.
And what is your programming background, if any.
>> ABBY: I've learned some C++.
DAVID J. MALAN: You've learned some C++.
And what is your game playing background?
>> ABBY: Not a lot.
DAVID J. MALAN: OK, so we'll take that.
So here's how the game is going to work.
I'm going to go ahead and click the green flag, which

is up here at the top right.

Now your predecessor in the class has given you some instructions here.
And in just a moment, it says "space to begin."
So go ahead and hit the spacebar.
>> COMPUTER GAME: Pikachu.
DAVID J. MALAN: And the goal is to catch the food, as depicted there
on the left.
And to [INAUDIBLE]
>> [GAME MUSIC PLAYING]
>> DAVID J. MALAN: Aww, well, thank you for playing.
We have here a little parting gift for you.
We have CS50 stress ball, if you'd like to choose.
All right, good to meet you.
Thank you for coming and challenging.
So we have more stress balls, so let's do one more example to motivate.
A volunteer?
All right, how about right here in front.
What's your name?
>> PHILLIP: Phillip.
>> DAVID J. MALAN: Phillip.
Come on up, Phillip.
So, Phillip is going to be challenged with another game
that one of your predecessors wrote as part of problem set zero,
called Ivy's Hardest Game.
And we'll see in just a moment what's meant by this.
Phillip, nice to meet you.
What is your background?
PHILLIP: Done a lot of coding.
Done a little gaming, too.
>> DAVID J. MALAN: OK.
Got a lot of gaming, too.
And have you played this game before?
>> PHILLIP: No
DAVID J. MALAN: All right, so here we go.
I'm going to go ahead and click the green flag.
>> [GAME MUSIC]
>> [MUSIC MC HAMMER, "U CAN'T TOUCH THIS"]
>> PHILLIP: [INAUDIBLE]
DAVID J. MALAN: [INAUDIBLE]
PHILLIP: [INAUDIBLE]
[LAUGHING]
[MUSIC MC HAMMER, "U CAN'T TOUCH THIS"]
DAVID J. MALAN: [INAUDIBLE] Plow through it.
PHILLIP: [INAUDIBLE]
DAVID J. MALAN: Go ahead.
[MUSIC MC HAMMER, "U CAN'T TOUCH THIS"]
DAVID J. MALAN: All right.
Congratulations.
>> [APPLAUSE]
>> DAVID J. MALAN: We will post that online later so
that you can procrastinate with it as well.
Princeton comes up next, after that.
>> So now let's actually proceed to start from scratch,
so to speak, and actually build up until we can tease apart some of these ideas
and get to something even more complex by the end.
I'm going to go over here and I'm going to go ahead and create a new file.
So again, the problem set will walk you through some of these steps.
But, all I did was go to the File menu and I
said "new," so much like Microsoft Word, or any program like that.
>> And let's go ahead now-- and we implemented "Hello world" a moment ago,

but let's do something a little cuter.

I'm going to go up to events.
And I'm going to do "when green flag clicked."
And then I'm going to use, shall we say, a branch.
So I'm going to use an "if" condition.
And notice how as soon as I get close to it, it wants to snap together.
So I let go and it snaps together.
And now I can do something interesting.
If I scroll through here, I'm going to see a whole bunch of blocks.
If I go to "data"-- let me zoom in-- there is something about variables.
If I go to "motion," you can apparently turn things around.
If I go to "operators"-- oh, this is interesting,
I can pick a random number.
So let me do something with only some probability, just because.
I'm going to go ahead and drag this puzzle piece,
this is that less than block, so it's just
"is this number less than that one?"
But I don't want a hard code a number because that be pretty pointless.
So I'm going to drag this piece here, and notice how it snaps in,
and now let me go ahead and say "if the number that's picked randomly
is less than six, do the following."
Now why less than six?
What probability is this effectively going to give me, just intuitively?
About 50%, right?
If the number that's guess randomly between 1 and 10 is less than six,
clearly it's one, two, three, four, or five.
And so that's going to give me a 50% probability of what happening?
>> Well let's do something like this, "play sound meow."
And notice, again, the puzzle piece grows
to fit, so long as the shapes match.
That's what's important.
Let me go over to Scratch here and click "play."
Nothing happens.
Is that a bug?
No, not necessary.
It could just be that a bigger number was chosen.
So let's do it again.
Nothing.
>> [MEOW]
DAVID J. MALAN: There it is.
[MEOW]
DAVID J. MALAN: Again.
No.
>> [MEOWING]
DAVID J. MALAN: So if you've ever played a game, of course,
where stuff is happening randomly, like the bad guys are coming or not
coming on to the screen, or things are falling or not falling,
that's just because something super simple like this is happening.
Pick a random number, and if it's less than some value,
maybe do this or maybe do that.
We can incorporate that into a condition.
Let's do something different.
>> Let me throw that away.
You can get rid of stuff by just dragging it off to the left
and letting go.
Let me go ahead and do a forever block and very quickly do something annoying.
Let me go ahead and say "play sound meow."
But I don't want this to be too annoying, so let me grab this block,
"wait one second," and notice there's no more room for it.
But if you go close enough, it wants to go there.

So I let go and it will grow to fill the block.

So now, this is a loop.
[MEOWING]
DAVID J. MALAN: I'm literally doing this forever.
Again and again.
That is just not natural sounding.
Let me go ahead and change this to not one second, to two seconds
and hit Enter.
And what's nice about Scratch is that you could program interactively.
Make a change, maybe hit Enter or Play again, and it will just keep going.
Well, now why don't we do something a little cuter?
Rather than do everything from scratch, let me go ahead and open up an advance
made one, that I pre-baked, called "Pet the Cat."
And we'll post all of these files online,
and problem set zero will tell you how to access them and open them up.
And notice, this is pretty simple.
But in advance, I seem to have grabbed a "forever" block, so I've got a loop.
And then I've got an "if" condition.
I've got a Boolean expression.
>> So in English, just glancing at this, especially if you've never
programmed before, just intuitively, what is this going to do, this program?
>> [AUDIENCE CHATTER]
>> DAVID J. MALAN: If you pet the cat, the cat is going to meow, right?
Because "forever unchecking" is the mouse pointer touching the cat.
So to be clear, and I didn't say this before, all of these puzzle
pieces and the script that we have combined them into,
so to speak, a script is synonymous with program, really, belongs to this cat.
And the reason is-- because notice how this same cat here is highlighted,
down here you can create a second cat or dog or really
anything you want graphically.
You can import something from Photoshop, or the like,
and integrate something if you want to make it for a project.
And what you'll find, ultimately, is that you
can add scripts, add puzzle pieces, to individual characters.
So these all belong to this particular cat.
So now if I go ahead and play this program, nothing's happening.
But it is running.
The program is in this forever loop, kind of waiting for what to happen?
>> [AUDIENCE CHATTER]
>> DAVID J. MALAN: To pet the cat.
So if I move my mouse toward him->> [MEOWING]
>> DAVID J. MALAN: So now I'm petting the cat.
Meanwhile, we can have a double branch.
Let me go ahead and open up don't pet the cat.
We'll post this online as well.
This is a little more complex, but without saying
you can guess perhaps what's going to happen.
>> [MEOWING]
>> DAVID J. MALAN: Cat is meowing, grand old time.
But this program is of course called "Don't Pet the Cat,"
so clearly, I want to pet the cat.
>> [ROARING]
>> DAVID J. MALAN: Don't pet the cat.
Now, let's take a look at another example here.
This one will be called "Hi, Hi, Hi," for reasons
that will be clear, because as soon as I run this thing->> [SEAL BARKING]
DAVID J. MALAN: Very easy to write annoying Scratch programs.
[SEAL BARKING]

DAVID J. MALAN: Now we won't go into great detail with all of these,
but notice there is a couple of new features here.
There's a variable, called "muted," and then there's a bunch of conditions.
And for now, let me just tease you by saying
that if this guy gets too annoying, I can hit the spacebar and he stops.
Because the role being played by these two scripts is as follows.
One of them is doing the barking every few seconds.
The other one is just waiting for me to hit the spacebar.
And if I do hit the spacebar, it's going to change
the state of this variable, the value of this variable, that's apparently
called "muted," I didn't call it something boring like n,
I called it an English word, "muted."
From 1 to 0 or 0 to 1.
From true to false or false to true.
And so you can actually see now, that you
could have two scripts, two programs running simultaneously,
and both of them might be sitting in a loop doing something.
Waiting for the human to do something like hitting spacebar.
[SEAL BARKING]
DAVID J. MALAN: And now he's on his way again.
[SEAL BARKING]
DAVID J. MALAN: So what else might we do with these examples?
Well, let's go ahead and do an example with counting sheep.
We'll continue this along the lines here of-- let's open up the sheep example.
And notice, much like before, this one, thankfully, is a little less annoying.
Once I hit play here-- Oh no, this is annoying.
He is going to baa with some probability.
Let's play this again.
>> [SHEEP BLEETING]
DAVID J. MALAN: The only difference is we've changed the costume, so to speak,
and we're halving and say what that actual number is.
Well let's go ahead and take this one step further.
And let me tease you with one other feature here.
Let's go ahead and open up a program called Threads.
So much like you can have one sprite, having multiple scripts,
you can have two sprites, a bird in a cat, each having their own script.
And each of them can operate simultaneously.
If you've ever heard the word "multithreading"
a computer is "multithreaded" means it can do multiple things at once,
and, indeed, so can Scratch.
>> And now notice the bird is kind of dumb.
It's just doing things randomly, bouncing off the screen.
Clearly the cat has been programmed to kind of have seeking capabilities
to home in on the bird because he's always pointing at him.
Until finally, he catches the actual bird.
So I won't dwell on the details here, but you can kind of
glimpse the same shapes, some "if" conditions, some variables,
maybe some loops, are ultimately doing the same thing.
>> Now let me go ahead and open up something else altogether,
to tease some of you, particularly those more comfortable,
what you can actually do with this.
I'm going to go ahead and open up Button here.
And this is a super simple-seeming program,
but watch what happens when I-- Watch what
happens when I open this version of it, here in the browser, scratch.mit.edu.
And when I click this big red button, notice what happens.
So what's going on here?
There's actually a lot more complexity going on underneath the hood,
even though I've implemented this, or frankly, Dan Bradley
has implemented this so simply.

He has designed a custom Scratch puzzle piece, known as a Scratch extension,

he called it Toggle.
>> And what Toggle does is it sends a message over the internet.
And that message itself looks a little cryptic.
But this, too, you'll understand by term's end.
The message he's actually sending looks a little something like this.
It's just text.
Cryptic.
You'll understand it by the time we get the problem set seven.
It's just sending a textual message over the internet to a server.
And that server is, ultimately, talking to this light bulb, which
has one of those fancy light bulbs in it that, itself, is talking
to the Wi-Fi in the network here, where a local device down here-and, ultimately, it's actually turning that light on and off.
But we can do more interesting things still.
Notice what Dan also did for us.
He made multiple sprites, each of which has a script waiting for a click.
And if I click red, it goes red.
If I get blue, it goes blueish.
Green, yellow, orange.
And all of this is happening by going way out onto the internet,
back down here to the light bulb, on and off.
>> And if you can believe it-- and this is perhaps one of the most complex Scrat
ch
projects someone has implemented-- he did it, in fairness, in a day.
And that was the challenge we threw down to Dan when we saw have binary bulbs,
we have Scratch, how can we combine them?
And, indeed, this is absolutely something anyone in this room
could do by semester's end-- Is he reimplemented binary bulbs using
the same interface that was on our iPad on Wednesday.
So that now, if I actually click the plus over here,
we have one, two, three.
I can hit the 16 and turn that one on.
128, and so forth.
>> Now if that alone has and blown your mind,
you could do things far more accessible, not involving any hardware certainly.
Just things on the screen itself.
And, indeed, what most students end up doing is some kind of game,
some piece of artistic work, or some kind of interactive animation.
And I will say one of our favorites has been this one.
And I thought if we could dim the lights,
we'll take a glimpse at this final Scratch project in conclusion.
But what you'll should keep in mind, as I can tease you with one last detail,
sectioning will begin next week.
Office hours will begin next week.
Problem set zero will be posted CS50.harvard.edu later today.
And you will be greeted in problem set zero
to CS50's own Zamyla Chan, who guides most of our walkthroughs.
These are embedded videos in the problem sets
that will hold your hand through a lot of the initial set up and through many
of the possible design decisions.
So if you've ever had that emotion when picking up a homework assignment
and wondering, where do I begin?
She will have that answer for you.
And now, a final program from one of your predecessors
in answer to the question "What does the fox say?"
[MUSIC YLVIS, "WHAT DOES THE FOX SAY?]
>> YLVIS: (SINGING) Dog goes woof.
Cat goes meow.
Bird goes tweet and mouse goes squeak.

Cow goes moo.

Frog goes croak.
And the elephant goes toot.
Ducks say quack and fish go blub.
And the seal goes ow ow ow, but there's one sound that no one knows,
what does the fox say?
And
>> DAVID J. MALAN: That's it for CS50.
We will see you at Puzzle Day and on Monday.
>> [APPLAUSE]
>> [MUSIC YLVIS, "WHAT DOES THE FOX SAY?"]
>> NARRATOR: And now deep thoughts, by Daven Farnham.
Today I got hit in the face with a phone book.
Confusing, as I'm at home watching online.