All language subtitles for https___cdn.cs50.net_2022_fall_lectures_0_lang_en_lecture0.srt

[MUSIC PLAYING]

DAVID J. MALAN: All right.

This is CS50, Harvard
University's introduction

to the intellectual
enterprises of computer science

and the arts of programming.

My name is David Malan, and I actually
took this course myself, back in 1996.

I was a sophomore at the time.

I was actually concentrating in
government, because a year prior,

as a first year, I'd come
into Harvard thinking

that I liked history and constitutional
law and similar classes in high school.

And so when I got here,
I rather gravitated

toward that which was familiar.

I figured, if I liked and if I were
good at that particular subject

in high school, then that's presumably
who I'm supposed to be here.

But it wasn't until
sophomore year that I got up

the nerve to step foot
in the CS50 classroom,

and even then, it was
only out of curiosity.

Like I had no intention of studying
computer science of even taking CS50

when I got to campus.

But people were talking about it,
and there was a lot of beware.

And it was perhaps for
the initiated only,

and I didn't really ultimately
what computer science was.

But for me, the light bulb went off.

I found that, contrary to
what I'd seen in high school,

where I saw friends of mine like
programming away in the computer lab,

heads down, antisocially just doing
whatever it was they were doing,

it really wasn't that, once I
got to this particular class

and this particular place.

It was much more about problem solving
more generally and just learning

how to express yourself in
code, in different languages.

So that you can actually solve
problems of interest to you.

Even if you have no intention of being
a computer scientist or an engineer,

but just want to be
able to solve problems,

analyze data do interesting things, in
the arts, humanities, social sciences,

physical sciences, or
really any other field.

And indeed, this particular
path led me to computer science,

but the hope for CS50 more
generally is that, indeed, you

just find your way to
applying principles

that you'll learn over the
coming months to whatever

field is of interest to you.

With that said, it was
definitely a lot of work and not

without its frustrations for me.

But there was no better feeling than
like banging your head proverbial

against the wall for some number of
hours, even days, trying to fix a bug,

a mistake in your code.

And then, oh my God, the rush
of emotion of accomplishment

of pride of exhaustion when you
finally solve some problem that's

really been weighing on you.

It's just so incredibly
gratifying but also empowering.

Because unlike a lot of
fields, like computer science

was built by humans themselves.

And so if a human built this,
surely, you, another human,

can understand it as well.

And so even though there's going to
be some distractions along the way,

you're going to see what looks
incredibly cryptic, if you've never

programmed before.

Over time and with practice, everything
just starts to make more sense.

And with time and with
practice, you just

get better at this particular field.

And indeed, really, the key to
success in programming in general

is just to allow yourself enough time.

And so at least,
thankfully, I quickly got

into the habit of starting
early in the week,

for instance, when writing actual code.

Why?

Because you're going to
run up against a wall.

You're not going to see some bug.

Something's not going to jump
out at you, and that's fine.

That's when you call it a day, take
a break, move onto something else,

and then just come back to it.

And that's what keeps programming fun
for me, even all of these years later,

whether it's teaching
or actually applying it.

But there's, down the road,
a history of an MIT hack,

and it looked a little something
like this, in yesteryear.

And there was a little sigh the MIT
students, when they made this hack.

On the wall it says, getting
an education from MIT

is like drinking from a
fire hose, which indeed they

have connected to what should have
been otherwise just a water fountain.

And that's going to be what
it feels like, sometimes,

not just in computer science per
se, but just an unfamiliar field.

If you're not from STEM, if
you're not from CS, that's fine.

But so much of it, ultimately,
is going to be absorbed by you

and going to be within
your grasp by terms end.

So just keep in mind,
that's very much the intent,

but you'll be amazed what you're
able to create, to accomplish,

just three or so months hence.

Indeed, 2/3 of you, contrary to
what you might think are assume,

have never taken a CS class before.

So it's absolutely not the case that
the person to the left or the right

surely must know more than you.

Indeed, it's quite the opposite.

And as you'll see in the coming
weeks, as you write your own code

and solve your own problems, what
ultimately matters in this course

is not so much where you end
up relative to your classmates

but where you end up relative
to yourself when you began.

And it really is all about that
delta, whether you've programmed

or not, just getting something
out of a class like this.

And if it does take time, and if
you do feel those frustrations,

but you simultaneously eventually
feel that sense of accomplishment,

that just means it's all working.

And indeed, hopefully, all the more
worthwhile and gratifying, ultimately,

as a result.

So what are we going to
do in the coming weeks?

So here we are in week zero.

We'll soon see why computers and
computer scientists start counting,

if you will, from 0.

But week 0, is one in which we
explore computational thinking,

thinking like a computer, and starting
to clean up your thought processes.

Getting you to think, to solve
problems more methodically,

and then ultimately,
translating that into code.

And some of you might recognize
this environment here, a.k.a.

Scratch, coincidentally also from MIT.

You might have used it in grade school.

We'll use it today and a little bit this
weekend in the course's first homework

assignment or problem set.

But not so much to play
around in a way that you

might have if you did
use it in yesteryears,

but to explore ideas of
computer science and programming

that we're going to use and reuse
every week hereafter as well.

Thereafter, we're going to
transition just next week

to week one, so to speak.

Whereby, we'll introduce you to a more
traditional language, a lower level

language, an older language
called C. And in C, you're

going to use your keyboard, not so much
your mouse and pointing and clicking,

but you're going to write
code that soon is going

to look a little something like this.

And if you've programmed
before, you can probably

glean what this is going to do.

If you've never programmed before,
which is the case for most of you,

this too will soon make sense.

But this is the most canonical program
that most any programmer ever writes

called Hello, World,
and indeed, that and all

of the surrounding syntax above and
below just that sentence Hello, World,

will soon make all the more sense.

You'll learn how to use
industry-standard tools, so to speak.

Pictured here is something called
Visual Studio code, or VS Code.

You'll use a cloud based
version of it initially,

so you don't have to suffer
with any technical difficulties

or headaches like that.

It'll just work right
off the bat, but we'll

use that to [INAUDIBLE]
others ultimately

to then explore ideas in computer
science, principles that you can apply.

And we'll take a look
underneath the hood,

so to speak, of your computer at your
memory or RAM, Random Access Memory,

where all of the data is
ultimately going to be stored.

We'll also take a look
thereafter at bugs.

A bug is a mistake in a program.

Here is an actual bug in an
actual computer in yesteryear,

but we'll teach you how to debug
programs, find your own mistakes,

find others' mistakes, and
improve that code as well.

We'll transition then to algorithms,
step-by-step instructions

for solving some problems,
which we'll touch on today too.

And if you picture
here, this is actually

a pretty representative problem.

Odds are, you haven't had to
deal with something like this,

but it's representative
sorting, for instance.

If you think of each of these
small bars as being a small number,

each of the bigger bars
is being a bigger number,

you might wonder, well, how could you
as a human sort all of these bars,

like get all the short bars over
here, all the big bars over there?

Well, odds are, if you're like me,
you would probably kind of eyeball it,

and if you could
physically interact, you

might just start grabbing
the smallest elements first,

put them over on the left.

Maybe grab the biggest elements,
put them over on the right.

But what's your algorithm there?

Like how would you teach someone younger
than you, who's never done that before,

how to do it?

How would you compel your Mac or PC
or phone to do something like that?

You can't just wave your hand,
and say, oh, figure it out.

Move things around.

You have to express
yourself more methodically.

So we'll translate even ideas
like this into code too.

And that's what the Googles
and others of the world

are doing constantly, as they sort
and organize the world's information.

We'll use metaphors along
the way, if it helps.

We'll talk about your computer's
memory as being like a postal address.

Like every mailbox in the world has some
form of postal address, street, city,

state, country, and the
like, and it turns out,

that's how your Mac, your
PC, and your phone also work.

You've got a whole bunch of
memory, like the picture before,

but you can think of it really
as individual mailboxes.

And you can put anything
you want in those mailboxes,

and you can go to a mailbox to
grab information that's from it.

So at the end of the day,
that's really all your computer

is doing with information.

It's just organizing it,
not into mailboxes per se,

but a term you probably know called
bytes, for instance, instead.

We'll talk about problems
that arise even nowadays.

In fact, most of you are
familiar with your Mac,

PC, even phone like spontaneously
rebooting sometimes, crashing,

the little annoying spinning beach
ball or hourglass icon that happens.

Like what is with that?

Well, those are just bugs in programs
that humans at Apple and Google

and Microsoft and others, they
screwed up, and they wrote buggy code.

And your computer, when it
encounters those mistakes,

doesn't know what to do.

And so 9 times out of 10, so to
speak, it just crashes or freezes

or the like, but that kind of
stuff will make more sense.

So even the real world will
make sense, and pictured here

are some lower level terms we'll
eventually get to mid-semester.

But generally speaking, when
something is going this way,

as per this arrow, and something is
going this way, as per this arrow,

like that does not end well.

And that often is what happens
when your computer crashes.

Someone's using memory up here, but
someone else is using memory down here,

and then they're not really
talking left hand and right hand.

So that is just a high level overview
of some of the problems we'll encounter,

but we'll focus to on data, ultimately.

So pictured here is something fairly
technical called a hash table.

It's an amalgam of something we're
going to soon call an array and also

something we call a link to list.

And these are just fancy
terms for describing

how you can organize
information even more flexibly

than just putting individual
values in mailboxes.

Like how could you build structures,
like actual data structures

so to speak, two-dimensional
structures at that?

And so what you're seeing here
is a glimpse, as some of you

might have recognized, of some
Harry Potter universe names,

but they're organized
somewhat alphabetically.

And notice, that any time there's
multiple people with a name that

starts with H, like Hermione,
Harry, and Hagrid, well, they

can't all fit in that mailbox, if
each of these squares along the left

is that same mailbox.

So you have to chain them together.

Well, you'll learn how
to do that in code.

So that even if you get
more data than you expect,

if your business is booming, and
you're some web-based business,

how do you keep adding
and adding information

to your software to
actually keep up with it?

But this, again, is what code's going
to soon look like, as soon as next week,

in week one, this here being C,
but we'll transition in a few weeks

to a more modern, higher level
language, so to speak, called Python.

Indeed, the course very deliberately,
back in my day and now this,

introduces you first to C, which
funny enough, many people don't

tend to program in certainly every day.

I use C, generally,
September, October, November,

December, when teaching CS50 itself.

But it's everywhere, nonetheless.

In fact, even today's other languages,
with which you might be familiar,

like Python and Java and
yet others still, you

see this same primitive
language underneath the hood,

because it's so darn fast.

And as you'll learn
over the coming weeks,

it really gives you access to
and an understanding of what's

going on conceptually down here.

So that thereafter, after
CS50, when you're writing code,

you can think at a very high
level what's actually going on.

So in fact, in just a few
weeks, what looks like this in C

is going to look instead
like this in Python.

And you'll better understand what's
going on underneath the hood,

and odds are, after this class,
you'll reach for a language,

like Python more frequently
than C, but you're

going to benefit from that
bottom-up understanding thereof.

Thereafter and towards term's end, we'll
introduce you to a few other ideas,

like where do you put
large amounts of data?

In things called databases, not
things like spreadsheets, like here,

but actual databases.

We're using those same
kinds of data structures,

you lay things out in an
interesting way in memory.

Thereafter, we'll transition
to a very familiar environment

that you and I use every day, the web.

Like the web has become rather
the User Interface, or UI,

that we use everywhere, on the laptops,
desktops, and even mobile devices,

nowadays.

Well, pictured here is
a language called HTML.

It's not a programming language.

It's a markup language, and some
of you might have made home pages

or portfolios in the past.

But you'll understand what's going
on here, but more powerfully,

you'll understand how the computer
sees that same kind of code,

builds up a hierarchical family
tree-type structure in memory.

And then you can manipulate
that tree with code

to actually add more and more
information, chat messages, anything

on the screen that you like.

And finally, we'll tie
all of this together

by introducing what are called
frameworks and libraries,

third-party code that makes it a lot
easier to solve problems of interest

to you.

And so in particular, here,
this is the very first web app

that I myself made back in like 1997.

I was part of the first-year
intramural sports program,

not as an athlete but as the
programmer, and I was teaching myself

how to build web applications.

I only knew C and maybe a little
bit of something else at the time.

But this became, for Harvard at
least, the very first website

for the first-year
intramural sports program,

and it wasn't just a static website
with links and images and the like.

It was interactive.

You could register for sports.

We could input exactly who was in
a tournament bracket or the like,

and it could actually automatically
keep track of this data.

So there too, after just three
months of a class like this,

you'll go from writing
quite simply this week

and next Hello, World
to building things like

this for whether it's web,
mobile, or other platforms

as well, if you so choose.

But we'll get you off of the course's
infrastructure, by the end of the term.

You won't be using any toy
environments along the way.

We'll empower you, ultimately, to write
code after CS50, especially if this

is the only CS class you ever
take, on your own Mac or PC,

using the same software, but not
the cloud-based version thereof.

But all of this software is
itself free and can be used by you

powerfully after the course's own end.

But along the way, as
you may know, there

is this tradition within the class,
particularly in healthy times,

of a number of events that really
brings people get together,

not just collaboratively
and academically,

but to just solve problems and generally
engage with each other as well.

Coming up first, CS50 Puzzle Day,
which is meant to be not jigsaw

puzzles but logic puzzles that
require no prior experience

with computer science or programming.

But it's just an opportunity to
quietly work on a packet of puzzles

with some number of friends
for prizes and more.

Later in the semester, once
you tackle your final projects,

the capstone of the course, where we
don't give you a homework to write,

you yourself come up
with something to build.

We'll get together generally
around 7:00 PM in the evening,

wrap up around 7:00
AM, if you so choose.

And it's an evening, a 12-hour
opportunity to collaborate with

classmates on your very own final
project, in a large space on campus,

that ends--

if you're awake with us-- at 5:00 AM.

We can hop on some CS50 shuttles and go
down the road for some pancakes at IHOP

around 6:00.

Of course-- of course, this is
6:00, 7:00 AM at that point,

but it's an opportunity
finally to lead into what's

called the CS50 fair, which is an end
of semester celebration, an exhibition,

of everything that you'll
accomplish over the coming months.

And in fact, pictured here are some
of your predecessors in healthy times.

The CS50 fair allows you to
come with your laptop or phone

and exhibits of students,
faculty, and staff across campus

put together something
in person and on video

that people can delight in seeing,
as you exhibit what it is you created

and what you learned over the
course of the several weeks.

And ultimately, a chance to just
share and inspire others as well.

And you'll all walk home,
ultimately, with your own I took

CS50 T-shirts saying as much as well.

So with that high level
overview of the course,

I propose that we begin to take a look
at what computer science itself is

and what it is we're going to be
doing over the next several weeks

at this lower level [INAUDIBLE] too.

So what is computer science?

Right?

If you're maybe like me or new people
like my friends in high school,

