>> [MUSIC PLAYING]
>> This is CS50-- Harvard
University's introduction
to the intellectual
enterprises of computer science
and the art of programming.
And my name is David Malan, and
I was just thinking this morning,
it's been amazingly 20 years today
since I last sat where you guys do now.
>> It was 1996.
I was a sophomore, and I was taking
CS50 for the very first time.
And I hadn't even gotten up the nerve
to take it myself freshman year,
partly because of the time.
Computer science to me
was kind of like, meh.
I was a bit of a geek growing
up, but I didn't really
have any intellectual
interest in what appeared
to just be a whole bunch of
people programming all the time.
>> And I was scared to be honest.
The course and computer science more
generally had and to some extent,
still has this reputation of a field to
beware, if only because so many of us
are unfamiliar with it and unsure of it.
And it really wasn't until I shopped
this class that sophomore fall--
and even then, I only enrolled
because the professor--
one of my first mentors, Brian
Kernighan now at Princeton--
allowed me to take the class pass fail.
And indeed, that's why
today we allow and encourage
students to take this class sat/unsat.
>> And only then, by the
end of the semester
did I realize like, wow, this
wasn't such an unfamiliar field.
Indeed, this was a
very empowering field,
and more excitingly,
especially later on,
as I took courses in
Dramatic Arts 101 and Latin A
and then eventually
grad school archeology,
did I really start to see the
intersections of this field, computer
science, with the humanities,
natural sciences, the arts, medicine,
and the like.
And so that's what's just so
neat about computer science
ultimately, as we hope you'll
see-- is its applicability
to these other fields, and how you can
take some of today's and the semester's
ideas and practical skills
back to your own domain,
and actually explore this intersection
of the liberal arts and the sciences.
>> So 73% of you, if last
year is any indication,
have never taken a CS course before.
So if, like me, you are
feeling a little bit
scared, or frankly you're not
really sure why you're even here.
Perhaps you just followed some
friends over to Sanders right now.
That's totally fine.
The goal here is to hook
you and to reassure you
that if you do look to
the left and to the right,
you're going to see classmates with
as little or as much experience
that you yourself might have.
And indeed, we'll share
some statistics later today
as to what the demographics of
the class typically look like.
>> And as added reassurance-- and this we
do mean since I took over the course
some years ago-- in
the course's syllabus
is this-- that what ultimately
matters in this course
is not so much where you end
up relative to your classmates,
but where you in week 11, the end of the
semester, end up relative to yourself
in week 0, which is
where we are here today.
And this is what I realized
all those years ago.
And I know a lot of
classes say this, but it's
especially true in computer science.
At the end of the day, this field
is unfamiliar as it was to me
and might be to you, is really
just about problem solving.
And as such, it does have this
applicability to get other fields.
And in fact, if we tried
to distill what this means,
this is problem solving
in its essence, I daresay.
There's input-- so whatever it
is that you're trying to solve.
There's output, which is hopefully
the solution to that problem.
And then, as we would
say in computer science,
there's this black box in the
middle that you don't necessarily
have to care about how it works.
You yourself eventually might
implement what's inside that box.
But for today's purposes and more
generally in life, all you care about
is that these problems get solved.
>> And what this course is
ultimately about is exploring
the intersection of
these inputs and outputs,
and these so-called
algorithms, as we'll soon see,
that implement what is
underneath there, the hood.
But these inputs and these outputs--
what does that actually mean?
Well, at the end of the day, we need
some way of representing information.
This is especially true in a computer,
which as fancy and complex as it
might seem, is a pretty dumb device.
It takes electricity-- whether from
a cable or a battery as input--
and then it produces some
preprogramed responses on the screen.
>> But how do we get from
start to finish there?
Well, what's a problem to be solved?
Well, maybe we might, at
the start of any semester,
try to take attendance
in a room like this.
So I might do like one, two, three.
Or maybe, if I did it
to sort of keep track
of myself-- to keep track of things--
I could quickly run out of fingers.
So I might just make hash marks-- one
person, two, three, four, five, six,
seven, eight.
And all of us have probably
done this, whether on your hands
or on a piece of paper.
And this is actually just
something called unary notation--
where if you only have one letter
in your alphabet, one or hash
mark in this case, for every
input you want to count,
you need to put down one of these
letters-- one of these marks.
>> All right.
That's all fine and good and
not all that complicated.
But computers aren't all
that much more complicated.
Indeed, most of you probably
know even if you've not really
considered what this means, that
computers only understand zeros
and ones-- the so-called binary system.
We humans, by contrast, are so
much more sophisticated insofar
as we understand zeros through nines.
>> But even if binary is, at first
glance, not all that familiar,
it turns out it's just like the systems
and the ideas that we already know.
So for instance, consider this.
This is just a sequence of symbols.
And all of you, when
glancing at it, probably
think 123-- nothing
really interesting there.
But why is it this number, 123?
These are just glyphs on
the screen-- just patterns
that someone might have drawn or typed.
But if you're like me, you
probably remember from grade school
that there are sort of
columns or places here.
There's the one's place and the
ten's place and the hundred's place.
And the reason that this is 123 and
not just a pattern of three symbols
is because, of course, if we
have a one in the hundreds place,
you do the math of 100 times one,
and then two in the ten's place.
So that's 10 times 2, and then three in
the one's place and that's 1 times 3.
And when you add all of those up, of
course, you get 100 plus 20 plus 3.
>> So we started with just a pattern
of symbols-- an alphabet--
but then we mapped meaning onto
it by way of these columns.
Well, it turns out that
computers are really not
all that different from you and me.
But instead of using powers of 10,
so to speak-- 1, 10, 100, 1,000,
10,000 place and so
forth-- they actually
just use powers of 2--
so one, 2, 4, and then
if we put more digits, 8, 16,
32, 64, 128, and so forth.
And so this is how a computer
would represent the number 0,
just like we humans.
>> 0, 0, 0-- and you can probably guess
what pattern of zeros and ones,
if a computer can only
speak 0 or 1-- what
pattern is going to represent
the number we humans know as 1?
Yeah-- 0, 0, 1.
All right.
So 0, 0, 1 is how we represent
1, so you might be inclined then
to represent the number 2, if you have
the four's place and the two's place
as the one place, you might say, well,
if we had a 1 in the one's place,
and now we want to
count up to 2, you might
do this and leave this to be a zero.
But of course this is not how
the decimal system works either.
If you put a digit in
both of those columns,
you've got to do the arithmetic.
So what number did I
accidentally just represent?
>> So it's 3, because 2 times 1 plus 1
times 1, of course, gives us three.
So this would be two.
The bit sort of flips, so to speak, as 0
becomes a one, much like a 9 roles over
and becomes a 0 when you carry the 1.
This then would be three of course.
Four-- another interesting thing
happens, where the ones roll over
and you carry the 1, so to speak.
So this, of course, is 4.
>> But if you fast forward now,
what's the biggest number going
to be that a computer can represent?
 
So it's just seven in this case, right?
Because you have a one in the four,
a one in the two, a one in the one.
So that's 4 plus 2 plus 1.
So that gives you seven.
And indeed, it would
seem at first glance
that computers can count
no higher than this.
>> But this of course is not true.
What do we humans do when we want
to count higher than like 999?
 
