Programming – Understanding Technology – by CS50 at Harvard


[CLASSICAL MUSIC] [MUSIC – SESAME STREET’S OSCAR THE
GROUCH, “I LOVE TRASH”] OSCAR THE GROUCH:
(SINGING) Oh, I love trash. Anything dirty or dingy or dusty. Anything ragged or rotten or rusty. Yes, I love trash. If you really want to see
something trashy, look at this. I have here a sneaker
that’s tattered and worn. DAVID J. MALAN: So this
is, believe it or not, the very first program I wrote using
a programming language called Scratch. It’s a graphical
programming language that was developed by MIT’S
lifelong Kindergarten Group. And it was designed,
initially, as an environment with which to get students excited about
computing about technology, especially after-school programs. But what’s wonderfully
exciting about it too, is that it’s also
wonderfully instructive when it comes to what programming is. And indeed, we’ll be able to use this
programming language, ultimately, to explore the whole
world of programming. Now, what is programming? So programming is ultimately
about making software. And software, of course, is what runs
on our hardware, runs on our computers. Software is something you double-click
and then see and can interact with. Software is the files that you open
on your computer and interact with. And software, ultimately, is what
is written using programming code. Now, the software itself ultimately
runs in any number of devices. It might be your desktop PC or your Mac. It might be your iPhone
or your Android phone. But at the end of the
day, all of those devices are programmed by a human
writing, quite simply, code. What is code exactly? Well, at the end of the day, code is
really just a technical implementation of algorithms, where
algorithms themselves are step-by-step instructions
for solving some problem. Now, what kind of problems
might we want to solve? Well, let’s consider an
old-school one first. This here is an older technology, an
old-school phonebook, inside of which are thousands of names
and thousands of numbers. But it’s a wonderful opportunity
to think about a problem that we might want to solve, like
looking someone up in a phonebook so that you can actually call them? Well, suppose I’m actually looking
for someone like Mike Smith. Now, I can find Mike Smith in any
number of ways in this phonebook, assuming he’s actually in here. I might initially start very
correctly and very foolishly, perhaps, at the first page,
looking down for Mike. I don’t see him. So I move to the second page, look down. And I don’t see him at the
third page, and so forth. And as I proceed through
the phone book, I do claim that this algorithm, this
set of instructions, step-by-step, for solving this problem, is correct. Because if Mike is here, I’m
going to find him eventually. But of course, this is
completely ridiculous. This is a completely
inefficient algorithm for actually finding Mike Smith. Why? Well, it’s going to take
me forever to find him if he’s all the way toward
the end of the phone book. Wait, I know how to do this faster. I remember, from grade
school, an old trick where, rather than counting by
ones, you might count by two. So here I might do 2, 4, 6– literally. [LAUGHS] This algorithm turns
out, is much slower. 6, 8, 10, 12, 14, 16, 18, and so forth. And at that rate, I’ll certainly
find Mike much faster, twice as fast, in fact. But is that algorithm,
are those steps correct? Now, they’re not quite correct. Because what if by chance I
happened to be grabbing two pages and Mike happens to be
sandwiched in between them? I might blow right past
Mike’s name in the phone book. So I better have at least a
check, a sort of condition where I think to myself,
wait a minute if I hit someone whose name
starts with t instead of s, maybe I should double back. At least one page. Of course, no one out there– if
you even still use this technology– is going to solve this
problem in that way. What are you going to do instead? Well, if you’re like me,
you’re probably going to instinctively go roughly to
the middle of the phone book and look down there
to see where you are. Odds are, if you’re like
me in this book here, you’re going to find
yourself in the M section. But Smith, of course, comes after M.
And so we know Mike is to the right side here. And so that suggests that we could take
a pretty big bite out of this problem. I don’t need to start
flipping one page at a time. I know Mike is not in this
half of the phone book. And what’s nice about this
intuition is that, you know what? I can not only figuratively but shall
we say, tear this problem in half. That wasn’t really very
hard at all this time. Throw 1/2 of the problem away,
and I’m left with just 1/2 of the very same problem, fundamentally. Now, what might I do? I don’t want to resort
to the slower approach. I want to leverage that intuition,
divide and conquer this problem, look down and realize,
oh, I’m in the T section, I went a little too
far, but no big deal. Let’s tear the problem in
2/3 and really, in 1/2. So I’m left with just
1/4 of the problem now. And I can repeat this algorithm
again and again and again, until theoretically, I’m left with
just Mike’s number on this one sheet, or in this case, one scrap of paper. So what have I really done there? So the intuition, ultimately, is that
rather than looking for Mike one page at a time, I’m instead leveraging the
fact that that phone book is sorted. And I’m literally dividing and
conquering the problem again and again and again so that if I started with
1,000 pages, I then go down to 500. I then go down to 250, 125, as
opposed to starting at 1,000 and going to 999, then 998, 997, which
surely is going to take me much longer. Of course, that’s not the real
way to tear a phone book in half. So fortunately there are just
two of these books left on earth. And we have the second one here. So indeed, if I want to go
ahead and tear a problem in 1/2, the real way you do this– shall we say? There we go– is– [STRAINS] –that way. But now back to some programming. So I just solved that problem. But what was the algorithm
exactly that I used to solve it? In fact, can we distill
some of the key components of what I did fairly
intuitively and see if we can’t then later apply
those same principles to solving other problems altogether? Well, let’s consider this. I propose that the very first
thing I did was this in step one, I picked up the phone book. Step two, I opened to the middle of the
phone book, and I looked at the names. But then I had to make a decision. Because I was, at that point,
presented with some information as to what is on the page. And so step four, if Smith is among the
names, on the page, then, step five, I was going to call Mike. Else if, step six, Smith is
earlier in the book, that is, he’s to the left alphabetically,
well then, logically I should open to the middle
of the left half of the book and then go back to step three, thereby
looking at names again and continuing down this same set of steps. However, if after step six, I decide
no, Smith is not earlier in the book and therefore, I should not
do step seven and eight, well then, let me ask the question
else if Smith is later in the book, then is he to the right of
where I’m currently looking? And if so, opens in the middle
of the right half of the book and then go back to step three. Because now I’m looking at a different
page and a different set of names. However, if that’s not the case
that Mike’s among the names, and it’s not the case that
Smith is earlier in the book, and it’s not the case that Smith is
later in the book, then what should I do, perhaps, in step 12? Well else or otherwise, I should
incept their team just quit. Because logically, if Mike’s not on
this page, and he’s not to the left, and he’s not to the right, that
he must not be in the book at all. And so what do we have here? Well, this is something
that I would call code. It’s not written in C or C++ or Java,
or some other programming language you might have heard of. It’s written in English of some
sort, pretty succinct, terse English. And indeed, it doesn’t follow
any particular vocabulary. I just tried to say each of these
lines as succinctly as I could. So we’ll call it pseudo code,
sort of code-like syntax that happens to be written in
English, so you could write it in most any other language. But what’s important is
a few characteristics. One, just to keep things nice and
orderly, I’ve numbered the lines. Now, I did that manually. Software can certainly do
that automatically for us. But that helps me make sense
of what comes after what. And in particular, it also
allows me, in steps 8 and 11 to make these back references
and sort of go back to and re-execute some earlier lines. But there’s also some similarities,
I’d argue, among some of the verbs and some of the language
here that I’ve used. Let’s see if we can’t highlight
a few of those principles. So one, notice here in
yellow, are a whole bunch of actions, a whole
bunch of verbs, that are telling me to go do something, pick
up, open to, look at, call, open, go back, quit. Those are all very specific procedures,
or we’ll call them functions, shall we say? What else is similar among these lines? Well, here I have if, else
if, else if, and else. So let’s henceforth call
those conditions, or branches. Really, they’re decision points. This is really a
four-way decision point. And I have to go down either
this road or that road or this other road or this fourth
road when making a decision. But what do I use as input
to make that decision? Well, let’s consider these questions,
really, that we’re asking ourself. Is Smith among the names
on the page in front of me? Is Smith earlier in the book? Is Smith later in the book? Well, a programmer would call
those three phrases Boolean expressions, named after someone
by the last name of Boole. And a Boolean expression, by definition,
is either true or false, yes or no. So it’s really a question that has
a yes-no, or true-false answer. And indeed, each of these
yellow phrases has an answer. Because I use that answer,
yes or no, to decide whether or not to execute
some subsequent lines. And in particular, notice that only if
those Boolean expressions, and ergo, the whole branch is true and is
to be taken, only then should I execute lines 5 and 7 and
8, and 10 and 11 and 13. And notice, per the indentation,
that those lines are very deliberately associated with
exactly those conditions. So you only do them if the line
above them is true, or is yes. Lastly, there is this curiosity. And both line 8 and line
11 go back to step three. Well, henceforth, let’s start
calling this a loop or a cycle. Because conceptually, that’s
pretty much what’s happening. I’m being told, in steps 8 and 11,
to go back to some earlier step. But given that I came
from that step, this is a loop, in the sense that
I’m going to keep doing, perhaps, the same thing again and again. Maybe going left maybe
going right, hopefully eventually exiting or calling
Mike, because I’ve deliberately induced some kind of loop here. But these aren’t the only ideas that
we might see in a computer program. And indeed, that’s what that was,
finding Mike Smith in that phone book, that was, effectively, a computer
program being executed by me, albeit, a human. But the code, or the pseudo-code
that drove my thinking and drove my actions is
exactly the same kind of logic that you might feed to an actual
computer, whether it is a PC or a Mac or an iPhone or Android phone. Because what computer programs tend to
share in common, no matter the language they’re written in, are things
like functions and loops and conditions and Boolean expressions. And even more features still, things
called variables and threads and events and even more features. And so that’s what
we’ll do here in on out, is explore not just
programming fundamentals, but explore some of these
fundamentals in the context of some actual languages. First, one of the oldest
languages someone might know, and we’re not going to go with it
as far back as FORTRAN and COBOL or binary or familiar, rather,
we’ll start with this one here. This is a small program,
just a few lines of code, so to speak, written in an
older language called C. A language that’s still very
much in use but it’s older, in that it’s been around
for some decades now. And it doesn’t tend to
have that many features. But it’s nonetheless a very powerful
language, on top of which, so to speak, more recent, more modern
languages have been built. It looks pretty cryptic,
I’ll grant you that. There’s like, this hashtag over
there and these angled brackets and curly braces, parentheses,
semi-colon, backslash n and a few other syntactic curiosities. But what do all those mean? Well, even if unsure at first
glance, like odds are you are, you can probably take a guess
as to what this program does. Suppose I did write this
program as such and then somehow ran this program on my Mac or
PC or phone, what’s it going to do? Probably, yeah, I mean, even if you
don’t recognize all the syntax– I do recognize the word Print
or Print-F, whatever that is. But printing I’m familiar with. And I do see a phrase
here– “hello, world,” but I’m not quite sure
what that backslash n is. So I’m going to guess this program, when
run, is going to print hello, world. And indeed, that’s what it does. There’s a bit of overhead here. Not just syntactically,
but sort of conceptually. Because you, as a programmer, need to
understand, what does this line do? What does this line do? What do these curly braces mean? Why is there the backslash
n there and so forth? But those are all just
things that you learn. For instance, if you’ve
not spoken Japanese as a language or Spanish, or any number
of other languages, the very first time you look at that written language,
it might look like Greek to you, so to speak. And might, indeed, be Greek
if you don’t speak Greek. But that’s just because you haven’t
recognized those patterns before. You haven’t recognized
those symbols before. And indeed, if right now
you’re staring at something that’s completely unfamiliar and
while you do recognize some patterns, it’s not all very
straightforward, that’s just because you don’t
yet speak the language. You don’t yet know the language. You don’t yet know how to program
in this particular language. But what’s exciting about
programming in general is that even though there are dozens, if
not hundreds, of programming languages, in use today, they’re
much more accessible, I dare say, than written
and spoken human languages. Rather, you’ll find many, many,
many similarities among programming languages such that once
you know one and a few, can you relatively easily
bootstrap yourself, teach yourself other languages that
might have newer and fancier features and then just, therefore,
make you more productive? Because at the end of the day,
that’s what programming is all about. It’s about writing software and
therefore, controlling hardware with it to solve problems on your behalf. Whether that problem is to make a
telephone call on a mobile device, whether that problem is to send
an email or search for something on the internet, all of
those problems are solved by controlling hardware with software. And the means by which you do that
is by programming writing code like this, that ultimately
runs on those devices. And yet– and yet, I
can’t help but recall that the computers I know or grew
up with, somehow or other, only understand zeros and ones, right? They only understand the
so-called binary system. And yet, this does not quite
look like zeros and ones. So how is it that I, who can just
barely understand this as a human, can program a computer using
this and have it understand this, even though these, themselves,
are not zeros and ones? In other words, how do we
get this to that instead? Well, it turns out when
writing a computer program, there’s often multiple steps. And sometimes these steps are automated. But sometimes you have to type, you
have to make them happen manually. And in general, the process
of converting this code here, or source code, which tends
to be English-like syntax that does follow a set of standards and use
a certain vocabulary, this being C, the language known as C, I can convert
this source code to machine code, that is zeros and ones that look
like this by running this source code through a special type of program
quite simply called a Compiler. A compiler is simply a
program that compiles code, converts it from source code to machine
code so that the human can write it, but the machine can
ultimately understand it. Consider another example here. This program looks almost kind
of– well, not really the same. But it’s written in a very
similar language called C++. Now, here too, you might not recognize
some of the symbols on the screen. But you probably do recognize
hello world, this time without the backslash n. And even though we have a different word
up here, I/O stream and standard, endl here, odds are it’s a pretty
good bet that this program too does print hello world. And this is already, in simplest
form, testament to the fact that many programming languages
do the same things differently. Indeed, whether you know C or C++ or
something like Java or PHP or Python or Ruby, or any number of
other languages, odds are, at the end of the day, you can actually
solve the same problems using any number of different languages,
much like you, as a human, can express yourself verbally in
any number of spoken languages. But it might just be
easier to communicate with other humans in one language. It might just be easier
and less time consuming to solve problems using one
programming language over another. And this indeed, in part at
least, explains why there are just so many programming languages. We’ve seen just two so far. But many different languages exist. Because as more and more time
passes, and more and more humans use these languages, do they
realize, wow, I could do this better. Or gee, I wish I had this
feature instead or wow, I wish I could type fewer keys
on the keyboard in order just to have my computer say hello world. And so you’ll find that different
languages do things differently even if the end result is the same. For instance, here is a
language called Python. And thank God– this is the
simplest example of the ones we’ve seen thus far– it
really just says what it means. No hashtags up top, no
curly braces, apparently. Just print hello world. And that’s with this
program in Python does. Now Python, it’s worth
noting, is a different type of language in most implementations. That is to say, you typically
don’t write Python source code and then manually convert it to
machine code, zeros and ones. Rather, there is a special program that
you use that’s not called a compiler, but called an interpreter. Because what’s also the
case, with some languages, is that rather than convert
them directly to zeros and ones, that your CPU, your computer’s
brain understands directly, you instead convert them to some
intermediate language, generally known as bytecode. Java is the same way, as
are some other languages. And so with Python,
before running this, I might actually compile it or
convert it to this much more cryptic-looking format. This is not code that I, myself,
would particularly enjoy writing. But this is what’s outputted
when you write Python code. And it’s outputted as
something called bytecode. So this is just an intermediate format
that still is somewhat readable. It’s at least alphabetical
characters and not zeros and ones. So as a human I kind
of sort of can read it. But my computer can
absolutely read this. Specifically, a program called
an Interpreter on my computer, that, I could download to my
Mac or PC or some other device can understand these
lines one at a time. And so generally, a
language like Python might again, be compiled to an intermediate
language like this here, this bytecode. And then it’s this code, ultimately,
that’s read by the machine. But the takeaway for us
is really, quite simply, that there are different
ways of doing the same thing in any number of languages. And even among those languages, do
they get used in different ways? Sometimes you have to compile your
code and then run the resulting machine code, the zeros and ones,
by double clicking an icon or typing some command. Or might you be able to write your
code and not explicitly compile it, just instead interpret it. The steps might feel or
be a little different. But at the end of the day, most
users experience the software in a familiar way, by
double-clicking an icon by running in the name of a command. And for all intents and purposes,
your users or your customers don’t need to know or care what
language something is written in, so long as it is created for
your particular type of computer or your particular operating system. This is why, if you have a Mac, for
instance, and a friend has a PC, you can’t necessarily just share
software and run the same programs on multiple computers. You might each have to buy or
download different versions of the software, one of which is for
Mac OS, one of which is for Windows. And even though those programs might
be written in the same language, they generally have been compiled for or
packaged for different computers, CPUs, or really, different operating systems. But this is just a decision that
the software author, the software developer, or software
engineer, so to speak, simply has to make on your behalf before
shipping his or her software to you. What about other languages? This one here is Java. It too has some syntax of its own. But at the end of the day, it’s
going to do the same thing, print out the screen just hello world. This example here is
another language called Ruby, which is commonly used as an
alternative to some of these languages here as well. And it is even more
simple syntactically, in the particular example, in
that it’s going to put or print on the screen, hello world as well. This one here is written
in a language called LISP. The salient difference here
being these parentheses on the outside, which are just
hinting at a syntactic feature of this particular language. But this is quite simply how
you might print hello world. And then in another language
altogether, JavaScript is this how you might print hello
world to the screen or browser window as well? Now, we’ve certainly only just scratched
the surface of these several languages. And surely these languages
can do much more. And odds are, it’s going to
take many more lines of code. But throughout each of these
language are some commonalities, support for things like
functions and loops and conditions and Boolean
expressions, and maybe things like events and threads
and variables and more. And so rather than get too much into
the weeds of very specific languages, let’s focus here on the
ideas, and let’s focus on these ideas as
graphically and as pleasantly as we can by revisiting that first
programming environment called Scratch. In particular, you’ll recall
that Scratch, just a moment ago, was raining trash down on
my screen in synchronization with the old Sesame Street
song that you might remember. But how was that program working? Well, consider how we might
have gone about implementing some of these basic ideas. There was trash falling from the screen. But what does it mean
to fall from the screen? Well, a screen, recall, is just
a grid of dots, a grid of pixels, a bunch of pixels left-right,
a bunch of pixels top-down. And so to move on the screen or to
animate something on the screen really means just to take an image, whether
it’s a .png or .gif or .jpg or some other format and just move
it slightly, slightly. Maybe one pixel downward at a time. And if you move that image downward
one pixel at a time quickly enough, it doesn’t look like some
very jagged movement. It, to the human eyes, actually
looks like a very clear movement. And so indeed what I was
probably doing in order to make trash fall from the sky
here is it started off screen. And then in some kind of loop,
moved some number of pixels every second or every split second. And the result is some animation. Well, why does the trash, like
the shoe and the piece of trash, actually stop at the
bottom of the screen? Well, odds are, I could solve that
problem with some kind of condition, some kind of logic or
Boolean expression where I ask the computer if you’re touching
the bottom of the screen, sneaker, then stop moving. Or conversely, only if you’re not
touching the bottom of the screen, should you be moving top to bottom. So you can effectively
stop the animation by just using some additional
logic, and asking a question, are you at the bottom of
the screen, yes or no? True or false? Meanwhile, every time I click
and drag the piece of trash into the trashcan, what
was happening while Oscar was emerging from his trash can,
which was another form of animation altogether. But he was also shouting
out, in a little cartoon bubble, the number of pieces of trash
that I’d already deposited in his can, starting at one, then two, then three. Well, he would appear
to be using something you might recall from algebra,
being a variable like x or y or z. And this variable was probably
initialized, or set initially to 0, because we’d put no pieces of trash. And every time Oscar received
a new piece of trash, he probably incremented, or
added 1, to that variable. So 0 becomes 1, which
then becomes 2 or 3. Now, how did I increment that variable? Odds are, there is
some kind of condition, saying if piece of trash
added to trash can, then increase the variable’s value by 1. If it’s called x make
x 1, then 2, than 3. So again, a basic building block. Now, there is more and more trash that
would eventually fall from the screen. And my god, there’s that song
that I still can’t get out of my head, 10 years later. But that, too, was playing on some kind
of loop or some kind of synchronization with the game at hand. So even if, at first glance,
this game seems pretty daunting. And you might think, that
must have taken you like, what, David, eight hours? Well, that is true. It did take me at least that long. And I swear, by far the most
challenging aspect of this game wasn’t getting the logic right, but was
getting that song in of and henceforth, never out of my head. But the key takeaway is, is that
all of this seeming complexity, if you kind of zoom in
and focus conceptually on just individual aspects of this
game or this computer program, it can be reduced to just
conditions and loops and variables and some basic building blocks. And I daresay, if you think about
the software you, yourself, use every day on your phone, on your
laptop or your desktop, odds are, even if you might have no idea
how a browser is implemented or no idea how Excel or
Word or Keynote or Numbers or any number of other
programs are written, if you really focus on just small pieces
of that software, individual features, could you probably start to glean
exactly how the software developers who made the software actually
implemented those features? So let’s now break down Scratch
into some of its fundamentals and start applying some
of these very ideas. Here is perhaps the simplest
of programs that you might implement with Scratch as a language. Surprise, surprise, this is how, in
Scratch, you would say, hello world. Now, in the world of Scratch,
you have a graphical environment where there is, as we’ll soon see, a cat
that actually performs all the action. So it’s much like I, the human who was
performing these actions with the phone book just a bit ago, in the
world of Scratch, by default, is a cat going to perform any of the
commands that you provide in software. We can change the cat to anything else. Indeed, I turned him into
Oscar in that example. But this is what the commands
themselves are going to look like. And Scratch, as we’ll see, has
a whole bunch of fundamentals. For instance, Scratch is going to have
functions or actions or verbs that look a little something like this. This is a puzzle piece,
purple in fact, that’s going to specify that Scratch
should say hello world. Here’s another puzzle piece
that, as you might guess, is going to tell Scratch to say
hello world forever, again and again and again, in some kind of cycle. Meanwhile in Scratch,
this is how you’re going to repeat something a fixed or finite
number of times, 50 in this case. This in Scratch, though
a much bigger block, is how we’re going to
specify things conditionally. If x is less than y,
then do the following. Else, if x is greater than
y, do the following instead. Else, third fork in the road, do
this, some other thing, altogether. And so indeed, you can
really see in this example that Scratch, being graphical in
nature, actually has you programming. Not by typing words
alone on the keyboard and numbering your lines, as I did
earlier with the phone book algorithm. But rather, putting together
puzzle pieces whose shape kind of implies what they do. The fact that this if block
kind of looks like this. And inside of that block
you can put other blocks, apparently, implies that you should
only say that x is less than y if it’s inside of this if else block. And now, notice we have apparently
crammed another if else block inside of this to effectively
create a threw-way fork in the road. And in green here, do we see
some Boolean expressions? Asking the question is x less than y
or greater than y, in these two lines here. And then in orange we have
variables, x and y themselves, which are probably just numbers. So how do we go about assembling
all of these building blocks into actual programs written in
this language called Scratch? Well, let’s go ahead and run
the Scratch software itself. Scratch is not only a
programming language. It’s also a whole
programming environment. It’s a piece of software
unto itself that’s going to allow us, by dragging
and dropping these puzzle pieces, to program the computer. Well, let’s take a look at
the User Interface, or UI. At the top left here is Scratch himself. He lives in this two-dimensional world
that has a height and has a width and currently, by default,
has just this blank backdrop. And he can move up, down, left,
right, and do many more things in that environment as well. What kinds of things can he do? Well, in the middle
of this user interface do you see a whole bunch of palettes
or categories, these being the scripts? And these blue blocks here all
fall under the header of motion. So these are all puzzle
pieces or blocks that somehow relate to Scratch’s motion. Meanwhile, if we click through Costumes,
we could change the aesthetics. And in fact, we could turn
Scratch into a dog or to a grouch. And under the sounds tab, could we
actually explore sounds and multimedia that we can integrate into Scratch? But the blank slate with which we
begin is this big area over here on the right, to which I can
drag and drop these puzzle pieces and actually interconnect them in
order to instruct Scratch to do things. For instance, let’s try. Now, I just know, from
having used Scratch before, where some of these blocks are. And the first one I’m going
to grab is under Events. And I’m going to click and drag
and grab this one here, which is titled when green flag clicked. Because if you didn’t
notice before, notice now that above Scratch’s
two-dimensional world here is not only this blank background,
but also this green flag and green, signifying go, and this
red stop sign, signifying stop. And it’s by clicking either of those
buttons that I can start or stop. Respectively, any program
here that I write. Very similar in spirit
to double-clicking an icon on your desktop,
or typing a command in a prompt on a typical computer. So meanwhile, I have now this
when green flag clicked block. And I want Scratch to say something. Well, I know from having used Scratched
before that the Say block happens to be under Looks, where a whole
bunch of puzzle pieces are as well. And notice what I can do
now is click on say hello, where hello is just the default word. And then notice here, if I drag, notice
how it turns white and kind of glows when I move the block close enough,
as though they’re magnetized? Well, that’s because these two blocks
want to logically snap together. So as soon as I release my mouse
button, will they lock together as such? And now I can double-click
on the text box there, and type hello comma world, and
actually type and any number of words that I might want Scratch to say. Well, let’s zoom out, move my cursor
over to the green flag and click. And voila, the first of my programs. It’s doing exactly what I said. And if you notice, it’s not
stopping to say hello world anymore, because I never actually
had a command that said hey, Scratch, stop saying hello. And so I’m just going to manually
stop this program for now, with the red stop sign up there. All right, so that’s all fine and good. But it’s not all that realistic. Cats do not have speech bubbles
coming out of their mouths. So let’s make it a little more realistic
by moving up here to my blocks, clicking and dragging and
pulling away the Say block. And I can just let it go
anywhere in the middle and it will just
disappear or be deleted. And now this time let me go up to Sound. And oh, this is promising. Play sound meow is
the purple block here. Let me go ahead and do this. And notice it too has
a very similar shape, even though it’s a little longer. And it wants to interconnect
as soon as I let go. Let me go ahead and zoom out
and click now the green flag. [MEOW] Aw. [MEOW] Aw. [MEOW] Aw. So Scratch has just meowed
three separate times because I ran the program three times by
clicking on the green flag three times. Now, that’s a little tedious. And it’s also not very
lifelike if every time I want to hear Scratch I have to
breathe new life into him by clicking the green flag. Wouldn’t this be an
opportunity to leverage one of those principles we looked at
already, that of a loop or a cycle, if I want Scratch to do
something again and again? So for instance, let me go ahead and
poke around under the control box, perhaps. And oh, there’s that repeat block. It defaults to 10, but we can
change that to anything I want. And if I click and drag here, now,
this isn’t quite right logically. Because I don’t want
to play the sound meow when the green flag is clicked and
then repeat something 10 times. So you know what? I’m going to just leave this in
no-man’s land for just a moment. I’m going to click and drag this purple
block away so it becomes detached. And now, notice, you might
think that it definitely is not going to fit inside this
repeat block that’s just not too tall of a space. But notice that the
whiteness is, in fact, illuminated, kind of
saying yes, this is OK. And the shapes do kind of match. And so what’s nice about
Scratch is that so long as the shapes are in
accordance, can you let go? And the containing block will grow
to fill that particular shape. And even though it looks like
we’re now completely out of room within that Repeat
block, we can actually drag and squeeze more and more blocks
there, and the block will grow to fill. So let’s just do this three times. And now let’s go ahead and connect
this to when the green flag clicked. Zoom out, click the green flag, and– [MEOW] Huh. Now, I am pretty sure logically this
says when the green flag is clicked, repeat the following three times. Play sound, meow. And yet, unless I’m not hearing
things right, I only heard one meow. So what’s wrong? Is this a bug? A mistake in Scratch? Did MIT screw up? Or is this a bug in my code somehow? Did David screw up? Well, let’s consider the options. Let me go back to that sound
category, and see if there’s maybe a different block I should be using. Now, I’m only just now
reasoning through this. Right? Because I’ve written a program
that I think should do one thing. I have realized it did
not do what I intended. So is it my fault? Is it the software’s fault? And maybe am I misunderstanding the
functionality of some of these blocks? Now, what do you notice here? Scratch supports drumming,
apparently, and other notes. But up above, it can play sound meow. Or more precisely, it can
play sound meow until done. What happens if I use that one instead? Let me try. Let me go ahead and drag this one
away to effectively delete it. And then drag this one in its
place so it too still fits. Now, let me go ahead and
click that green flag. [THREE MEOWS] Interesting. That time I did hear it all three times. Let’s just be sure. [THREE MEOWS] OK. I definitely heard it all
three times that time. But why? Well, with the previous
version, which I’ll restore here by going back to the way it is,
notice that the program was actually performing correctly. Correctly, so far as the
definition of these blocks go. Just incorrectly, with respect
to my own expectations. Computers, recall, are really fast. Right? This Mac here might be a
gigahertz or two gigahertz fast, which means it can do one or
two billion things per second. And that’s a lot. I mean, I am, by far, the limiting
factor as the human in this equation. So maybe, just maybe,
Scratch was literally doing what I told it to do which
was when the green flag is clicked repeat the following three times But Scratch, being a computer
program, is just so fast. It played the song or
the sound three times. But it played it so fast
within this Repeat block that all three of those meows
were effectively overlapping. So we only heard one of
them because all three were being played pretty
much at the same time, because that loop was
going around so quickly. But by contrast, with this other puzzle
piece, play sound meow until done, now I’m compelling the
program to just give me a moment to listen to the
entirety of that sound before you proceed to the next
iteration, or the next cycle. And then one more pause
until the next cycle, so that I can hear it three
and exactly three times. So such a simple program
and such a simple example. And odds are, whenever
you’re writing code and it doesn’t behave as you intend
and you look at it and you think, no, that is right. Eh, that’s not necessarily the case. And indeed, bugs, or
mistakes in one’s code, are going to be perhaps one
of the most common and one of the most frustrating experiences
one has when first learning to program. But these are the kinds of things
that, with practice, go away. And so like I just did, you
reach instinctively, here on out, for the right block, as
opposed to the incorrect one. Now let’s see what else we can
do here when it comes to sound. What about not just playing
a sound, but adding a bit of, shall we say, animation here? Well how might it go
about making this cat moo? Well, let me go ahead under
Control and do something forever. Because I just want
this cat, ultimately, to move back and forth,
back and forth forever. That of course, involves motion. So let me go to motion. And all right, I like the sound of this. Move 10 steps. And 10 steps is probably going to be
10 dots or 10 pixels on the screen. Well, then what do I want him to do? Well, let’s see what happens
first if I click the green flag. OK. So not quite what I intended. Because he’s not really moving anymore. And this is actually a feature, being
designed for aspiring programmers and not to mention, children. Scratch realized, or rather, MIT
realized, that in designing Scratch, probably shouldn’t let the
cat go 100% off the screen. So we can just click and drag him
back into view here if we want. But of course, program’s still running. So he’s just going to
run away from us anyway. So how do we fix this? How do we make him go back and
forth and back and forth without me having to manually intervene? Well, what about some kind of condition? Let me poke around the Control blocks. And let me actually grab
one of these conditions. And instead of moving 10
steps forever again and again, after making 10 steps
let me ask a question. Am I touching the edge? Because if so I don’t
want to keep going. So to ask that question, let
me go under sensing here. And indeed, let’s see. This one here, Touching,
sounds about right. But I don’t want this
to have anything to do with the mouse pointer or the
cursor, but rather, with the edge. So by this drop-down, let me change this
Boolean expression to Touching Edge. Drag and drop this over here. And this certainly doesn’t seem to fit
size-wise, but shape-wise, it does. So if I let go, the block, as expected,
grows to fill that particular Boolean expression. And now, what do I want to do? Well, now, maybe if
I’m touching the edge, I should turn some number of degrees. 15 doesn’t feel quite right. I want to turn all the way around. And I know that to be 180 out
of 360 total possible degrees. And now let’s see what happens
when I click the green flag. OK. So better. He’s not just running off the screen. And now, I don’t have to click
and drag him back into view. But of course, turning 180 degrees
isn’t quite the visual I want. We don’t really intend for the
cat to be flipping upside down. So maybe there’s a better way. This, definitely a bug aesthetically,
but perhaps not functionally. But there’s still an opportunity here. Let’s leave that bug alone. Let’s pause the program
with the red stop sign here. Let me go into sounds, just for fun. It’s hard to justify
this academically here. But let me go into this sound
bar, where you can hear– [MEOW] –not just the default meow, But you
can also click on the microphone. And let me go ahead and
give my best example of cat running into the side of a screen. Ouch! And stop that. You can now see a waveform,
or a graphical depiction of what my voice apparently sounds like. Let me go ahead and click and Delete the
moments of silence beforehand and also a little after. And interestingly, it seems like
I’ve really mustered some energy and then said ouch. But we’ll leave the rest
of the wave together. I’m going to go ahead and
name this recording ouch. And now notice if I go back
to Scripts, and I go to Sound, now ouch is available from the
drop-down as one of my Sounds. And let me go ahead and put that not
outside the condition, but inside. So that now, if I’m
touching the edge, not only do I want to wrap around 180 degrees,
I also want to play this sound. Let’s see what my newest
program now sounds like. Ouch! Ouch! OK. Ouch! OK, maybe not very cat-like. [OUCHING CONTINUES] A bit more like human
hitting the edge of a screen, but at least correct, that
180-degree detail aside. So notice what’s guided my
building of this program. I didn’t set out and drag all the
possible puzzle pieces at once. I didn’t record the sound
in advance all at once. I instead took the proverbial
baby steps, very small, incremental steps, starting
with something very simple, just a forever loop, and
just have the cat move all the way to the side of the screen. Then did I add to that the
feature where he would actually wrap around conditionally,
in the form of that If block. And then did I go in and add the
third feature, which was this a silly human ouch-like sound. But the key takeaway there
is that it’s much easier, I’d argue, to write complex programs
if you start off by breaking them down into those component parts and consider
individual milestones for yourself, so how you might set out implementing
just one feature at a time, as opposed to everything. And indeed, if you consider real-world
software that use on your phones or your computers, certainly did
Microsoft not set out to build, in one day, an entire
word processing program called Word or an entire
spreadsheet program called Excel. Odds are, their software
developers back in the day, the very first version of the software,
did they write just one small feature? Maybe you double-click
the icon and it just opens a big rectangular
window that does nothing, but at least they had the
beginnings of the software. Then maybe they added support for
just a column, maybe two columns, maybe any number of columns
in any number of rows. And so there too, might
Microsoft, among other companies, have set milestones for themselves
such that the end result is impressive and amazingly complex. Maybe even millions of lines
of code in C or C++ or Java, or some other language. But they didn’t start out by
trying to tackle that all at once. Just like I, when
starting out this program, did not set out to
implement it all at once. Now, with that said, let’s
open a couple of examples that have already been written
and see what they do themselves. This, then, is Pet the
Cat, a program I wrote in advance that still stars
Scratch and already has these puzzle pieces assembled. So what does this do? Well, lets go about
reading code, which is another side of software development. Most software programs,
certainly the largest of them, are not written by
single humans, but rather by teams of humans
who are collaborating. Indeed, even though you might have
the mindset or the expectation that programming is largely
a solitary exercise done late at night with lots of caffeine and
darkness and a flickering computer screen, the reality is it’s an
incredibly collaborative profession. It’s an incredibly collaborative hobby,
for some, whereby you work either alongside a whole team of
individuals or remotely with a whole team of individuals
collaborating at whiteboards, collaborating virtually, and
ultimately reading each other’s code. Not only to understand what
someone else has written, but to enhance what he or
she has done by building atop their own lives of code or in
this case their own puzzle pieces. So let’s try exactly that. And let’s read this code
that I’ve already written. When the green klag flicked– [LAUGHS] When green flag clicked,
forever do the following. If touching the mouse
pointer, then play sound meow, and then wait for two seconds if
touching mouse pointer, then play sound meow, then wait for two seconds. So what’s this program going to do? Well, its title kind of gives it away. But if I click the green flag,
nothing seems to be happening. But notice that all these
puzzle pieces are now highlighted in yellow, to indicate
that the program is indeed running. But nothing’s happening until– let me move my mouse
pointer over the cat. [MEOW] Ah. Let’s try that again. Interesting. So this time, rather
than meowing forever, Scratch is only meowing when my
mouse pointer is touching him, just like this. [TWO MEOWS] So this is kind of like the digital
equivalent of petting the cat. Well, what about the opposite? What might it be like to write a program
where you don’t want to pet the cat? Well, for that example let’s open Don’t
Pet the Cat, which now looks like this. So this program’s a
little more complicated in that it has not just an
If block, which asks one question, but an If Else
block, which asks a question and then behaves one way if it’s
true and another way if it’s false. In this case, we forever if
touching the mouse pointer, then play sound lion five– so like the fifth of our lion sounds– until done. Otherwise play sound meow,
and then wait for two seconds to give the human a
chance to sort of orient himself or herself
and pet the cat again. So let’s see what happens here. But consider that I’ve induced,
this time, an infinite loop forever. [MEOWING] Every two seconds. What about not touching the cat? What was the imperative there? Let’s try moving the
cursor closer, closer. Closer. [LION ROARS] That is why you don’t
want to pet the cat. So in that case, did
the lion sound only play when the cat was actually
touched with the mouse pointer? Well, what about variables? What about programs
in which you actually want to count something, as
in the case of the sheep? Of course, in the human world it’s often
we humans who are doing the counting. But let me propose that it’s sheep who
deserve a chance to count themselves sometimes. And so here we have counting sheep. And indeed, this is
literally a sheep counting. And how is he doing that? Well, over here, since I’ve
already clicked the green flag, do you see highlighted the
program that he’s running? When green flag clicked,
he said counter to zero. So this orange puzzle piece
is like a custom piece that I made in advance
via the Data Palette. And it allows me to create a variable
called anything I want, x or y or z, or frankly, more descriptively
in English, counter. Because what it is, I want a variable– something that stores a value– that does counting. I’m going to call it counter instead
of the more generic x or y or z. And then I’m forever
going to do the following. I’m going to say not hello
world or some other phrase, but rather, the value of the counter. So I seem to have dragged and dropped
the variable’s puzzle piece right on top of the Say block for one second. Then I’m going to wait for a second. Then I’m going to
increment the counter by 1, so change it by 1, by
adding 1 to its value, and then just keep doing this forever. And so the sheep is now going
to count up and up and up and up and up, seemingly forever. If that gets a little boring, I suppose
we could always remove the weight block and just have the sheep count again
and again and again and again. And so now there’s no blinking effect. Because the speech
bubble isn’t going away, but the number’s indeed
counting a little faster. Because we’re saying it
for one second at a time. But it’s one thing to use
puzzle pieces that MIT has created for us, these conditions,
these loops, these variables. What if my programs start
to get sophisticated enough and my ideas start to get
grand enough that I’d really like to start creating
my own puzzle pieces, puzzle pieces that maybe MIT didn’t
envision programmers needing? Well, turns out in most programming
languages you can do exactly this. You can create your own
custom functions or procedures by assembling new functionality out
of other existing puzzle pieces. And so in this way, can we use existing
puzzle pieces, kind of wrap them up with a new name, with a new shape, and
actually then give that shape a name so that henceforth, I don’t
have to worry about using all of those individual puzzle pieces. I can use just one newly-named
one to achieve some goal. Let’s consider the
following example, cough 0. This is an example, per
the puzzle pieces up here, that simply instruct
the cat to cough three times, waiting a second in between. Say cough for a second, then wait. Say cough for a second, then wait. Say cough for a second then wait. Of course, if I click green flag
on here, you’re going to see– as you might expect– the cat is unfortunately
coughing not once, not twice, but three times in total. This is clearly an
opportunity for better design. And you can see the surface of an
opportunity for better programming. This is not a good design. It’s a correct design in that
it will say cough three times and wait a second in between. But it’s not a very good design
because it kind of sort of looks like I copied and pasted
these puzzle pieces, much like you might do with your
own processing program or email client or the like. I’ve just taken a couple of puzzle
pieces and said, copy, paste, paste. And maybe I’d do it
even more if I wanted Scratch to cough more than three times. But we can do better than
that with programming. We can use loops instead. So in cough one do we have
an alternative example, wherein the cat now is
going to cough three times, but by way of a repeat block, a loop. Now, the code is functionally the same. But this would be
arguably better designed. Because now if I want to change what the
cat is saying, or when he’s coughing, maybe I want to spell it differently. Or I want him to wait some number
of seconds that aren’t just one. Well, I can just make
a change in one place rather than in like, six
different puzzle pieces. I can focus on just
the one instance here. But suppose that it’s coughing
that is the puzzle piece that I want to create and use
here on out, so I don’t have to remember that
that is how you make a sprite, a character
on the screen, cough. Because in addition to
having one cat like this, we can actually have multiple
cats, or a cat and a dog or a cat and a dog and a grouch, or any
number of other characters. So this is to say, it would
be nice, once I figure out how to do something in a
programming language like Scratch, I’d really like to save that
functionality in a custom function, in a puzzle piece that I have
made so I can use it elsewhere. Not just for this sprite
or cat, but for others. So in cough two do we now
have an example that defines a new puzzle piece called cough? It’s purple in nature. I grabbed it from the
More Blocks Palette. And you’ll notice that I
defined, with this special puzzle piece, a new piece called cough. Beneath that block is
a number of statements. Say cough for one second, wait
for one second, and that’s it. But now, above this is my new program. And this is where things
get really interesting. Because now I can drag and
drop when green flag clicked. I can still grab a Repeat block
and do something three times. But what do I want to do three times? This time I just very
simply want to cough. And so now, thanks to my Custom
puzzle piece being defined here, I now have access– under More Blocks– to a custom puzzle
piece called cough that not only says what it means– which is nice and
descriptive and easy to use– it also hides or, so to
speak, abstracts away all of the underlying implementation
details or the complexity, relatively speaking, of what it means to cough. So that all I or a friend who
is using this puzzle piece has to worry about here on out is
that the puzzle piece is called cough. Does not matter how it’s
actually implemented. And it turns out that in
programming languages, just like Scratch, you can make
one additional improvement on this. Rather than have to rely
on your own repeat block, notice what else you can do. In this case, I’ve refined my
implementation of this custom puzzle piece, cough, to take what we’ll
call and what a programmer would call an argument or a parameter,
some number of inputs that influence the behavior
of the puzzle piece. Now, we’ve seen arguments or
inputs all over the place thus far. Move some number of steps. That’s an argument or a parameter. Say something. That’s an argument or
a parameter, because it influences the behavior of the Moo
block or the Say block, respectively. So how do I do that? How do I make a cough puzzle
piece that doesn’t just cough once, but coughs 2
times, 3 times, 10 times, however many times the user
of that puzzle piece wants? Well, would use the
puzzle piece like this. And notice there’s now a little
white box where I can type a number. But it turns out you can parameterize
your own custom functions by using a special puzzle piece
like this, that has not just the name of your custom
function, but also a placeholder for a variable, really. A variable being another way of
thinking about a parameter or argument. And so what I’ve done with n– and
I’m just calling it n for number, but I could have called it anything
I want, x, y, or z or something else. I can now repeat in the implementation
of cough that many times. I don’t have to hard code 3 anymore. I don’t have to hard code any number. I can drag and drop a copy of n here. So that whatever number the user
of my puzzle piece types in, that’s what will be used
for the Repeat block. And that’s how many
times this puzzle piece will say cough and wait one second. And so this now is just a small
example of what it’s really like to program and solve problems. The problem, to be fair,
is relatively small here, in that we just want the cat to
cough visually on the screen. But the opportunities that
problem affords really are captured in these several examples. With these examples, do
you see me starting out in the simplest, most naive
and correct way possible? But it wasn’t very well
designed, because I was just kind of duplicating the Say
block and the Wait block and then the Say block
and the Wait block and the Say block and the Wait block. It’s just, it already sounds tedious. And indeed, it’s poor form. But then I factored that
out with the repeat block. And then I introduced a custom
puzzle piece whose second version also allowed me to parameterize it. And so the fun in programming,
and the opportunities to become a better programmer are
illuminated with examples like this. To be good at programming is to
notice opportunities like this, to actually take
opportunities like this, to factor certain common code out, to
abstract it away or bundle it inside of custom puzzle pieces or
black boxes, so to speak, is what’s evidence, generally,
of not just correct code, but good design and well-designed code. Now, these are just a few of the
features you might see in a language. There are certainly a few others too. Let me go ahead and open up
an example here called Thread. And you’ll see, as promised, Scratch’s
support for multiple sprites, multiple characters. And this is the funny thing. Because thus far, almost all
of our programs or indeed, all of our programs, have had just
one cat or one sprite, and therefore, really one thread, as we’ll call it. They’re only doing one thing at a time. With this example, per
the cat and the bird, this example will
actually have two things happening at once simultaneously. And there’s some kind of
interrelation between them. Notice that the cat
is kind of stealthily, and very predictably,
following the bird. This is not random. But oh, no, please, getting– [LIONS ROARS] Not exactly what we
were hoping for there. So there was clearly some kind of
interaction or dependency there. So what was going on? Well, notice that the bird is
highlighted in the bottom left, as has been our cat previously. And so this, at top right, is the
program driving the bird’s behavior. When the green flag was clicked it
went to negative 150 and positive 150. It turns out that blank world
in which Scratch lives can be addressed with coordinates, x and y. So some number of pixels left or right. Some number of pixels top and bottom. And I just decided arbitrarily
to start it at negative 150, 50 with some trial and error. I then had it then point
in a 45-degree angle, just because it starts
off in an interesting way. And then I forever told
the bird do the following– if not touching the cat, the other
sprite, then move three steps. And if on edge, bounce. Which is a nice one-line version, one
single-puzzle-piece version of the if construct we did earlier where
bounce means turn 180 degrees. But I’ve used a puzzle piece
that comes with Scratch to achieve the same result. So that’s it. If the bird is not touching the
cat, then just move three steps. And if you’re on the edge, bounce. So just keep bouncing around. Just keep moving. So the bird doesn’t put all that
much thought into what it’s doing. The cat, meanwhile, is kind of clever. The cat, when the green flag is clicked,
goes to negative 160, negative 160. So I made sure that they don’t
start too close to one another. I then have them point
in a random direction. Scratch, like a lot of languages,
supports random or pseudo random numbers. Where just like a human can pick a
number, like 50, that’s sort of random, so can a computer pick a
number between 91 and 179. And that, you might notice, is between
essentially a 90-degree window. And just because I wanted
the cat to at least start off at some range of angles. Then I wanted the cat
forever to do the following. If you’re touching the bird,
place sound lion 4 this time. Then stop this script. So I wanted to make
sure that the cat didn’t keep moving if it touched the bird. I wanted the game just to
stop or the animation to stop. And so I explicitly say stop,
so that the human doesn’t have to click the red stop sign. But then here’s the cleverness. Forever point toward the
bird and move one step. So the cat has this
very stealthy advantage that no matter where the
bird is, and remember, the bird is kind of bouncing
all every which way, bouncing randomly off the
walls, ultimately, the cat is slowly but surely tracking the
bird by always pointing toward it and moving one step. And so even as the bird is sort
of aimlessly flying around, the cat is very slowly but very
methodically, very algorithmically, if you will, pointing
itself toward the cat. So if we rerun this program,
you’ll see the cat’s indeed exercising exactly that logic. And the bird’s kind of getting away. But again, the cat is
pivoting to follow him. And he keeps going and
keeps going and keeps going. And we’ll again find him right– [LION ROARS] There. Now, we could give maybe the
bird a bit more of an advantage. Let me go ahead and click on the bird. And how about instead
of moving three steps, let me have him move six
steps, twice as fast? Click the green flag. Very nice. So the cat is still
moving at the same rate. Unfortunately, it’s still
moving toward the bird. And the bird is not
taking that into account. We could give the advantage
to the cat instead. So if I go back to the cat script
and instead of moving one step, how about 10 steps, and
let’s see what happens now. [ROARS] Cat pretty much seeks out the bird. A bird-seeking cat. How about one more example
that speaks to the height of the ceiling with an environment
like Scratch, just how much you can do using some
basic fundamentals. This time we have a couple
of our puppets here to star. Notice one is blue, one is orange. And one is called playing Marco
Polo, it would seem, if familiar. This is a game that kids might play
whereby if one person says Marco, the other kids are supposed to say Polo. And then one is supposed to find
the other in that particular game. But we’re just using it as an
example of something called Events. So it turns out, per the last example,
that a computer can effectively do multiple things at a time,
thanks to multithreading, where a thread is an
independent thread, so to speak, of execution, that is happening
in parallel with something else on the computer. And especially nowadays, now that
computers have multiple cores or CPUs, they can literally do
multiple things at once. And even if they can’t, computers
are so much faster than use humans that even if the cat and bird aren’t
technically moving at the same time, even if the cat gets to move a bit
and then the bird cat, then the bird, the fact that that’s
happening so quickly means my human eyes
probably won’t even notice. So for all intents and purposes,
a multithreaded program is indeed doing multiple things at
once, just like our past example. But sometimes those threads
might want to inter-communicate, not just pointing themselves at each
other, but actually sending messages. And notice how this can work. When green flag is clicked, let’s have
this puppet forever do the following. If the key space– so the space bar is pressed– then say Marco for two
seconds, as per this game. And then broadcast
something called an event. An event is like sending
a message wirelessly that only computers can hear. So it’s not saying just the word, Marco. It’s also transmitting a
signal called an Event. And so long as the other puppet has been
configured to listen for that event, then it can respond to
the first puppet’s action. So the orange puppet is going
to say Marco and then broadcast this so-called event. The blue puppet, quite
simply, is going to do this. When I receive Event, say
Polo, for two seconds. So in other words,
this blue Muppet is not going to do anything when
the green flag is clicked. There is no such block there. Rather, when I receive Event, that
secret wireless signal from some other sprite– in this case,
the orange Muppet– the blue Muppet is going to
say Polo for two seconds. And so notice the dependency we’ve
created between these two guys. When I now click on the green
flag, nothing appears to happen. But the orange Muppet, remember,
is listening for my space bar. And so as soon as I hit it,
he says Marco and the blue guy hears it and says Polo. But the only thing listening for
my key press is the orange puppet. The blue puppet, meanwhile, is
only responding to the Event emitted by the orange puppet. Now, this allows us to implement
this simple little game with puppets. But this idea that one thread
can convey a message to another is what’s ultimately compelling. Surely I could use that in
more complicated programs as a mechanism for having
two sprites interact somehow. Not to follow each other around on
the screen like the cat and the bird, but maybe exchange
messages of some sort. So that something only
happens to one sprite if something has just
happened to another sprite. Woo. Well, that was Scratch. This is just one programming
language, and it’s graphical at that. And indeed, programmers
in the real world don’t typically write software by
dragging and dropping puzzle pieces. Rather, they write
textual lines of code, like the C and C++ and Java and Python
and Ruby code that we saw earlier. But the ideas that they write down
and the ideas that they leverage are functionally identical
to so many of the ideas that we’ve seen here in Scratch. What Scratch does for
us, for our purposes here, is just get rid of
things like the hashtag symbol and the curly braces
and the parentheses, and so many other syntactic features
that are really just distractions. And necessary for the
language as vocabulary, but not necessary to
understand the ideas. So if you walk away today with an
understanding of what functions are and loops and conditions,
Boolean expressions, variables, and perhaps threads and events,
and some of the other features we’ve seen evinced by Scratch, do you
have really a fundamental understanding of what it tends to be like to
program in fairly common languages? Indeed, we focused on one
type of programming language here, imperative or
procedural programming. And there’s other worlds out there. There’s object-oriented programming. There is functional programming. But the end of the day, the key takeaway
is that in those and these languages, are there are generally these
principles, these fundamentals, these building blocks as embodied
by the literal puzzle pieces here, with which you can assemble
solutions to problems by using very small problems solved with
these puzzle pieces and build, on top of those solutions, even more
and more sophisticated solutions. Still consider, after all, where
we began, looking at Oscar Time. That is a game where you
have to rack up a high as high a score as possible by
clicking and dragging and dropping trash that’s falling from the sky
into the trash before the game ends. But what does that even mean? Again, if you zoom in to the
lowest level at the puzzle pieces and the building blocks
that compose that program, there is just a loop that
was making the trash fall. And there is just a variable
keeping track of the score. And there was an If condition
raising the lid of the trash when the cursor got close enough. And so all of the complexity of that
particular game, at the end of the day, can be reduced to these
and other basic primitives. As to what other
languages are out there, this is just a slice
of the possible list. But on the screen here, would you see
some of those familiar ones again, C and C++, but so many others that are
being used currently or have been used in the past. And the dot, dot, dot suggests
that there’s so many more. In fact, if you’d like to
take a look in Wikipedia and be completely overwhelmed
by the many languages out there, you’ll be impressed by just how many
we humans have created over time. But at the end of the day, there
tend to be trends in this industry. And when you are a programmer
or a software developer or a software engineer in the
real world working for a company or really just working for a
hobby, will you, as a programmer, tend to have just one or a few
languages that you tend to reach for? So becoming a programmer
is not about learning that list of programming languages. Even I only know a tiny
fraction, probably count them on one or two hands in total. But you tend to want
to introduce yourself to different types of
programming languages. So that when something new comes
along or some new device comes along that you want to program for, you have
the basic ideas and principles in mind and simply need to pick
up a bit of new syntax. And as such, it’s a little
bit easier, I daresay, than learning a new spoken
or written human language. Because these languages tend to be more
narrowly defined with fewer keywords. But the ideas persist, even as
some of those particulars changed. To wrap for now, I thought we’d
take a look at an oldie but goodie, a program written by one
of our own former students that synthesized music,
synthesized loops, then synthesized
conditions, all to create a wonderfully-animated conclusion
to this look here, at programming. [MUSIC – THE WEATHER GIRLS, “IT’S
RAINING MEN”] WEATHER GIRL ICON 1: Hi! WEATHER GIRL ICON 2: Hi! We’re your weather girls. WEATHER GIRL ICON 3: Uh-huh. WEATHER GIRL ICON 2: And
have we got news for you! WEATHER GIRL ICON 1: You better listen. WEATHER GIRL ICON 2: Get
ready, all you lonely girls, and leave those umbrellas at home. WEATHER GIRL ICON 3: All right. ALL (SINGING): Humidity’s rising. WEATHER GIRL ICON 2: Mm, rising. ALL (SINGING): Barometer’s getting low. WEATHER GIRL ICON 2: How low, girl? WEATHER GIRL ICON 1: Uh-oh. ALL (SINGING): According
to all sources– WEATHER GIRL ICON 1: What sources, now? ALL (SINGING): The
street’s the place to go. WEATHER GIRL ICON 2: We better hurry up. ‘Cause tonight, for the first
time, just about half past 10. ALL (SINGING): Half past 10. WEATHER GIRL ICON 2: For
the first time in history, it’s going to start raining men. WEATHER GIRL ICONS 2 AND
3: Start raining men. WEATHER GIRL ICON 2: It’s raining
men, hallelujah, it’s raining men. Amen. I’m going to go out. I’m going to let myself get– ALL: Absolutely soaking wet! WEATHER GIRL ICON 2: It’s raining men! Hallelujah!

, ,

Post navigation

17 thoughts on “Programming – Understanding Technology – by CS50 at Harvard

  1. Cute animation at the end it made me bust out laughing thanks I needed that and great explanation for beginners in programming.

Leave a Reply

Your email address will not be published. Required fields are marked *