[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!
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.
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!