Just carry the one and just
add a fourth digit to the left.
And so indeed we could.
We could have an eight's
place and a 16th's place,
and a 32's place, 64, 128-- and you
can just keep going on up to infinity.
So these zeros and ones--
the so-called binary system--
are what a computer scientist would
generally call a bit, or binary digit.
>> But now, how do we get from the
concept or the graphics of these things
to an actual computer?
We seem to be skipping a step here.
Well, the only input at the end
of the day, to my laptop here
is this flow of electricity.
Even if it's been a long
time since you thought about
or never thought about
how electricity works,
there's electrons flowing in or
out, and that's my kind of input.
>> So if that's all that we're
getting as input here,
what can we do with that information?
Well, we might think of a zero as
just an absence of electricity.
Nothing is flowinw, nothing is
moving, nothing is happening.
That's just the default state-- zero.
But if there is electricity flowing, why
don't we just arbitrarily, but globally
consistently, call that a one.
>> So simply by having no power,
we have a zero, yes power,
we have a one-- no power, yes power.
And in that way, using something
more physical or electronic
we start to implement this notion of
something either being one or a zero.
Indeed, we could just do it over here.
So here, I have not three but
eight light bulbs, each of which
has its own switch.
>> And so if I wanted to represent
the number seven here,
I might turn on these three light bulbs.
And indeed, inside of
my computer is millions,
billions of things that are just
smaller than that, called transistors,
switches, that you just turn on and off.
So these are big-- relatively
big-- switches inside my laptop--
are many, many, many,
many more switches.
But all they do is exactly that--
turn something on, turn something off.
And as such, a computer can represent,
with those millions or billions
of transistors, lots and
lots of zeros and ones.
And there's other hardware still that
lets you store information long-term,
so that when you pull the
plug, you don't lose it.
But that's a story for another day.
>> So what can we do with these bits?
Might we just to take
the pressure off of me--
might someone want to come
up here and offer up a demo?
I saw this hand first.
What's your name?
MADAY: Maday.
DAVID MALAN: Maday, come on up.
Nice to meet you.
MADAY: Nice to meet you.
>> DAVID MALAN: Come this way.
I won't have to lip you up.
All right.
So here, we have, notice-- one, two--
we'll edit that out-- one, two, four,
eight, 16, 32, 64, 128.
This is deliberate.
There's eight bits here--
binary digits-- zeros and ones.
And a bit is a useful unit of measure--
not as useful a unit of measure
onto itself.
Usually you want at least
eight of these things, a.k.a.
a byte.
So we have a byte of bits here.
>> So if we wanted to challenge you with,
for instance, spelling out, in binary,
this value here-- 42.
Want to take a stab at that?
>> MADAY: [INAUDIBLE].
DAVID MALAN: Yeah, just push the
little white switches in front.
And you want to spell
out 42, and up for grabs
is this CS50 stress
ball if you get this.
All right.
So you have 32.
We're going to need 42.
So that's an eight, so that's 40.
And excellent-- very nicely done.
Thank you.
>> [APPLAUSE]
All right.
So we have one more stress ball.
Let's do this once more if we may.
One other volunteer?
Free stress ball, free stress ball.
OK.
Over here in the middle,
do you want to come down?
All right.
I know.
There we go.
>> So the numbers here-- come on down.
What is your name?
>> DAVEY: Davey.
>> DAVID MALAN: Davey.
OK.
Come on up, Davey.
Nice to meet you.
And what we're going to have you
spell-- if you could linger there
for just one moment-- is the number 50.
But, but, but but, but, these are
grade school magnets for a reason.
 
Just got a little harder, all right?
There's still eight.
 
All right.
So what do we have on there?
We have 32.
Nice.
32 plus 16 gives us 48-- so close.
And wonderful.
Congratulations to Davey as well.
>> [APPLAUSE]
>> All right.
So we can do this all day long, and
it doesn't get all that much more
interesting and more challenging.
But that's really the point--
is how relatively simple
it is, at the end of the day, what a
computer does to store information,
to store inputs and ultimately
store or represent those outputs.
But numbers alone aren't
all that interesting.
>> So humans, some years ago,
decided, you know what?
It would be nice if
computers were not just
calculators for arithmetic
operations, but actually could
do things like word processing, or
email, or more modern incarnations
of these kinds of technologies.
And so the world decided
arbitrarily, but universally,
that if you want to store the capital
letter A in a computer, you know what?
Let's just all agree to store
some pattern of zeros and ones--
bits-- that ultimately
represents the decimal number 65.
We'll just all agree on that.
>> 66 would represent B,
67 would represent C,
and there's bunches of other patterns of
zeros and ones, or underlying numbers,
that would represent
other letters still.
So if you kind of mentally
absorb this for a moment,
I deliberately put up A through
I, where H a 72 and I is 73.
If a computer then, in the context of
a word processing program or an e-mail,
revealed underneath the hood to have
these patterns of bits-- pattern
of bits representing
72, then 73, then 33--
what might this spell in that program?
>> So hi, and then something.
We don't necessarily know, but indeed
33-- not on the chart earlier--
was simply an exclamation point.
So 72 was H, 73 is I, 33 happens
to be an exclamation point still.
But that's all fine and good,
and in fact nowadays, rather than
just use seven or eight
bits, thanks to something
called Unicode as opposed
to Ascii back in the day,
we actually can represent even more
interesting characters than just
these original English biased letters.
But we can also represent even
neater things like colors.
>> If you've ever heard the acronym
RGB, red, green, blue, that
just means that a computer
typically uses three sets of bits--
some number of bits that represent
a number for how much red you want,
another set of bits for
how much green you want,
and another set number for
how much blue you want.
So a big number means lots of
red, small number means no red.
And so these are kind
of middle values here.
>> So give me some red, give me some
green, and give me a little bit of blue.
And if you mix those three shades
of color together, in this case,
you get this murky shade
of yellow or brown.
But that pattern of eight plus
eight plus eight-- so 24 bits--
left to right, is how a computer
would represent that particular color.
Now this is just a dot on a screen.
If you look really close at your TV your
computer, you'll see dots or pixels.
And if you have a whole grid of
pixels, horizontally and vertically,
you have images.
And then if you take
an image and then wash
show yourself another image, another
image, another image, another image,
really fast, you of course have movies.
>> And so notice where we started.
We started with these zeros and ones.
We worked from there to decimal
numbers, how we represent them.
Now we have letters of the alphabet.
But in other contexts wait, we can use
a few more bits and represent colors.
As soon as you have the
ability to represent colors,
you have the ability to represent
photographs and animated gifs
and other such characters on the screen.
And when you have a whole bunch of
images flying by the human at once,
it looks like motion pictures,
and so you get videos as well.
>> So using these very
simple primitives do we
have the way of representing
ultimately all of these forms of media.
And we've abstracted again
and again and again, until we
get from the lowest level
to this highest level.
So that gives us this
general idea of abstraction.
But we started here.
>> Here now, we might
represent in a computer
our inputs with zeros and ones,
our outputs in zeros and ones,
but what goes inside the box?
That's where computer
science gets interesting.
That's where you actually bring your
own minds to bear to solve problems.
We can now stipulate, for the
rest of the semester, yes.
I know how binary works.
I remember how Ascii or Unicode--
the mapping to letters-- works.
And it certainly stands
to reason that we
could represent red and green and
blue, and represent multimedia as well.
But this is the interesting stuff.
This is what makes someone
capable of solving problems.
>> And one such problem
we like to do, indeed,
is taking attendance, or
doing this algorithmically.
And again, I might do this.
I might do one, two, three, four
five, six, seven, eight nine.
And I could write it
down to keep track of it.
But that's just how I would
represent the information.
Or I could do this faster-- two, four,
six, eight, ten, 12, 14, 16, 18, 20,
22-- it feels like twice
as fast but it's still
going to take a whole lot of time.
>> But it turns out, if we leverage yet
another resource-- and indeed computers
these days have multiple CPUs or brains.
It turns out computers can
do lots of things at once,
and indeed we, in this room,
might represent exactly this.
>> So it's a little socially
awkward, but if you would humor me
for just a three-step process, let
me ask everyone in place there just
to stand up for a moment.
Stand up.
So think to yourself, number
one-- so everyone in this room,
except the people who didn't
oblige, are thinking number one.
So that is your number right now.
That is the first step, or as a
computer scientist or a programmer
would typically do, we're going
to start counting at zero.
If the smallest number we can
represent with those light bulbs
is zero, by just leaving them
all off, I might as well just
start counting from
zero is instead of one.
And so that's what
computer scientists do.
So step zero, stand up and
think of the number one.
The next step is this-- pair
off with someone standing
and add your numbers together.
 
Wonderful.
>> So at this moment in time,
literally everyone participating
is thinking of the number 2, except
for one odd person if we have
an odd number of people in the room.
And now the third step here is going to
be this-- one of you should sit down.
One of you should sit down,
and if you're still standing,
go back to step one.
 
All right.
 