you probably assume that
it means programming.

And that's absolutely a big part of it
for a lot of people, because with code,

you can write, you can express
ideas, and solve actual problems,

especially involving data.

But computer science itself is really
the study of information, if you will.

How do you represent it, and
how do you actually process it?

And in that sense,
computational thinking

is just the application of ideas from
computer science, a course like this,

to problems of interest to you, again,
in the arts, humanities, sciences,

social sciences, whatever the
domain of interest is to you.

So with that, if computer science
is all about information and with it

the solving of problems, well, what does
it actually mean to solve a problem?

Let's see if we can't propose a model
into which all of the lessons learned

will ultimately follow.

And I'd propose that
this is problem solving.

You've got some input, which is
like the problem you want to solve.

The goal is to solve it.

So that's the so-called
output, and then somewhere

in here, the proverbial black
box, is some kind of secret sauce

that gets the work done.

And in the coming months, we'll
have to decide, well, how are we

going to represent these inputs and
outputs, and really, how do we code up?

How do we write solutions for what it is
that's solving the problem of interest

to us?

So when it comes to representation of
information, like there's a lot of ways

we can do this.

And for instance, if the
problem at hand quite

simply is to take attendance
at the beginning of class,

on the first day of school, well,
how could we go about doing this?

Well, we could actually
use a system called unary.

Well, what is that?

Well, that's a fancy way of saying
1, 2, 3, 4, 5, maybe 6, 7, 8, 9, 10.

And I can use my digits--

pun intended-- on my fingers
to actually count everyone up.

And eventually, you need toes and
whatnots, if you have to count so high.

But unary is a very
simple system of using

a single symbol, a human finger in
this case, to just solve some problem,

like counting the number
of people in the room.

Let's make this slightly more technical
for a moment, a little more mathy.

That's just called base-1, where the
base under which you're operating

has one digit in it, like
literally a human finger, and maybe

multiple such fingers, if
you need to count higher.

But of course, most of
you, if not all of you,

generally, vaguely know that computers
use something other than unary--

and even you and I probably
don't use this that often-- they

use what language or alphabet instead.

Yeah.

So binary, so binary is indeed the
system that computers somehow use.

So in this case, bi implying two,
and so computers have two digits,

it turns out, at their disposal.

And in fact, if you've ever
heard the technical term bit,

which is like a smaller version
of a byte-- more on that soon.

Well, a binary digit is the
origin of that term "Bit,"

because if you get rid of some of the
letters, and are left from binary digit

with just B-I-T, thus is a bit.

A bit is just a 0 and 1.

It's two more digits than you
might have on your own finger,

and of course, it's fewer
though than you and I have.

You and I typically use, as
humans, the decimal system.

Dec meaning 10, because you and
I generally use 0 through 9.

So on the one hand--

another pun intended-- you've got unary.

Computers use binary.

We humans generally think
and talk in terms of decimal.

But at the end of the day,
these are fundamentally

going to be the same
thing, which is to say

that it's all pretty accessible to us.

Even if you're not a computer
person, I daresay you're about to be.

So what is a bit?

Well, a bit then is a 0 or a 1.

That is a so-called binary digit.

But how do computers
only speak in binary?

How do they solve problems, represent
information, using only binary?

Well, at the end of the day, if
they want to represent 0 and 1,

we need to do so physically somehow.

And I daresay that maybe the simplest
way to think about a bit, a 0 or a 1,

is like a light bulb.

And so by human convention, let's just
assume that if you were a computer,

be it a laptop, desktop,
phone, or the like,

and you want to represent
the number 0, you

know what, you just keep
the light switch off.

You keep a light bulb off.

If by contrast, you're
that same computer,

and you want to represent
the number 1, you

take that same switch, that same
light bulb, and just turn it on.

So a light bulb that's on represents
a 1, and a light bulb that's off

represents a 0.

So why is this relevant to computers?

Well, at the end of the day, you and
I are charging our laptops or phones

at night.

So there's some physical resource
being replenished there, whether you're

on battery or some power cord.

And so inside of a computer
are just thousands,

millions of tiny little
switches, nowadays.

You can think of them
metaphorically as light bulbs,

but they don't actually shine light.

But there are tiny,
tiny little switches,

and those switches, if you've ever heard
the term, are just called transistors.

So like computers have millions of
transistors that can either be flipped

on to represent 1's or
flipped off to represent 0's.

And from that very simple
mechanism, electricity is there,

or it's not, a 1 or a 0.

Computers can actually count,
obviously, from 0 to 1,

but it turns out, even higher, if they
use a little more electricity as well.

So how might I do this?

Well, let me go ahead and propose that
I just grab one of our own light bulbs

here on stage.

This one is off.

So for instance, if this were
miniaturized inside of your Mac, PC,

or phone, this would be a
transistor, and indeed, here's

the little switch on the bottom.

And if your computer wants to represent
a 0, it just leaves the switch off,

and the light is not shining.

If you want to represent a 1,
well now, I've counted as high

as 1, because the switch is now on.

I've grabbed a little electricity.

I'm holding on to it
inside of the computer,

and so now I see that this is a 1.

All right, but unfortunately, with
just one switch, one light bulb,

I can only count from 0 to 1.

How do I count out higher,
might you think, intuitively?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Say it again.

AUDIENCE: More lightbulbs.

DAVID J. MALAN: Yeah,
so more light bulbs.

So let me do this.

Let me just grab something to put
these on, so I can use a few of them

at a time.

And let me propose that here, instead
of having just one light bulb,

let me give myself maybe three in total.

So all of them are initially off, and
if you think of this in miniature form,

in your mind's eye, this is like
a computer with three transistors.

Three switches representing now
the number you and I know as 0.

Why?

They're just all off.

So how does a computer go about
representing the number 1?

Well, it turns on one
of these light bulbs.

And how does the computer
represent the number 2?

Well, you might think, if I may, you
just turn on a second light bulb.

And if you might think, how
does a computer represent 3?

You just turn on the third light bulb.

And so as such, with
three bits, a computer

would seem to be able to
count from 0 on up to 1, 2, 3.

But it turns out, if I'm
a little smarter here,

I can actually count higher than that.

Why?

Well, I'm just considering the
combination of bulbs being on here.

What if I do something like this?

This is still 0, I will claim, but
what if I propose now that this

will be how a computer represents 1--

on, off, off.

This, though, will be how
the computer represents 2.

Notice, I didn't turn on the same two.

I'm just turning on
the one in the middle.

This I now claim will be
how a computer represents 3.

This is going to be-- in just a second--

how a computer represents
the number we know as 4,

and yet, I'm still
only using three bulbs.

This is going to be the number
the computer represents as 5.

This is going to be how the
computer represents the number 6,

and then lastly, it turns
out, with three light bulbs,

if you're smart about it, you
can count it seems as high as 7.

Now, even if you lost track of
what I was turning on and why,

I claim there were eight different
patterns, from all of them

off to all of them on.

But notice that I
started to permute them.

I took into account which ones
were on and which ones were off.

Why, though, do these represent
the numbers we know as 0 through 7?

Well, let me go ahead,
and maybe let's do this.

Instead of just considering
there to be light bulbs,

let's assign some special significance
to each of them, based on where it is.

And maybe for this, could we get maybe
three volunteers, three volunteer?

OK.

You're being volunteered.

OK.

Come on up.

If you want to go over
to the stage there.

Yeah.

You want to come on up as
well, and over here as well.

So there are some stairs on either end.

Maybe a round of applause for
our first volunteers of term.

[APPLAUSE]

All right.

So you want to be our number 1, and
if you want to go ahead and stand

roughly right here.

How about do you want to be number 2?

AUDIENCE: Yeah.

DAVID J. MALAN: Come on over
right to the right of here,

and you'll be number 4, it turns out.

If you want to come
over here, on this end,

let's give you all a moment to introduce
yourselves briefly to your classmates,

if you'd like.

AUDIENCE: Hi.

I'm Ellie.

I'm a senior.

DAVID J. MALAN: Nice to meet.

AUDIENCE: I'm [? Rayhanna, ?]
and I'm a first year.

DAVID J. MALAN: Welcome.

AUDIENCE: Hi.

I'm Joseph, and I am a first year.

DAVID J. MALAN: Welcome.

All right.

So so glad to have all
three of you up here.

Thank you.

[APPLAUSE]

Let me propose now that
we'd like you three

to represent how about the number 0.

And I claim now that if each
of you now represents a switch,

you have fancier light bulbs now.

One is a 1.

One is a 2.

One is a 4, but each of you
is still just has a switch

on the bottom, in fact,
of your plastic devices.

I claim these three volunteers
are representing the number 0.

Let me ask you all now, how
might you represent the number 1?

How should you cooperate here?

OK.

So we would have on,
off, off, which I think

matches what I did with
my three light bulbs

as well, if you want to
go and turn yours off.

How might you three
represent the number 2?

OK, so off, on, off
now, from right to left.

How would you three
represent the number 3?

Ah, so that's why my two light
bulbs went on at the end.

How would you three
represent the number 4?

Perfect.

Number 5, number 6, and number 7?

All right, and give us one more.

How would you represent 8?

AUDIENCE: We can't.

DAVID J. MALAN: OK.

You can't.

How about then one more
volunteer, one more volunteer?

OK.

Come on up.

All right.

What's your name?

AUDIENCE: My name is [? Moin. ?]

DAVID J. MALAN: If you
want to say it into there.

AUDIENCE: My name is [? Moin. ?]

DAVID J. MALAN: All right,
[? and Moin, ?] you're

going to be number 8, and if now
you all-- actually, let's make this

how would you represent number
8, all collectively, as 4 bits

or for switches?

OK, 8, and now lastly, give me 15.

Everyone's awkwardly doing arithmetic
in their head, oh, using unary.

Yeah.

Is that everyone--

Yes.

OK.

Round of applause.

OK.

Thank you all.

If you want to leave
your numbers over here,

we have a CS50 stress ball for you,
but thank you for volunteering.

You can turn those numbers
off and leave them over here.

So thank you.

So how do we go about-- how do we go
from there to creating these patterns?

Well, even though we still had three
bits, initially, and three switches,

later four bits and four
switches, ultimately, we still

used the same approach fundamentally
to actually representing information.

And now why were they
those patterns, and why

did I very deliberately have our
volunteers line up in that way?

Well, I wanted them using base-2, a.k.a.

binary, but with binary
there comes certain rules.

And even if you're not
familiar with binary

beyond that it exists and
relates somehow to computers,

it's actually pretty much identical
to the system you and I use

every day, known as base 10, a.k.a.

decimal.

So let's consider, if you will, by
rewinding to primary school for just

a moment, like how decimal works.

And you'll see that even if you're not
a computer person, you actually are.

You just have to tweak your
mental model ever so slightly.

So here is the number that
you're probably viewing as 123,

but why is that?

Well, it's not really 123.

This is just a pattern of three symbols
on the screen, 1, 2, 3, and your mind

is rapidly assigning mathematical
meaning to them, 123, but why is that?

Well, if you're like me, you
probably learned back in the day,

when you have a three-digit number
like, this the rightmost number

is in the 1's place, the
middle digit is the 10's place,

the leftmost digit is in the 100's
place, and why is that relevant?

Well, if you then quickly do some mental
math, as you and I just do instantly

nowadays, that just means 100 times
1 plus 10 times 2 plus 1 times

3, of course, 100 plus 20 plus 3 gives
us the number you and I know as 123.

But beyond that, how do we get to just
two digits instead of as many as 9

in the decimal system?

Well, let's generalize this.

In the decimal system,
you and I know, if we've

got three digits represented
by these hashes here,

yes, it's the 1's place,
10's place, 100's place,

and if we keep going 1,000's, 10,000's,
and so forth, but why is that?

Well, base terminology is
now a little more germane.

That's technically the 10 to the 0th
column, the 10 to the 1, 10 to the 2.

So these are powers of
10, where 10 is your base.

Computers just simplify
things a little bit,

because computers, at
the end of the day,

only have access to
electricity, on or off.

They don't have access to 10 different
types of electricity, just 2,

on or off, if you will.

Well, they just use a different base.

And the rightmost digit would be
in the so-called 2 to the 0ths.

Then the middle digit is 2 to the 1.

The left most is 2 to the 2, a.k.a.

1's place, 2's place, 4's
place, and as we kept going, 8,

and if we keep going, 16,
32, 64, 128, and so forth,

but the idea is fundamentally the same.

So why is this how the
computer represents

the number you and I know is 0?

Well, off, off, off, from right to
left or in this case left to right,

is just 0.

Why?

Because that's 4 times 0 plus 2 times
0 plus 1 times 0 is, of course, 0.

This is why 001 represents 1.

This is why 010 represents 2 and
3 and 4 and 5 and 6 and 7 on up.

And why did we need a
4th bit to represent 8?

Well, we kind of needed to
carry the 1, so to speak,

using our familiar human terminology.

But for that we need a 4th bit,
another transistor, and this

now represents the number 8.

And that's why we ended with on--
from left to right-- off, off, off.

So I keep saying on and off,
or the light bulb is on or off,

but really, I just mean 1 or 0.

And so computers and we humans
think of things digitally

as just being 0's and
1's, but mechanically,

you can think of it indeed
is these light bulbs.

Now, a bit is not very useful.

Even 3 bits, 4 bits, not that useful.

You can count to 7 or
15, generally speaking,

bytes are a more useful unit of measure.

And anyone familiar how
many bits is in a byte?

Yeah.

So 8 bits are in a byte.

You can think of it as
an octet equivalently.

In some contexts, there are
nuances there, but think of a byte

as just being 8 bits, and that's
just a more useful measure.

So what does this mean in real terms?

So if you've ever downloaded like a
music file or a photograph or a video,

those are measured in bytes.

Probably not small
numbers of bytes, probably

kilobytes for thousands of bytes,
megabytes for millions of bytes,

gigabytes for billions of
bytes, especially for video.

That just means you
have a lot of patterns

of 8 bits, some combination of 0's
and 1's on your computer's hard drive.

Here then, with a byte of bits, 8
bits, is how a computer would typically

represent the number 0.

And if that same computer
uses all 8 of its bits,

its full byte, to change it to 1--

anyone who's quick with math
or have seen this before,

how high can a computer
count with 8 bits or 1?

[INTERPOSING VOICES]

Yeah, 255.

Why is that?

Well, we're not going to turn this
into a constant math exercise.

Indeed, after today,
we're not really going

to think about or talk about
bits at this low level.

But this is the 1's place,
2's, 4's, 8s, 16, 32, 64, 128,

and if I do all of that math from left
to right, that indeed gives me 255.

It ignores how we might represent
negative numbers, but perhaps

more on those some other day.

But computers, of
course, do so much more

than numbers and math and
all this low level stuff.

We send text messages, write
documents, emails, and the like.

So how might a computer represent
something like the letter A?

I claim, at the end of the
day, your Mac, your PC,

