SPEAKER 1: All right, this is CS50,
Harvard University's introduction
to the intellectual
enterprises of computer science
and the art of programming.
And this was apparently
me around the time
that I sat where are you guys
now sitting thanks to a teaching
fellow who spent a little too much time
trolling around Lemont Library, where
the 1995 freshman registers
apparently still are.
And I point this out because
this was a big deal for me
back when I was a
freshman and ultimately
sophomore considering to take a class
like this, CS50, but more generally,
computer science.
And if you, like me, have this
perception of computer science
from high school or
even middle school, you
might have the perception that it's
entirely based about programming.
It's perhaps a bit antisocial.
It's perhaps the
computer lab, heads down,
sort of coding away on something that
you don't necessarily understand.
And yeah, I too had that perception
freshman year in this course
and, dare say, the field
more generally, really did
have this reputation to beware.
I certainly assumed that
most everyone around me
certainly knew more than I did.
And this wasn't just true of CS for me.
This was true of most any field
at Harvard in the course catalog
that I had no familiarity with.
And so I instead gravitated
toward the more comfortable.
I took a lot of gov classes
and economics and history
just because that's kind of what
I knew and liked in high school.
I wouldn't say I loved it, but I knew
it and it was within my comfort zone.
And it wasn't until
sophomore year that I got up
the nerve to take this class, CS50.
And I only did because the professor
at the time let me take it pass-fail,
now called SAT/UNSAT.
And that allowed me to get
over this sort of mental hurdle
that I imposed upon myself,
sort of fear of failure
or simply not doing as well as
I might have been accustomed to.
And so I bewared a class
like this until then.
And I always kind of regretted
not exploring earlier on.
And that doesn't have to be this class.
It doesn't have to be CS but can
be really any field more generally.
But those really were my takeaways
around the time I looked like this.
And I've taken comfort since
in taking over this class
and have found it inspiring that these
days, 68% of the students in this room
and in this room last year had
never taken a CS course before.
So if you do have that mental
model of everyone to your left
and your right surely must know
more than you, odds are it is not,
in fact, the case.
In fact, within CS50, we have these
different tracks, different types
of sections for students less
comfortable, students more comfortable
and students somewhere in between.
And there's no formal
definition to these labels.
You just sort of know it if you are.
And if you kind of have one
foot mentally out the door today
because you're not really
sure this is for you,
you're probably among
those less comfortable.
But as such, you're in the majority,
56% of last year's students.
If by contrast, you
have been programming
since you were eight
years old, 10 years old,
whatever but you're largely
self-taught and therefore
maybe have lots of
gaps in your knowledge
or don't really understand
all the formalities,
you just kind of figure things out, you
might be among those more comfortable.
And if not, maybe you're
somewhere in between.
And so in CS50 sections, do we
have similar students together,
similar comfort level,
similar backgrounds,
so that everyone can kind of feel
comfortable speaking up not knowing
things, knowing things, and beyond.
Because ultimately, the course is
graded and assessed ultimately very much
manually, very much very
delicately with respect
to students' prior
background or lack thereof.
Indeed, what's most important
at the end of the semester
is not so much where you end
up relative to your classmates
but where you end up in week 11, our
very last week, relative to yourself
today in week 0.
And in fact, thanks to CS50's
own Haley James and a whole bunch
of CS50 team members--
this summer, they spent
a while traveling around the
country bringing folks back
to campus, alumni and former students
and staff who had some connection
taking or teaching CS50 in some form.
And if you'd like to see stories of some
of your predecessors and folks who sort
have found their way--
accidentally, even--
to computer science finding
challenge along the way,
check out this domain that the team
put together-- project5050.org.
Now the course itself ultimately
is not about programming per se.
That's indeed a tool that we'll use.
It's really about this.
And that's really what CS
is, the field more generally.
Whether you're starting hardware
or graphics or theory or any number
of fields, artificial intelligence
these days, machine learning and beyond,
it's really just about solving problems.
And what's really cool
about CS I found early on
is that it doesn't necessarily--
it's not an end unto itself.
It's this field that empowers you to
go do more interesting, more powerful
things in the humanities, social
sciences, physical sciences, the arts,
anything because you have this new
mental model for how you can solve
problems better, more efficiently,
how you can solve them correctly,
and how you can sort of
analyze large datasets
or solve problems that might have
otherwise been beyond your grasp.
So what does this mean?
What is problem solving?
Well we could perhaps
distill it as simply
as this-- a big black
box, some secret sauce,
into which go inputs, like
the problem we want to solve,
and out of which comes outputs,
the solutions that we want.
So a very generic way of
describing it, but what's
pictured here in the black box
is the so-called algorithms.
And we'll come back
to that in just a bit
the actual ingredients
for solving problems.
But how do we represent
inputs and outputs?
Odds are even if you're not a computer
person and don't really think like one,
you probably know that shooters only
understand a very limited vocabulary.
Like, what is the alphabet,
so to speak, that they speak?
ASCII maybe, but more--
AUDIENCE: Binary.
SPEAKER 1: Binary, binary, bi
meaning two for zeros and ones.
So whereas we humans
typically use decimal--
dec meaning 10, 0 through 9--
as in our alphabet of letters,
computers of course, as you may
have heard, only use zeros and ones.
Now why is this powerful?
Well, turns out as soon as you have
at least two digits in your alphabet,
you can start to represent things
much more powerfully and much more
efficiently.
For instance, how many-- if I wanted
to count the people in this room,
how many of you could I
count on just one hand?
Hopefully five.
So I could call five.
It would be one, two, three, four, five.
But you know what?
If I were a little more clever,
I bet I could use the same hand
and count as many as
32, maybe 31 of you.
Well, how is that?
Well, right now, I'm kind of using
the unary system, uno meaning one.
So it's just one digit in your
alphabet-- the finger or no finger.
It's not quite the same as zero or one--
so one person, two, three, four, five.
But what if I instead permuted
my fingers in some way
so that the pattern of fingers
that are up actually matters,
not just the quantity?
So maybe this is still 0 this now is 1.
And instead of 2 being this,
maybe two could be this.
So if my second finger is up,
I'm going to call that two.
And if my first two fingers are
up, I might call that three.
Somewhat offensively, if
just this finger is up,
I might call this four and then five.
And then this gets kind of painful--
six, seven.
And what I'm actually doing
is counting in binary.
Now that might have
looked completely cryptic,
but it turns out as soon as
you have two digits, that's
enough to represent anything you want
and to do so pretty darn efficiently.
But why?
So odds are, if you're like me,
you probably grew up learning,
of course, the decimal
system, zero through nine.
And you might have written on the
board some points like this number--
123.
But why do you think of that as 123?
It's really just a pretty
pattern of symbols--
glyphs, so to speak-- on the screen that
we ascribe some kind of mathematical
meaning to--
123.
But really, it's just like someone
drew in ink on the screen some symbols.
Well, if you're like me
back in grade school,
you probably learned that
the right-most number here
is in the so-called what place?
The ones place, right?
And so if we wanted
to label these things,
we might put ones place there
and then of course the tens place
and the hundreds place, maybe the
thousands, 10,000, and so forth.
So we had this sort of mental
models for the columns.
And notice they happen
to be powers of 10.
10 to the 0 is 1.
10 to the 1 is 10.
10 to the 2 is 100 and so forth.
So that's the pattern even if
your grade school teacher didn't
talk about exponentiation at the time.
So why is this number 123?
Well, it's because we have a
one in the hundreds column--
so 100 times 1.
We have a two in the tens column.
We have a three in the ones column.
Them.
And of course, if we start
to do the arithmetic now,
that's 100 plus 20 plus
3 or obviously 123.
And all of us take that
certainly for granted these days.
You see a number, you know
what it is mathematically.
But computers fundamentally
work in the same way.
So even if you up until now have never
thought of yourself as a computer
person or had no idea
really what it means
for computers to speak just zeros
and ones, all you have to do
is update the places.
Instead of powers of 10 dec, meaning
decimal, we're going to powers of two
for binary.
So now we're going to have 2
to the 0 2 to 1, 2 to the 2, 2
to the 3, same idea.
It's just a different base.
We change tend to 2.
And so now we have places like this--
1, 2, 4, and if we kept going,
8 16, 32, 64, and so forth.
So as such, what number is this on
the screen in binary if you convert it
in your head to decimal?
It's just the number one, right?
Because you've got a 1 in the ones place
and then a zero in every other place.
So it's just 1 times 1 equals 1.
Now if I were using unary or my hands,
the sort of traditional way, two
would be this where
you put up two fingers.
But not if you're trying to use
patterns as well as quantities.
And so in binary, how do I
represent the number two?
010.
It's the equivalent of putting
up just my index finger here.
And if I want to count to three,
now I need to add a 1 to the mix.
So I add the ones place.
And now if you start
to visualize this, it's
like one of those really
old school clocks where
the numbers flip around and roll over.
Now those ones are going to
kind of flip and become zeros
and the zero is going to become a one.
And so now we have five and
then six and then seven.
And then dang it, how does
a computer count to eight?
Yeah, you just need to
add another place, right?
Just like we humans don't have
an infinite number of numbers
when we write something
down-- we sort of stop
when it's not necessary--
all we need is another bit.
We just need to add another 0 or
1 to the left, specifically a one.
Then all these ones can become zeros.
And we can do this toward infinity.
But where are these bits coming from?
This is all very abstract and
just pictures on a screen.
Well, it turns out that we
have one physical ingredient
to all of our computers.
Maybe it's your laptop or
desktop or your cell phone.
At the end of the day, they're
either driven these days
by batteries or like a cord into the
wall where electricity comes from.
And even if you have little
familiarity with electricity,
you probably know that it's
like little electrons flowing.
So there's some kind of physical
resource that can flow or not flow.
You can turn it on or off.
Well, much like these
desk lamps here, here I
have three physical lights that are of
course connected into the electricity.
So I have some physical input.
And now that I do, I can kind
of implement my own computer
using these simple desk lamps.
If I want to represent some value, some
input or output, OK, here's the zero.
This is zero in binary.
I just need to leave
three light bulbs off.
If I want to represent a
one, I need to turn this on.
And that's now the ones place.
If I want to represent two, I
just need to turn this light on.
If I want to represent
three, this one comes on.
If I want to represent
four, that goes on.
5, 6, seven, and then of
course we need like 8,
if we want to represent and turn
these off, four total bits together.
And so that's all that's going on inside
of your phones and your computers.
Phones and computers
and devices these days
have what are called transistors,
which are tiny little switches that
are on or off.
And that's all we need if we have some
source like electricity to just store
information.
We just need lots and lots
of switches, lots and lots
of light bulbs, certainly much smaller
in order to represent information.
But computers of course can do
much more than represent numbers.
What about letters and
e-mails and things like that?
Well, for that, we actually
need to kind of decide
as humans how we're going to interpret
things like these light bulbs.
In one context like a calculator,
or they might represent numbers--
decimal numbers whatever.
But in an email program--
Microsoft Word, Google Docs--
you probably want those light
bulbs or those transistors
in the computers storing
not just numbers,
or else you could just do math.
You want them storing letters and
sentences and paragraphs and so forth.
And so we need to have
some kind of mapping.
And we'll do that as follows.
ASCII, which is just
an acronym describing
a mapping from numbers
to letters-- humans years
ago just decided, you know what?
In the context where
we need letters, let's
just store a pattern of bits
that's equal to the number 65
if we want the letter a.
Pattern of bits equal to the
number, decimal number, 66
if we want to store the number b.
Fast forward to h and i.
If you want to store h or i, 72,
73, and just store that many bits.
And now I don't care any more in this
story how you represent 65 or 73.
I just need to know that you
can somehow with light bulbs
on stage, with transistors in my
phone, or whatever the device may be.
We can begin to abstract
away these low level details.
In fact, we're not
going to spend much time
after today talking about
binary in CS50 because here, we
have sort of electricity conceptually.
On top of that, we can build the
notion of binary, zeros and ones.
And once we come up
with this convention,
now we can start to talk
about letters of an alphabet.
But that's not the only
thing we can talk about.
We can also talk about graphics
and videos and all the things
we take for granted these days.
For instance, and just to
recap, what message have I
encoded here on the
screen if you recall?
AUDIENCE: High.
SPEAKER 1: Yeah, it's high because
72 and 73 I claimed a moment ago
are just the numbers we humans came
up with years ago to represent HI.
I don't really know what 33 is.
You'd have to look it up or be told it.
Turns out it's an exclamation
point because indeed humans decided
to express in numeric codes as
well all the keys on a keyboard.
Unfortunately, they weren't
very far sighted early on.
They only used 7 bits total
and later kind of 8 bits.
But even that, even though that gives
us over 200 possible values, 256,
there's a lot of languages that
aren't in like the English alphabet,
Asian languages and the like,
that have many, many, many more
symbols than you can express with
just seven or eight bits alone.
And so now ASCII has been succeeded
by something called Unicode.
And long story short, humans have begun
to solve problems that were initially
created by not anticipating, needing, or
wanting even larger values than these,
but in another context like
Photoshop or any graphics program,
you might see the same pattern of bits--
72, 73, 33.
But in those programs, they
know to interpret these numbers
as some amount of color.
If you've ever heard of RGB--
Red, Green, Blue-- this
is just an acronym that
describes how you can mix
together three different colors,
sort of in the spirit of paint
or more technically light,
combine these three different colors,
and get any color of the rainbow.
So each of these numbers I'll claim
can be from 0 to 255 and 72 out of 255.
That's like a medium amount of red.
That's like a medium amount of
green and just a little bit of blue.
And if you combine those three
colors by mixing them together
into just one dot or pixel,
as it's called in a computer,
you get this sort of
murky shade of yellow.
But in the context of Photoshop
or some graphics program,
that is what those same three patterns
of bits would be interpreted as.
And it happens to be the case that
talking in terms of single bits,
it's not all that useful.
With one bit, you can
count as high as one.
So humans long ago also standardized
on a nomenclature a byte, B-Y-T-E,
is just 8 bits.
And if you've ever heard of
kilobytes and megabytes and gigabytes
and terabytes and the like,
those are just multiples thereof,
typically orders of magnitude
of 1,000 or 1,024, or more.
So with just three
bytes, 24 bits, can we
represent letters,
numbers, and the like.
And ultimately, these are
just examples of abstraction.
And this is going to be
a thing that permeates
not just this class, but computer
science more generally-- taking
very simple ideas that really don't seem
all that interesting at first glance.
But as soon as you use them as
ingredients to solve a problem,
you can then sort of reuse that tool
to build something more interesting,
reuse that tool to build
something more interesting
still until you get to work
application development
and solving real problems
that you care about,
taking for granted the
people that came before you
have solved a lot of these lower level
implementation details, so to speak.
So what is inside this black box?
It is what we shall call algorithms.
And an algorithm, if familiar, is what?
It's kind of a fancy looking
word, but it's a simple thing.
What is an algorithm if anyone knows?
AUDIENCE: Step by step instructions.
SPEAKER 1: Yeah, it's just step by step
instructions for solving a problem.
That's it.
That is an algorithm-- step by step
instructions for solving some problem.
So what might be a problem
that we want to solve?
Well, I'm reminded of, and we've--
I'm reminded of fifth grade.
My homeroom teacher
was trying to teach us
as effectively as she could how
to follow directions correctly.
And at the time, it was
a complete disaster.
But I always remember from
that example the demonstration
that she did because it lent
itself, although she didn't
use this word at the time, to this
notion of computational thinking
or thinking like a
computer, if you will,
whereby you want to solve
something correctly.
But to do, so you need to be
fed very precise instructions.
And this is easier said than done.
And so in fact, to recreate this, thanks
to the team here, we have a plate.
We have a loaf of bread.
We have a jar of creamy
Skippy peanut butter.
And we have a jar of
Smucker's Concord gape jam,
and then for the invariable
need, a whole lot of paper towel
and this one knife.
And so let me propose
that for just a moment,
I'll play the role of
a computer or maybe
in this form like a robot who's
implementing some algorithm where
you guys are the programmer, the person
who's supposed to feed me instructions
so that I can solve the problem.
And the problem here will be to,
implement, perhaps no surprise,
a peanut butter and jelly sandwich--
easy to sort of do intuitively
if you grew up eating these things.
But if you've never really thought
about how to teach someone else to do it
and that someone else is not as
sort of forgiving as another human
where we humans have conventions
of just reading between the lines--
computers can't do that.
They will only do what
you tell them to do.
And as such, they are less powerful,
in some sense, than we humans.
So what's the first step for
making with these ingredients--
these inputs, if you will-- a
peanut butter and jelly sandwich?
AUDIENCE: Open the bag of bread.
SPEAKER 1: Open the
bag of bread, I heard.
AUDIENCE: That's wrong.
SPEAKER 1: Correct, but not really
what you had in mind, perhaps.
But that's OK.
The bag is open.
So what might a more
precise step two be?
AUDIENCE: Remove two slices.
SPEAKER 1: Say again?
AUDIENCE: Remove two slices.
SPEAKER 1: Remove two slices.
OK.
AUDIENCE: Put those two
slices on the plate.
SPEAKER 1: Put those
two slices on the plate.
AUDIENCE: Drop the knife.
SPEAKER 1: Drop-- what?
Drop the knife?
AUDIENCE: [INAUDIBLE]
SPEAKER 1: OK.
AUDIENCE: Unscrew the jam.
SPEAKER 1: Unscrew the jam.
OK.
AUDIENCE: Grab the knife.
SPEAKER 1: Grab the knife.
AUDIENCE: Put the knife in the jelly.
SPEAKER 1: Put the knife in the-- oh.
What?
AUDIENCE: Other end of the--
SPEAKER 1: Oh, thank you.
Right?
Grab the knife from the other end.
Someone from farther back, perhaps?
AUDIENCE: Stick the knife in the jam.
SPEAKER 1: Stick the knife in the jam.
What's that?
AUDIENCE: Take it out.
SPEAKER 1: Take it out.
OK.
Again?
AUDIENCE: Put the knife in the jam.
SPEAKER 1: Put the knife in the jam.
Ow.
Scoop it.
AUDIENCE: Yeah.
Dump it on the bread.
[LAUGHTER]
SPEAKER 1: OK, we're halfway there.
Now what?
AUDIENCE: Spread the jam with
the knife across the bread.
SPEAKER 1: Spread the jam with
the knife across the bread.
AUDIENCE: Evenly!
SPEAKER 1: Oh, evenly.
Let's be careful here.
OK, OK.
Next?
AUDIENCE: Do the same thing you did
with the jam with the peanut butter
on the other slice of bread.
SPEAKER 1: OK, so I
think we did this first.
AUDIENCE: And this time, don't
get a lot of peanut butter.
SPEAKER 1: We did
this, then we did that.
Then-- oh.
All right, I'll take some liberties.
OK, and now we put it in again.
AUDIENCE: Scoop a little bit out.
SPEAKER 1: "Scoop a little
bit out" I heard this time.
AUDIENCE: Onto the other slice of bread.
SPEAKER 1: Onto the other
slice of bread, thank you.
AUDIENCE: Spread it evenly.
SPEAKER 1: Spread it evenly.
Next time, have me use
my right hand please.
OK, and--
AUDIENCE: Put the knife down.
Put the jam side on the peanut butter.
SPEAKER 1: Thank you.
Put the jam side on
the peanut butter and--
delicious.
OK.
Thank you very much.
[APPLAUSE]
So a silly example, to be fair, but
just realize how much opportunity there
was even in something as simple
as that for ambiguity or scenarios
you didn't anticipate.
And indeed, among the things
we're going to do today
as we begin to formalize these ideas
with code, with programming code,
are how you think about breaking down
problems into their constituent parts,
considering what happened-- what
should I do if this happens?
What should I do if this happens?
What should I do if this happens?
Because unless you anticipate
the kind of silliness
that I was deliberately
acting out there,
who knows what the computer
might end up doing?
After all, odds are
everyone in this room
like me has seen like a spinning
beach ball or an hourglass
on your computer or your Mac
or PC freezes or crashes.
And almost always that's just
the result of some human error.
Someone at Google or Microsoft or
Facebook or wherever made some mistake.
He or she did not
anticipate some situation,
didn't anticipate you typing
in a word that you did,
didn't anticipate you
running 20 programs at once,
didn't anticipate some scenario.
And so as such, the computer's
behavior was effectively undefined.
And so the incorrect
solution was outputted.
So how do we begin to think about this?
What would be ideal if we somehow--
if we somehow formalize
this by way of actual code.
And we'll do that with
sort of another old school
problem, one that's a lot
more digital these days
but it's still with us today.
Whether you have an Android
phone or iPhone or anything else,
odds are you have like a little app
for your contacts or your address book.
And then there are a
whole bunch of names,
probably alphabetical by
first name or last name,
and a whole bunch of telephone numbers
and maybe more information like emails
and so forth today.
But the physical incarnation
of that icon on your phone
is this old thing, a phone book.
And if I wanted to look for an old
friend like, say, Mike Smith, how might
I go about finding him in
this old school phone book?
Well, just as in my
digital form, I might just
scroll through the list looking for him.
So could I look at the first page,
look down, not see him, turn the page,
look down, not see him, turn the page,
look down, not see him, and so forth.
Is this algorithm correct?
AUDIENCE: Yes.
SPEAKER 1: Yeah, it's correct.
It's kind of dumb right
because it's going
to take forever to get to Mike
if there's like 1,000 pages here,
but it is correct.
And it's the equivalent really of
sort of slowly methodically scrolling
through your list of contacts
without the luxury of like searching
or autocomplete or the like.
Well, I could do a little better.
Back in grade school, I generally
learned to count by two.
So I could instead do
2, 4, 6, 8, 10, 12.
I'm flying through the phone
book now clearly faster.
But is that algorithm correct?
AUDIENCE: No.
SPEAKER 1: No why?
AUDIENCE: You might miss him.
SPEAKER 1: Yeah, I
might miss him, right?
Like Mike, just by chance,
might be sandwiched between--
so it is, no pun intended-- between
the two pages then I'm flying past
and I might miss him.
But I can at least fixed this
mistake or bug, so to speak.
A bug is a mistake in a
program, just human error.
If I hit like the T section,
t comes after Smith.
So I can maybe double back at
least one page and solve that bug.
So it costs me a little bit more time
to double back, but if I do it right,
it only costs me like
one extra page turn.
So better and now correct.
But obviously no one in this room
is going to look for Mike Smith
by starting on the first page.
Where are you going to roughly look?
In the middle, maybe a little toward
the end because you know where S's are.
And so you open the book to the middle.
You look down and you see the M section.
So I haven't gone far enough.
But what's nice about
this old school technology
is that we can now tear this
problem in half, throw half of it
away, and be left with fundamentally
the same problem but a smaller version
thereof.
This now is maybe not 1,000 but 500
pages, but it is the same problem.
And I can apply the same logic, go
roughly to the middle, look down.
I went a little too far
this time, the T section.
But I can again tear off almost
a quarter of that problem,
leaving me now with a total
size of the maybe 250 pages
after dividing it in half twice now.
And now I can repeat
and repeat and repeat.
And so long as Mike
is in the phone book,
I should ultimately find
him once and only once
on the final page of the phone
book, at which point I can call him.
So the real question then
is how much better was this.
It's a little wasteful.
You can't sort of undo
here in the analog world.
But let's consider how we can think
about how good that algorithm was,
the one that we all probably took for
granted and should have started with.
Well, if here's a simple plot
and on the x or horizontal axis
is the size of the problem--
so the number of pages in the phone
book, however you want to measure it--
and then the y or vertical
axis is time to solve--
so maybe number of seconds,
number of page turns,
however you want to count up the steps--
that's a relationship, size to time.
And the first algorithm
I'm going to draw
like this-- a straight line in red.
And I'm going to call it n where
n is just like the number of pages
in the phone book.
Computer scientists tend to use n as
a variable so to speak, just a symbol.
And it's a straight line
for the following reason.
If the phone book gets a little longer
next year, a little longer next year,
by like one page, that
means I might have
to spend one more step looking for Mike.
So the slope of this line is linear.
There's a one to one
relationship between number
of pages Verizon or the phone company
puts in the book and the number of page
turns I need to make.
The second algorithm, though,
is also a straight line,
but it's lower drawn here in yellow.
And n over 2 means it's twice as fast
or equivalently takes half as much
time because for a given size problem,
if you kind of follow my hand straight
up, the yellow line should
be below the red line
because I'm flying through the
phone book two pages at a time.
So it should take me half as much time.
But if I use the first algorithm,
I have to go all the way up
to the red, which measures
that number of seconds.
But the third algorithm is a
fundamentally different shape.
And this is where the sort of beauty
of computer science and algorithms
specifically comes out.
It doesn't become straight ultimately.
It looks like it's gradually easing off.
But it's going to do this forever.
It's just becoming such
a slow increase in time--
you can't even really see it especially
if the screen were even wider.
We'll call this logarithmic, log
n, more on that down the road.
But the shape is
fundamentally different.
It's curved.
And what's powerful about this-- and
you can think about it much more easily,
intuitively.
If Verizon next year doubles
the size of the phone book
because like maybe
Cambridge and another town
merge together into
one book, no big deal
because if Verizon doubles the
size of the phone book next year,
how many more page turns
do I need to find Mike?
AUDIENCE: Just one.
SPEAKER 1: Just one, right?
Because I just split the problem
in half one more time, no big deal,
instead of flipping through an
additional 1,000 or 500 pages.
And so this intuition with
which you entered Sanders today,
odds are you can harness it already
to solve problems more effectively so
long as you start to notice the
patterns and the sort of useful inputs
with which you can solve problems.
But we need to begin to
formalize the process.
We need to be able to express ourselves
a little less organically than we
did with the peanut butter and jelly.
So how might we more
methodically express
that algorithm with the phone book
for which we probably nonetheless
have an intuitive understanding?
Well, let me start counting at zero
just because programmers and computer
scientists tend to
start counting at zero
because that's like all
the light bulbs are off.
So you might as well start there.
And then step zero would
be pick up phone book.
It's sort of an action.
Do this.
Step one is open to the
middle of the phone book.
That's pretty much what
I did a moment ago.
Step two is look at the names--
another action or verb
Step three, if Smith is among names.
So this is a different construct.
And that key word here
is going to be if.
It's a question you're asking yourself.
It's kind of a proverbial
fork in the road.
If Mike is among the names on the
page you're looking, then call Mike.
And I've deliberately indented it
because in many computer languages,
indentation means logically
that you should only
do step four if line three were true.
Or the answer to that question is yes.
Else, if Smith is earlier in the book,
he's meant to my left, then step six,
open to the middle of the
left half of the book.
So that's when I tore it in half,
threw it away, and then repeated
on the left half.
Else, if Smith-- oh, sorry.
Then go back to step two, a key step.
Now that I've divided
the problem in half
and I'm looking in the
middle of the left half,
the problem is fundamentally
the same as I claimed before.
Just do the same thing
but on a smaller problem.
And what's beautiful about this
algorithm-- it's recursive,
so to speak, as we'll
see down the road to--
is that you keep doing the same
thing, same thing, same thing,
but because the problem
keeps getting smaller,
eventually you're not
going to do this forever.
You're going to find the
answer you're looking for.
And so we go back to step two.
Step eight, else if Smith is
later in the book, to my right,
open to the middle of the
right half of the book
and then again go back to step two.
Else-- what's the fourth
scenario to consider?
AUDIENCE: [INAUDIBLE]
SPEAKER 1: Yeah, what if
Mike isn't in the phone?
He's unlisted.
We'd better anticipate that less my
program crash or my computer freeze
because, like, it doesn't know
what to do if Mike isn't there.
So I'll quit in this particular case.
And now let's tease this
apart by highlighting
in yellow those operative
verbs or actions.
Henceforth, we're going to call things
like these yellow words functions,
so to speak, in a programming language.
These are verbs or actions, and I'll
call them out, albeit in English
because there's no one language here.
This isn't like a formal
vocabulary we're introducing.
It's just my most distinct way
of expressing that algorithm.
And that's what pseudocode is.
It's English like syntax
that anyone in the room
should hopefully be
able to follow if you're
nice and clean and precise about it.
But there's another
type of keyword in here
and that's the if and the else
if and else if and the else.
These are the keywords
that languages typically
use to represent these
forks in the road-- go left,
go right, go here, go
there, do different things.
And each of those decisions, if
you will, is based on the answer
to a question.
And these questions we're going
to call Boolean expressions named
after a person named Bool years ago.
And a Boolean expression is just
a question with a yes or no answer
or really more technically
a true false answer.
And notice the fact that everything
falls into like buckets of two--
yes, no, true, false--
means we can use those light
bulbs really to our advantage.
Maybe off shall be no or false.
Maybe on will be true or yes.
Just using a one light bulb can
we represent any of these answers
to these questions.
And so those are Boolean expressions.
And then lastly, there is these things--
go to step two, which is
perhaps the most explicit.
It's inducing some
kind of loop or cycle.
Do something again and again.
And all of these ideas, functions,
conditions, Boolean expressions, loops,
and more are going to permeate
several languages that we explore over
the course of the semester.
But of course this unto
itself is not yet real code.
And today in just a little
bit, we're going to dive
into real programming code, albeit
graphically using a language
called Scratch, and then follow that
on later next week with a programming
language called C.
But before that, let me make
just a couple of introductions.
Behind CS50 and its lectures and
sections and office hours and more
is a whole team, nearly
100 staff every year,
that are here to make this
course successful for you
so that irrespective of your
prior background or lack thereof,
you too can succeed, especially
if you are among those 68%.
And allow me to invite up Maria
and Brian and Doug and Rob
to come say hello from
the course's staff.
DOUG LLOYD: Good morning, everybody.
My name is Doug Lloyd.
I'm the course's senior
preceptor and course manager.
12 years ago now, I sat
figuratively where you sat.
It was in Lowell Lecture
Hall just across the street.
I was among those less comfortable.
I had never programmed
before in my life.
I took CS50.
It totally changed the way I
thought about problem solving.
I switched to CS major
shortly thereafter,
and I've been on the staff
with David for 11 years now.
So it's great to be here once again.
Thank you all for being here.
MARIA: Hi, everyone.
My name is Maria.
I'm a senior living in Cabot, and
it's my fourth year in the course.
I took it as a freshman at an awesome
time, and it's my third year on heads.
And I've absolutely loved it.
The staff is amazing.
Working with all of
us amazing and I can't
wait to have an amazing
senior year with you guys.
BRIAN: Hi, everyone I'm Brian.
I am the course's head course assistant.
I am a junior living in Winthrop,
and I took the class my freshman year
two years ago now.
And really glad that all of you
are here and really looking forward
to a fantastic semester and
working with all of you.
ROB: Hey, guys.
I'm Rob.
I'm a fourth year PhD
student living in Thayer,
and this is my eighth
year with the course.
And every year, I think
the course gets better.
And we put a lot of effort
into the course over the summer
and building new tools
and making new curriculum.
And I really think that you
guys are going to enjoy it.
[APPLAUSE]
SPEAKER 1: Thank you.
We have a tradition in CS50 of ending
the first week with cake or cupcakes.
And so after today's lecture,
you're welcome to join us
in the transept to meet even
more of the course's staff.
But first, and before we transition to
one of these first actual programming
languages, we thought
we'd dim the lights
and paint a picture too of not just
the course's support structure,
but also its culture or
community, which is something
we've increasingly focused on in recent
years so that students in the class
feel that it's not only an opportunity
to get an introduction to computer
science but also an
introduction at Harvard
and, as you've seen at Yale and
beyond there, a community of support
so that you can lean on each other
as you tackle the week's problems
and ultimately exit having had a
very shared similar experience.
This is CS50's community.
[MUSIC PLAYING]
SINGER: [SINGING] [INAUDIBLE]
Stop rocking the beat.
Come on!
[INAUDIBLE]
SPEAKER 1: All right, so before--
so before long, this is what
code is going to look like.
And frankly, it's pretty darn
cryptic and it's pretty darned
distracting with the semi-colons,
as we'll see, and curly
braces and parentheses and the like.
And frankly, these kinds
of syntactic distractions
tend to get in the way
of learning what's really
the interesting intellectual content
about programming and computer science
more generally.
And so we instead begin today
before transitioning next week
to that language with Scratch,
an adorable language that
was invented down the
street at MIT's Media Lab
some years ago that wonderfully has
all of the concepts we've looked
at thus far in the form of Mike Smith,
in the form of peanut butter and jelly,
and yet more ideas and
allows us to program
today by dragging and
dropping puzzle pieces,
really, that only interlock if
it makes logical sense to do so.
And coincidentally too, as you may have
glimpsed as part of CS50's community,
is as you may have seen door
drop this week's CS50 Puzzle Day,
an opportunity to not solve problems
using computers and programs but rather
peers and forming teams of two
or three or four across the river
at the iLab for CS50 Puzzle Day.
Grab one of the invites
on your way out, the goal
there being to message the computer
science itself is indeed not
about programming but
ultimately about problem solving
and, in this case, pizza
and prizes as well.
So this here is Scratch.
And what's nice about scratch
is that via this language,
can we distill that previous,
more cryptic program
into just a couple of puzzle pieces?
And let's see the comparison.
If we look back just
a moment ago, there's
this program in C, a fairly
old programming language.
But it's nice in that it's fairly small.
We'll see that we learn almost every
aspect of this language before long.
But what do you think it does?
Especially if you've
never programmed before
and don't even recognize some
of the words on the screen,
what operative word maybe
does jump out at you?
What is the-- prints.
So it's technically prints
f, which I don't really
know what that means right now.
But printing sounds familiar.
And what's it going to print?
AUDIENCE: Hello world.
SPEAKER 1: Probably hello world.
When I run this program
on my Mac or PC, odds are,
it's going to print,
quite simply, hello world.
How?
Don't know yet, but we'll get there.
But for now, the same program
in this other language,
Scratch, can be implemented graphically
by dragging and dropping two puzzle
pieces together so that scratch
has, you'll soon meet as a cat,
says hello world in a
cartoon-like bubble on the screen.
And so in fact, we'll be able to explore
with Scratch all of these same ideas--
functions, conditions, Boolean
expressions, and loops--
and then bunches of others as well that
we'll then see again in C and later
in the semester in Python and later
in the semester in SQL and JavaScript
and beyond.
And so we'll begin by
exploring them as follows.
Let me go ahead and open
up this program Scratch.
It exists in two forms--
an offline version
that I tend to use in class just
so we don't have Wi-Fi issues,
but then an online
version at scratch.mit.edu
which you'll use for the course's
first assignment problem set zero.
And this is what the
environment looks like.
On the top left where this cat here
is, we'll call this Scratch's stage.
This is his two dimensional
world wherein he can move up,
down, left, or right.
In the middle is a whole bunch
of categories of puzzle pieces.
This one here says move 10 steps,
turn 15 degrees, and so forth.
And up at the top are different color
coded other categories of other puzzle
pieces we might want to use.
And then at right here is
a so-called scripts area.
This is where I can program.
This is where I'll drag and
drop these puzzle pieces.
And down here if I want more than
one cat or some other character,
I can create other sprites
or characters as well.
So how do I program in this case?
Well, notice first that Scratch's world
has a green arrow and a red stop sign.
Green arrow is going to mean go.
Stop sign's going to mean stop.
So that's how I start and stop my
program up here just above Scratch.
Meanwhile, if I want to start
programming, I'm going to do this.
And I know this only from having
used Scratch before where things are.
If I click on the Events category,
notice this puzzle piece here--
when green flag clicked.
I can drag and just drop that
puzzle piece anywhere on the right.
And my program's not
going to do anything
because I haven't finished the thought.
But if I now go to looks, a
different category in purple,
I might say something like, say--
and now notice when I get close
enough, they're sort of magnetic.
They want to interlock.
So I can let go and then type
in here hello comma world.
I'll zoom out now, move my cursor
over to the green flag, and click.
And now I've written my first program.
It's not all that complex, certainly.
All I did was drag and
drop a couple of graphics.
But logically, it's doing
exactly what I told it to do.
Well, before we proceed further,
let's see what some of these blocks
are fundamentally going
to look like so that we
have a mental model for these
various color coded categories.
In purple, we're going to see
functions-- actions, or verbs, like we
saw with the phone book example.
Here, we're going to have conditions.
It's a few more puzzle pieces, but they
very beautifully interlock together.
And this is a branch or a condition.
And notice too just like
in my textual program,
I indented things by hitting
the space bar or tab key.
So here is it kind of indented
because the yellow wraps
around the whole puzzle piece.
So it's only going to say x is less
than y if those orange puzzle pieces
x and y, which we'll call variables,
which just like an algebra hold values
like one or two or three or four.
We're going to say x is
less than y in that case.
Meanwhile, we can nest these things.
So even though they
look like a fixed size,
they'll actually grow to fit other
blocks if you want to cram more in.
So here, we have a three way fork in
the road just by combining these ideas.
If x is less than y, then
say x is less than y.
Else if x is greater than y,
then say x is greater than y.
Else the third scenario, of
course, is x must be equal to y.
So this is how we'll program.
We'll just drag and drop
these puzzle pieces together.
What is this green block here
called generally speaking?
AUDIENCE: [INAUDIBLE]
SPEAKER 1: Well, the
condition we'll technically
call the yellow that's
using this green block.
AUDIENCE: Boolean.
SPEAKER 1: Yeah, it's
a Boolean expression,
and it is because it's a
yes/no or true/false answer.
x is less than y is
either true or it's false.
It can't be both.
And so we might have more
generally is i less than 50.
You don't have to compare variables.
Just like in math, you can
compare numbers against variables.
But here is a different concept.
We call this a loop, some kind
of cycle that does, in this case,
something forever
like, say, hello world.
Or we can do it a finite number of
times-- like, 50 times say hello world
and then stop.
Here's how we might set a variable.
This orange block says set a variable
called i by convention because i
stands for integer like a number.
Set it equal to 0.
And then these two things are
demonstrative of a more powerful
feature that Scratch and languages
tend to have of multi-threading.
This is a fancy way of saying a
program can be written in such a way
that it does two things at once.
How?
Just use two of these puzzle pieces
so that when you click the green flag,
multiple things happen at a
time, thus our supported threads.
And then there's this,
an even fancier feature
but that's relatively easy to use.
It's called event handling,
and we'll come back to this
when we introduce web programming
later in the semester.
Broadcast and when I
receive just mean this.
One sprite, one character,
like the cat, can kind of
sort of whisper to another
sprite in the program
and send it a message that it can
hear or, more properly, receive
and then do something based on it.
So rather than have your
program do something only
when you click the
green flag, you can have
one sprite talking to another
telling it when to begin
or something along those lines.
And so with just these
fundamentals are we
able to begin implementing
any number of programs.
In fact, let's go ahead and do this.
Let me go ahead make this
more interesting by not just
saying it on the screen.
Let me go ahead and go to
sound and play sound meow.
[MEOW]
With slightly more volume.
[MEOW]
Oh, With slightly less volume.
[MEOW]
Adorable.
It's a simple program.
And if I want it to meow three times--
[MEOW]
--I just have to hit it three times.
But I can do better than this.
I don't want to rerun the program.
What's the construct that
would let me meow three times?
Yeah, a loop or repeat.
So let me go to control.
I'll zoom in.
Repeat-- by default, it's 10 times.
So I'm going to change that to three.
I can drag this away
and now put it inside.
Notice it wants to connect
inside and it grows to fit.
And now I can let it connect there.
Let me hit play again.
[MEOW]
Hm, what's happened there?
My first bug.
This is subtle, but
it's the kind of thing
that should give you pause, especially
if encountering this on your own.
Turns out I should have thought a little
more closely about what blocks to use.
The hint is kind of on the
screen, though it's very subtle.
Until done-- like, there's
this alternative block.
And you know what?
I don't know why this is going to
be true yet, but let me do this
and get rid of this by
just dragging it away.
Let's see if this fixes the
problem even if we're not sure why.
[MEOW]
[MEOW]
[MEOW]
It's not a very natural sounding
cat, but it kind of fixed the bug.
So can we infer retrospectively
why it was previously buggy
and how it was buggy?
AUDIENCE: It played all three at once.
SPEAKER 1: Yeah, it kind of
played all three at once.
Not technically at the
exact same time, but my Mac
is so darned fast these days, right?
Intel inside-- you've got
a gigahertz CPU or brain
inside of the computer or 2 gigahertz.
Those numbers literally mean your Mac or
PC can do a billion things at once or--
sorry, a billion things
in a second, which
just still pretty good, or 2
billion things in a second,
which is still pretty good.
So certainly it can meow
three times and the things
just kind of trip over each other.
But if we instead use the block
that says play it until done,
then you'll actually hear all three.
And we can actually do a
little better than that
because that was not a very normal cat.
I can drag this block, wait
one second, and let's see
if this is a little now more natural.
[MEOW]
[MEOW]
OK.
[MEOW]
So not bad-- pretty darn adorable.
But what if we want to
add in some motion now?
Let me go ahead and remove this.
And let me do a forever block
so I don't have to figure out
in advance how long to do this.
And let me go to motion and move 10
steps and now click the green flag.
Ah, OK.
Thankfully, MIT realized
that this could be bad.
So they give us just enough access
to his tail to pull him back.
But this is not the best program.
It would probably be better if he
bounces off the side or detects--
collision detection, right?
We're living in a world now of
self-driving cars, apparently.
It would be nice if things--
well, maybe they don't
bounce off of each other,
but they avoid things altogether.
So that's OK.
I have the vocabulary
with which to do this.
Let me zoom in.
And what is the construct
I want to solve this?
Like if you hit the edge, turn around.
It's some kind of if, right?
So let me pull this out
and then say, oh, OK.
If-- now I have to finish the sentence,
and I can do this more quickly just
from experience.
So I'm going to go to sensing.
And then I'm going to grab this
Boolean expression in blue.
And notice it's way too big,
but it will grow to fill.
And now from this dropdown, I can
actually ask this question instead.
If touching edge, what
might I want to do?
Maybe turn like this.
And I'm going to turn like 180 degrees
just to completely wrap around.
And now I need to move this back in.
And again, it looks like it might
not fit, but it will grow to fit it.
Else go ahead and move 10 steps.
So let me go ahead and hit play now.
OK, still a little buggy,
but at least it's dynamic
and it's doing this forever.
Now we can stray from the
academics of this example
and do something silly like this just
so you know what features it has.
This is a microphone.
That was me recording
this is a microphone.
Here we go.
Ouch!
OK, that's what the word ouch
looks like as a waveform.
Let's now call this ouch.
And now I need sound.
Whoops-- scripts.
Sound, play sound ouch logically.
So just to give you a sense of what we
did, if touching edge play sound ouch,
turn around.
Ouch.
Ouch.
Ouch.
It's a little bit of a delayed
reaction, but we've now
sort of combine these different ideas.
And already we've kind of moved
quickly beyond where we started.
All we did initially was say something.
Then we move the cat.
Now we moved it forever.
Then we moved it forever unless
you hit the edge in which case
you should turn around.
So just by building on
these very simple ideas can
we make more complicated programs still.
And let's fast forward for just
a moment before we tease apart
some of the more sophisticated features
to take a look back at actually
the very first program I myself
wrote back in graduate school
when Scratch first came out.
I called it Oscar Time since
I always loved Sesame Street.
And this was the program I made that
combines many, many, many, many hours
after first starting with Scratch
a whole bunch of these same ideas.
And rather than I playing
this, it would be more fun
if someone else perhaps plays.
Could we get a brave volunteer
maybe a little farther back?
Yeah, what's your name?
AUDIENCE: Mansi.
SPEAKER 1: Mansi, come on up, Mansi.
All right, thank you to Mansi.
[APPLAUSE]
And you have to be comfortable
being on the internet
now since there are cameras.
Nice to meet you.
SPEAKER 2: Nice to meet you too.
SPEAKER 1: Come on over.
And so with Oscar time here, notice
there's a whole bunch of sprites.
So you'll see a bunch of
things happening at once.
And realize I did not start writing
this program by implementing this game.
I implemented just pieces of it at a
time until the net effect many, many,
many hours later was the
game you're now about to see.
Let me go ahead and full screen it.
And we'll see some directions
on the screen in just a moment
and you can control with the keyboard.
Drag as much falling crash
as you can to this cash down.
OSCAR: [SINGING] Oh I love trash.
Anything dirty or dingy or dusty.
Anything ragged or--
SPEAKER 1: Very good.
OSCAR: [SINGING] --or rusty.
SPEAKER 1: So as she plays, let's
consider what some of the building
blocks are of this program.
So the first thing I think
I did when I implemented
this game, which is about to get
more and more complex, is I just
figured out how to move a piece of
trash from the top to the bottom.
And that's kind of what
we just did with the cat
albeit a top bottom
instead of left or right.
And then after that, I think I
probably implemented part of Oscar.
And Oscar is very sort
of simply animated.
This is not like a video.
This is like three or
so different images.
So the trash can is closed.
It's partly open.
It's fully open.
He pops out.
It's just a bunch of different images
or costumes, as MIT calls them,
that I play like a half second
apart in order to create
the illusion like those old
school flip books of something
happening in animated fashion
Meanwhile, he's counting clearly.
So that using variable, one of those
orange puzzle pieces we previously saw.
There's some kind of randomness.
It turns up programs,
and Scratch included,
can use pseudo randomness--
kind of sort of random values
so that the trash sometimes
falls here or here or here.
And lots of video games do this, right?
A lot of the games you
might have grown up playing
would be pretty lame if they are the
exact same every time you play them.
You want the computer
or CPU to do things
a little differently or randomly.
OSCAR: [SINGING] Now look
at this rest of this junk.
A clock that won't work and an
old telephone, a broken umbrella--
SPEAKER 1: Now keep in mind, this
song is like three minutes long
and having just one bug
partway through this program
was an absolute nightmare to debug
waiting the minute or two until it
happened again.
OSCAR: [SINGING] Oh I love trash,
anything dirty or dingy or dusty.
SPEAKER 1: It never really stops.
So congratulations.
Thank you.
Let me thank you with a
little CS50 stress ball.
No less as well.
So that then is Oscar Time.
But what's nice about
it, beyond being my baby,
is that it gives us an opportunity
to consider how you might build up
something pretty complex looking
and hopefully pretty fun at the end
but just out of these constituent parts.
And let's see what other ingredients,
for instance, we actually have.
Let me go ahead actually and
open up, for instance, Sheep.
This is an example.
And this, like all of today's,
are on the course's website
if you want to play.
I changed the cat to
a sheep in this case.
And if I hit Play, you'll see
what happens here is the sheep--
whoops, the sheep does not count at all.
Let me go ahead and grab a
different version of the sheep
since I broke it a moment ago.
Apologies.
Sheep is coming up now.
So here we have a sheep
with a very simple script.
That is also missing his program.
How embarrassing.
And here, we have the
online version of Scratch.
And of course since every browser
in the world now blocks flash,
we have to enable it.
Here we go.
And now finally we have the sheep
counting, so very anti-climactic.
This is literally just a counting sheep.
OK.
So I put a lot of time into this.
So I'm glad we got it working.
So at the top right, though, you can
consider the parts that went into this.
When green flag clicked, set a
counter which is just a variable.
It's more interesting
than calling it x or y.
I called it counter.
Set it equal to 0.
And then forever say the
counter for one second
like in the little cartoon
bubble, wait one second,
and then change the counter
by 1 by simply adding 1 to it.
And we get this effect of perpetual
counting up by using this variable.
We can do something else
as well, for instance.
Let me go ahead now and
have a bit of dynamic input
from a character like a cat again.
And this one is called Pet the Cat.
So in Pet the Cat here,
we have the following--
nothing, even though I hit play.
But wait a minute.
Let's look at the program.
How do I make this program do something?
AUDIENCE: Pet the cat.
SPEAKER 1: Oh, pet the cat, right?
So there's an if condition
there that's asking the question
if you're touching the mouse pointer.
So let's try it.
[MEOW]
Ah.
[MEOW]
It's kind of nice.
We can do--
[MEOW]
--kind of the opposite,
though with don't pet the cat.
You'll see that I have an if else
so that by default, the cat now--
[MEOW]
[MEOW]
--meows.
[MEOW]
But if you pet this cat--
[MEOW]
[MEOW]
[GROWL]
--so don't put this cat.
How does this work?
Well, you just need
another fork in the road.
If you're petting the
cat, make the lion sound.
Else just meow in a much
nicer, more tranquil way.
And we can go beyond this too.
Let me go ahead and now
open up threads, which
is an example of a program
doing multiple things at a time.
In this case here, we have
another type of cat and a bird.
And which seems to be
the smarter of the two?
The cat kind of knows a bit more
than the bird about what's going on--
a sort of AI if you will.
[GROWL]
OK, so same sound there.
But notice now we have
interaction between the two.
The cat, frankly, is kind of cheating.
It's not really AI.
It's just point at the bird.
And so here we have a puzzle piece
that says forever if touching the bird,
play the lion sound.
So that's how the program ends.
But at the bottom there, point
towards bird, move one step.
Point toward bird, move one step.
And so what does this do if I get a
little sort of impatient and I give
the cat some god-like powers here just--
[GROWL]
--to speed it up moving
10 steps at a time.
And that's all, again, animation is.
Instead of moving one
dot or pixel at a time,
move 10, the effect
of which to us humans
is that it actually moves a lot faster.
Of course, we can give
the bird an advantage.
So the bird is apparently
moving three steps at a time.
Lets up that to 30.
[GROWL]
That did not work out very well either.
But in this case, the two
sprites are interacting
because one is checking whether
or not it's touching the other.
Meanwhile, you can do this.
Let me introduce events,
which is another program too.
It's not very long, but it again has
two sprites, two little puppets here.
And if I hit Play here, nothing
happens until I hit the space bar.
When if you played this game growing
up, one says Marco and then the other
says Polo.
But one is saying Polo in response
to the other saying Marco.
Let me look at the sprite for the
orange puppet here and you'll see this.
Forever do the following.
If key Space pressed-- so if
the space bar is pressed--
then say Marco for two seconds
and then broadcast an event.
And an event for our purposes
today, it's like a whisper.
Whisper something that only other
sprites can hear, not humans.
Meanwhile if I look at the blue
puppet, it's not much going on there.
When you receive that event,
that whisper, say polo.
And so we have interaction
between these two sprites
much like Oscar was responding to
the trash being dragged and dropped
over his trash can.
Finally, we have this
one here-- hi, hi, hi--
which combines some of these
ideas as well that allows you--
[SEAL BARKING]
--to implement perhaps a familiar idea--
[SEAL BARKING]
--from like a video game on
your phone or the computer.
[SEAL BARKING]
This is very annoyingly
barks in perpetuity--
[SEAL BARKING]
--until you figure out how it works.
How do I make this stop?
[SEAL BARKING]
Yeah, so if you look at
the code at top right--
[SEAL BARKING]
--it mentions to the
space bar and it stopped.
Why?
What does hitting the space bar
actually seem to do logically?
It's in this left hand program.
If key Space pressed, what am I doing?
If-- yeah, if muted, which looks like a
variable because it's an orange block.
If muted is 0, set muted to 1.
Else set muted to 0.
So what does this mean.
Well, this is kind of the
programming equivalent of this.
If the light bulb is off, turn it on.
Else turn it off.
And so it's just a way of changing
state or changing the answer
from false to true or true to false.
And then I'm using that information to
decide on the right if muted is zero.
So zero means off or false.
So if it's not muted, if muted
equals 0 means not muted,
play the sound sea lion.
And that's how the program stops
until I do it by actually--
[SEAL BARKING]
--hitting that.
So we have all these puzzle pieces,
if you will, of these ingredients--
[SEAL BARKING]
--and all of these abilities
to weave these ideas together.
And you can do ultimately
some pretty amazing things.
And in fact, in the spirit
of bringing our two campuses
together both here and
in New Haven, we thought
we'd conclude with one
final game here for which
we need one additional volunteer to
play for us here Ivy's hardest game.
Let's have you come up because
your hand was up last time too.
What's your name?
LUKE: Luke.
SPEAKER 1: Luke, come on around.
So here comes Luke to
play Ivy's hardest game.
This was written by one of your own
CS50 predecessors, a former student.
And you'll see the instructions here
on the screen in just one moment.
Here we go, full screen.
I'm going to go ahead and
play for you and you'll
use the arrow keys in this game.
Here we go Luke.
[MUSIC PLAYING]
[MUSIC - MC HAMMER, "U CAN'T TOUCH
 THIS"]
MC HAMMER: [RAPPING]
You can't touch this.
You can't touch this.
SPEAKER 1: [INAUDIBLE]
MC HAMMER: [RAPPING]
You can't touch this.
SPEAKER 1: Very good.
Ah, you can.
That's OK.
MC HAMMER: [RAPPING] My,
my, my music hits so hard.
That's what I'm saying, oh my lord.
Thank you for blessing me.
SPEAKER 1: Very nice.
Notice the two variables at top.
Level three has death zero.
Meanwhile, there's of course,
multiple sprites on the screen.
Three Yale ones.
They, like the cat, are
bouncing off the edge.
Very n-- oh!
Keep going, keep going.
Death is now one.
Death is now two.
Infinite.
It's OK.
Very nice.
Level six.
Nice.
Clearly there's an if
near Harvard, move away.
Nice.
Come on, you can do it.
Second to last level.
Death is up to seven.
Nice.
Last level!
Just a couple more tries.
Nice.
One more time.
Let us end on that note.
This is CS50.
Cake with the staff is now served.
We'll see you next week.