All right.
So more and more people
should be sitting down.
Notice that this has induced
a loop-- some kind of cycle.
Some of you should be awkwardly stuck,
going back and forth between step one
and two, one and two, one and two.
 
That's OK.
Our first bug.
We'll deal with that.
All right.
Let me try to spur things along.
>> In theory, only one person is standing
as everyone continues to pair off.
But let me speed things up
with the people still standing.
What number are you thinking of?
46.
OK.
Go ahead and sit down.
You guys are still standing.
Who's still standing?
What number are you thinking of?
OK.
>> So we'll come back to you.
In the back?
What is that?
22.
OK someone else up top-- yeah?
34.
OK.
Over here on my right-- up here?
132, very nice.
22?
>> OK.
And who's still standing?
Over here?
46, very nice.
72.
I can't stall much longer.
Yeah?
30, nice.
Over here?
23?
23.
>> And I think that's everyone
except you guys, no pressure.
Oh, wait.
28?
 
Just eight.
OK.
Just eight.
Down here?
30.
23.
24.
 
18.
This is the worst implementation
of this algorithm ever.
OK.
So anyone else?
Anyone else?
OK.
One more.
16?
OK.
16.
All right.
So if I haven't missed anyone in
the glare here, when I hit Enter,
we will see, algorithmically, the
total number of people in Sanders.
Because again, it's as though everyone
as you sat down, passed your number off
to someone else, to someone else,
to someone else, so that in theory,
in the end, only one awkward
person should be left standing.
But that's fine.
We sped things up manually.
It's especially hard to see
in this particular space.
>> And the total number of people
we think there are here is 546.
The total number I was handed
by the teaching fellows,
who did it the old
school slow way, was 820.
>> [LAUGHING]
>> [APPLAUSE]
>> That's OK.
So surely then, there are these bugs.
And that's fine.
And so think back on this
the first time something
you write doesn't necessarily work.
This has happened to me here as well.
But let's now consider how we might
apply this same idea to something
you might have seen before, which
is this old school technology here--
a really big phone book.
And suppose that this phone book
has 1,000 pages and 1,000 names
and numbers alphabetically inside of it.
>> Well, we could kind of apply a similar
idea to this very physical problem,
just using me.
I just kind of cheated
by leveraging all of you
with lots and lots of different CPUs
or brains executing some algorithm.
But if it's just little
old me, I can still
leverage that same essence of an idea
of dividing and conquering that problem
again and again, whereby half of you,
half of you, half of you, half of you,
theoretically kept sitting down,
until we were left, theoretically,
with just one person.
>> So in this old school
technology-- we don't
need this map-- this
old school technology,
we might start looking for someone
like Mike Smith, one page at a time.
And I see that no, Mike is not here.
I'm still in the A section.
Eventually, I find
myself in the B section.
And this is an algorithm--
step-by-step instruction.
Start at the beginning and one page
at a time, look for Mike Smith.
Is this correct-- this
algorithm or approach?
>> Yeah, it's correct.
If Mike's here, eventually
I'll get to him.
But it's not efficient.
It's obviously very slow.
So I can leverage the
same twosies approach.
I can do sort of two,
four, six, eight, 10, 12.
It's twice as fast.
I'm going to get to Mike
faster if he's there.
Is it correct?
Yes, but I heard a little-- no.
Now I heard a no.
Yeah.
There's a bug potentially.
Maybe Mike just accidentally gets
sandwiched between two pages,
because I'm flying through
this two at a time.
So at least we need some
kind of conditional fix.
I need to say, hey,
if I hit someone whose
name starts with a T instead of an S,
I better double back at least one page.
So buggy at first, but fixable.
But none of us are going to look for
Mike Smith through a 1,000 page phone
book one page at a time.
What's a normal person going to do?
You're going to go to the S's,
if you knew where the S's.
You might go roughly to the middle
or slightly skewed towards the end.
And I look down here and
I'm in the M section.
But what do you know
about this problem now,
that we didn't necessarily know before
with all of us just counting ourselves
equivalently?
Well, Mike is clearly going
to be in this half of the book
if he's here at all because it's sorted.
>> And so you can very dramatically--
>> [GASPING]
>> I know.
>> [APPLAUSE]
>> It's actually really easy if
you do it down the spine there.
But you can then throw
half of the problem away.
Now, I'm left with the same problem--
find Mike Smith in a phone book--
but now the phone book starts at M
and goes to Z, but it's half as big.
>> But this is what's impressive.
Just like in theory, you guys, when
you all sat down only half at a time,
the problem got half as big,
half as big, again and again.
So has this problem become the
same problem but half as big.
Now it's a 250 page problem.
As soon as I realize, oh, I'm
in the T section accidentally.
I've gone too far.
I can throw that half
of the phone book away.
Now, I'm down to a
quarter of the problem.
>> And you can repeat, repeat,
repeat until, in theory, you're
left with just one page.
And if Mike is on that page,
I can now solve this problem.
But how quickly did I solve it?
In the first case, it took me like
maybe 1,000 steps to find Mike Smith.
It might have taken me--
I picked up the phone book
and I started looking
one page at a time,
and Mike might be 1,000 pages later.
>> Second approach maybe
takes me 500 steps,
because I'm flying
through two at a time.
And the third approach though,
it's especially powerful.
But let's consider what we actually
did with this third approach.
I'll have what I'll call just these
statements here, one at a time.
Pick up a phone book.
Open to the middle of the phone book.
Look at names.
And then things get a little
more intellectually interesting,
if still simple.
If Smith is among the
names on that current page,
then do something conditionally.
It's like a fork in the road.
Call Mike.
If Mike is among the names
on that page, called Mike.
But only do line four if line
tree, if you will, is true.
The answer to that question is yes.
>> Else if Smith is earlier in the book--
in other words, if I'm in the M section
and I'm looking for someone to
the left, then what I should do
is something very similar.
Then I should open to the middle
of the left half of the book.
So go left, and then
go back to step two.
Look at the names there.
>> So in other words, do the same thing,
but on a problem that's been halved.
You know what else?
If Smith is later in the book
based on the page I'm looking at,
open to the middle of the
right half of the book
and then go back again
to step two, else--
there's a fourth possibility here.
Mike's either here or to the left
or to the right or not there.
And here we better consider this.
And in fact, if you've ever had
your computer just crash on you,
that is sometimes, but not always, the
result of just a human programmer not
realizing, oh shoot, there's
actually this fourth scenario.
And if you don't write code
to handle that scenario,
sometimes you don't know
what the computer might do.
And indeed a program might crash.
>> But in this case, I thought
about it, and I said, else quit,
because that's the fourth
logical possible scenario.
Now, let's just add
some vocabulary so we
can start to toss around terms that
are otherwise pretty intuitive.
All of the things I've just
highlighted in yellow here,
I'm just going to the
functions or procedures.
They're just kind of actions.
So pick up, open to, look
at, call, open, open,
quit-- these are just actions, or we'll
call them more formally, functions.
>> Meanwhile, now in yellow,
I've highlighted things
that-- let's just start calling
them conditions or branches.
These are decision points where
you might go this way, this way,
or some other direction still.
So those will be conditions.
And now this one's a little fancier.
Let's call these questions
Boolean expressions,
after someone with a last name Bool.
>> And a Boolean expression
is just something
that's either true or false, yes or no.
So it's the question whose answer you
care about, so as to in a condition
make a decision-- get back an answer,
and then go left or right, or something
else altogether.
>> And then lastly, these
lines here-- go back
to step two, go back
to step two-- we could
implement this idea in different ways.
And then those of you with
programming experience might have done
or can imagine doing this differently.
But for today's purposes, it's
just the idea that matters.
This is inducing what
we'll generally call
a loop-- some kind of cycle, because
it's making me do something again.
>> So now, let's just consider
how good this algorithm is.
It's correct.
If Mike's in the book, it's one of
those four scenarios-- again and again
and again, we'll find him.
But how good is it?
Well, we don't have
to be too formal here.
But let's just plot
something, x and y, to get
a sense of the shape of this problem.
>> On the x-axis here is
the size of my problem.
And they a y-axis here
will be the time to solve.
So maybe this is number of pages.
Maybe this is seconds or
page turns-- whatever.
However you want to count is
what this picture will represent.
And that first algorithm, I'm going
to describe as just a straight line.
If there's n pages in
the phone book, then it
might take me as many
as n steps to find Mike.
If Verizon or the phone company
adds one more page next year,
it might take me one more step--
one more unit of time to find Mike.
So there's just this one to one ratio.
It's a straight line slope.
>> Meanwhile, that second
algorithm-- if I'm
going two at a time-- two,
four, six, eight, or double--
going through the pages twice
at a time, two at a time,
it's still straight line.
There's now a one to two
ratio, but just a little lower.
So if there's this many pages
on the chart here in yellow,
that might take me this
many steps or seconds,
otherwise it's going to take me
twice as many on the red line.
>> But the green line is the real takeaway.
This is what we generally
call a logorithm-- log
of n, where n is the number of pages.
But it's the shape that matters
today, because we don't have
to even think about plotting points.
>> Think about an extreme scenario.
Suppose Verizon tomorrow doubles the
number of pages in that phone book,
from 1,000 to 2,000.
In the first algorithm, I
might waste an extra 1,000
steps looking for Mike, just because
Verizon doubled the size of the book.
The second algorithm-- it might
take me an extra 500 steps.
1,000 more pages, I go two at a
time-- 500 more steps to find Mike.
>> But that third algorithm
is kind of magical.
Verizon doubles the number
of pages from 1,000 to 2,000,
but how many more steps does
it take me to look for Mike?
It's just one, because I can just
tear the phone book one more time
from a 2,000 page problem to a
1,000 page problem, and voila.
I've taken a massive bite out of it.
>> And if you go really extreme,
suppose that the phone book
company had something crazy like
a 4 billion page phone book.
Well how many steps might it take
to find Mike Smith in a 4 billion
page phone book?
It's a big number, but just 4 billion to
2 billion to 1 billion to 500 million,
250 million-- still
sounds like big numbers,
but I'm very quickly
getting to smaller values.
>> And in fact, if I do the math
right, I can only divide 4 billion
by roughly 32 times before
I get down to just one.
So if that phone book were 4
billion pages long, no big deal.
Within a few seconds, maybe 32
seconds, I could divide it in half
and eventually find Mike or
conclude that he's not there.
And that's the essence of an
algorithm-- a good algorithm.
And that's one of the
goals of a class like this,
is trying to figure out how do I
solve the problem not just correctly,
like I always knew how to do it one
page at a time-- but correctly and well.
How do I design good
solutions to problems?
So let's take a moment here
and give you a sense now
of CS50 the course itself-- introduce
a few course's staff members.
Just before 2:00, we'll
take a short break
so that those of you
who are shopping can
duck out and take a
look at some other class
and watch the rest of this online.
But for now, let me introduce
CS50, the class itself,
and particularly what is new.
>> So the past spring, we
spent quite a bit of time--
the course's staff and I-- thinking
about what it is we want CS50 to be,
and going back to first
principles, so to speak,
to consider what it is we want
this course to look like and be
like for its students.
And so you'll see in problem
set zero as well, an invitation
to take a look at that
URL which summarizes
some of the motivations behind the
following characteristics of fall 2016.
>> So as you may have gleaned
from the TL:DR handout,
the syllabus today as well as from
the course catalog, this year in CS50,
you're only expected to attend
today-- so job well done--
and the last lecture on November 21st.
And you're welcome but not expected to
attend those lectures in the middle,
because what we're doing
this year, is shooting
in real-time the course's material.
So everything will stay
current and incorporated
as best we can-- current events
and conversations that folks might
be having in industry in the
world, but making that material
available, as a result, even earlier--
complete with full text transcripts
and searchability and
links to other resources.
>> And indeed, we've been
claiming for some time
and we do now believe this,
that we can create, digitally,
a more immersive, a more compelling
educational experience, as opposed
to gathering here some 23 times
in person, hearing someone like me
simply talk about computer science,
as opposed to engaging more actively.
So you'll see in the course's syllabus
a sketch of the semester here,
along with when lectures will
be filmed, to which you're
welcome but not expected,
and when they will
be released on the course's website.
>> And what we'll do here on
Wednesdays starting next week,
is a lot more intimately, with only
those folks who want to participate,
is a so-called walk through,
where I and the course's heads
will actually make things
a little more intimate
down here in the orchestra
section, still have some technology
and walk through the
current week's problem set,
and offer you particularly-- if among
those less comfortable-- all the more
guidance that you might want or
need for the week's challenge.
And similarly, for those who can't
attend those in person, no big deal.
There will be similarly led by
one of the course's senior staff,
Zamalya, the same opportunity embedded
in the problem sets themselves.
>> Problem sets this year
will be released on Fridays
and no longer do seven days later,
but 10 days later-- deliberately
overlapping with each problem
set, so as to better accommodate,
we hope, ebb and flow
in student schedules,
especially when midterms or athletics
or academics or extracurriculars
tend to come and go
especially mid-semester.
That should give you a little more
discretion as to whether you front
load your week with CS50 or back load
it on the following weekend instead.
So look to the course's syllabus
here for the schedule thereof.
And you'll notice too among
the changes this year,
for those more familiar with
programming in the past,
we'll start the semester as
we will today in Scratch,
focus especially on the language
called C, and then transition not
to PHP, but to a language called
Python towards the end of the semester
in the context of web programming,
along with SQL and JavaScript,
HTML, CSS, and yet more.
>> And in answer to an FAQ,
it's indeed the case
that CS is not as scary as I once
thought it was, but it is as much work
as I had heard it might be.
But this is the say that here are some
statistics from fall 2015 student body,
whereby the horizontal blue lines
represent the average number of hours
reported.
And you'll see an average of
six to 10 to 12-- maybe 16
or so and so forth, but with
high variance to be clear.
And so realize that there is not only
students more comfortable and less
comfortable in the course,
but a corresponding support
structure to get those students
through the semester successfully.
>> Indeed, in answer to an FAQ, should
you take CS50 as a first year?
Absolutely.
And in fact, I do regret
not having found my way
or found a new field
that first year as well.
And should you take CS50 with
other courses, certainly as well--
and the general advice we might
give students, that CS50's probably
not the kind of class or intro class
that you should take with three
other or four other p-set classes.
But if you're taking two other p-set
classes, something else, and CS50,
absolutely manageable.
I've had many students in the
past done so quite successfully.
>> And to get you toward that
finish line successfully,
does the course have sections--
different tracks for students
less comfortable, more comfortable,
and somewhere in between,
whereby in the course's
first problem set,
you'll be asked to describe yourself.
And if you are among those less
comfortable, it's the kind of thing
that you just rather know.
And indeed, that's been the
growing demographic in CS50
for quite a few years.
>> As of last fall for
instance, 58% of the class
described themselves as
among those less comfortable,
with 9% among those more
comfortable, and then
the other students there in
red describing themselves
as somewhere in between.
And you'll see here the topics overall
and schedule of sections, all of which
are offered in person, in
real time, with the course's
amazing staff of teaching fellows
and course assistants, some of whom
you'll meet in just a moment.
>> Sections themselves, as you'll see, will
be Mondays and Tuesdays and Wednesdays,
so as to allow you to dive
in after engaging, if you so
choose, in the course's
lecture earlier that week.
And then office hours, which
certainly, with each passing year,
have been no less of a
challenge for the course.
And this year, we're planning not
only to hold office hours-- one
on one opportunities for help for
students on Wednesdays Thursdays
and Sundays, the last of those
being in the afternoon by design
to reduce some of the stress that
invariably arises with late night
p-settting with a deadline looming--
but office hours will also be offered
on Mondays and Tuesdays and
Wednesdays, and Fridays and Saturdays,
thanks to our friends at HSA.
>> CS50 now has its own space
for students and CS50 staff,
atop 67 Mount Auburn Street,
right there in Harvard Square.
The vision for which is that CS50's
TFs and CAs throughout the week,
pretty much throughout most
days, will be there for support.
So if you've got some
question on a p-set
or you're feeling a little
blocked or a little confused,
and heck, you've got an hour or
half an hour between classes,
especially in the square-- can you
pop in and have that question answered
of have that confusion clarified--
very much in the spirit,
you're familiar, of the math
department's own math questions center,
but pretty much around the clock per
[? Gcal ?] that we will post online.
>> Tutoring is also available for those
students, freely from the course's
own staff if you would like
more intimate one on one,
or two or three classmates only, working
with one of the course's staff members.
And indeed, these here are just
some of the course's staff members,
a few of whom you'll
meet in just a moment.
In fact, CS50's own
head teaching fellow,
and head course
assistant, and preceptor,
could come on up, allow
them to say hello.
>> [APPLAUSE]
SPEAKER 1: [INAUDIBLE].
 