your phone just has lots of
transistors, lots of switches

that it can use in units
of 8, in units of bytes.

How, though, if it's already using
those patterns of 0's and 1's

apparently to represent
numbers from 0 on up,

how do you go about representing letters
of the alphabet, might you think?

Yeah?

OK.

So we could assign a
number to every letter.

OK.

So let me just conjecture,
well, let's just

call A 0, for simplicity, B 1, C 2,
and now let me play devil's advocate.

OK, how do I now represent 0 or 1 or 2?

Well, we've maybe created
a problem for ourselves,

if now we have to steal some
numbers to represent letters.

We kind of have to pick a lane,
but there's a solution to that

too that we'll see.

And it turns out the world is
not quite as simple as A being 0.

A typically is represented, by
computers everywhere, phones everywhere,

with the number 65,
the decimal number 65.

Using 8 bits, if we turn some of the
0's to 1's, let me just stipulate,

you can represent the letter A using
8 bits, by turning certain ones on

and certain ones off, but we will
try not to focus on that binary level

too much.

So if A is 65, it turns out
that B is going to be 66,

and C is going to be 67, and so
forth, and so where does that get us?

Well, it turns out there's a whole
system that maps numbers to letters.

And here, as I alluded
to verbally a moment ago,

is the pattern of 0's and 1's
via which you'd represent 65.

And just quick check
here, we won't constantly

do math 1's place, that's easy, 2's,
4's, 8's, 16's, 32's, 64's place.

So 64 plus 1 gives us 65.

So once I do that, how do
I get to all of the others?

Well, it turns out a bunch of
Americans years ago came up with this

ASCII, the American Standard
Code for Information Interchange.

Now, what does that mean?

Well, it's just an acronym
describing what really you proposed,

a mapping between numbers and letters,
not quite as simple as 0, 1, 2.

Starts at 65, 66, 67
for capital letters,

but here are most of the letters in
use today, at least with this system.

So this is just a big chart
from online, and you'll

see in the middle of this chart,
here, here's my 65, A. Here's my 66,

B, C, and let's see, 72 is
H, 73 is I, and so forth.

So there's a mapping, at least for
English, between all of these numbers

and all of these letters.

And if we focus here, those are the
beginning of our uppercase alphabet.

So suppose then that today,
tomorrow, you receive a text message

from someone, and underneath the hood,
now that you're a computer person,

you figure out a way to see what
pattern of 0's and 1's was sent.

In this case, it's wireless
as opposed to wired,

but it's still some
pattern of 0's and 1's.

And your phone is turning
some switches of its own

on and off to represent
that message from a friend.

Suppose that the three
patterns you received

were these three bytes,
from left to right,

spelling out a three-letter word.

Well, if we do out the math, 1's
place, 2's place, and so forth--

I'll spoil it for you.

Suppose that you received a text message
that doesn't literally say 72, 73, 33,

but you've received a pattern
of 8 plus 8 plus 8, 24 bits

that if you do out the math represent
the decimal number 72, 73, 33.

Anyone recall what message
you might have received

from the green and white charts?

Yeah?

AUDIENCE: Hi.

DAVID J. MALAN: Hi.

Yes, hi is the message, but 72,
73 gives us H and I. What's 33?

Any guesses to 33?

Yeah, over here.

Yeah.

So it's an exclamation point.

How would you know that?

Well, you really do need some
kind of cheat sheet, a.k.a.

ASCII in this case.

And if we look elsewhere-- let me
highlight the left of the chart--

you can see that next to 33 in decimal
is indeed the exclamation point.

So back in the day, a bunch
of humans got in a room,

decided that, hey, when we start
building PCs and later Macs and phones,

we all just have to agree on this
form of representation of letters

of the English alphabet, in this case.

We just need to agree on this mapping.

But somewhat curiously, notice this.

It turns out that, once you
paint yourself into this corner

and start using 65
for A, 66 for B, well,

how do you represent 65 the
number and 66 the number,

if you want to do math or use
Excel or something like that?

Does anyone see the solution, perhaps?

How do you represent
the number 1 in ASCII?

Yeah, in the middle?

AUDIENCE: [INAUDIBLE].

DAVID J. MALAN: Yeah.

So this is getting a little
maybe inception or something,

but you could represent
numbers with other numbers.

And so if you want to
represent the number

you and I know as 1, like when
you type it on your keyboard,

turns out the computer stores
that as the decimal number 49.

If you hit 2 on your keyboard, the
computer is not storing 2, per se.

It's storing the decimal number 50.

Now, thankfully, the
paradox stops there.

We just have a mapping
now of numbers to numbers.

But really, at the end
of the day-- and you're

going to learn this when we start
writing code in that other language, C,

next week-- it's just context-dependent,
at the end of the day.

Inside of your Mac, PC, and phone,
there's just all of these permutations

of bits, all of these
patterns of 0's and 1's.

And generally speaking, when you open
up a text message that you've received

from someone, it's 0's and 1's.

But obviously, if it's a text message,
the whole point of text messages

is to send text, and so those
patterns of 0's and 1's, by default,

will typically be interpreted
as letters of the alphabet.

So you won't see 0's and 1's.

You won't see decimal numbers.

You'll see the English message
that your friend intended.

By contrast, if you open
up something like Excel,

that same pattern 0's zeros and 1's
might indeed work out to be 72, 73, 33.

You might see cells in your spreadsheet
with literally those three numbers.

Why?

Because spreadsheets are
all about numbers and number

crunching and math, in many cases.

If by contrast, you open
up Photoshop and try

to look at that same pattern of 0's and
1's, it's not going to be 72, 73, 33.

It's not going to be 0's and 1's.

It's not going to be hi.

It's going to be some
color of the rainbow.

You're going to use those
patterns of 0's and 1's, it

turns out too, to represent colors.

And indeed, so long as you and
I just agree, as humans long

have, what these patterns are
going to be, all of our systems,

many of our systems nowadays
are indeed interoperable.

But I'm being very biased here,
and indeed, the A and ASCII

is very American-centric.

What do you not see in this chart?

If you speak any other
language than English,

odds are, you're not seeing
characters you know and love and need

every day to type or send messages.

Well, there's a huge
character set that's

not supported here, whether
it's accented characters

and a lot of Asian alphabets.

You have many more symbols than
can fit even on this screen here.

And so humans kind of painted themselves
into a corner, early on, or really,

Americans did.

But on a typical keyboard, US
English keyboard, yeah, you

have A's and B's and C's,
uppercase and lowercase,

but you also have
accented characters here.

And nowadays, not sure if this
is maybe necessary, but nowadays,

you have other characters on
your keyboard, like these.

And these are a playful
incarnation of what's actually

a technical solution to this problem.

If I claim for the moment that ASCII
historically used 7 bits to represent

letters-- and let's just
round that up to a byte--

8 bits to represent letters, ASCII
can represent as many as 255,

or really 256, total characters.

Why 256?

Well, if you have them all 0,
that's 0, and the highest number

I claimed a moment ago was 255.

So that's 256 total possibilities.

That's not many letters.

It's fine for English, but
not a lot of human languages.

So what might the intuitive
solution be, if you

want to represent accented characters,
Asian characters, emoji, even

like these, which are just
keys on a keyboard nowadays?

What's the intuitive
solution, if a byte's too few?

Yeah?

AUDIENCE: Add another digit.

DAVID J. MALAN: Yeah.

So add another digit.

Just like we had a 4th volunteer
come on up to give us a 4th bid,

let's just throw hardware at the
problem and use a few more bits.

So maybe instead of 1 byte, let's use
2, or heck, let's use 3 or 4 bytes.

Even though it's getting
a little expensive--

we're going from 8 to
16 to 24 or 32 bits--

that's how computers
do things, these days.

And thankfully, we have so much memory
inside of our computers and phones,

we can certainly spare a few
to represent these things.

And the solution then to ASCII
is what we'll call Unicode.

So Unicode is also just a
mapping of numbers to letters

but in many different languages.

And indeed, the Unicode
Consortium is a bunch

of people from all different companies--

a lot of different companies and
countries and cultures whose mission,

as an organization, is to capture
digitally all forms of human language

in this case.

And to ensure that especially smaller
demographics of humans speaking

lesser-known languages are nonetheless
represented and preserved digitally

using some mapping of these 0's and 1's.

It turns out, though, if you start
using 32 bits, as many as 32 bits,

to represent characters on a keyboard,
that's 4 billion possible permutations

of 0's and 1's.

That's way more than we need
for most human languages.

So there's a little bit of room in there
for some of those more playful things,

like those emoji.

So for instance, suppose you got
a text message with this pattern

of 0's and 1's.

Or if we do out the math, suppose
you receive a text message

that, if you do out the math
in decimal, is 4,036,991,106.

Anyone know what emoji
you're looking at?

It would be weird if you
do, but what is this?

Well, it turns out that,
as of this past year,

this is the most popular emoji
to be sent by many measures,

Face with Tears of Joy.

So that is the pattern that a bunch
of humans in the Unicode Consortium

decided would represent this.

But you'll notice, many of you
might have iPhones, some of you

might have Android devices
too, and sometimes, these

don't actually look quite the same.

This happens to be the current version
of Face with Tears of Joy on iOS.

On Android, it tends to look a
little something more like this,

and here is kind of a curiosity.

Even though you and I look at these
things and they look like images,

they're not images.

They're characters, at least as
we've defined them now in Unicode.

And iOS and Android and Windows and
Facebook and other companies and apps,

nowadays, really just have
different fonts, if you will.

So just like fonts with
English and other languages

can give you different
characters with serifs or not,

emoji are themselves, yes,
drawings that someone made,

but they're really just a font.

And so that same pattern of 0's and 1's
might just render slightly differently

on someone's phone or another.

If you've ever gotten like an
icon on your phone that's broken,

and you've been sent an emoji, but it's
like a square or something arbitrary

and not sensible, it might
just mean that you have not

updated to the latest
version of iOS or Android,

which just updates the
font of supported emoji.

Because those folks at
Unicode, pretty much every year

nowadays, are adding more and more
emoji to that particular character set.

Now, I went down the rabbit hole of
figuring out the other day just which

are the most popular emoji these days.

On Twitter specifically, this past year,
the most popular emoji, by contrast,

was Loudly Crying Face.

I don't know if that says more
about 2021 or about Twitter,

but you'll see different trends,
certainly, in how these are used.

But even humans themselves didn't
necessarily think two steps ahead,

and now a lot of the emoji
are the default yellow color.

But there's a lot of emoji that
aren't these cartoon characters,

but they're meant to represent
humans in various professions

or gestures or the like.

And nowadays too, you've probably
noticed on your phone and Macs and PCs,

there are different skin tones that
you can assign to certain emojis.

If it's supported by the
company and by Unicode,

you can actually touch and
hold on a certain emoji,

and then you can choose
the appropriate skin tone

to represent yourself or someone else.

And that then modifies the display.

Well, let's just think
for a moment here,

how did Apple and Google
and Microsoft and others

go about implementing support for
emoji with different skin tones?

How could you do this?

If you want to represent some
smiling emoji but in five,

in this case, different skin
tones, you could come up with what?

Five different patterns that
are identical, structurally,

except for the skin tone
used in places in that image.

But that's a little inefficient to just
do copy, paste, paste, paste, paste,

and change the color in
Photoshop, if you will.

That's going to use more bits, more
information than you might need to.

How else, if you now start
to think a little bit more

like a computer scientist, if at
the end of the day, all you have are

0's and 1's, how else could you
implement skin tones, might you think?

Yeah?

AUDIENCE: RGB.

DAVID J. MALAN: OK.

So RGB, we'll come to
that in just a moment.

That stands for Red, Green, Blue.

That's one way.

In this case, though, I'm
seeking an alternative

to just using five different patterns of
0's and 1's to represent the same emoji

but different skin tones.

So not quite RGB.

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: OK.

So store one copy of the emoji and then
store different variants of the color

that you want to assign to that emoji.

Yeah.

So this is actually an example
of-- do you want to elaborate?

AUDIENCE: You could use a loop.

DAVID J. MALAN: OK.

So you can use a loop to
actually output these things.

More on that in a moment.

Let me go down this
road for just a moment.

This would be in some sense a
better design, if you will, but why?

Yeah?

AUDIENCE: A filter?

DAVID J. MALAN: OK.

So filter, if we think of
in the Instagram sense.

You can change the color of something,
and that could be related here too.

AUDIENCE: Could it be
another font [INAUDIBLE]

DAVID J. MALAN: Oh, interesting.

So maybe it could be just a
completely different font.

And you have five different
fonts that are almost identical,

except for the various interpretations
of skin tone for those same emoji.

Let me spoil.

I think if we go down
this one particular road,

the way the Unicode folks decided
to do this some years ago where

the first byte or bytes that
you receive via text or email

just represent like the structure of
the emoji, the default yellow version,

thereof.

But if it's immediately followed
by a certain pattern of bits

that these humans
standardize to represent

each of these different shades of
skin tone, then the phone, the Mac,

the PC will change that default
color, yellow in most cases,

to whatever the more apt human tone is.

So you just use twice as many bits, but
you don't use five times as many bits.

So what do I mean?

You don't have five completely
distinct patterns, per se.

For each of these possible
variants, you have a representation

of just the emoji itself,
structurally, and then

reusable patterns for
those five skin tones.

Unfortunately, that wasn't quite
versatile enough for other features

that were in the pipeline,
and nowadays too,

and there's a double meaning
now to representation.

Emojis intended to focus on certain
professions, and early on too,

were certain professions associated
with certain genders and vice versa.

And you couldn't necessarily
be one gender or another,

in a certain profession or another.

There were these combinatorics
that just weren't possible.

But nowadays, as you
might have seen, you

can have couples in
love for instance that

actually look a little more like three
emojis, but just kind of combined

into one.

And indeed, this is just
one key press on your phone,

and you can combine different emoji
on the left and then the right

with the emoji in the middle.

And so it turns out
how computers nowadays

represent these patterns are one set
of bits for the character on the left,

one set of bits for a
character on the right,

one set of bits for whatever
emoji you want in the middle.

And then you assemble more
complicated compositions of emoji

by just reusing those same
patterns and bits and bits.

The Unicode folks don't have to come
up with a whole new representation

for some very specific incarnation.

They can create one
for person, for male,

for, female for other characters
that you might want to display,

and reuse those same
patterns of 0's and 1's.

And so here, you see the
imperfection, of or lack

of foresight, of humans for
building a system early on that

was entirely American-centric, no
characters, emoji, or the like,

that's evolved too.

And so that's an important
detail in computing, nowadays.

It too is evolving, and
the languages you're

about to learn in the coming days,
those too are evolving as well.

And new features are getting added,
and even programming languages have

version numbers.

You might have a different
version of an app on your phone.

Programming languages too have
different versions as well.

Questions then thus
far on how information

is represented using ASCII or
Unicode or anything in between?

Yeah?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Oh, good question.

