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.