>> [APPLAUSE]
SPEAKER 2: [INAUDIBLE].
 
>> [APPLAUSE]
SPEAKER 3: [INAUDIBLE].
 
>> [APPLAUSE]
>> DAVID MALAN: And allow us to
bring on board two of CS50's most
senior staff, Rob and Zamayla as well.
>> [APPLAUSE]
>> Indeed, both Rob and
Zamayla have been with us
for so long, that I was able
to go into CS50's archives
and find this very SD
footage of them participating
on stage themselves some years ago.
ROB: [INAUDIBLE].
 
>> [APPLAUSE]
ZAMAYLA: [INAUDIBLE]
 
>> [APPLAUSE]
DAVID MALAN: Thank you.
 
So in addition to these
team members here,
CS50 has a team of nearly 100
staff members, all of whom
will be available for sections
and office hours and so much more.
And as Rob says too, this is
the most significant overhaul
of CS50 in the 10 years that
I've been in [INAUDIBLE].
[INAUDIBLE] focused especially
in providing a support structure,
trimming away a lot of
the bulk that's been
accumulated in 10 years
of iterative developments
on the course's problem sets.
>> So this year, not only in class but
also in the form of the course's problem
sets, should you find things to
be more streamlined, trimmer, much
more manageable than
in years past, as we
shed some of the baggage that's
developed by nature of evolving year
after year and iterating.
So the new and improved begins today.
>> You'll meet some more of the
course's staff out in the [INAUDIBLE]
at 2:30, where we serve,
as a tradition, cake.
There's a bit more cake
than that, but you'll
meet Erin and Tobias and others still.
And let me give you
a tour before we hear
from some of the other staff members
in the class, of what awaits as well.
In fact, we always start CS50's
semester this coming Saturday,
with what's called CS50 Puzzle Day.
>> It has nothing to do with
computer science per se,
but with about problem
solving more generally.
And if you so choose to partake,
per some of the invitations,
you might have seen door
dropped or on the stage here,
it's an opportunity in teams
of two or three or four,
to participate for puzzles and pizza
and prizes and more-- this Saturday,
stay tuned for more.
>> You'll find too that every
Friday, at Fire and Ice,
does CS50 bring a
whole bunch of students
to lunch, to make a large
class feel more intimate,
and generally bring together
alumni and friends from industry
to talk about what they've
been up to since graduating.
Similarly, this year, will we
inaugurate the first ever CS50 50
coding contest-- a mid-semester
opportunity to allow everyone
on an opt in basis, to have a
challenge of wits against classmates,
again in teams of two or three or
four, using only that programming
savvy that you then have under
your belt after just six or seven
weeks of the class, and participating
in this kind of competition
online-- if you'd like to hone your own
skills all the more in that challenge.
At the end of the semester is
the so-called CS50 Hackathon--
an opportunity that begins at 7:00
PM ends at 7:00 AM, and along the way
are 12 evening hours in which to dive
into the course's final project--
an opportunity to design and
implement most anything of interest
to you with your teaching
fellow's guidance.
Around 9:00AM do we typically
serve pizza, 1:00 AM,
Philippe's, and the few of us
who are still awake at 5:00 AM,
are shuttle bussed down the
road to IHOP for breakfast.
>> And then a few days later
is the so-called CS50 fare--
an end of semester exhibition in
celebration of just how far so many
of CS50 students have come from
week zero all the way to week ,
and keeping in mind that 73% of those
classmates and yours this year have
never taken a CS class before.
In fact, to reemphasize as much, here
is a few more faces from CS50's staff.
SPEAKER 4: [INAUDIBLE].
 