So to recap, why can't you just--

well, let me summarize
that as why can't you

similarly use different patterns
to change the context of what

these patterns of bits
represent, whether it's

a number or a letter or a graphic?

In actuality, that's kind of what's
happening underneath the hood.

It's not standardized in quite the
same way, but starting next week,

when we transition from scratch to C,
you'll learn about types, data types.

Where the onus initially is going
to be on you, the programmer,

to tell the program whether
or not this pattern of bits

should be interpreted as
a number or as a letter

or as a color or something else.

Nowadays, though, and toward
the end of the semester,

you'll use languages, like Python,
where the computer just figures it out

for you by context, which makes it even
easier and faster to program as well.

Other questions on
Unicode, ASCII or the like?

All right.

Well, how about just a few
other forms of information?

RGB was called out
earlier, Red, Green, Blue.

How do images get
represented in computers?

Well, in fact, it's typically an
assembly of some amount of red,

some amount of green,
some amount of blue,

but there are other representations.

If you're a graphic designer,
you might know them,

but RGB is still pretty common.

What does this mean?

This means to represent every
dot on your phone or every dot

on your TV or your
laptop or desktop, there

is a number representing how
much red that dot should show,

a number representing how much
green, and a number representing

how much blue it should show,
red, green, blue, respectively.

So for instance, if a
dot on your screen were

using these three numbers, these
three values or bytes, 72, 73, 33,

in a text message or email, that would
be interpreted as I claimed "High."

But in Photoshop or in
some graphical program,

that same pattern would
be interpreted as let's

call it a medium amount of
red, a medium amount of green,

and a little bit of blue.

And why medium and little?

Turns out, each of these are bytes, the
smallest value you can have in a byte

we said is 0.

The largest value you
can have a byte is 255,

so I'm just kind of spitballing here.

This is like medium, medium, and
a low amount of red, green, blue,

specifically.

Those three colors, like wavelengths
of light, are combined in such a way

that you would have this dot on
the screen, a sort of murky shade

of yellow or brown.

That is how a computer would
store precisely that color,

and in fact, we've seen this color.

When you type in Face with Tears
of Joy, generally, on your screen,

it looks like this,
typically much smaller.

But let's zoom in, or let's
Zoom in a little more.

What are you starting to
see, if you know the term?

AUDIENCE: Pixels.

DAVID J. MALAN: So pixels,
it's getting very pixelated.

A pixel is just a dot on the screen,
and if you really zoom in on it,

you can literally see all of
the dots that compose an emoji,

in this case on iOS, in the font
that Apple is using to represent this

particular pattern of 0's and 0's.

So one of those yellow dots-- and
there's many of them all kind of blend

together here--

each dot on the screen
I claim is 3 bytes.

How much red, green, blue for this dot?

How much red green blue for this dot?

How much red green blue for this dot?

And you'll notice too, that when it
gets to be sort of brownish here,

the dots really stand out.

The 3 values, the 3 bytes, a.k.a.

24 bits, are just slightly different.

And so underneath the hood,
this is why images, photographs

that you take or gif that you
download, get so darn big,

potentially, because you have a number
representing every dot on the screen.

Well, if this I claim is
indeed how images are typically

represented, using
pattern of bits that are

assigned to some amount of red,
green, or blue, how do you get video?

What is a video, if at the end of
the day, all we have are 0's and 1's?

What's a video, perhaps?

Yeah?

Let's go here, way in back.

Yeah.

Pixels really changing values over time.

and do you want to confirm or
deny, the hand that went up here?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, or
equivalently, a sequence

of images that, over time,
are changing on the screen.

So both of those are
valid interpretations,

and just for fun, if you grew
up with these picture books,

you might remember a
little something like this.

if we could dim the lights?

[MUSIC PLAYING]

So that's the old school
analog way to implement

a video, in the sense that that artist
wrote out like hundreds of pieces

of paper, with almost identical images,
but where the ink from their pencil

or pen was slightly moving.

And if you digitize that, such
that each of those strokes

are represented with dots instead,
that's really what you're seeing

is a sequence of all of these
images flying across the screen.

And if we dive into the real world,
if you've ever watched a film,

a Hollywood movie is typically
24 FPS, Frames Per Second.

That really means you're seeing 24
images per second, or on TV or in soap

operas, it's often 30 frames per second.

That makes things look
a little more smooth.

So it's not actual motion
picture, if you will.

It's sequences of pictures,
and your brain and mind

are interpolating that, oh, this is
smooth movement, even though we're just

seeing a lot of pictures really fast.

Now, that gets really big, and
we'll talk later in the semester

how you can compress information,
so that you're not using way

more bits than you actually need to.

And there's fancy algorithms
that folks have developed,

but at the end of the day,
that's really all a video might

be is a sequence of images.

Conversely, if you want to
represent the music that

accompanies that or something else,
if any of you play an instrument

and can read sheet music,
how could you digitize this?

[PIANO MUSIC]

Like how could you represent
musical notes in a computer?

You and I hear them when
we play files, but what's

really going on underneath the hood?

Any musicians, piano players?

Anyone?

Yeah?

AUDIENCE: Hertz value?

DAVID J. MALAN: OK, so Hertz
value, so some frequency.

So sound is some frequency, and
it's kind of hitting your eardrum.

And that's what makes it sound low
or high or somewhere in between.

So maybe we could assign, just like
there's letters A through G here,

maybe we could assign specific
frequency values, which

are just going to be numbers
measured in something

called Hertz, something per second.

And maybe we could have a few other
numbers for each of these notes,

not just the note or the frequency.

Maybe, we could represent the
loudness of it, like how hard

or how softly a human might
equivalently press it.

Maybe a third number, like
duration, like how long

is there finger on the keyboard?

So you can imagine quantifying something
like music that in the real world

is perfectly continuous as
something more discrete,

by representing each note over time
as just some sequence of values.

And there's so many different ways
to do this, MIDI, if you've heard,

mp3's, AAC.

Almost all of the file extensions
you see on your Mac or PC,

if you see them at all,
ultimately just mean

there's a different form of
representation for, in this case,

something like sound.

So let me just stipulate,
there are these and many more

ways to represent inputs and
outputs, and thankfully, humans

have standardized a lot of this.

They don't always agree,
and this is why we

have different file
formats for Apple numbers

and Microsoft Excel
and Google Spreadsheets

and stupid incompatibilities like that.

But generally speaking,
humans have standardized

how we represent the inputs and
outputs to and from problems.

But let's now focus on this
Black box, so to speak,

in the middle, this abstraction.

So abstraction is technically
a term that you'll

see all over the place
in computer science,

and really, problem
solving, that just refers

to the simplification of something,
so that you don't focus on the lower

level implementation details.

You really just focus on the high
level goals or the process itself.

Therefore, your car,
if you have a license

and have driven or have been in a car,
a car, so far as you're concerned,

is probably an abstraction.

Most of us, if you're like
me, probably don't really

know or care how the engine works
and all the parts that are moving.

To you, it's just a way
of getting from point A

to point B. It's an abstraction,
but someone, hopefully the mechanic,

does know those lower level
implementation details.

If you had to understand how
a car works every time you

want to go to school or to
the store, it's probably

going to be a pretty slow process.

You just want to think and operate
at this higher level of abstraction,

and we're going to do this all the time
when writing code and solving problems.

So what then is in this black box,
this abstraction at the moment?

Well, generally, it's
what a computer scientist

would call an algorithm, step-by-step
instructions for solving some problem.

Now, let's consider the
implementation details,

that is to say how you might
solve certain problems,

and let's take a old school
example but in modern form.

This icon, if you have an iPhone, is,
of course for your contacts application.

And if you've got a whole bunch
of family members or friends

or colleagues in your
phonebook, you have

some kind of contacts pictured here,
and it's alphabetized typically

by first name and last name.

And odds are, you and
I are in the habit,

if they're not already a favorite,
of like clicking on Search

and then using autocomplete.

And what happens when you
start typing autocomplete?

Well if you type in the letter
H, you'll see only, presumably,

Hagrid, Harry, Hermione, and so forth.

If you type in H-A that shows
you only Hagrid and Harry,

and it all happens super fast.

So how is that happening?

Well, typically, you could just start
at the top and look to the bottom,

searching for all of the H's or all
of the H-A's, but for larger data

sets that's going to get slow.

For the Googles of the world,
that's going to get really slow.

And even on our phones when you have
hundreds, thousands of contacts,

eventually, even that kind of
approach, that algorithm step by step

it might be slow.

So how might we go about searching
for someone in a phonebook

like this, like say John Harvard?

Well, here's an old school
incarnation of this,

and odds are, you might not have
had occasion to even physically

use this thing, nowadays.

And in fact, this is
a bit of a white lie,

because this is the
yellow pages, which means

this is a book of companies not people.

But this is all you can find, and at
that, it's even hard to find this.

But this is the same thing in
analog form, physical form.

So if I wanted to search for someone
like John Harvard, how could I do that?

Well, I could start
on page 1, and I could

start searching for page
2, page 3, page 4, page 5.

A little hard to do
physically, especially since no

one's used this phone
book in a lot of years.

But is this algorithm correct, turning
page by page, very inelegantly?

Is this correct?

Will I find John
Harvard, if he's in here?

All right.

So yes.

This is a little stupidly tedious,
because if there's like 1,000 pages,

he might be a few hundred pages
into this, but it's correct.

At some point, I will find him, and if
he's on the page, I'll be able to call.

Why?

Because presumably, the names
are alphabetized in here,

and there's no cheat sheet on the edge.

So I have to search for John Harvard
from left to right, searching for H,

if it's alphabetized by last name.

Well, what would be marginally better?

Well, how about two pages at a time?

It's hard to do with a
20-year-old phone book,

where the pages are grown
together, but 2, 4, 6, 8, 10, 12.

This algorithm, is this correct?

AUDIENCE: No.

DAVID J. MALAN: All right, so no.

Why?

AUDIENCE: You're skipping pages.

DAVID J. MALAN: Yeah.

So I'm skipping every other page.

So if I don't consider that, and I find
myself in like the I section or the J

section, well, I might
accidentally conclude,

nope, I haven't found John Harvard yet,
just because I skipped him, because it

was sandwiched between two pages.

Now, I can fix this, I think,
if I do hit the I section,

well, let me just double back one page,
just in case he was in that last page.

So it's recoverable, but it's almost
twice as fast, minus that hiccup there.

But what most of us would
do, and what your phones

are doing, albeit
digitally, is they open up

roughly to the middle of the phonebook.

And they look down, and they say,
oh, I'm in roughly the M section.

So I'm roughly halfway through
the 1,000-page phonebook.

But what do I now know
about John Harvard?

Where is he, to my left or to my right?

All right.

So alphabetically, he's
presumably to my left,

and so here I can, both
metaphorically and physically,

tear the problem in half.

You don't need to be impressed.

It's really easy down
the spine that way,

but I know that John
Harvard is to the left here.

But now I can throw, unnecessarily
dramatically, half and page one out

of the way, and what do I now know?

I've gone from 1,000 pages to like 500.

I can repeat roughly the same algorithm.

Go to the half of this, and so this
time, I went back a little too far.

I'm in now the E section.

So what do I know?

Is John Harvard to my
left or to my right?

To my right, so I can, again,
tear the problem in half.

Throw this half away, and
now I'm really flying.

I'm doing it verbally slowly, but
that went from 1,000 pages to 500

to now 250.

And now I can do it again, 125.

I do it again, roughly like 67, and
keep doing it again and again and again,

until I get left with, hopefully,
just one single page or in this case

an ad for, ironically, a mechanic.

OK, so what is the implication
for our performance?

Well, let's just do this sort
of in the abstract, if you will,

if that first algorithm were to
be plotted just quickly on a chart

without even numbers.

Here's my x-axis, size
of problem on the x-axis.

So the bigger the problem,
the farther out that way.

Time to solve the problem.

The higher you go up on the y-axis, the
more time you're taking to solve it.

How would we draw the running
time, the amount of time

taken to run that first algorithm?

Well, it's going to be a straight line.

Why?

Because if you add one
more page next year

because more people move
to Cambridge, you're

going to add one more
page turn potentially, so

one more second, one more unit of time.

So it's a straight line.

And we'll abstract it away as "n."

If there's n pages in the phone
book, the slope of this line

is essentially n.

The second algorithm, wherein I
was doing two pages at a time,

was twice as fast, but
it's still a straight line.

And in fact, let me just
draw some dotted lines here.

If the phone book is this
big, with my first algorithm,

it might take this many units of time,
this many steps, this many page turns.

But with that second algorithm, notice
that the intersection is much lower

on the yellow line than on the red.

So n over 2 means there's
half as many pages here,

if n is the number of pages.

So indeed, that algorithm--
the second one--

is twice as fast minus the little hiccup
that I have to double back one page.

But that's not a big deal if I'm
still doing things twice as fast.

But the third algorithm looks
fundamentally different.

It looks like this.

Logarithms, if you recall
from high school or prior--

if you don't, that's fine too.

It's just a fundamentally different
function, a different shape.

And notice that the
green line is going up

and up and up but a much slower rate
of increase, which means crazy things

are possible.

If two towns in Massachusetts,
like Cambridge and Allston,

across the river, merge next year, for
instance, in terms of their phone book,

they're phone book
just got twice as big.

For the first algorithm, that's
going to take me twice as many steps

to go through.

The second algorithm, almost it's
going to take me 50% more steps

to go through, two at a time.

But the third algorithm, that I ended
with, tearing things again and again,

dividing and conquering, if you will,
in half and in half and in half,

how many more steps
will my third algorithm

take if Cambridge and Allston merge
into a phone book that's twice as big?

AUDIENCE: Four steps.

DAVID J. MALAN: Just
one more step, right?

No big deal.

You just take a really big
bite out of the problem

once you decide if John Harvard
is to the left or to the right.

And so you've made much faster progress.

And so this, in essence, is
what your computer, your phone

is probably doing underneath the hood
when searching for Harry or Hermione

or Hagrid or anyone else
because it's that much faster,

especially when you have large data.

If you don't have that
many contacts, it probably

doesn't matter if you search
from top to bottom or more

in the form of this
divide-and-conquer algorithm.

But if you're the Googles of the world
or you're analyzing large data sets,

indeed, this is going
to add up quite quickly.

So where do we go with this?

Well, we're going to introduce
next something called pseudocode.

How can I translate what
I did verbally there,

sort of intuitively, to actual code?

Well, this won't be Scratch.

This won't be C or Python just yet.

It's just going to be
an English-like syntax.

And this is how many programmers
would start solving a problem.

They don't start typing out
code in C or Python or the like.

They use English or whatever
their human language is

to jot down an outline for their ideas.

My first step, really, was
picking up the phone book.

My second step was opening to
the middle of the phone book.

My third step was somewhat different--
look at the page, because why?

My fourth step was if person I'm looking
for is on the page, I then do what?

It never happened in my
example, but I call the person.

So I'm done.

Else if the person is
earlier in the book

alphabetically, as John Harvard
was in the case of my H, then

I should search to the middle
of the left of the phone book.

And then I should go back to step three.

Step 3 is look at the page,
thereby repeating the same process

again and again.

Step 9, though, might be else if
the person is later in the book,

then let's go ahead and open to the
middle of the right half of the book

and then go back to line 3.

Else there's a fourth scenario
we should probably consider,

lest my search process freeze or crash
or give me one of those spinning beach

balls with a bug.

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, what if John
Harvard isn't in the phone book?

I'd prefer that my algorithm, my
phone not just reboot or freeze.

I should handle that with
some kind of catch all.

Else, so to speak, let's
just quit the program.

So there's well-defined behavior for
every possible scenario of the four.

Now, let's call out a few
of these salient terms.

It turns out, if I
highlight in yellow here,

there's a pattern to what
I've been doing here.

These are all of my English verbs.

And in a moment, we're going to start
calling those verbs "functions."

When you program or write code and
you want the program or the computer

to do something for you,
some action or verb,

we're going to refer to
those actions or verbs

as these things called
"functions," like those here.

By contrast, I've just
highlighted, instead,

my "if," my "else if,"
my "else if," and "else."

This is going to
represent what we're going

to start calling a "conditional,"
a proverbial fork in the road where

you can either go this way or that
way, do this thing or this other thing.

And you're going to decide
which of those things

to do based on what I've now
highlighted here, which are going

to be called "Boolean expressions"--

Boole, referring to a
mathematician, last name Boole.

A Boolean expression is just a question
with a yes/no, a true/false, a 1 or a 0

answer, if you will.

And it governs whether you do this thing
or this thing or this thing or that.

The indentation, in
this case, is important.

The fact that I've indented line 5
implies, by convention in programming,

that I should only do line 5 if the
answer to line 4 is a yes or a true,

and same for these other
indented lines as well.

And the last characteristic
here is this here.

Someone called this
out earlier, in fact.

These lines, 8 and 11, are now
highlighted and represent what?

What might we call these
in code if you've done--

yeah, so these are loops,
some kind of cycles

that result in my doing the
same thing again and again,

but there's a key detail with
this algorithm in pseudocode.

Even though it's telling
me to go back to line 3,

why is this algorithm
eventually going to stop?

Why do I not constantly keep
looking for John Harvard

forever by nature of these loops
telling me to keep going back to line 3?

Good.

Eventually, he'll be on the page or, to
your point earlier, he won't be at all

and we're out of pages,
and so we just quit.

And that's the key about going to
the left half or the right half.

It doesn't matter if you do
the same thing again and again.

You're not going to get stuck
in a so-called infinite loop

so long as you keep dividing the
problem and shrinking it into something

smaller, smaller, smaller.

Eventually, there's going to
be no problem left to solve.

So even if you don't think of
yourself as a computer person,

even if you've never written code,
what you'll find in the coming days

is that these ideas that we've just
kind of harnessed from real life

are at your fingertips already.

And a lot of the process
of learning to code

is just going to be
some bumps in the road

because you can't quite see the
new syntax in a familiar way.

But you'll find that
the ideas, in fact, are

going to be more familiar than
you might otherwise think.

And so we'll see in a bit--
and we'll take a break

in a moment to take
a breather-- that you

will see these same ideas in a
moment in the context of Scratch,

an actual programming language
via which we'll drag and drop

puzzle pieces to make actual code work.

We'll see some variants
of these ideas, things

called "arguments" and "return
values" and "variables."

But we'll ultimately convert
it into this somehow.

Anyone want to wager
what this program will

do if fed to your Mac or PC or phone?

Here's just a massive
pattern of zeros and ones.

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: It will indeed say,
rather disappointingly, apparently,

just, "Hello, world."

And indeed, baked into all of these
0's and 1's are not just the H-E-L-L-O,

but also the verbs, the action of
printing something to the screen.

And there's other stuff too so
that the program knows how to start

and how to stop, a lot
of stuff that we won't

have to worry about, that whoever
designed the computer or the language

did.

But at the end of the
day, you're never going

to be writing the 0's
and 1's yourselves,

though our ancestors, once
upon a time, did in some form.

We'll be using a much higher-level
language, like this in C,

or better yet, in just a moment,
like in Scratch, like this.

And indeed, this is why
today we focus on and begin

with Scratch, this graphical
programming language,

so we have a way of expressing ourselves
with functions, conditionals, loops,

and more, but in a way that doesn't
have stupid parentheses and curly braces

and all of these visual
distractions in the way

and will translate that thereafter
to this lower-level language.

But for now, that was a lot.

That was definitely a fire hose.

Let's go ahead and
take a 10-minute break.

Feel free to get up or stay here.

And we'll resume in a bit
with some actual code.

[VIDEO PLAYBACK]