SPEAKER 5: [INAUDIBLE].
 
SPEAKER 6: [INAUDIBLE].
 
SPEAKER 7: [INAUDIBLE].
 
SPEAKER 8: [INAUDIBLE]
 
SPEAKER 9: [INAUDIBLE].
 
>> SPEAKER 4: [INAUDIBLE].
>> SPEAKER 10: [INAUDIBLE].
 
SPEAKER 11: [INAUDIBLE].
SPEAKER 12: [INAUDIBLE].
 
SPEAKER 13: [INAUDIBLE]
 
>> SPEAKER 14: [INAUDIBLE].
>> SPEAKER 13: [INAUDIBLE].
SPEAKER 15: [INAUDIBLE]
 
SPEAKER 16: [INAUDIBLE].
 
>> SPEAKER 11: [INAUDIBLE]
 
SPEAKER 5: [INAUDIBLE].
 
DAVID MALAN: Some of the team
are themselves shopping classes.
But if those members
of CS50 staff are here,
could come on up for just a moment.
CS50's TFs and CAs and [? staff ?]
members here-- these are just a few
of the faces-- one of whom you just
saw, and a few other-- and a few others
still.
Why don't we go ahead and allow
you guys a five minute break.
If you need to duck out to
shop classes, that's fine.
And in five minutes, we'll resume,
taking a look at Scratch-- the first
of our programming language, meet
the course's staff here some more,
and focus ultimately
on problem set zero.
So we'll be back in five minutes.
>> All right.
So we are back.
And in our remaining
time today, the goal
is to level the playing field
in terms of some terminology,
in terms of some ideas.
Because indeed, as per
some of the charts earlier,
there is going to be a range of
levels of experience in the class,
some of whose students have
taken some programming before,
some of whom haven't.
And so with this first problem
set and with this first language
do we have an opportunity to start
to take for granted after today
some common vocabulary and idea.
>> And we'll do this by way of
the course's first languages--
in addition to C and Python and
JavaScript and SQL and HTML and CSS,
we'll be focusing initially
and just for problem set zero
on this graphical language, called
Scratch, developed by MIT'S Media Lab
down the road, to help
students and kids especially
express themselves algorithmically--
in a way more consistent with what
we might call computational thinking.
>> And it's a useful language because
very quickly next week in week one,
do we transition to a more
traditional and arcane language called
C, which is purely textual.
You only use your keyboard in
order to write instructions
like these on the screen.
But even if you've never seen
a programming language before,
in just glancing at
this, all be it cryptic,
you can probably guess that
probably prints Hello World.
But there's a lot of
syntactic overhead there.
There is the weird hash
symbol or hash tag up top.
There's the angle brackets, some
parentheses, curly braces, semi-colon--
there's just so much visual
syntax that gets in the way.
We start the course with
Scratch so as to get
past all of those intellectually
uninteresting distractions,
and focus instead on the ideas.
>> In fact, this might be before.
This, for this, week shall be after.
This, in this graphical
language Scratch,
is how you would implement that same
program-- a program that when run,
simply says hello world.
And what's nice about Scratch is
that it's this graphical programming
environment that uses puzzle pieces or
blocks, that only interlock together
if it makes logical sense to do so.
And with Scratch can you develop
animations and interactive games
and art, and any number of things that
you might imagine in your own mind,
and implement them simply by
dragging and dropping puzzle pieces.
>> And indeed, we'll have the ability
to express some of the same ideas
that I just mentioned a moment
ago in the context of Mike Smith
and searching a phone book-- things
like functions, just actions,
things like loops that do
things again and again,
variables, which is
something we'll introduce,
but it's familiar perhaps from
algebra-- just some kind of placeholder
to store some value you might
need later-- Boolean expressions,
where those yes no or true
false questions from before.
Conditions are those forks in the
road-- those branches so to speak.
And then there are some fancier
features we'll see even today,
called arrays and threads and
events, that we'll then revisit over
time in different languages.
But Scratch allows us
to explore all of these.
So here in Scratch, this purple
block is what a function is typically
going to look like.
This purple puzzle piece that has some
word like say, which is the action,
and then it might have an
argument or a parameter-- some way
of kind of customizing
what that block does
so that it's not pre-determined by
MIT what this purple block says.
In fact, you'll see in a
moment that I'm able to type
the words like hello world, or
hello David, or hello Zamayla,
or whatever I want, in the argument
to that puzzle piece-- the white box
there.
Meanwhile, if I want a loop, we'll
see that there's puzzle pieces that
look a little orange like this.
And their shape kind of suggests that
something happens again and again
in a cycle.
>> So if I wrap a say hello world block
with a forever block in Scratch,
it's just going to keep saying hello
world forever, quite literally.
Meanwhile, there's another
type of loop in Scratch
that we'll see-- a repeat
block-- where, if you
know in advance how many times
you want the loop to execute
a finite number of times in fact-- you
can specify that by typing in a number
or even plugging in a variable,
like x or y as we'll see.
>> In fact, variables like
i in this case, which
is a common name for an
integer variable that
just stores a number--
an integer might be,
to use this orange block here to
set a variable like i to zero.
Here's an example in green of a
Boolean expression in Scratch.
Even though this looks like a math
formula, math inequalities like this
really are Boolean expressions.
This is either true or false.
I is less than 50.
It's either a yes or no answer
or true or false answer.
And we'll generally call
those Boolean expressions.
And it doesn't have to be 50.
It can be x less than y,
greater than y, equal to y--
any number of other
questions might be asked.
>> Now, at first glance, this might look
suddenly quite bold here, and it is.
But concept wise, it's
pretty familiar from before.
If x is less than y, than say as much.
Else if x is greater
than y, then say as much.
Else say x is equal to y.
So we have an example
there of a third scenario--
the only third possibility-- x is either
greater than, less than, or equal to.
So we have a three way fork in the road.
>> And notice what's cool here-- Scratch,
it would seem, has just one puzzle
piece, in this case, in if else block.
And yet that would seem to imply you can
only have a two way fork in the road.
You can go left or right, but
what about that third scenario?
What if x equals y?
No big deal.
Take one puzzle piece, put
another one inside of it
to create the semantic equivalent
of if, else if, else-- and now you
have your three way fork in the road.
And as we'll see, the
Scratch puzzle pieces
can be stretched and grow, so
as to cram more stuff in them.
You don't have to fit
everything in its default size.
>> This is something we'll
soon see is called an array.
It's like a list-- some way of
storing multiple pieces of information
in a variable, not just a number.
These we'll see a representative of
something called multi-threading.
In fact, all of your
Macs and PCs these days
support multi-threading,
which means you can literally
do multiple things at a time.
You can have Microsoft Word up in the
foreground, working on some essay.
You might have a browser
in the background opening
G-mail or Facebook or the like.
Your computer can do multiple things
today because it is multi-threaded,
and programs they're in in
particular are also multi-threaded.
>> There's things called events as
well in the world of Scratch,
and then there's a way too, to make
our own custom puzzle pieces if things
don't actually exist in advance.
So let's motivate this as follows.
Some years ago, when I
first discovered Scratch,
when I was actually a
grad student at MIT, we
ourselves were tasked to make homework.
And I implemented--
which, in retrospect,
was a very poor decision because it's
the most infuriating song in the world
to listen to for eight hours
while working on your homework--
but something I had called Oscar Time,
which is perhaps a familiar song.
>> CS50s own Jordan Hayashi, one of
our more senior staff members,
has upgraded it for 2015 and
now 2016, since back in the day,
I had everything just going
into Oscar's trash can.
Now we support recycling and composting.
>> But to paint the picture
of what we can do here
and to motivate some of
the lower level examples,
could we get one other
volunteer to just come on up
and play my first
homework assignment ever?
Come on up.
What's your name?
>> HENRY: Henry.
>> DAVID MALAN: Henry, come on up.
Come on up.
Head either way, and
you'll see in a moment,
I'm going to go ahead and hit the
green flag in the top right hand
corner, which means go.
The little stop sign icon
is going to say stop,
and that's when you start
and stop the program.
Nice to meet you.
All right.
So we're going to see the instructions
on the screen in just a moment.
And just by playing this game
for a few seconds-- trust me,
we're not going to want to play
all the way to the end-- you will
get a sense of what the program does.
And more than just focus on Henry
being good or bad at this game, focus
and how was it implemented by me
originally and then by Jordan.
In other words, where are the variables?
Where are the loops?
Where are the functions?
And we'll see if we don't see
those underneath the hood.
>> Just click and drag trash
to the appropriate bin.
>> [MUSIC PLAYING]
All right.
That's very good.
Why don't we stop it there.
Thank you.
Congratulations to Henry.
Thank you.
>> [APPLAUSE]
>> Just imagine debugging that program.
If there's a problem two
minutes into the song-- but so
what's going on here really?
As complicated as it might
start to seem to get over time,
indeed more and more
stuff started falling,
what's interesting about
this kind of example--
and we'll see a few
others-- is that if you
look past the complexity or
the sophistication of the game,
there's a very simple building
blocks that play-- all of which,
if you distill them to those
building blocks, are very accessible
and implementable unto themselves.
For instance, it's
been some time, but I'm
pretty sure what I initially did when
making this game for the first time
was I completely like procrastinated.
I didn't focus at all on the
logic or the puzzle pieces,
I focused on the graphics and finding
the street post and the trash can
and all of that.
But those were requisite
ingredients at first.
And once I finished procrastinating and
laying out the overarching framework,
I decided, let me just make one
piece of trash fall from the sky.
And we'll see Scratch
supports things called
sprites-- characters that can
have different costumes on so they
look different.
>> And so I put a trash
costume on one such sprite.
And I just needed it
to fall from the sky.
And so it turns out, Scratch,
like most programming languages,
supports random numbers or
technically pseudocode random numbers,
so that by dragging and
dropping certain puzzle pieces,
I was able to have the trash
come from the left at first.
And then the next time it fell, from
the right and then from the middle.
And all the game did was just
have trash falling from the sky.
You couldn't point at it or click on it.
You couldn't open the trash can.
You couldn't do anything.
But it was a baby step
toward my ultimate vision.
>> And after that, I actually
implemented some kind
of sensing so that if you did click
and drag on the piece of trash
over the trash can, Oscar's
lid would open and close.
Nothing would happen to the trash, but
at least the lid would open and close.
So then check, step two of two.
And this is what's going to be
key in both problem set zero
and in programming more generally, is to
take these very deliberate baby steps.
Because not only does it allow you to
feel honestly accomplished much more
quickly-- it's the
worst thing in the world
to try to implement all of Oscar Time,
then hours later hit the green flag,
and nothing works as expected
because where do you even
begin to debug or to
troubleshoot that program?
It's just overwhelming.
>> And so truly embracing this idea
of taking steps-- baby steps again
and again-- building up
something that's, in the end,
really impressive and complex, but
at first, is not nearly as much so.
In fact, let's do this.
Let me go ahead and-- Scratch itself
exists on the web at Scratch.MIT.edu,
and you'll be told as
much again in problem
set zero, the specification for
which is already on CS50's website.
>> But this is what Scratch itself is.
And there's really just
three primary areas.
At the top left there
is the so-called stage.
This is Scratch.
The default costume is a cat.
And this is the rectangular world in
which you can move-- up, down, left,
right and some other stuff.
In the middle here are our categories
or our pallets of puzzle pieces,
and different colors
mean different things.
And if you poke around, you'll see
things like loops and conditions
and variables and other ingredients.
>> And then over here is the scripts area.
This is where I can drag and drop
those puzzle pieces to do things.
So let's do one such thing.
Let me go ahead and--
and I know where it is.
So I'm going to immediately click on
where I know things are ready to be,
but pointing and clicking and
poking around are inevitable.
So when green flag clicked,
what do I want to do?
I'm going to do this.
I'm going to drag this purple puzzle
piece, say hello for two seconds,
and let me zoom in.
>> And I'm going to change this
to be what I want it to be--
hello world for two seconds is fine.
Now, I'm going to click the
green flag, or if I really want,
I can full screen it and then come back.
It will just keep
everything in one window.
Green flag-- hello world.
All right.
Not all that interesting.
So let me go ahead and do this.
Let me try another one.
When green flag clicked-- let's
do something like a sound.
And notice that out of
the box for free you get
a cat sound, as is the default sprite.
So now let me go ahead and
hit the green flag now.
>> [MEOWING]
>> Aw.
That's adorable.
I'm programming.
So what have I done?
This is the equivalent of a program.
It's obviously super simple.
It didn't really take all that much
effort and MIT did most of the work,
but I have called a function.
I have used a function.
I've made some action, using just
that one purple puzzle piece.
>> Well, if I want to do
three meows in a row?
Let me go ahead and do two and three.
And notice that when you
hover nearby a puzzle piece,
a little white line appears
sort of magnetically,
and it will snap
together when you let go.
Let's see what happens here.
>> [MEOWING]
 
>> There's a bug.
I only hear one meow.
Why might that be?
Yeah?
Yeah.
We don't really hear it,
but that's good intuition.
They're all playing at the same time.
Why?
Well, the computer is just going
to do what you tell it to do.
So if you say, play sound,
play sound, play sound,
but you don't tell it to play until
you're done, play until you're done,
it's going to blow through
the program really fast
and do only what you tell it to do.
>> So I actually need to fix
this in a couple of ways.
I could just do this, get rid of this.
Let me try this other puzzle
piece-- play sound meow until done,
and then drag three of
these and click Play.
>> [MEOWING]
>> It's not really very--
thank you-- very natural.
So why don't I-- let
me go to control here.
Nice.
Wait one second, and now let me go back
to sounds, and play sound until done,
and then let me get wait one second.
And then let me go and get one
more sound, and here we go.
>> [MEOWING]
>> A little more natural, but
this is not very efficient.
Like I was getting bored, all be
it briefly, clicking back and forth
and really duplicating my work--
pretty much copying and pasting.
Indeed, if I Control
clicked or right clicked,
I could have just copied and pasted.
What would be a better construct to use?
What idea from before?
>> Yeah, so a loop.
And in fact, if we poked around,
we might find exactly that.
Let me go to Events or rather Control.
So repeat-- I don't
want it to be 10 times.
That's going to get annoying quickly.
But I will repeat three times.
Let me go back to sound and
play the sound until it's done.
Let me go back to Control
and just wait one second.
And notice, you might
think it doesn't fit,
but again if magnetically you let it
snap in place, it will grow to fill.
What's it play now?
>> [MEOWING]
OK.
Nice.
And this is what would be called
a program that's also correct.
It meowed three times fairly
naturally, but it's better designed.
I'm using less redundancy.
I didn't copy and paste anything.
I just used a better idea.
>> Now, this is still not all that
interesting with Scratch not doing
anything.
So let's do something else instead.
Let's do something forever.
And you know what?
Motion seems interesting.
Let's have him move 10
steps and hit play now.
>> OK.
Well we can kind of drag
him back, and he's still
running because he's doing this forever.
So the loop is doing
what it's saying to do,
but this isn't all that interesting.
Let's do this.
Let me add a control block, and use one
of those conditions for the first time.
>> So it's going to move 10 steps--
10 dots, 10 pixels on the screen--
then it's going to ask this question.
If something is true, then do
something inside this block.
So it turns out sensing has a whole
bunch of Boolean expressions--
questions of the yes no or true
false form-- let me do this.
>> If touching-- and then there's
this little drop down menu.
I can parameterize it.
If touching the edge-- let's
do something like that.
So if touching edge--
let me go back to motion.
And why don't we just
turn around 180 degrees?
All right.
So forever, move 10 steps.
If you're touching the
edge, turn 180 degrees.
And that's not the end of the program
because you're in a forever block,
so it's going to go again and
again and again and again.
So let's see what happens.
OK.
A little buggy, but kind of cool.
>> And we can add to this some silly things
that aren't all that intellectually
interesting.
But if we hit this little
microphone button-- ouch.
Let me clean this up.
Let me enhance this as
they would say on TV.
Clean that up, Save, and
now go up to scripts.
>> And now, let me go to sound.
Let me give it a name.
I'll call this ouch.
And now play sound ouch.
Notice it appears in the
little drop down menu.
Let's see.
>> [OUCH]
>> [LAUGHING]
But we can change t his on the fly.
We can be twice as annoying.
>> [OUCH]
>> Or if we make it like
1,000 steps at a time--
 