[MUSIC - THE WEATHER GIRLS, "IT'S
RAINING MEN"] [MUSIC PLAYING]

[THUNDER RUMBLING]

- (SINGING) Hi.

Hi.

We're your Weather Girls,
and have we got news for you.

You better listen.

Get ready, all you lonely girls.

And leave those umbrellas at home.

All right.

Humidity is rising.

Hmm, rising.

Barometer's getting low.

How low, girl?

According to all sources--

what sources, now-- the
street's the place to go.

We better hurry up.

'Cause tonight, for the first
time, just about half-past 10:00--

half-past 10:00-- for the
first time in history,

it's going to start raining
men-- start raining men!

It's raining men, hallelujah!

It's raining men, amen!

I'm going to go out.

I'm going to let myself
get absolutely soaking wet!

It's raining men, hallelujah!

DAVID J. MALAN:
[CHUCKLES] All right, so--

[END PLAYBACK]

[APPLAUSE]

So this then is Scratch, a graphical
programming language from our friends

down the road at MIT's Media
Lab that indeed some of you

might have used in grade
school or the like,

for playing and writing
code and the like,

but you maybe didn't necessarily think
about how some of these primitives

ultimately worked.

And in fact, everything you've done--
if you've used Scratch before--

and everything you'll see today is going
to apply to all of the weeks to come,

as we explore these
things called "functions"

and "loops" and "conditionals,"
"Boolean expressions" and more.

With Scratch, because it's so
graphical and animated-congruent,

can you create animations, like this
one, interactive art, and software

more generally.

But you'll do so by
dragging and dropping

puzzle pieces that only lock together
if it makes logical sense to do so.

And you won't have to deal with,
in this first week of class,

is curly braces, parentheses,
all of the weird symbology

that you might recall seeing, when we
just wanted to say, "Hello, world."

Now, this particular
program, "Raining Men,"

was written by a former CS50
teaching fellow, Andrew Berry,

who's actually now the general
manager of the Cleveland

Browns, the American football team.

And so these are just
some of the programs

that some of your predecessors
in the class have created.

And you'll see, in the remainder
of class here, a couple of others

as well, and more in the course's first
assignment, namely, problem set zero.

So how do we get there?

Well, first a quick tour of
what it is we're going to do.

This, in Scratch, is perhaps the
simplest program you can write.

And even if you've never seen Scratch
or any programming language before,

you can probably guess that this
just says, on the screen somehow,

"Hello, World."

But what you don't have to do is type
esoteric commands and weird syntax,

those curly braces and
parentheses I keep alluding to.

You just drag this yellow puzzle piece.

You drag this purple puzzle piece.

Let them magnetically lock
together, so to speak.

Click a button and boom.

With those same building
blocks and several others,

can you make exactly the sorts of things
that Andrew brought to life as well.

So here's what we're about to see.

At Scratch.MIT.edu is a cloud-based
programming environment on MIT servers.

You can also download it
offline on your own Mac or PC.

And it gives you an interface like this.

On the left-hand side of the
screen, you'll see a blocks palette.

These puzzle pieces, a.k.a.
blocks, come in different colors

which rather categorize them.

So pictured here, for
instance, in blue, are

a whole bunch of motion-related blocks.

So Andrew used a whole bunch of
those to have the singer and the men

moving around on the
screen in synchronicity

with the song that was
playing in the background.

Meanwhile, in the middle of this
interface is going to be the code area.

And this is where Andrew, and
soon you, will drag and drop

some of those puzzle pieces
and other colors as well

and lock them together to
get your character-- soon

to be invented-- to do
something on the screen.

Indeed, at the bottom right
here, will you see, ultimately,

a sprite area, where a
sprite is a technical term

for like a character in a video game
or a programming environment like this.

By default, historically, Scratch
is the cat, the mascot, if you will,

for this programming environment.

And so here we see, by
default, just one sprite

selected because on the top right of
the screen is the stage for that sprite.

And you can click and zoom
in to make it full screen.

But this is the world in which Scratch--

by default, the cat-- will live.

But you can change Scratch's costume so
that it looks like a singer or the man

falling from the sky or
the like or anything else,

either creating the art yourself or
importing some of the things that

come with it or elsewhere online.

So what is this world that
Scratch rather lives in?

Well, generally speaking, we won't
have to care too much about numbers

because we'll be able to ask
questions, like interactive ones,

like is Scratch the
cat, or any character

otherwise, touching the edge of the
screen, touching something else?

But Scratch does exist in this
two-dimensional coordinate-system

world.

So when the cat or any character
is dead center in the middle,

that would be xy location
0,0, if you will.

Meanwhile, over here is 240 pixels,
or dots, all the way to the right.

So this would be 240,0, where y is 0
because it's right on that midline.

So it's neither up or below.

Over here to the left, of
course, would be -240 and 0.

Above the cat would be
x equals 0, because it's

right on that vertical midline, and 180.

And then down here, as you might
guess, would be 0, negative 180.

Generally speaking,
we don't have to care

about those precise pixel coordinates.

But it's helpful, ultimately, if you
do want the cat to move up, down, left,

or right.

Having some sense of direction
according to the x-axis and y-axis

as well can help you express
your ideas, ultimately.

So what might some of those ideas be?

Well, let's do this.

I'm going to go ahead and
create, on Scratch.MIT.edu, just

an empty screen like this one here.

And so this is the exact same interface.

But now I'm in my browser, full screen,
so that I can start writing some code.

And let's get that cat to say
something actually on the screen.

Now, this takes a
little bit of practice.

But honestly, just by scrolling
through these puzzle pieces can

you quickly get a sense of what's
possible, not just categorically,

but specifically.

And I'll jump around because I've
done this, of course, before.

But I'm going to go to
events, in yellow, first.

And I'm going to drag and
drop this first block, called

when Green Flag clicked.

And I've zoomed in there just to
make it a little more legible.

And notice that the
shape of this Green Flag

just so happens to mirror
this Green Flag here

at top, next to this
red Stop Sign, of sorts.

And the Green Flag is going to
mean go and the red Stop Sign

is going to mean stop, to
start or stop our program.

Next week, you're going to be writing
a textual command at your keyboard

to do the exact same idea.

But for now, it's a button.

So when Green Flag clicked,
what do I want Scratch to do?

Well, how about we have Scratch just
initially say something like, "Hello,

world," which indeed,
historically, is the first program

that most any programmer might write.

So anything related to what
the cat looks like it's doing

is actually going to be
under looks, here in purple.

So I'm going to drag over Say "hello."

And you'll notice something curious
and different about this purple block.

It says, of course, "Say" in purple.

But then there's this white oval and
some text that, by default, is "hello"

because MIT just decided that,
by default, the placeholder will

be "hello."

But anytime you see
this white oval, it's

an opportunity to provide an input
into the function called Say.

And so here I'm borrowing
terminology from before.

Problem solving, again, is all
about inputs producing outputs.

And in between there is some algorithm.

In a moment, we're going to
start referring to algorithms

quite frequently as "functions."

Why?

Because it's the implementation
of some algorithm.

So let me override the
default with, "Hello, world."

I'll zoom out.

And now if I go to the top right of
the screen and click the Green Flag,

we'll see, hopefully, my
very first program in code.

Now, it wasn't a huge lift, right?

It only was a matter of dragging
and dropping puzzle pieces.

But what has now happened?

Well, it turns out that
two things have happened.

When I, the human, clicked
on that Green Flag,

I triggered, what we're going to
start calling now, an "event."

An event is generally something
graphical or interactive that

just happens in a computer program.

You and I trigger events
on our phones all day long.

Whenever you tap or drag
or long press or pinch

or any of those gestures in
vogue nowadays on phones,

you are triggering events.

And people at Apple and
Google and elsewhere

have written code that
listen for those events

and do something when
that event happens.

That's what I just did.

When Green Flag is
clicked, I want something

to happen, namely, I want this purple
function, this verb, this action called

Say, to do something.

What do I want it to do?

I want it to say what this input is.

And I'm going to introduce
another vocabulary term.

The white ovals here are,
yes, inputs, very generically.

But in a programmer's
terminology, they're

called "arguments," otherwise
known as "parameters."

And that just means
an input to a function

that modifies its behavior in some way.

When I click Stop, that's
just another event.

And that one is just built into Scratch.

Scratch knows that when you
click the green Stop Sign,

everything should just
stop automatically.

I don't have to write code
to support that feature.

So that's all fine and
good, "Hello, world."

But if I keep doing stop and
start and stop and start,

it's going to do the same
thing again and again.

And it's really not that
interesting, at the end of the day,

maybe gratifying once, but it'd be nice
if this were a little more interactive.

So it turns out that we can do that too.

But we need a different
mental model instead.

So in this case here, when
we think about this function,

Say, in this input, "Hello,
world," this actually

maps pretty cleanly
to this model earlier,

that I propose is problem solving,
is computer science, if you will.

The input to the current problem
is going to be in white here,

"Hello, world."

The algorithm is the "say" algorithm.

Now, I don't know how MIT got it to
print out the little, pretty speech

bubble on the screen.

But they wrote those underlying
low-level implementation details.

And they gave me and you a
purple function, called Say,

that just does that for you.

You and I don't have
to reinvent that wheel.

The output of Say is another technical
term, now, called a "side effect."

A side effect is usually
something visual that happens,

like as a side effect of
you calling a function.

And so the side effect
here is that the cat

has this speech bubble magically appear,
inside of which is "Hello, world."

So we have an input.

We have an output.

We have an algorithm.

But now we're talking about these
ideas in the context of programming.

So now the input is an "argument."

The algorithm is a "function."

And the output, in this
case, is a "side effect"--

terminology that you'll
just hear more and more.

And it'll eventually sink in, but not
to worry if the terminology doesn't

come naturally early on.

So what more might I do with this?

Let me go back to Scratch here and make
this maybe perhaps more interactive

and actually get the cat to say
something a little more dynamically.

So instead of "Hello,
world," why don't we

get him to say hello to me
or to you or anyone else?

So let me do this.

Let me go under, say--

let me get rid of this first.

And you'll notice this neat trick.

As soon as you start dragging on
a block, if it gets close to it,

it kind of goes gray, and it can
be magnetically snapped together.

You don't have to do it very precisely.

Conversely, if I want to
get rid of a puzzle piece,

I can just drag it anywhere on the
left, let go, and that deletes it.

Or you can Right-click or
Control-click and a little menu

will let you delete it as well.

Well, let me do this instead.

Under Sensing, which I know is
there because I've done this before,

are a whole bunch of things related
to Sensing, whereby the cat can kind

of feel out its world, in some sense.

It can do things like ask this question,
"Am I touching the mouse pointer?"--

like the user's cursor.

"Am I touching a specific color that you
can override to be anything you want?"

"Is the distance to the mouse
pointer some specific value?"

But for now, I'm going to focus on
this, this blue puzzle piece that

asks a question, which itself is
this white oval that I can apparently

change, and then it's going
to wait for a response.

But this puzzle piece
is a little different.

It's a little special.

It comes with a freebie.

It comes with what we're going to
call, technically, a "return value."

So some functions don't just
do something on the screen.

They hand you back, so to
speak, a value that you

can do anything that you want with.

Nothing happens immediately
unless you do something

with that so-called return value.

So let me go ahead and drag this thing
over here, ask, "What's your name?"

And I'll use the default question.

That seems a reasonable place to start.

I'm not going to override that default.
And now let me go ahead and zoom out.

Let me go back to Looks.

Let me go to Say.

And let me just form the
English sentence I want.

So let me zoom in here and type
in "hello," maybe comma, space.

I could do "David," but
that's obviously not right

because I'm asking for a
name, and then I'm like,

in advance, hard-coding my name.

That's not what I want.

I just want, "hello," comma.

And now let me zoom out and
grab one more Say block.

Let me maybe Say here.

OK, I don't want to say, "Hello, hello."

I don't want to just type in my
own name because, again, then

what's the point of asking
the user for their name?

But notice this.

If I go back to the sensing block,
this is where that oval that's blue,

called Answer, is useful.

This will be the so-called
"return value" of that function.

So I'm just going to go ahead
and do this and drag and drop.

Even though it's not the right
size, it is the right shape.

And so Scratch will be
smart about it and grow

to fill that puzzle piece for you.

Let me zoom out now.

And now let me click the Green Flag.

You'll see that Scratch is indeed
prompting me with a speech bubble,

"What's your name?"

Notice the little text box below
the cat is asking, what's your name?

So I'm going to type in
D-A-V-I-D and hit Enter.

Or I can click the blue check.

Enter.

OK, it's a little weird.

I wanted him to say,
"hello," not just my name.

So let me Stop.

Let me start it again.

All right, hello, what's your name?

D-A-V-I-D. Enter.

Huh-- kind of rude.

Why is there this bug?

Like, I wanted to say, "Hello,
David," not just "David."

And yet twice it has failed to do so.

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, the
computer's processing my directions,

my actions, really quickly.

And so it actually is doing it.

It's just, you and I, in
the room, are just way

too slow to notice that it
said-- (QUICKLY) "Hello, David."

It just seems to have
just said, "David."

So all right, how can I fix this?

Well, here's where you start
to poke around and think

about how you might solve this.

Let me go back under Looks.

Maybe there's a smarter way to do this.

Maybe I could do--

OK, I could do this.

How about instead of
just Say "hello," there's

apparently another puzzle piece where I
can time it so I can maybe slow things

down a little bit.

So let me do this.

Let me throw away all of this.

Let me drag a Say "hello" for 2 seconds.

Let me drag another Say
"hello" for 2 seconds.

Let me change the first one
to, indeed, "hello" comma.

And then let me go back to Sensing.

Let me grab that same answer because
I threw it away a second ago,

and I'll just change it.

I don't even have to delete "hello."

I can just overwrite it like this.

So now I think we'll kind of pump the
brakes and see things more slowly.

Let me Stop.

Let me start.

D-A-V-I-D, Enter.

Hello, David.

OK, so it's better, like
it seems to be working.

I think your hypothesis was right,
just looks kind of stupid, right?

Like, the fact that it's saying Hello--

[PAUSE]

--David, like we can do better.

And like, literally every piece of
software on your phone or Mac or PC

is better than that.

It adds words together in the user
interfaces you and I are familiar with.

So let's go a little more fishing here.

Let me throw away these.

Let me go back to Looks and
just get the simpler Say.

I want this to say, "Hello"
comma name, where name

comes from that Answer return value.

So how can I do this?

Well, let me go under Operations,
which we haven't been before.

There's a lot of stuff in here.

Some of it's mathematically related,
adding, subtracting, and so forth.

You can generate random
numbers which might be useful.

And if I keep scrolling down, there's
this Join "apple" and "banana."

But that's just placeholder text.

You can join one piece of text
with another piece of text,

by default "apple" and "banana."

But let's change it to
"hello" and my name.

So this, too, wrong
size but right shape.

So let me let it snap into place.

Let me go ahead now
and do "hello" comma.

And now I think I just want to
go grab that Answer return value.

Let me drag the same
oval as before, clobber--

that is, overwrite-- banana.

So now I'm kind of composing functions.

The output of one
function, Join, is going

to be the input of
another function, Say.

So let's see what happens now that
they're kind of stacked on top

of each other or nested, so to speak.

Click the Green Flag, D-A-V-I-D. Enter.

"Hello, David."

All right, that was pretty fast.

Let's just do it once more.

Stop.

Start.

Here we go, D-A-V-I-D. Enter.

OK.

All right, it's not the most
exciting program in the world.

But it's more correct.

It's better designed just because
that's what you would kind of expect

the software to do and not be some
kind of lame user interface that's just

inserting random delays to just
make it kind of work, like that's

a workaround, a hack, if you will.

But there's some cool things
you can do with Scratch.

And we won't really go
down the rabbit hole

of all of the fun and
family-friendly features that it has.

But there is one that's
kind of cool here.

Let me go into the Extensions button
at the bottom left of my screen.

And this one's kind of cool.

Let me go to Text to Speech.

And you'll notice that this one requires
internet because it's cloud based.

But this just gave me some new
puzzle pieces in a new category,

Text to Speech.

And these green ones do
exactly what they say.

So let me do this.

Let me zoom out again.

Let me keep the Join block.

And I'm just going to
temporarily toss it over here.

It's not going to delete itself
because I didn't drag it over

to the other side.

But I'm going to get rid of
the Say block, in purple.

I'm going to do the Speak block here,
in green, and let it snap into place.

And then I'm going to drag and
drop this onto the input to Speak.

And now, perhaps a little
more adorably, let's try this.

Green Flag, what's your name?

D-A-V-I-D. Enter.

And--

COMPUTER: Hello, David.

DAVID J. MALAN: OK.

[LAUGHTER]

It's a little robotic.

But at least now it
has synthesized speech.

And I've kind of got my own, like,
Siri or Google Assistant or Alexa

thing going on here now, where
it's now recognized whatever text

it is, and it's played it.

Well, let's make this an actual cat that
doesn't talk in that weird human voice.

Let me go ahead and get
rid of most of this stuff.

And let's get the cat to actually
meow, like a cat tends to.

And let me go under the Sounds block.

Now MIT gives you a few sounds for free
because it's designed around a cat,

by default. And I'm going
to go ahead and grab

this one, Play Sound Meow until done.

And now-- and we heard a teaser
for this earlier in the crowd--

[MEOW]

It's a little piercing, admittedly.

Maybe we can lower the
volume a little bit there.

But notice, if I want the cat to meow a
second time, I'll just click it again.

[MEOW]

OK, and over there, too, I hear--

[MEOW]

OK.

[MEOW]

All right, so it's kind
of cute now, right?

So it's just meow--

OK, yes, echo, echo.

So it's meowing now every
time I hit the Green Flag.

Now, that's great, but even
a kid is probably going to--

[MEOW]

--like would prefer that it--

[MEOW]

--just meow, perhaps, like again
and again, without having to keep--

[MEOW]

--hitting the button.

So how might we do this?

All right, well, if I want it to meow
multiple times, why don't I just, like,

grab it another time and another time?

Alternatively, you can Right-click
or Control-click a puzzle piece

and just duplicate it from a
little menu that drops down.

So here we go, three meows.

[MEOWING]

All right, that's not
really a happy cat.

It sounds maybe hungry.

So can we slow that down?

Well, maybe.

In fact, if I poke around,
let me go under Control.

It looks like there's a Wait block.

Wait 1 Second, by default. And notice,
Scratch will be pretty accommodating.

If you just hover in between blocks,
it will grow to fill that too.

So I could change it to 1
or 2 or anything, seconds.

I'll just leave it at
the default for now, 1.

And now I'll go ahead and do this.

[MEOWING]

OK, so cuter and less hungry
and just more friendly.

But this isn't the best design.

It is correct.

And let's use that as a term of art.

Correct means the code does
what you want it to do.

I want the cat to meow
three times slowly.

And it did.

So I'd wager this is correct.

But it's not the best design.

And this is where things
get more subjective, right?

Like, you could write accurate sentences
in an essay for an English class,

but otherwise, it's
just completely a mess.

Like, your arguments here and there,
and you don't say anything wrong,

but you don't say it well.

In the context of code, we
can do better than this.

And Copy/Paste or repeating
yourself again and again tends

to be bad practice.

Why?

Suppose that you want to change
the Wait to 2 seconds instead of 1.

It's admittedly not a big deal.

Fine, I click there, I change it to 2.

I click there, I change it to 2.

But what if you meow 5 times, 10 times?

Now I have to change the Wait,
like, in 5, 10 different places.

Like, that's just stupid.

It's taking unnecessary human time, and
you're going to screw up eventually,

especially if your
program is getting longer.

You're going to miss one of the inputs.

You're going to leave the number wrong.

And that's a bug.

So just based on what
you've seen already

or if you've program before,
which a few of you have,

what's the term of art
here that will solve this?

How can we design this better?

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: I heard it here.

Yeah, so a loop-- a loop, some kind
of cycle that says, do that again.

Do that again-- not infinitely
many times, necessarily,

but some finite number.

Well, you can perhaps see
a spoiler on the screen.

Under the same orange Control
category is a Repeat block.

And by default, it's proposing 10.

But we can change that.

So let me do this.

I'm going to throw away most of
this Copy/Paste as redundant.

I'm going to detach this temporarily
just to make room for something else.

And I'm going to drag a Repeat block
over here and let that snap into place.

And I'm going to change it for
now, just to be 3, for consistency.

And this is the correct shape
even though it's too small,

but Scratch will
accommodate that for us.

And now-- same output but
arguably better designed.

Why?

Because if I want to change the number
of meows, I change it in one place,

no Copy/Paste messiness.

If I want to change
the waiting, one place.

I don't have to change it in
multiple places and not screw up.

So let me hit the Green Flag.

[MEOWING]

All right, so-- nice.

Now, it would have been nice if MIT
had just given us a meow block that

just automates all of this for us.

Let me wager, they gave us the
low-level implementation details.

They gave us the Play Sound Meow.

But I had to implement a
decent number of blocks

just to get a cat to
meow again and again.

I feel like we should have
gotten that for free from MIT.

Well, they don't have to be the only
ones that invent blocks for us to use.

You can write your own functions,
your own verbs or actions.

So how can we do this?

Let's make our own puzzle piece,
called Meow, that uses this code

but creates it in such a way
that it's reusable elsewhere.

So let me do this.

Under my blocks in pink here,
I'm going to go ahead and click,

literally, Make a Block.

Now, here's an interface by which
I can give the block a name.

M-E-O-W will be the name of this block.

And I'm just going to go
ahead and quickly click OK.

That just gives me a very
generic, pink puzzle piece

that starts with the word
Define because scratch

is asking me to define, that
is, implement or create,

this new puzzle piece for me.

Well, what does it mean to Meow?

I'm going to claim that it means to do
these two steps, to play the sound meow

and then just wait for 1 second.

But what's powerful about this
idea is look at this up top.

Now that I've made a block,
it exists in Scratch.

MIT didn't need to create this for me.

I created it for myself and even
you, if we end up sharing code.

So I can now drag Meow up in here.

And what's nice about Meow is
that itself is, yes, a function,

but it's also an abstraction.

Like, never again do I or even you
need to worry or care about what

it means to meow or implement it.

I can sort of drag it out of the way.

I didn't delete it--
drag it out of the way.

Out of sight, out of mind.

Why?

Because my code is now even
better designed, in some sense,

because it's more readable.

What is it doing?

When the Green Flag is
clicked, repeat 3 times Meow.

It just says what it means.

And so it's a lot easier
to read it, and it's

a lot easier to think
about it, especially

if you're using Meow
in other projects too.

Now, let me go ahead and click Play.

[MEOW]

Same thing.

[MEOW]

So it's not really
fundamentally any different.

[MEOW]

But I can make this custom puzzle
piece, this own function of mine, Meow,

even more powerful.

Let me kind of rewind a bit
and go to my Meow puzzle piece.

And I am going to Control-click or
Right-click on my pink puzzle piece.

And I'm going to edit it.

So I kind of regret
making Meow so simple.

Wouldn't it be nice if
Meow took an input, a.k.a.

an argument, that tells
Meow how many times to meow.

Then I can get rid of
that loop and just tell

Meow how many meows I actually want.

So I'm going to click on another button
here called, literally, Add an Input.

And it's going to have placeholder here.

So I'm just going to
put a placeholder there.

I keep using "n" for number, which is
a go to in computer scientist terms.

And I'm going to add some
descriptive text just so that it's

a little more self-explanatory.

I'm just going to say Meow n Times.

But there's only one oval.

Times is just going to
be explanatory text.

And now notice what has happened.

Now my puzzle piece
takes an input, a.k.a.

an argument, that will tell that
function to meow some number of times.

But it's not just going
to work magically.

I need to implement
that lower level detail.

So let me zoom out.

I have to remind myself
what this function was.

So I'm going to drag it
higher up just so they're

on the screen at the same time.

I'm going to go ahead now and
temporarily move this over here.

I'm going to temporarily
detach this over here.

Why?

Because what I thing I want to do is
move my loop into the function itself,

move the Play and the
Wait into the loop.

But I don't want a hardcode 3.

Notice that n here is its own
oval I can drag a copy of n

and just let it go there.

So now I have a new version of
Meow that takes an argument, n,

that tells Meow how many times to meow.

And now let me, again, drag
this out of sight, out of mind,

because who cares how I implemented it?

Once it's implemented,
it's sort of done.

Now my program is even better
designed, in some sense.

Why?

Because now it really
just says what it means.

There's no loop.

There's no repeat, no
implementation details.

When Green Flag Clicked, Meow 3 Times.

And so functions indeed let
you implement algorithms,

like they're just code
that do something for you.

But they're also
themselves abstractions.

Why?

Because once a function
exists, it has a name.

And you can think about it in that term.

And you can use it by its name.

You don't have to care or remember
how the function itself was built,

whether it's by you or even MIT.

So again, here I'll
click the Green Flag.

It's the same thing.

[MEOWING]

So still correct, but
better and better designed.

And so any time, here and
out, with Scratch, or soon C,

and eventually Python, when you
find yourself doing anything

resembling Copy/Paste or again and
again grabbing the same code, probably

an opportunity to say, wait a minute.

Let me refactor this, so
to speak, that is, rip out

the code that seems to be
repeated again and again

and put it in its own function so
you can give it a descriptive name

and use and reuse it.

Any questions just yet on now saying
or these loops or these functions

that we're using?

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: How did I make
it so it meows three times?

So I originally only had a
puzzle piece called Meow.

And I decided to improve it.

So I held down Control and I
Right-clicked or Control-clicked

on the pink puzzle piece at top left.

And I clicked Edit.

And that brought back
the original interface

that lets me add some arguments
to the puzzle piece itself.

And I clicked Add an
Input on the left here.

And then I clicked on
Add a Label over here.

So that just lets you
customize it even further.

All right, so we've done this.

Let's add one of those other primitives
too to do something optionally.

So how about we make the cat meow
only if it's being petted by a human,

as by moving the mouse to hover over
the cat, like a human would pet a cat?

Well, let me go ahead and
throw away the meowing for now.

And let me simplify it
by just using a sound.

I'm going to go ahead and do this.

I'm going to go ahead and
have a Control block that

says If, because I want to implement
the idea of if the cursor is touching

the cat, then play sound meow.

Or I could use my same
pink puzzle piece.

But I'm going to throw that away
and focus only now on the sounds.

And I'm going to do this.

If touching mouse pointer-- so I need
to sense something about the world.

And we saw this earlier--

so If Touching Mouse Pointer.

So notice this shape here, way too big.

But it is the right shape.

So if I hover just right,
it'll snap into place.

And this now, in blue, is my Boolean
expression, a yes/no question,

true false.

"If" is a conditional.

And what do I want to do?

Well, if the cat is
touching the mouse pointer,

I want to go ahead and
play sound meow until done.

So let's do this.

I'm going to hit Green Flag, click.

Now nothing's happened yet
because it's a conditional, right?

It's only supposed to do
something if I'm touching the cat.

Let me move the cursor over to the cat.

And-- wait for it.

Hmm-- another bug.

Why is the cat not meowing
even though I very explicitly

said, If Touching Mouse Pointer, Meow?

Yeah, in the middle--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, this
is-- again, my computer's

just so darn fast, like yours.

I click the Green Flag,
it asks the question,

am I touching the mouse pointer?

Well, no, because my cursor was
up there, not touching the cat.

It's too late.

The cat's out of the bag.

And so we have to instead
solve this by some other means.

How can we fix this?

How do we fix that sort of race?

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, so
why don't we just keep

asking the question until I eventually
am or am not actually petting the cat?

So let me detach this temporarily.

Let me go under Control.

Let me go under-- instead of
repeat some finite number of times,

let's just do it forever.

So sometimes loops that do
work forever are a good thing.

The clock on your
phone, that's in a loop

forever because you want it
to always tell time and not

stop at the end of the day.

So sometimes you do want code to
loop forever, as in this case.

So let me go ahead and
drag and drop it there.

Let me, again, click the Green Flag.

Nothing's happening yet.

But notice, the program
is still running.

And so if I move my cursor, move
my cursor, move my cursor, and--

[MEOWING]

OK, so maybe we could add some Waiting.

But the cat does not want
to be pet, in this case.

But it's indeed conditional.

So there we have an
incarnation in Scratch

of doing something conditionally.

Now, we can make this really
cool, really fast, if you will.

Let me stop this version.

Let me go ahead and do this.

Let me go ahead and
throw all of this away.

Let me go into my little
Extensions bucket over here.

And let me do Video Sensing, since
most laptops or phones these days have

cameras.

And there, indeed, I am,
with Sanders behind me.

And let me do this.

When Video Motion-- and
let me get out of the way.

When Video Motion is
Greater Than some value.

So 10 is the default. This is just a
number that measures how much motion

there is or isn't.

So small number is like no motion.

Big number is lots of motion.

So I'm going to choose 50,
somewhat arbitrarily here-- so 50.

This is not normal to
program off to the side.

But I'm now going to say this.

When Video Motion is 50, go ahead
and Play Sound Meow like this.

So the cat is still in that world.

I'm going to stop the
program and rerun it.

So here we go, Green Flag.

And now here comes-- all
right, this is a little creepy,

the way I'm petting the cat, but--

and-- [SIGH]

[MEOWING]

OK.

[LAUGHTER]

There we go.

OK, so 50 was too big of a number.

I have to pet the cat faster.

[MEOWING]

Whereas this, if--

I don't know--

[LAUGHTER]

Yeah, so--

[MEOW]

OK, so you can make things even
more interactive in this way

by just assembling
different puzzle pieces.

And honestly, there are so many
different puzzle pieces in here.

We're not going to even scratch
the surface of a lot of them.

But they generally
just do what they say.

And indeed, when you see on
the screen here this pallet

of puzzle pieces, really a lot of
programming, especially early on,

when learning a language, is just trying
different things and try and fail.

And if it doesn't work quite right,
look for an alternative solution

there too, as even I just
had to do a moment ago.

Well, let's go ahead and use, actually,
how about another example of something

a predecessor of yours made?

Let me go ahead and grab a program
I opened in advance here called

Whack-A-Mole Might we get a
brave volunteer to come up,

who is willing to whack a mole
with their head, virtually?

Maybe-- OK, let's see,
how about in way back?

You want to come on down?

All right, come on down.

Sure, a round of applause
for our volunteer.

[APPLAUSE]

All right, so here we have--

come on down.

AUDIENCE: Hi there.

DAVID J. MALAN: What's your name?

AUDIENCE: I'm Josh.

DAVID J. MALAN: Oh, actually,
say it into the microphone.

AUDIENCE: Hi, I'm Josh.

DAVID J. MALAN: OK, nice.

Welcome, Josh.

Come on over.

[APPLAUSE]

All right, so same idea here--

I'll take the mic back.

You'll have to stand
in front of the camera.

In just a moment, you're going to
have to position your head in a box

that your classmate
from yesteryear created.

[MUSIC PLAYING]

And we'll start with Beginner.

AUDIENCE: OK.

DAVID J. MALAN: So line your
head up in the box in a moment.

AUDIENCE: All right.

[LAUGHTER]

DAVID J. MALAN: Nice.

12 seconds.

5 seconds.

Notice the score's up to 18 already.

Pretty good.

All right, a round of applause
for Josh, if we could.

[APPLAUSE]

So notice how using some
fairly simple primitives,

things do get interesting pretty fast.

And how was that implemented?

Well, there were probably
at least four sprites.

So you're not confined to just one cat.

You can create more and more
sprites, change what they look like.

So they actually look
like a mole, in this case.

There's probably some conditionals
in there, some loops for 30 seconds.

That's checking if Josh's
head's movement is exceeding

some value over this
way or over this way,

then increment something
called a variable.

We'll see those too.

Just like in algebra
you might have x and y

and z, storing values like
numbers, so can computer programs,

have variables called x or y or z,
or more descriptively called Score,

as in this case at top
right, or another variable

called Countdown, typically one
word in code, but in this case

two words, that just store some value.

So there's probably some
math going on in there

whereby the author of this program
just is incrementing, that is,

adding 1 and 1 every time it detected
that a mole had been whacked,

in this case, with movement.

So back in the day, I, myself, actually
implemented my very first program

in Scratch when I was a graduate
student, actually, at MIT--

cross-registered at MIT, taking
a class from MIT's Media Lab,

specifically, the lifelong kindergarten
group, which is the group that created

Scratch, itself.

And the program I wrote all
those years ago and still

rather cling to is a
little something here

called Oscartime, that I thought I'd
play just a quick excerpt of myself

here.

So in this case, consider,
as the music starts playing,

how this program, which is much
more sophisticated, certainly,

than the earliest "Say hello" examples
we just did might also be implemented.

Let me go ahead now and
click the Green Flag.

[MUSIC - OSCAR THE GROUCH, "I LOVE
TRASH"]

OSCAR THE GROUCH:
(SINGING) Oh, I love trash.

DAVID J. MALAN: OK, so some trash is
moving, presumably in some kind of loop

from the top.

If I'm touching the mouse
cursor, it follows me.

If I hover over the
trash can, it responds.

If I let go, in some kind
of loop, Oscar pops out,

creates a variable
with the current score.

And it happens again.

OSCAR THE GROUCH: (SINGING)
It's awful, the holes.

And the laces are torn.

A gift from my mother
the day I was born.

I love it because it's trash.

Oh, I--

DAVID J. MALAN: It's
pretty easy at first but--

OSCAR THE GROUCH: (SINGING)
--anything dirty or dingy--

DAVID J. MALAN: So I don't
need to keep playing this up

on stage in front of everyone.

So my score is already
now up to some 6 or so.

But in a moment, too, you'll
see that it's going to escalate.

So I'm taking into account
some time apparently.

So now--

OSCAR THE GROUCH: (SINGING) I have
here some newspaper, 13 months old.

DAVID J. MALAN: So more and more
sprites are suddenly appearing.

And notice, that each
time they're appearing

from a different part of the screen.

That's an illusion, perhaps, too, that--

pick a random number between x and y.

So you can actually pick
some range of values

to have the game constantly changing.

And indeed, I'm going to
go ahead and click Stop,

since I spent like eight hours
plus, years ago, making this.

And I can never listen
to the song again,

not that I should be anyway
at this point in my life.

But this song is synchronized then with
a lot of the actions that's happening.

And ultimately, there's just
a lot of building blocks.

But I didn't sit down and implement
Oscartime, as I called it, all at once.

I really did take baby
steps, so to speak.

And I figured out, well, how could I
decompose this vision I had at the time

to create this game ultimately?

And how do I bite off maybe
the easiest parts first?

And honestly, the first thing I did was
I found this image, and I just dragged

and dropped it into Scratch--

OK, done-- like, lamppost is installed.

It doesn't do anything.

It's not interactive.

But I at least set the stage,
so to speak, for the program.

Then what else might I have done?

Well, let me do this.

Let me go ahead and open
up in another editor here

an early incarnation of
Oscartime by doing this.

Let me go into Oscartime here.

Let me full screen this.

And here you have--

let me hide the trash
for just a moment--

is what I might call the second
version of my program, wherein,

at the top right of the stage here,
I had the lamppost, which I just

dragged and dropped and got going,
but then I added an actual sprite.

And it has to be a sprite if you
want it to do things interactively.

The lamppost-- not a sprite.

It's just an image a costume,
if you will, for the whole

stage itself, a backdrop.

But this thing is indeed
a sprite because it

needs to respond to code and
events, like dragging and dropping.

So what might I have done
early on with that code?

Well, maybe the first
version would have been

something like this, whereby my
very first version of Oscartime

might have said
something like, oh, this.

How about, let me control the program
as before-- or, rather, events.

When the Green Flag is
clicked, what do I want to do?

Well, I want to go ahead and
forever do something like this.

Forever-- so I want the lid
to open up if I touch it.

So if the cursor gets near the
lid, I want the lid to open up.

And then if I move away,
I want it to close.

So how can I do that?

I want an If, but I just don't want
one question, I really want two,

a fork in the road that goes
left or right, so to speak.

And let me grab this puzzle
piece here, as I did long ago.

So notice, it grows to fill.

What's the question I want to ask?

Well, under Sensing, I'm
going to go ahead here

and say If this trashcan is
Touching the Mouse Pointer--

what do I want to do?

Well, I want to change what
the trashcan looks like.

And this part, I did
in advance of class.

If you go up here to Costumes, this is
where all the graphical stuff happens.

And you'll see that I imported a
whole bunch of different costumes

that effectively, much like a
video, when you play them quickly,

creates the illusion of
movement, some animation.

But it's really just
dot, dot, dot, dot, dot--

different images showing on the screen.

Well, some of these costumes
are called like Oscar1, Oscar2.

Oscar1 is closed.

Oscar2 is open.

So let's just deal with those first.

So if I'm touching the mouse pointer,
let me go under-- how about Looks?

And we didn't use this before,
but there's this block,

Switch Costume to Something Else.

I'm going to drag and drop
this inside of the If.

And notice it's a little bit indented.

I'm going to change it
not to Oscar8, but Oscar2.

Otherwise, If Not Touching
the Mouse Pointer--

this is the other direction
in the fork in the road--

let's go ahead and switch the costume
back to what I described as Oscar1.

So let me run this program.

And not much of interest
is happening yet.

But notice, if I move
the cursor up, down--

but how is that working?

It's just changing the costume
that's being overlaid on the sprite.

So it looks like interactivity,
but you are really

just changing the aesthetics.

And we humans are just kind of
assuming, oh, it's opening up.

Well, no, it's just changing a costume.

So here's the difference.

The high-level abstraction--
trashcan opening.

The lower-level implementation
detail-- costume

changing, creating that illusion.

And if I want it to look prettier, I
could just have many other costumes

and go boom, boom, boom, boom, boom
to create more frames per second,

if you will.

So I need to do one other thing.

Maybe if I accidentally
leave the trashcan open,

let me make one change here.

Let me make sure that
the very first thing

I do when the Green Flag is clicked,
is always start with the trashcan

closed because otherwise, you
might accidentally leave it open.

So this gets me into some default state.

So now it's always closed until
I manually hover over it instead.

Well, what might I have done next?

Well, if I wanted to introduce something
like the trash, I need a second sprite.

And here, in advance, I
grabbed the image already.

Let me pretend that this never happened.

Let me drag this away here.

And now I have nothing in my code
area for this piece of trash.

But it is the second sprite.

And all I did was I clicked on
the little cat plus icon here,

created a second sprite.

I named it trash.

I added a costume for it.

Sort of the aesthetic
stuff, I did in advance.

But here I'll do now the code.

How do I want to do this?

Well, how about when the Green
Flag is clicked, for the trash can,

I want the trash can in parallel to do--

I want the trash, the piece
of trash, to do its own thing.

So what I want it to do is maybe
let's do Motion, how about?

And let's go to a specific coordinate.

Now, there's a lot of options here.

There's Turning, Go to a Random
Position, Go to x,y, Glide,

more elegantly.

There's a lot of different
ways to implement movement.

I just want it to go to a
very specific location first.

So I'm just going to go to x,y first.

And I'm going to say
x, how about, will be--

let's not hardcode this.

Let's just have it be-- well, let's
do it at 0, initially, and then 240.

So-- whoops-- let's do 0,240
so that this piece of trash

always starts at the top
middle of the screen.

If you think back to that coordinate
system, 0,0 is in the middle.

240 is straight above it.

All right, now, after I do
that, what do I want to do?

Well, how about I control
this thing by forever falling.

Now, how do I make the trash move?

We haven't seen this puzzle piece yet.

But under Motion, the very first thing
is called Move Some Number of Steps.

By default, it's 10.

But we'll do it more simply.

Let me go ahead and move--

oh, sorry.

Move is going to move it in
whatever direction it's facing.

I only want it to move down.

So here, even I'm getting confused
as to how many different ways there

are to do things.

What I thing I want to do is this.

Let me only change my y-axis as follows.

So here's another puzzle
piece called Change y.

So again, y is the vertical.

So let me just change
y by one pixel downward

at a time, so -1 one pixel at a time.

So it's kind of slow.

And I think now--

I think that's it.

Let me hit Stop.

Notice that my trashcan is
still going to be interactive.

I haven't changed or deleted that code.

I've just added now code
for my piece of trash.

If I click the Green Flag, notice that--

after I enable it-- let
me start that again.

I had it hidden for before class.

But let me enable it now--

Green Flag, notice it starts dead
center, at x equals 0, y equals 240,

and it's dropping one pixel at a time.

If that seems a little boring, we
can change it to -10 pixels at a time

and, boom, it's done.

So that's how you might
change the speed of a program.

But I'm going to leave
it more simply as -1.

And honestly, it would be nice if it
doesn't always start from the top.

Otherwise, this game is not
going to be very interactive.

I'm literally going to be grabbing the
trash from the same place every time.

So why don't I, instead, Stop this.

Let me go under Operators, and
let's pick a random number.

So let me change the hardcoded--

the manually inputted-- 0, and
let's make x be somewhere between 0,

so in the middle and
all the way over to--

what was it-- oh, I
got my numbers wrong--

240 and my y will be 180.

Sorry, I got my x and my y confused.

So let me play this again.

And now we have a game
that's more like games

you might have played
growing up or even now,

like there's some randomness to it.

So the CPU, so to speak, is
doing something more interesting.

Let me run it again.

Now it's a little to the left.

Let me run it again.

Now it's a little more to the left.

Again-- now it's back to the right.

So randomness just makes
games more interesting.

And this is why when you play any
video game, if different things are

happening, there's probably
just some randomness.

And it's quantized as
just a simple number.

Now, I think I just need one
final flourish here, if I may.

Let me go ahead and add this.

How about Events-- or rather--

yes, Events.

When Green Flag is clicked, I can do
multiple things within the same sprite.

They don't all have to be
attached to the same one.

Let me go ahead and forever go
ahead and do something else.

How about, Whenever the Trash is--

how about-- Touching the Trash Can--

so Forever If-- let's see,
I need a Sensing block.

So how about, Is Touching--

not the Mouse Pointer, this time,
but Touching Oscar himself there.

Now let's see what happens.

All right, so let's go ahead
and click the Green Flag.

Now I go down over here and let go.

OK, I kind of want it to
go into the trash can.

How do I make it go into the trash can?

How can we take this high-level
idea, put trash into the trash can,

and make it seem to disappear?

Logically, what could we do?

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: OK, so when it
touches it, let's have it disappear.

So I could hide it.

Or honestly, if the game is
going to be ongoing, like it was,

letting me drop more and
more trash, let me just

have it go ahead and pick
a new random location.

So let me do this.

Let me go ahead and Copy this
puzzle piece up here and Duplicate.

And I don't want the whole thing, sorry.

Let me get rid of this.

Let me just do this.

Let me go back to some
random location at the top.

So now notice what happens.

If I click and drag
on it-- here it goes--

and I let go, it looks like
it's going into the trash can

because it snaps back up
to some random location.

Now, the only thing I'm not doing really
is keeping track of any kind of score.

And it turns out, if I full screen
this, it's not going to be draggable,

by default.

So just as a corner case,
so to speak, something

that you might trip over otherwise,
let me go ahead and under, let's

see, Sensing, it turns out I also
need this for the piece of trash.

There's this way of setting,
in Scratch, a sprite

to be draggable or not draggable.

I need to explicitly
make it draggable so

that when I do full
screen this thing now,

it still remains draggable
and someone like myself

can play it again and again.

Well, how about we supplement
this with one final flourish?

Why don't we keep track
now of the user score?

So how about, when the user
actually drags the piece of trash

to the trash can, let me
go under Variables here,

where, in advance, I've already
made myself a variable called Score.

I could have called it x or y or z or
ABC, but that's not very descriptive.

In programming, you typically give
things a more descriptive English,

or some other language, name.

So I called this one Score.

So how do I want to do this in my Score?

Well, let me go ahead and
initially set this game

score to 0 at the very top
of one of these scripts--

one of these programs up here.

And then any time my
piece of trash is touching

Oscar, let's not just jump to the top,
let's change the score by 1 up here.

So now notice, If Touching Oscar,
Change the Score-- that is,

Add 1 to the Score--

and then Pick a new Random location.

And now Green Flag--

let's do this slowly.

Here it goes.

The trashcan opens.

I let go.

And now notice, at the top left of my
program, notice the score is now 2.

Notice the score, if I do this
again, is about to become 3.

And so here we have
building blocks, literally,

of making this program
better and better and better.

And so, indeed, that's how you generally
approach solving any problem with code,

be it in Scratch or C
or Python or some other.

You take this vision you
might have or some vision

you've been assigned in
a homework assignment

and try to break it down
into these constituent parts

and just pluck off the easy ones first.

Put the lamp post there
first, and at least

feel like you're making some progress.

Then pluck off something
like the trash can, and just

make it do a little thing.

And it doesn't have to be
in some same order here.

I could have done this in
a million different ways.

But figure out what the small
pieces are that, ultimately,

like a few of the problems we've solved
today, assemble into a greater solution

there too.

So that you have now a mental model
for these types of blocks and others,

let's return for a moment to this.

We saw a moment ago that when I
started saying, "Hello, David,"

and nesting those puzzle pieces, we had
a whole different paradigm altogether.

My input for that second version of,
"Hello, world," was to now pass in,

for instance, "What's Your Name?"

into my function, called Ask.

That gave me not a side
effect, but what I called,

again, a return value, called
Answer, by default, in Scratch.

And now notice and recall,
when I had that same output

become the input to my next block, it
looked a little something like this--

Say.

So how does this type of block and
this nesting, this stacking of blocks,

fit into the same mental model?

Well, same idea-- my input for that part
of the story is now taking in not one

input but two--

two arguments-- "hello"
and the answer from before.

The function, in this case,
is that new block called Join.

The output thereof is, "Hello,
David," which itself became--

if we sort of animate this--

the input to my final function,
which indeed was still Say.

And this is only to
say-- no pun intended--

that almost everything that you
do with these puzzle pieces,

be it in the context of
Oscartime or the mole whacking

or even just something
simple like, "Hello, world,"

will ultimately fit into that
relatively simple mental model there.

Now, I thought we'd end by taking a
look at just a couple of final examples.

These ones, too, made by
some of your predecessors.

And for this, I thought we
would not write code together,

but read it instead.

And so allow me to open
up one other example here

that will show us a few
different versions of a program

that a predecessor made.

Give me just a moment here.

And we'll see how we might build up
to something even more interactive.

And in just a moment,
we'll see something

they called Ivy's Hardest Game, focused
here on these particular mechanics.

So here is version 0, so to
speak, of this program, wherein

the goal was to create a game where you
have to get out of some kind of maze.

And you have to get out, in this case,
the Harvard crest from this maze.

Let me go ahead and just
hit Play on this Green Flag

so you can see what the first building
block for this program might have been.

Notice that my hand here is actually
on the Arrow keys on my keyboard.

And it seems that by moving
up, down, left, or right,

this little crest on the screen
responds in exactly that way.

Now, let's hypothesize
for just a moment.

Even though we've not done
anything quite like this before,

how might this code be implemented?

How do you get a sprite,
be it a cat or a crest,

to respond to keys on a keyboard--
might you think intuitively?

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah,
there could be something

sensing what key you're pressing on.

And if you do it again
in forever a loop,

you'll just constantly be
listening for keystrokes.

And this is how, like, every
piece of software nowadays works.

It's constantly waiting
for your phone to be tapped

or something to be typed on the screen.

So let me go ahead and look inside
of this existing program here.

And there's more going on,
but we'll take a quick glance

what's actually going on.

Well, up here at top
left, notice, we just

have Go To x Equals 0 and y Equals 0.

That means put the Harvard crest dead
center in the middle of the stage.

Then we have Forever
two functions that we

made in advance as custom functions--

Listen for Keyboard, Feel for Walls.

So it's doing two things at once.

It's forever listening
for the keyboard-- up,

down, left, right-- and
feeling for the walls,

in the sense that if I
get too far to the left,

I don't want it to keep
moving past that black wall.

And if it moves too far to the right, I
don't want it to blow through that wall

either.

So it's going to do two things
constantly, listening for keyboard

and feeling for walls, so to speak.

And how are those implemented?

Well, this one's a bit long.

But on the left here
is Listen for Keyboard.

So this pink puzzle piece,
Listen for Keyboard,

first checks If the Key Up
Arrow is Pressed, question mark,

Boolean expression in a
conditional, Change y By 1.

That means, move it up 1.

Else If the Key Down Arrow is
Pressed, then Change y by -1,

and similar for Left Arrow,
similar for Right Arrow.

And even though there's not
a loop in this pink function,

there is where I'm using it.

So it's constantly being
asked again and again.

How about feeling for walls?

Well, over here to the right--

it's a little cut off-- but here
you have, If Touching Left Wall,

Change x by 1.

So if you hit the wall, it's too late.

You're kind of blowing
through it already.

So I want to move it back one pixel
so it's no longer touching that wall.

Similarly, if it's touching the right
wall, I want to back it up one pixel

so it's no longer touching that wall.

So it's kind of like bouncing
off ever so slightly so that it

doesn't slip through that actual wall.

And what are those walls?

Well, notice down here, it's just
a simple sprite with a black line

that I've oriented vertically
instead of horizontally.

And that's just so that I can ask
questions of these other two sprites.

Now, that gives me that
form of interactivity.

What more can I now do?

Well, what if we make things a
little more interactive here?

Let me go ahead and see
inside version 1 our second.

And let me propose what's
going to happen here.

Well, how might we add a little
something like Yale into the mix?

Well, what's Yale going to do when I hit
the Green Flag now based on this code?

Any hunches?

Here is the code for my Yale sprite.

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah,
it's kind of going to be

an adversarially by blocking
my path, theoretically,

if I keep writing more code.

So why?

It too goes to the middle of the screen.

It points in direction 90 degrees.

So similarly, there's a
whole degree system as well.

And it forever asks this.

If Touching the Left Wall Or--

notice the green block--

Touching the Right Wall, then
just Turn around 180 Degrees.

And indeed, if you think
this through logically,

that just means you're
bouncing this way and this way

by just flipping yourself around 180
degrees for just this Yale sprite.

So if I go ahead and zoom in on
this and click the Green Flag,

I can still move up and down.

But Yale is just kind of doing
this all day long, back and forth

and back and forth, forever.

Nothing bad happens if
I try to go through it.

But we could add that,
certainly, to the mix.

In fact, let's add one final feature
before we play this particular game.

And let me go ahead and open up the
final version of these building blocks

that adds MIT to the mix.

So here is MIT.

Someone want to explain
what this code does?

And this is what we're doing.

This itself is a skill.

Reading someone else's
code and understanding it

is half of the part of
programming besides writing.

Yeah--

AUDIENCE: [INAUDIBLE]

DAVID J. MALAN: Yeah, it's chasing
down the Harvard logo outline.

So this is apparently
the name of the costume

that this student made,
Harvard logo outline.

And apparently, it goes to
a random position first.

But then it forever points to Harvard.

So no matter where I'm
moving it, up, down, left,

or right, MIT is being a little
more strategic than Yale,

bouncing back and forth like this.

So let's go ahead and play
this one in full screen.

And here we have a Green Flag.

So if I move up, MIT,
rather strategically,

is following me no matter where I go.

All right, so still,
nothing bad happens.

But now it's struggling, right?

It's going up, down, up, down.

It's trying to follow me
even though I'm not moving.

So we need some final flourishes.

And so I think, for this, we
need perhaps one final volunteer.

After this, cake awaits
for everyone outside,

as is an end of first
lecture CS50 tradition.

Would you like to come
up and be our volunteer?

[APPLAUSE]

All right.

And so this will be the actual version
but written by one of your predecessors

that I'll full screen here.

It's going to stitch together all
of these same primitives and more,

but add the notion of scores and
lives so that there's actually

a goal, which in this case is to move
the Harvard crest to constantly pursue

the character on the right-hand side
so that your sprite touches that one.

Would you like to introduce yourself?

AUDIENCE: Hi, my name is Mohammed.

DAVID J. MALAN: All right, wonderful.

Welcome aboard.

And here we come with some
instructions and final

flourish if we want to keep the lights
up but perhaps increase the music.

[MUSIC PLAYING]

[MUSIC - MC HAMMER, "U CAN'T TOUCH
THIS"]

MC HAMMER: (SINGING) You can't this.

You can't touch this.

DAVID J. MALAN: Notice he is
using the up, down, left, right.

But there's many more walls now.

First level's pretty easy.

But now Yale's in the mix,
bouncing back and forth.

Again, pretty easy.

Now there's two Yale's at
slightly different positions.

MIT is coming soon.

But first, we have three Yales.

MC HAMMER: (SINGING) As such.

And this is a beat, uh, you can't touch.

DAVID J. MALAN: Very nice.

[APPLAUSE]

MC HAMMER: (SINGING) I told you,
homeboy, you can't touch this.

Yeah, that's how it look when
you know you can't touch this.

Look at my eyes, man,
you can't touch this.

Yo, let me bust the funky
lyrics. you can't touch this.

Fresh new kicks and pants,
you got to like that.

Now, you know you want to dance.

So move out of your seat and get a fly--

DAVID J. MALAN: You got to go quick.

MC HAMMER: (SINGING) Catch
this beat while it's rolling.

Hold on.

Pump a little bit, and let them know
what's going on, like that, like that.

Cold on a mission, so fall on back.

Let them know that you're too much
and this a beat, uh, they can't touch.

Yo, I told you.

You can't touch this.

[APPLAUSE]

Yo, sound the bell.

School's in, sucker.

You can't touch this.

Give me a song, a rhythm.

Making them sweat, that's
what I'm giving them.

Now they know, you
talk about the Hammer,

you talking about a show
that's hyped and tight.

Singers are sweating, so pass
them a wipe or a tape to learn.

What's it going to take--

DAVID J. MALAN: Second-to-last level.

MC HAMMER: (SINGING) Legit.

Either work hard or
you might as well quit.

That's word because you know--

DAVID J. MALAN: Last level.

MC HAMMER: (SINGING)
You can't touch this.

DAVID J. MALAN: Hey!

[LAUGHS]

[APPLAUSE]

Congrats.

All right, that's it for CS50.

Welcome.

Cake is now served.

We'll see you next time.

[PROJECTOR CLICKING]

[MUSIC PLAYING]