>> OK.
So we're going to leave that one alone.
So again, building blocks-- I
started with something super simple,
and then I added a feature,
added a feature, added a feature.
And I no longer need to worry about
how the first of those features
was implemented as I continue
to layer things on top.
So in fact, let me do one other here.
Let me go ahead and open a file that
I brought in advance, called Sheep.
>> So it has a slightly different
character that looks like this.
And let me see if I can't
do something using a counter
in this case-- a so-called variable.
I'm going to go ahead and under Events--
let me get a green flag clicked.
Then let me go to Data, which I know
from just playing around before,
is where variables are.
And I'm going to go ahead and drag this.
>> So a variable called counter, and
I'm going to initialize it to zero.
I can call it anything-- x or
y or z-- but in programming,
calling something in a semantically
useful way, like counter,
that describes what it is, it's a
lot easier to read your code later.
Let me go ahead and get
a forever block here.
And let me go to the looks
page and do a Say block.
But what's cool about variables is I
don't have to just type in something
like hello world, which we've already
done, I can instead go to Data
and drag my variable, and even
though the shape doesn't quite
look like it should fit,
it will grow to fill.
And I'll just say the counter for one
second-- spoiler-- he's going to count.
We'll say it for one second.
Then I'm going to go and
have him wait for one second,
so it doesn't count up too fast.
And then lastly, change counter
by one-- in other words,
increment the counter by one
additional value and do this forever.
>> So the sheep too, like a
programmer, counts from 0.
 
And if we wait long enough,
he will do this forever.
But that's not exactly true, because
in fact, as we'll discover in week one,
integers and computers more generally,
technically have only a finite-- well,
rather computers, when
they represent integers,
only have a finite number of bits.
Those light bulbs there
can only count so high
before you're out of light bulbs.
And a computer too,
only has so much memory,
only has so many transistors,
so it can only count so high.
>> So it turns out that the sheep,
I think, can count to 2 billion
or something pretty big.
So we're not going to
wait for this to happen.
But eventually some bug will happen
that can have some very real world
ramifications.
But beyond the sheep, that
just introduces a variable.
Let's go ahead and open up
something I made in advance
here called Pet the Cat--
Pet the Cat over here.
And notice here it's few
blocks, but when green flag
clicked, forever doing the following.
If you're touching the mouse
pointer-- so the cursor on the screen,
the arrow-- play sound meow
and then wait two seconds.
And just do this forever.
Just constantly wait
to see if the pointer--
if the cat is touching the pointer.
>> So I hit play.
Nothing's happening.
But as I move the cursor over the cat,
>> [MEOWING]
>> And if I move it away, not
petting the cat anymore.
So some conditional logic
nested inside of a loop.
How about this example, deliberately
called Don't Pet the Cat?
What's this going to do?
>> [MEOWING]
>> Why should you not pet the cat?
>> [MEOWING]
>> OK.
So this is an example of an if else.
It's a decision point and
because it's sitting in the loop,
they're both getting checked.
Is this true?
Is this true?
Is this true?
Is this true?
And eventually, one of
those is going to apply
and so you hear either the meow or
the roar of the lion in that case.
>> Well, let's do a slightly more fancy one
that I made in advance too-- threads.
So a thread is just one
thing that a computer can do.
So a multi-threaded program is a program
that can do multiple things at once.
And all of these examples
thus far have had
just one script, so to speak--
one program like this up here.
But notice this program has
two sprites, two characters.
One is a bird.
One is a cat.
>> And notice when I click on these down
left, they each have their own scripts
or programs associated with them.
And both of those
programs, notice, start
with when green flag clicked--
let's look at the cat--
when green flag clicked.
And so indeed, when I hit play now,
two things are going to happen at once.
The cat and the bird are both
going to operate simultaneously
to create this effect.
And you might imagine what's happening.
There's a loop and the bird
and the cat are in a loop.
The bird is just bouncing like
I was before when I said ouch.
But the cat clearly has an advantage.
There's another sensing block
that points the cat deliberately
to the bird in this case here.
So we could tease apart, by looking
through those blocks, what's happening.
But the key ingredient here is one.
The bird, so that this game isn't
completely boring-- or this animation--
starts at a random direction.
And the computer is picking
a number between 90 and 180
essentially, so that it's a slightly
different animation each time.
>> And then notice here, if the
cat is touching the bird, then
play the lion four sound-- the roar.
But meanwhile in the bird's
palette, we have this.
Forever, if not touching the cat,
just keep moving three steps.
And then here's another puzzle piece.
If you're on the edge, bounce.
So the bird is just kind of
minding its own business,
just flying around and
bouncing, and it's really
the cat that had the conditional logic
to determine if it had caught the bird.
All right.
So let's do one other here,
this one being called Hi Hi Hi.
And this one here just does
this in a forever loop.
But notice-- how do we stop
this very annoying program?
 
Hit the space bar.
Because if I do that,
the left hand program--
notice it's constantly listening--
is the key space press.
If the space bar pressed,
and if so, what does it do?
It does a very common technique.
It sets a variable equal to some value.
But it toggles that value.
[? So appearance ?]
based on the shape-- I
have a variable that I
wrote in advance called
Muted, which just says yes or no.
Is the sound muted or not?
True or false?
And notice, I'm saying this-- if
muted is zero, then change to one,
else set mute it to zero.
So just flip the value from zero to one.
I could have done-- change it
from two to three and three to two
or four to five or four to six.
But it doesn't matter
what numbers I use,
so long as I keep
changing it the opposite.
>> And most any programmer would just
choose zero and one-- false and true,
off and on-- to represent this.
And this is still running.
If I hit the space bar again
>> [SEAL SOUNDS]
>> The program is still running.
Because there's this other script
that says, forever do the following.
 
If the muted variable equals
zero-- so if you're not muted
is the logic-- if it's false
or no, then play the sound,
because you're not muted.
You should play the sound and then
think hi hi hi for two seconds
and then wait, and do it
again and again and again.
>> And so in this way do we have a way for
people to-- for programs to interact.
And they don't have to
be as dated as others.
In fact, poking around--
no pun intended--
someone spent a huge amount of
time on the internet implementing
PokemonGo in Scratch.
It even geolocates you in
Cambridge or Allston here.
So if you want to see too what people
can do is this-- very fancy menu.
Click on here.
>> This is me with my arrow keys now.
I'm going to go after this.
Click.
 
And now you click the PokeBall.
 
I mean, I think you're
supposed to click the PokeBall.
All right.
So I did that.
I can go over here.
And this person implemented some more
PokeBalls over here-- three PokeBalls.
>> We'll post a link to this
online so you can play.
But notice there's just
some basic building blocks.
It looks a lot fancier, and it is.
This is impressive and more
than we would typically
expect, certainly for problem set zero.
I have no idea how long
this person spent online.
But it's all just a loop.
There's a sound playing.
There's some kind of loop
listening for whether I'm
hitting the up arrow or the down
arrow or the left and the right,
and then if so, it's moving
it some number of pixels.
And then if I click on
another sprite, there's
some kind of if condition there.
Yeah, this is getting too intense.
We're going to stop.
It's all those basic building blocks.
There are no other ingredients other
than the ones we've looked at already.
>> And yet here, let me do
one final set of examples
that paints a picture too
of what you can do here.
Here's a very simple program that
just does this-- cough, cough, cough.
And based only on what
we've looked at thus far,
where is the obvious
opportunity for improvement.
This program is correct.
It coughs three times,
which is what I intended.
But it's poorly implemented.
It's badly designed.
Why?
Yeah.
It's not a loop.
And it's not so much
that it's not a loop,
it's that there's a lot of redundancy.
There is copied and
pasted code, so to speak.
And the solution probably
is indeed a loop.
So let me go ahead
and improve upon that.
And I'm going to drag these over here.
Let me go ahead and get a repeat
block, change this to three.
I'm going to throw away
some of those blocks.
>> And you'll notice it's pretty intuitive.
You drag and drop and things
appear and disappear eventually.
And I can just drag this in here, and
now I have a cleaner version still.
But you know what?
There's this opportunity
now for abstraction--
to start to define new vocabulary
that MIT didn't anticipate.
There's wait and repeat
and forever and if,
but what if I want to introduce
the word cough as a block?
What if I want a puzzle piece
whose purpose in life is to cough?
>> Well, let's look at this version
here, which I made as follows.
Magically, I have created
this puzzle piece here,
which Scratch allows you to do.
And indeed C and Python
and JavaScript are
going to allow you to do this as well.
You can create your own custom
pieces that you call what you want.
In this case, cough feels
like a reasonable definition.
And then with these pieces down
here can you define what it means.
>> I dragged and dropped from
this palette here-- more
blocks-- this big purple
block, where I typed in cough
as the name of my new puzzle piece.
And then I'm saying any time a user
calls this new cough puzzle piece,
do a say and a wait.
And so up here in my repeat block,
I can just cough three times.
>> And I would argue, especially
if now you hide this detail.
Who cares how cough is implemented?
All I care about as a
programmer that I can cough.
I don't care how say is implemented.
I just care that the
cat can say something.
I can abstract away that detail and
only focus on what's on the screen here.
But I can take this one step further.
>> Notice that here, I have
implemented the loop three times.
But what if instead I grab this version?
And what if instead
in this version here,
I just change my puzzle piece to take
an argument and input unto itself?
And that input can be
a number like three.
So now, if I am writing a program
and I want the cat to cough,
I can actually tell the puzzle
piece how many times to cough,
because at the bottom here, a fancier
version of these custom puzzle pieces
lets me specify that
cough actually takes
an input-- takes an argument like this.
And you know what?
Maybe I realize, wait a minute.
Coughing is the same--
it's fundamentally
the same idea as sneezing.
It's just a different
word on the screen.
I can abstract away
further and implement
this final version of a
cough, which at first glance
is way more complex looking.
But notice what I've done.
I have now generalized-- genericized
really-- this puzzle piece
to be called say word n times.
>> And now I have two new puzzle pieces
down here define cough n times.
And what does the cough function do?
What does my custom puzzle piece do?
It just calls the say block,
passing in the word I want to say,
passing in the number
of times I want to say.
Because now I can implement
sneeze by simply saying achoo,
in this case, some number of times.
>> And so I'm layering and layering.
And again, the key here is not
how I implemented it, but the fact
that if I just literally
move these off the screen,
look how simple if not
pretty my program now looks.
Because it does what it
says, I've abstracted
away what is inside that black box.
it happens to be a purple box here,
but I've obstructed away what's inside
because I don't care how it works.
I just care now that it works.
>> And indeed, in problem
set zero, this is exactly
the kind of layering of ideas you'll
have the opportunity to explore.
It's exactly the opportunity to
apply problem solving techniques,
to what's probably an
unfamiliar environment.
And whether you've not programmed
before or programmed before,
you'll find that there's
a little something
in this environment for everyone.
And with problem set
one in a week's time,
we'll be transitioned to focusing
on a higher level language called
C-- or rather a lower
level language called
C-- that's even more
powerful, even though it's
a little more cryptic at first glance.
>> And you'll realize per today's TL:DR,
that this problem set has a shorter
window of time than future ones, simply
because you should find it fairly
accessible.
And not to worry if
you add the class late.
We'll address that before long.
And before we adjourn for cake, let's
finish with just a two-minute look
at what awaits you here in CS50.
 
[MUSIC PLAYING]
All right.
That's it for CS50.
We will see you soon.
Cake is now served.
 
[MUSIC PLAYING]
SPEAKER 17: Have you heard
of a sabbatical, Chief?
 
SPEAKER 18: Perhaps there's
more under the hood.
 
