SEAN WALKER: Hello everyone, good afternoon. This is CS50, week 1, slash week 0, part 1, depending on how you're counting things. I'm Sean Walker. I'm a senior in Hopper, and I am your head teaching assistant. JANA VRANES: Hi everyone, my name is Jana. I'm the head course assistant for CS50 this year. SEAN WALKER: So yeah, we'll be seeing you guys in office hours. I'll be maybe seeing some of you in section. Can't wait to start the semester. We're very excited. There's so much cool things in store for you this semester, including this Saturday, there is a great event-- one of my favorite of the year-- which is called Puzzle Day. And maybe Jana will tell you a little bit more about that. JANA VRANES: So every year, CS50 partners with Facebook to organize Puzzle Day. Puzzle Day is this really fun event we put together. It's basically just like a fun afternoon slash evening that you can spend solving puzzles with your friends. This event is-- of course, all of you are invited and encouraged to come, but it's also open to anyone from Yale. So please feel free to bring your friends, bring your roommate. And the puzzles aren't CS50 or CS-related. So it's really open to everyone. And we will have super-cool prizes for the winners of the event, as well as a raffle. So yeah, make sure to come. It's this Saturday. It's going to be in Hillhouse 17, which I'm sure most of you know where it is. Yeah, it's right up there. And then one more announcement we have is that, next week, in the same time slot, Benedict, who is our professor of CS50 here at Yale, will be holding a-- he's right over there-- he'll be holding a hot takes CS50 tutorial right here in this room, from 4:00 to 5:15. So if you can come, please do. It's going to be just a lot of helpful advice, things you should know about the course. But it also should be recorded and available online if you can't come. Thank you, everyone. Have a great semester. [APPLAUSE] DAVID MALAN: So good to see everyone again. So this is a continuation of where we left off last week. Which, recall, was a look at computational thinking, where we tried to more methodically start thinking about problems, and start to leverage some of the intuition that you might have had with things like phone books and the like, to start solving more interesting problems. And in fact, Puzzle Day is ultimately about exactly that-- problem-solving. And indeed, as Jana said, it's not about computer science. There's no computers even required, or programming required. It really is just about taking input and producing outputs. And in this case, the inputs are the puzzles themselves. The outputs might very well be some fabulous prizes. But it really is meant to be an opportunity to bring you and some of your classmates together right at the start of the term, whether they're taking or not taking CS50, and really just think hard about some interesting, fun problems, and then sort of delight at the end as to who got as many of them as possible. But you'll recall that when we started framing problem-solving like this, it first required that we represent those inputs and outputs. And there's any number of ways we can represent inputs to problems. Like the number of people in this room, that's an input-- each of the bodies in this room. And we could count them sort of old-school like we did last time, or perhaps a little more methodically. We might think of the inputs, though, not as being physical as much as they are digital. Right? Recall, we introduced binary, which really is just an abstraction on top of electricity-- either being there or not being there, one or zero, true or false. And so we came up with a number of ways last time to represent information and recall this theme of abstraction we had the electricity sort of literally at the ground floor, then we had this layer of binary-- zeros and ones-- above it. From there, we could represent decimal, and another base system if we wanted. We could represent letters through ASCII, or we could represent emoji through Unicode. If we just thought about those bits in a different way, we could actually use the same zeros and ones to represent colors. And from colors, we get pictures. And from pictures, we get movies. And so there is this sort of hierarchy, this layering of one concept on another, so that we can start thinking about problems at this level, and just take for granted that someone else before us figured out how to actually map it to physical things like computers. So where does that leave us? Well turns out abstraction can be both useful and not so useful. And I thought we could explore this by way of just a couple of problems. The first of these requires that we take advantage of the white pieces of paper that hopefully you're holding in your hand. If you don't, any piece of notepaper suffices. Or just raise your hand, or one of us can run over with a piece of paper. You just need that plus a pen or pencil. And if we could ask for one brave volunteer who's comfy appearing on stage and the internet, we need you to come on up for just a moment. Can't distinguish hands asking for paper or hands asking for volunteer-- volunteer? Yeah, OK, come on up. What's your name? AUDIENCE: John DAVID MALAN: John, nice to meet you, David. All right, so John here is going to see in just a moment a picture. And John is then going to take on the role of a programmer, if you will, an expessify, step-by-step, how you all, as the computers, if you will, will execute that program by applying pen or pencil to paper. And the goal is for John to be as precise and as explicit as possible. You can say anything you want, but you can't make any physical gestures. And the goal is for all of us to transcribe, perfectly, exactly what it is that John is describing. So let me go ahead here and just temporarily mute my image, if I may, so that John and only John and I know what the picture is. And I'm going to ask that you draw this for the audience, verbally. Execute. And go ahead and right it into here. OK, just don't hit the keys, or this will spoil something. AUDIENCE: So start with the vertical line down the middle. DAVID MALAN: OK, a little louder. AUDIENCE: Start with the vertical line down the middle. Then two lines jutting out from the bottom-- well, start with one line at the right side, at an angle, about 30 degrees up-- 30 degrees from the horizontal. Just draw a line from the right, and then do the same thing on the left side. All the lines should be equal length. DAVID MALAN: By the way. [CHUCKLING] AUDIENCE: Yeah, after the fact, yeah. Then, at the end of those two lines that you drew, draw two more vertical lines, going straight up, yeah. Then, draw lines that will connect those two previous vertical lines, and connect them at a point. Then, draw a line that connects the three vertical lines together. DAVID MALAN: Good? All right, end program. So a big round of applause for John for coming on up, if we could. Thank you. [APPLAUSE] Give me just a moment to plug back in here. All right. So, if the staff wouldn't mind, could we just collect a random-ish sample of the answers here, just grabbing a few. We don't have to grab them all. No, OK, you're refusing. OK, who's willing? No? OK. Over here, thank you. Sorry for reaching. OK, thank you. OK, thank you. OK, little shy. Thank you. OK, sure. Thank you. OK. And let me get one more from the right-hand side. Thank you. All right. Thank you very much. So suffice it to say, at quick glance, it looks like there's been a number of interpretations of what John was prescribing. And that's fine. Thank you, Sean. Let me go ahead and lift up just a few of these, and then consider how we got to this point. So here is one that I'll project. Maybe it goes this way. Let's see. OK, here's one that's maybe a little more kite-like. OK. This one's pretty similar. This one got a little frilly, or a little on undo, undo, undo. [LAUGHTER] Maybe. OK, so this one looks a little more house-like, perhaps. OK, but it looks reminiscent of the same length line someone was-- that John prescribed. This one looks three-dimensional-- very nice. This one, less so. [LAUGHTER] And let's take a look-- actually, it looks like we got one more that has a bit of 3D to it. So let me go ahead and go back to what John alone was looking at. And in fact, what he was describing was this. So it looks like a few of you. So a round of applause for those of you who did get the-- who did get, frankly, the cube, which was a word I noticed you didn't actually say. But that's fine, because John was trying to be ever-so precise, like a computer might need to be, in specifying exactly what line needs to be drawn, and where it needs to be drawn, how long it needs to be. But notice just how much harder that problem was without John just indulging in the luxury of saying, hey everyone, draw a cube. Now, there's some ambiguity, to be fair, in just saying, draw a cube. Because which way is it rotated, at what angle? So he probably would have had to specify. But that's all an abstraction is. We all know, intuitively, what a cube is, in this room. But when you really start to think about it, well, a cube is really like a diamond shape on top, and then two more on the sides, and everything lines up with equidistant lines. So there's a specificity required, where you really get into the weeds, so to speak. And I'm sort of painting a picture down here, because those are the lower-level implementation details, like when we discussed binary. So in this case, maybe abstraction would have helped. It certainly is how we would think about this. But how would a computer do this? Odds are a computer would paint this picture quite like John was prescribing, putting down the equivalent of a pen or a marker, and then moving up, or down, or left, or right, maybe going up at one point to then move that pen or ink elsewhere. And that's the level we're going to start thinking about in just a bit today when we introduced Scratch, the first of our programming languages, via which we'll program by dragging and dropping puzzle pieces. And some of those pieces very well could do exactly what John was doing by drawing. But we'll see we need to actually build some of these abstractions ourselves. Now in the reverse direction, let's flip it around so everyone can rather partake. Can we get one more volunteer to come on up on stage. Let me look just a little farther back this time, a little more-- OK, right here. OK, come on-- yeah, sure. What's your name? AUDIENCE: Chloe. DAVID MALAN: Chloe, come on up. So this time, no one else needs paper. Because Chloe, you're the only one who has to draw this time. And you're the only one in the room who's not going to see what the picture is. AUDIENCE: All right. DAVID MALAN: So, and the only rule is you may not turn around at any number of screens that show you what everyone else sees. And I'm going to project it over here. So if you want to go ahead and now just take on the role that you did a moment ago, but all of us will now program you verbally, step by step, to draw without looking. Just look that way, please. A little to the right. To your right. OK, good. Who would like to offer step 1, from the audience, for Chloe? Yes. AUDIENCE: Draw a circle in the upper half of the chalkboard. DAVID MALAN: Draw a circle in the upper half of the chalkboard. AUDIENCE: [INAUDIBLE] DAVID MALAN: OK. OK. Step 2. Yes? AUDIENCE: From the middle of the middle of the bottom part of the circle, draw an upside-down Y. DAVID MALAN: From the middle of the bottom part of the circle, drawn an upside-down Y. OK, step three? Step three. No one? Yes, in the middle. AUDIENCE: From the point at which the circle connects to the line, draw the line in a 90-degree angle, with the point facing down. [LAUGHTER] CHLOE: Is the point facing [INAUDIBLE] AUDIENCE: The point of the angle. DAVID MALAN: All right, let's be more precise. I think she's at the right starting point. So let's go from there. Your-- AUDIENCE: Draw a line at a 45-degree angle down. Draw a line 45-- CHLOE: [INAUDIBLE] [LAUGHTER] DAVID MALAN: OK. Took some liberties there, but OK. Step 4. Step 4. Someone else? Step 4. Yes, in back. AUDIENCE: Complete the triangle on the left side. DAVID MALAN: Complete the triangle on the left side. OK, nice. Step 5. Yeah, right here, in the middle. AUDIENCE: On the right. So that line that's sticking out of the intersection of the circle and the other line-- OK, that one. [LAUGHTER] [INAUDIBLE] draw on the right, at a 45-degree angle. DAVID MALAN: Draw a 45-degree angle up. OK, nice. Step 6, almost home. Yeah, in the front. AUDIENCE: So bring your chalk to the top left of the circle, and then go-- without touching, hover like one inch up. Yeah, OK. Now touch the chalkboard, and draw a one-inch line to the left, up, like at a 45-degree angle. So you're like one inch away from the circle on the left. Yeah, but move-- yeah, that's fine. [LAUGHTER] And draw a line 45 degrees up, to the left. [LAUGHTER] CHLOE: Left or right? AUDIENCE: Oh, sorry. So start on the right, then you're moving up to the left. [LAUGHTER] DAVID MALAN: Yes, OK. Very nice. And finally, step 7. Yeah. AUDIENCE: To the left of that line, just move [INAUDIBLE] DAVID MALAN: Anything you want. AUDIENCE: All right, [INAUDIBLE]. OK, right edge [INAUDIBLE] CHLOE: Right-- AUDIENCE: Right edge [INAUDIBLE]. DAVID MALAN: An abstraction you could also just call, hi. [LAUGHTER] And if we could, I think-- Chloe, you want to take a look at what you were being prescribed to draw? I think a round of applause. That's pretty good. [APPLAUSE] Thank you. Thank you. So there, too, it actually felt like everyone, including you, were kind of resisting the tendency to provide abstractions. But clearly, they're useful, right? It's a lot easier to have said, draw "hi," or even slightly lower-level draw, an H and an I, then frankly, it would have been to tell Chloe, well, put your chalk at the top left, then draw down an inch, then lift it up, and move it up a half an inch, and then move it to the right. I mean, that's what an H is, a capital H. But when we think of H, you don't think about it as really being three lines that are sort of mathematically defined. But a computer ultimately will. And thankfully, once we, or one person in the world has decided how to draw an H on the screen, odds are, you and I don't have to bother with that low-level implementation detail anymore. Because you could imagine programming could get super tedious if literally every time you want to do something interesting graphically, you had to implement all of that low-level logic yourself. And we're not going to have to do that. In fact, because of this language and other scratch, you have at your disposal a whole toolkit, so to speak, of puzzle pieces, or as we'll start calling them, functions-- verbs, actions-- that someone else wrote, that we can use to actually achieve the effects, graphical or otherwise, that we actually want to perform in the computer. So let's see what other building blocks are going to remain in this toolkit for us ahead. So problem-solving, recall, was defined as this, inputs and outputs. And inside of that proverbial black box were what? AUDIENCE: [INAUDIBLE] DAVID MALAN: Say once more. AUDIENCE: [INAUDIBLE] DAVID MALAN: I sort of. AUDIENCE: [INAUDIBLE] DAVID MALAN: Algorithms was the keyword we proposed last week, is inside the black box. And an algorithm is just step-by-step instructions for solving some problems, but sounds fancier than that. And so these algorithms we began to introduce by way of a few of those step-by-step problems, like counting the number of people in the room, finding Mike Smith in a phone book, sorting the humans on the stage. All of those were algorithms. But only one of them did we really start to refine a little more precisely using something called pseudocode. And arguably, that's our first language of CS50-- pseudocode, which has no formal definition. It just means, in English, or whatever your native language is, just write short, succinct instructions that gets your point across. And the point we wanted to get across last time for finding Mike Smith in a phone book looked something like this. And recall what we did was call out a few of the key operative words in this pseudocode that kind of fit a pattern, all of the highlighted words here, did we call what? AUDIENCE: [INAUDIBLE] DAVID MALAN: Say a [INAUDIBLE] AUDIENCE: Commands. DAVID MALAN: Commands, or functions, we call them, technically-- commands, actions, verbs. And we're going to just start, across the board, calling them functions, if only because that's what a lot of programming languages call them. Functions provide you with functionality. You can think of it like that. They are really among the building blocks of a program. A program-- a computer program, or a piece of software, is just a collection of one or more uses of functions and other building blocks. And among those other building blocks, for instance, are these. So highlighted in yellow now are keywords like "if," and "else if," and "else," which we described as examples of what last tie. Yeah. AUDIENCE: Conditions. DAVID MALAN: Conditions. So these are questions-- very well done. Questions that you can ask in a computer to decide whether you're going to do this, or that, or this other thing. It's sort of like the proverbial fork in the road. Go left, go right, or maybe somewhere down the middle in a forking of the road. Now in yellow here-- slightly fancier term-- but these were the actual questions to which we had or wanted yes/no or true/false, or 1/0 answers. And we called these what? AUDIENCE: Boolean. DAVID MALAN: Boolean expressions. Boolean expression is just an expression that evaluates to true or false. That is, it is true or false, yes or no, 1 or 0, however you want to think about those two opposites. And you use Boolean expressions as part of conditions to decide on what basis to go left or right or somewhere else when deciding what to do in a program. And then lastly, we had these, which we called what? AUDIENCE: Loops. DAVID MALAN: Yeah, loops. They were cyclical in nature. And we're going to see them in different forms today, and next week, and beyond. But in this case, it's a loop in the sense that it's literally telling you, go back from these steps to step 2, and that induces the cyclicity. Do this again, and again, and again, thereby achieving the same functionality, hopefully until we find, in this case, Mike Smith. So this is just a few of the building blocks in this toolkit, if you will, that we're also going to see now in another language, called Scratch. And Scratch, also, like other languages, provides us with a few other ingredients, too, things called variables, which you might recall from algebra-- x, and y, and z. But these are more general purpose, not storing just numbers, but really storing strings of text-- words and paragraphs. You can store colors, and images, and videos, just variables or placeholders. And then we'll talk a little fancier about terms like threading and events. These are more technical terms, but they provide us with very useful and very straightforward features in a program. But to do that, we need to actually introduce a language. So what is a programming language? It is typically a set of English-like words that some humans in a room, years ago, decided can be used to express yourself precisely and methodically to get a computer to do something. And some other people, typically, then took that language, a sequence of English-like words, and they figured out how to convert those English-like words to the zeros and ones that our computers actually understand. So when you hear the slogan, "Intel inside," that refers to a computer having Intel hardware. Intel, a big, popular company, for hardware, they make CPUs-- Central Processing Units. And those are chips that might be yay big, or even smaller, or even bigger, that just know what to do when it sees certain patterns zeroes and ones. And what might the CPU, the brain of the computer, do? Well, sometimes it might do addition. Sometimes it might do subtraction. Sometimes it might save something for you-- information, sometimes that might load information for you. Sometimes it might print something on the screen. So Intel Inside means that every Mac and PC and other device these days-- or there's other brands, too, can do certain very simple operations. And when we humans want to program, we're not going to want to program in zeroes and ones. We're not going to want to program, necessarily, in the same way Intel might have designed that chip. We want to program in something that's as close to English as possible. And we can actually go even further-- it would be nice if we could actually program more pictorially. And that's where Scratch enters. This is a programming language that someone else figured out how to convert effectively to zeros and ones, but that allows us humans to write software with loops, and conditions, and functions, and more, by just dragging and dropping little graphical icons. We use it just for a week in the class, just for one homework assignment, just to give everyone a sense of what you can do with the language. And those of you who have programmed before-- not to worry, even if you find it more readily accessible-- odds are, you'll find yourselves pushing yourselves, trying to figure out how to do something in this language because it might actually be non-obvious if it's not quite like the languages you've seen before. So what is Scratch? That is not Scratch. At the moment, it is a website. So this is a programming language that is implemented in the confines of a web browser. Because that just makes it very accessible to people around the world. It's targeted generally at younger students who use it in afterschool programs to just learn how to do more computational thinking in a fun way. We're going to use it to explore some of those very same building blocks of programs, and then next week, translate, literally, those graphical puzzle pieces to the more technically-looking but conceptually identical keywords in different language called C. So what is it we're looking at here? So you'll see in the first homework assignment, ultimately, what URL to go to, and how to log in, and all of that. Today, we'll focus more on the ideas, and the features, and the programming we can do with this. On the left-hand side or all of those puzzle pieces I keep referring to. And those little circles that are colored just categorize the puzzle pieces into different modes of functionality. So you have collections of functions, you have things related to conditions, you have things related to variables. And even-- because it's a fun environment-- things like sound, sensing-- so you can sense your environment-- colors, and the like. So there's some more aesthetic stuff in there, too. On the right-hand side, way up there on top right, is Scratch, the default cat that you get with any program you write. So you can very quickly change him into a dog, or to a person, or to nothing at all. That's just an implementation detail, ultimately. He exists on a so-called stage, that rectangular or square-like region in the top right-hand corner. And very simply, he's going to be able to minimally move up, down, left, right, and do other things as well. That is his world. And then lastly is this big middle region that's currently blank, a blank slate, if you will. That is where we'll be able to drag and drop puzzle pieces, have them interlock together, and then command-- just like John did to you, and we did to Chloe-- them to do something on that stage. So most simply, for instance, might we do this. I'm going to go down to Control, because I want to control-- rather, I want to control what this program does. And you'll see some familiar keywords. Let me zoom in. You'll see things like "if," which we note already to be a condition. We see some new words, like "repeat" and "forever." But odds are, those are examples of loops. They just kind of say what they mean. And if we scroll a little higher, there's something called events. And it turns out, there's some helpful events here, the first one being when green flag clicked. Because it turns out-- you might not have noticed- that just above Scratch's stage, up here, is a green flag, like in a race, that means go, run the program. And then a little red stop sign icon that just means stop. So that's how we're going to run and stop the program. So what does this mean. Well, I have a puzzle piece that literally says, when the green flag is clicked, that's kind of the way to start running a program. Because when I click the green flag, the following is going to happen. At the moment, nothing is going to happen, because there's no puzzle pieces snapped onto the bottom of this. But let's go ahead and do that. Let me go ahead and-- let me go down to Looks. And let me go ahead and quite simply say, the very canonical computer science-ey term, "hello, world." And notice, I've provided input now to this puzzle piece. So this purple puzzle piece, say, is an example of a function. It's an action, clearly. It's literally a verb. And it actually takes an input, the words, or a word, or number, or whatever, that you want the cat to say. And because it's now attached to the one green flag clicked, just logically, that is literally what's going to happen. So just in case this is a little small, this is the program we've written thus far. And notice it's indeed attached. I can detach it, and move it over here. But they're rather magnetic, and they kind of want to go together. And now, if I zoom out and click the green flag, I'm going to indeed play this program. And that's it. Kind of underwhelming, certainly, with what we can do here. But if we could, can we get one volunteer? And let's quickly fast-forward to the end game here, something you can really do once you start connecting these blocks, from a former student. Someone like to come on up and play a game, just a few seconds? Yeah, come on up. What's your name? STEVEN: Steven. DAVID MALAN: Steven? STEVEN: Yep. DAVID MALAN: OK, nice to meet you, David. All right, so this is a game by a former student, called Pikachu's choose Pastry Catch, that at first glance is probably going to only impress, but perhaps overwhelm, that you go from "hello, world" with two puzzle pieces to the interactive game. But over the course of today, what we're going to do is distill programs like Pikachu's Pastry Catch, and think about, well, if you actually focus on one piece of it at a time, you can actually build it, step by step by step, until you're really impressed with yourself some number of hours later. Let me go ahead and fullscreen it here. Let me go ahead and click the green flag, and hit the space bar. PIKACHU: Pikachu. [LAUGHTER] DAVID MALAN: That was one puzzle piece to do that. So you want to-- [VIDEO GAME MUSIC PLAYING] --there we go, left and right, and up. That was bad, bad. OK. OK, a round of applause for Steven. [APPLAUSE] OK, let's do it once more. AUDIENCE: Let's do it. What's run, and what's [INAUDIBLE]? DAVID MALAN: OK, so let's go back to the-- let's stop and restart. So here we go. I'm going to hit the space bar for the instructions. PIKACHU: Pikachu. DAVID MALAN: Catch the food, don't catch the bombs. STEVEN: I see. DAVID MALAN: OK. [LAUGHTER] PIKACHU: [INAUDIBLE] [VIDEO GAME MUSIC PLAYING] DAVID MALAN: Nice. So notice, as Steven plays-- that's a bug. Notice, as Steven plays, there's some kind of counter keeping track of how many cookies and cakes he's caught. And so we're going to call that a variable. It's just a number, like x or y, that's getting incremented-- added to again and again. Notice that this time he still has three lives left, per the icons in the top right-hand corner. Just so we can see, do you mind throwing a game? Can you just let a bomb hit you? And watch the variable. Now he's down to two. You can also jump, I think, with up. So let's consider what some of these building blocks are. He's clearly moving left, right, and up. Left is the result, clearly, of him hitting a key on my keyboard. So apparently, in a computer program, you can listen for specific keys. Notice, if he hits up-- hit up once more. Notice, when he hits up, it's not just up, down. There seems to be a bit of animation. And now it's a loop. Here's an example of a loop. And you'll see that sometimes things fall more quickly than others, which is making the game arguably harder. So if you've ever heard of, back in the day, AI, or artificial intelligence, this is often what it typically meant, just make things harder, don't necessarily understand what the user is doing. And we'll see now, it looks like Steven has 16 seconds left. And everything's falling faster. 10 seconds-- so that, too, is probably just a variable that's being decremented-- decreased again and again. Very nice. One second. And you still died, I guess, at the end. All right, a round of applause for real. [APPLAUSE] Thank you. So most of my voiceover there was just trying to justify spending that much time playing the game. But there are indeed these various building blocks. Because think about all of the various components on the screen. A moment ago, we just saw Scratch say, "hello, world." Now, we clearly see so much more going on. And indeed, the programs look a little scary at first glance. It's lots of puzzle pieces. But the student who wrote this did not just start dragging and dropping all of these puzzle pieces, and voila, thus was born the game. They focused on individual building blocks. What might some of those building blocks have been? Well, when the game first started, the cakes and the bombs were falling somewhat slowly, and not all that often. And each of those cakes and each of those bombs is just what we're going to call sprite. It's some kind of object in the program that you can associate scripts or puzzle pieces with. And just as Scratch is a single sprite, this game had at least a dozen or more sprites moving along. So this middle area where all your scripts are actually associated with each of the characters or sprites in the game. This, for instance, because Pikachu is highlighted, are all of the scripts associated with Pikachu, who Steven was playing as. Then there is a separate sprite for the cupcake. And these are apparently all the puzzle pieces that govern just what the cupcake was doing, again and again. If we keep clicking, here's what the bomb was doing. And if we actually really looked closely at this, we could understand why was the bomb moving so quickly, why was the cake starting from the location it did. And we're not going to go into those weeds with this game. But realize things escalated quickly, but not before we'll take these step-by-step approaches to building some of these pieces of functionality. So what do I mean by that? Well, let me go ahead and actually just write a slightly different program. Let me clear the stage here. And you'll see, at the moment, Scratch is in beta. So you might have to dismiss some of those warnings, but it works. And what you'll see here is just a clean slate again. So let's do something that actually takes some input this time, and specify something like this. Let me go down to Events, because many of my programs are going to start with just this one puzzle piece, when green flag clicked. And now I'm going to go ahead and let's look for, say, Sensing. Notice this block here. It turns out you can actually get input from the user. You can ask the user questions. So ask, what's your name and weight? That's just a placeholder in the white box there. So I'm going to go ahead and drag and drop this, under that puzzle piece. And literally, it asked the user that. And then once I get his or her name, you know what I'm going to do. I'm going to go ahead and say something. Previously, I said "hello, world." But it would be kind of cool if I could actually say the name of the user who just typed in his or her name. So how do I do that? Well, let me go back to Sensing, which is the category of blocks where I found this ask block. And notice, right below it is something that's apparently related. It turns out that this puzzle piece functions in the following way. When the user is asked what his or her name is, the answer is actually stored in a variable called Answer. And a variable, again, like in math, x, or y, or z, you can give them more descriptive names. Because it would be a little misleading to just call it x. So they called it Answer. And notice what I can do. I can drag and drop Answer. And just notice, as I hover over there, it's a little magnetic as well. I just let go, and voila, it grows or shrinks to fit the block. So now, if I go ahead and click Play, notice, Scratch is asking me what's my name. I can go ahead and type in, David, and hit Enter. And now it says just, David. That's not exactly how you're supposed to greet someone, by just saying, Benedict. It would be nice to say something like, hello, comma, Benedict. So how do we do that? Well, I only figured this out by futzing around myself. But it turns out, under Operators, down here, there's some other puzzle pieces that I got curious about. These are just placeholders, apple and banana, but Join does exactly that. It takes not one input but two inputs. Or, as we're going to start calling them, arguments-- two arguments to a function that somehow control its behavior. And what I'm going to do now is actually this. Let me go ahead and remove Answer, and just drag it over there. If it's disconnected, it's not going to do anything. But I don't have to throw it away just yet. I'm going to drag one of these join blocks. Notice it magnetically clicks into there. I don't want to say, apple, banana. I want to say hello, comma, space, and then move answer right there. So now I'm passing two inputs to join. But if you kind of think through the logic, how many inputs am I then passing into Say to control its behavior? There's kind of this nesting approach. And the fact that I literally put one puzzle piece on top of the other indicates what the order of operations is. This is going to join the two words-- "hello," comma, and then "answer," and then it's going to pass whatever that answer is-- otherwise known as a return value, but more on that next week-- into Say as its argument. So functions can take arguments, whether it's one, or two, or even more. Now let me go ahead and hit green flag again. What's your name? David, Enter, "hello, David." So now it's a little more interactive. And I can type in any name, and it will just work. So it's not hard-coded anymore. So I have a dynamic program. And notice, the key takeaways here is not so much what it does but how it does it. But this is a little underwhelming, certainly on the heels of the game Steven was just playing. So let's actually take things up a notch. I'm going to go ahead and start over. And I can do this by just dragging all of my puzzle pieces away. They just get deleted. Now I'm going to go ahead and do this. I'm going to go ahead and start with the same puzzle pieces before, when green flag clicked, and then go under Sounds. And Scratch is a cat. Turns out he actually comes with some cat sounds. So let me go ahead and play this game now. [CAT MEOWING] Aw, it's kind of cute. [CAT MEOWING] It's a little annoying that I have to literally click the button every time I want to hear this play. But that's doing literally what it says. What if I want the cat to meow three times? How might I do this? Well, I see I have more of these, sort of an infinite supply. So I could just do this. Let me go ahead and hit play. [CAT MEOWING] Hm, that didn't seem to work. Let's do it again. [CAT MEOWING] Hm, doesn't quite sound right. But there are three puzzle pieces. Feels like a bug. My mistake, MIT's mistake, what's going on? I kind of wanted to hear "meow, meow, meow--" though not quite like that. Yeah. AUDIENCE: The time in between three [INAUDIBLE] DAVID MALAN: Yeah. It turns out that Macs and PCs are pretty fast. But this sound, of course, is stretched over a second or so. And the puzzle piece literally just says, start the sound, meow. And it doesn't say, wait for it to finish. It doesn't say anything about time. It just says, start the sound, start the sound, start the sound, three, one after the other. And so they're just kind of tripping over themselves because I've not waited. So-- [CAT MEOWING] --they're there, they're just all overlaid on each other. So I can fix this in a few ways. Let me actually go ahead and go to Control. Notice here, there's a weight block, which might actually help me fix this. So let me go ahead, and notice, you can kind of snap things inside if you want. So let me wait one second there, let me wait one second here, and now click Play. [CAT MEOWING THREE TIMES] OK, the cat's a little agitated. So that doesn't sound quite natural. I can change the input to wait to maybe be two seconds, and now play it. [CAT MEOWING THREE TIMES WITH WIDER  INTERVALS] OK, a little more realistic. But this is getting a little tedious. But it turns out, if I look a little more closely, Scratch actually came with something a little more straightforward. Which puzzle piece should I probably have just used in the first place to solve the same problem? I'm currently using start sound. Yeah? AUDIENCE: Play sound, meow, until done. DAVID MALAN: Yeah, I mean, that just kind of says what it does-- play sound meow until done, thereby eliminating the tripping over of the sounds. So let me try that. I'm going to throw all of these away. And now let me just grab three identical copies of this, and see what happens. [CAT MEOWING THREE TIMES, QUICKLY] All right, so it's kind of the agitated cat again, but at least I didn't have to do as much work. It's three puzzle pieces instead of six, which just feels a little cleaner. It's twice as fast to write. But I bet I can do better than this. I'm asking the cat's meow again, and again, and again. What's the concept that comes to mind? AUDIENCE: [INAUDIBLE] DAVID MALAN: What's that? AUDIENCE: Repeat. DAVID MALAN: Repeat in some form. So a loop more generally. So we saw one of those earlier. If I go down to Control-- and notice here, repeat 10. So let me detach these. Let me grab a repeat block. And it doesn't look very big, but that gap in the middle will actually grow to fill. Let me just grab one of these now, throw the other two away. And now, even though it's still three puzzle pieces, it just feels like it's a little more maintainable. Because now I can just change how many times I want it to run there. [CAT MEOWING THREE TIMES, QUICKLY] OK, not quite natural. But again, how do I fix this problem? Yeah, I should probably wait. So let me go back to Control, and grab Wait One Second. This will snap to fit. And now-- [CAT MEOWING THREE TIMES AT ONE SECOND  INTERVALS] OK. So it's getting better. And now we're sort of making a cleaner program, if you will. Because consider the alternative. If I wanted the cat's to meow 10 times, if I took that first approach, and dragged and dropped 10 play-sound blocks, that just gets messy. It feels like you're just wasting time and effort. Why not just grab one block, the repeat block, as you proposed, and just sandwich in one or two related blocks, like "play sound and wait," in order to achieve the same result. Well, let me go and do something a little fancier now. Let me go ahead and get rid of these, and let me demonstrate how we might have Scratch actually count itself in a program. Let me go ahead and go down to Variable here. And notice that there's a whole bunch of blocks here. But by default, I actually get one variable, called My Variable. But that's not very descriptive. Let me go ahead and make my own variable by clicking this box. That pops up this window. And I'm going to go ahead and make a variable called Counter. I just want a counter that just counts from one on up. I could call it x, or y, but Counter is more descriptive in English. Now notice I have a new puzzle piece in orange, Counter. And let me go ahead and drag-- let's go ahead and drag this one, Set Counter to 1. So this is a command in Scratch that just lets me do exactly that, initialize this variable to having a specific value. Then let me go to Control. And let me go and forever do the following. I want Scratch just to demonstrate to me that he can count up to, say, as high as he can go. We'll see how fast he counts. So let me go ahead and have him say-- not a word this time, so not "hello" for two seconds. Let me go down to Variables, and let me drag Counter where the word "hello" is, and have him just say the counter for one second. And then after that, what do I want to do? I'm going to go ahead and change the counter by one, and then let him repeat. So these programs alone-- let me go ahead and zoom in on the program that I just wrote. This program, composed of these five-or-so puzzle pieces, would seem to set a variable, called Counter to 1, and then show it on the screen. Then add one to the counter-- So hopefully it's up to two-- and then just say that on the screen. And repeat, and repeat, and repeat, and just do this forever. Because of that block, literally forever, an example of a loop-- 1, 2, 3, 4-- so it's going to go pretty straightforwardly. So what are the building blocks here? We have a loop, we have some functions, and we have, now, a variable. Now this gets very underwhelming quickly. Let's see if we can't make Scratch count a little more quickly. What would be a faster way of counting than by one? AUDIENCE: 10. DAVID MALAN: By 10, we could do. Or even more so-- 20 is more. So we could obviously play this for a while. So why don't we just have scratch double what he's doing on every iteration and every cycle? So how do I do this? Well, instead of changing the counter by one, you know what I'm going to do? I'm going to go ahead and set the counter-- let me stop the program. I'm going to go ahead and set the counter. And if I dig into Operators down here, Multiplication, I feel, is going to add up pretty quickly. So let me go ahead and set the counter equal to itself, times, say, two, and get rid of this altogether. So now, on every iteration, after starting at one, it's going to go two, four, eight, 16, 32, 64. And that would seem to grow-- technically, exponentially-- much faster. All right, so we're already counting pretty much higher than we did before. But this is still kind of tedious. What would happen if we instead do this? Let me go to Looks. And let me not say the counter for one second, why don't I just go ahead and say it by stealing this-- oops, let me get rid of this block, and just do this. So let's stop waiting. Now the cat can count pretty high-- 10 to the 70th, 80th, 90th. Now it just can't even fit in the speech bubble. So he's counting pretty high. This is times 10 to the 160, 10 to the 200 is coming up. This is kind of inviting the question, how high can Scratch-- or more technically-- how high can a computer count? Yes, last week we only counted up to, like, eight on the stage. Now we've already passed that. And at some point, Scratch appears to have just given up. Why? What's the intuition here, beyond a 12-year-old not really needing to count this high anyway, with this program? Why does Scratch just kind of say, that's it, infinity? What would be the implication of counting up, actually, forever? Yeah. AUDIENCE: You could go back past the amount of space that you have. DAVID MALAN: Yeah, you might, right? Because think about these abstractions we've built up over the past week. We know that there's electricity in zeroes and ones, and from there, we get decimal numbers, or any number of other types of data. But we always, always, always had a finite amount of battery capacity in our laptop. We had a finite number of bits or humans on the stage or on the chalkboard. We have a finite number of zeroes and ones. And you can only permute-- that is arrange-- a fixed number of zeros and ones in so many ways. Eventually, you're going to get all ones-- one, one, one, one. And you can't just carry the one again, because you don't have more hardware. You don't have more bits. And so you have to decide what to do. Scratch decides to just say, that's it, I can't count that high. Because MIT has decided to only allocate Scratch some number of bits to count super high, but no further. But if you didn't have that boundary. And you had, in your memory, a whole bunch of ones, ones, ones, ones, ones. And it turns out you can't spend any more space because you just don't have the hardware. The next number after this value on the board, guess what? It becomes what? This is 31, if we actually did the math. What comes after 31 if you only have five bits? Zero, zero, zero, zero, zero, because the only way you can change the pattern is to just change them to zeroes. So long story short, there's an implication for computers of what they're even capable of. You might think that they have this infinite capacity beyond us humans, but that's not actually the case. And we're just seeing a tiny bit of evidence of that here. Well now let's actually make Scratch more of a pet, and demonstrate some other building blocks with which we can navigate a program here. Let me go ahead and grab a one green flag clicked. Let me go under Control, and go to Forever again. And let me go ahead now and ask a question for the first time. Under Control, I'm going to go to this If block. And I'm going to say something like this. I want to kind of take scratch for a walk, if you will, on that stage. I want him to move around and interact with me or my cursor on the screen. So it turns out there's this category of blocks called Sensing. And notice this one at the top, Touching, mouse pointer. It's kind of a funky shape, with diamond shapes on the ends, left and right here. And so this is actually a category of Boolean expressions, questions you can ask that have yes, no, or true/false answers. So if I drag this, notice it's the right shape but not the right size. That's OK. It's going to grow to fill it. And now what I'm going to go ahead and do is go ahead and play the sound, meow, only if Scratch is touching the mouse pointer. So now if I go ahead and hit Play again, nothing's happening. But notice my cursor is in the top corner there. Let me zoom in. My cursor is now above Scratch. But now, if I move to pet him-- try this again. [INAUDIBLE] [CAT MEOWING] OK, that's a bug in Scratch, I think. So logically-- we'll pretend the last 20 seconds didn't happen. The program is indeed working as expected. All right, so what's going on? If the mouse pointer is actually touching Scratch, we're noticing it in that If condition. But it's super-important that I have wrapped it in that Forever block. Why? Scratch doesn't seem to be doing anything forever, does he? Why is there that forever, Chloe? AUDIENCE: If you don't put it in forever, then there won't be [INAUDIBLE] DAVID MALAN: Exactly. If you don't put the Forever, it's just going to ask that question once. And honestly, I don't think I can hit the green flag and move my cursor quickly enough to pet Scratch before it's already asked the question, if touching mouse pointer. And so odds are, what's going to happen is, he's just never going to meow. But if I instead use a Forever, he's just sitting there patiently, waiting and waiting, without doing anything, seemingly. But really, he's listening, if you will, or waiting for an actual touch of the mouse cursor. So now the key here is that we've embedded, within a loop, a condition, asking it again, and again, and again. And now let me go ahead and open up another example. And we'll post all of these sample programs on the website later today so you can play with them if you'd like, or use them as pieces to your problem set. I'm going to go ahead and open up another program here , called Meow 1. Oops, no, I'm going to recreate it really fast. Let's go ahead and do this. Let me go ahead and Forever, Control-- so do I want to do that one, Meow-- oh, let's do this. Let me go ahead and open this one, called Pet 1. So this one-- notice-- is going to work a little differently. This one-- [MEOWING] --is meowing endlessly, with just enough pause. But what's going to happen, apparently, when I do move to pet this cat? Yeah, he's going to roar. So in this case, the logic is a little different. Let me zoom in on the puzzle pieces here. So Forever, if touching mouse pointer, then Roar, apparently. Else, just meow. And at the moment, I'm not touching the cat. Notice my cursor is not even near it. But if I do move it closer and closer while it's still running-- [MEOWING] Bug. There we go. OK. Sorry for the bug. All right, so the reason is I needed to click on the white stage so that he would know my cursor was nearby. So here we go again. And now if I move to touch, there we go. All right, so let me open up a different one altogether, to demonstrate some actual movement here. Let me go ahead and open up what's called Bounce Zero. And this example here-- come on, upload. Notice what's happening here. So now we have the ability to start making something that's kind of a puzzle-- a building block for the game that Steven was playing earlier. It's just bouncing and bouncing off the stage. Why? Well notice, it's forever doing this. Every time that Forever loop executes, he moves 10 steps, apparently. But if he's touching the edge, he turns around 180 degrees. And you can kind of see him quickly doing that just over there. And if I zoom out, we'll see that he's still moving. But it's not exactly like real movement, right? His feet are just-- I can't even do it physically. But his feet are just in some fixed position as he's sliding across the stage. So let's breathe a little more life, so to speak, into this program. What does it mean for an image on the screen to give you the illusion of walking? What would need to happen to his feet, probably? Right now, they're just kind of fixed in place. Yeah, they need to shift somehow, right? Like when you walk, let's consider what happens. You kind of lift one foot, and it goes up, and you could imagine kind of taking one, or two, or three photographs of me or whoever while they're walking on the stage, and just using those photographs as examples of where their feet should be at points in time. And in fact, we can do this. I'm going to go ahead and pull up a slide, if you will, here. This is the original version of Scratch. And the subsequent slide actually looks like this. Legs are just a little different-- heads mostly those same, bodies mostly the same. But there's a little bit of movement. But notice, this is just my PDF of slides. If I go back, forth, back and forth, back and forth, it kind of looks like-- let me do it with two hands-- it kind of looks like he's walking now. It's pretty primitive, right? I kind of need a third, or fourth, or fifth frame to make it really look fluid. But that's all animation is. Recall from last time, when we talked about an image, and from images, we get videos. Videos are just like 24 or 30 images per second flying across the screen, thereby creating the illusion of movement. This would be two frames per second, maybe, just one snapshot, two snapshots, again, and again, and again, and again. But we can go pretty far with that. So it turns out that Scratch has this other feature. It's purely aesthetic. But it allows you to have multiple costumes. So by default, you get this one costume for Scratch, per the icon at top left. And you can actually draw any important GIFs and JPEGs from online if you want to make things look differently, like the student did for the Pikachu game. But by default, we just get this one costume. Well let me go ahead and instead open up a follow-on example here, this one called Bounce 1. And notice this one, if I go back to Costumes, actually has those two-- that one and that one. And again, it's just two points in time. But if I add one puzzle piece here, in purple, called Next Costume, if you read the documentation for Scratch, all that does is change the costume, change the costume, change the costume again and again. It's saying, next, because it just toggles among however many there are-- in this case, two. So now if I hit Play, it's cute. It's not really that natural. But now he's kind of legitimately sort of walking. How could we make it a little more fluid by changing the program, do you think? Why is he kind of moving so quickly? Was that a hand in back? AUDIENCE: [INAUDIBLE] DAVID MALAN: Wait a little longer before it changes. Yeah, I can do this in a few different ways. Let me try just waiting a second after he moves 10 steps. So now he's like tiptoeing. So that's probably too much. So rather than wait a second, let me try waiting 1/10 of a second-- better. Let me wait a little less than that, 0.05. OK, it still looks a little jittery, but that's only because we have two costumes to work with. But it's a little more realistic, too. And 10 steps, too, was how many he was moving. What's going to happen if I have to move 20 steps at a time, or maybe 20 pixels on the screen? What's the effect going to be? Bigger steps effectively. So let's try that. 20, Enter-- now he's moving quicker again. So now the wait really isn't helping because we're overwhelming it by movement. How about 30 steps. Now he's really moving. Let's go ahead and do 100 steps at a time. And if we do this enough-- 500? I mean, now he's just jumping back and forth on the screen. But again, that's all animation is. And frankly the game that we saw played, the Pikachu game, is really just a fine tuning, in parts, of those kinds of principles. Well let's make this actually more interactive again. Let me stop that, let me just reload to get back to a blank program. And let me go ahead and grab a when green flag clicked. And let me go ahead and, under Control, let me get a Forever block. And now let me go ahead and do this, motion. It turns out that there's bunches of blocks here. And we don't honestly care about all of them, per se, because they do what they say. We don't need to sort of exhaustively explore, I think, all of them. But this one sounds interesting-- point towards mouse pointer. Let me go ahead and grab that inside of my Forever block. And then let me have it move, just like one step, not 10. That's it, four puzzle pieces. What is this program going to do once I play the green flag? It's going to follow the mouse. So actually, that's kind of a funny, unintended pun. The cat is going to follow the mouse, if you will. But notice, that's exactly what he's doing. He's moving slower and more smoothly, but that's just because he's moving one step or pixel at a time. As my mouse moves, he's following it exactly. I mean, we can really kind of mess with him here, because he's just going to literally do what I say, depending only on the speed of my finger. But now we have the ability to do a more interactive game, not even using the keyboard, but using the mouse. So what more can we do with some of our building blocks here? Well this one, let me go ahead and open in advance, because it's a whole bunch of puzzle pieces. But let me go ahead and open this. I changed the costume for this one to be a-- let's see, upload here, let's call this Bark. Notice this one actually has a seal icon. And let me move the puzzle pieces-- there's actually two scripts here. And here, we can introduce the notion of threads. So it turns out that computers are so fast that they can kind of sort of do multiple things at a time. And that's sometimes a white lie. But sometimes computers have multiple cores, so to speak, or really multiple CPUs. If a computer has two or more brains, then it can literally do two or more things at once. One of those might be to run the program on the left, the other might be to run the program on the right. And we'll see what those programs do. But also, even in a computer that just has one brain, one CPU or core, as they say, computers are so darn fast and we humans are so relatively slow, a computer can give the illusion of doing multiple things at a time by spending a split second doing the work over here, then doing a split second of work over here, then over here, then over here, and over here. And because our CPUs, those Intels Inside, are moving at 1 gigahertz-- 1 billion operations per second, we humans don't even notice that it's splitting its time across these tasks. It just looks like things are happening in parallel. And so when a program is multi-threaded, so to speak, like threading a needle, that just means you can have two things happening-- or more-- at once. And that's useful here, because notice, both of these programs start when the green flag is clicked. Let me go ahead and hit Play. [SEAL BARKING] And then let me lower the volume. [SEAL BARKING] Come on. OK, a little lower volume. So what's going on now? How can I make it stop? If you can read this program, even though part of it's a little chopped off. [SEAL BARKING] Hit the space bar, and that's going to mute this program, apparently. Let's say-- OK, I didn't hit the Stop icon. I hit the space bar. I'll do it again, if you trust me-- space bar, space bar. So what's going on? Well, this is an example, now, of an even more interactive program. Notice on the left that I have the following. I created, in advance, what apparently is orange and a variable. I called it Muted this time instead of Counter. And again, just good choosing good words for variables that say what they are, just to help you think about what your program is doing. And I set it equal to literally False. I couldn't have set it equal to zero, but I just chose, literally, the word, False, per last week. Then, forever, what am I doing? I'm asking a question. If the space bar is pressed, then what do I want to do? Well, if muted equals false, change muted to true. Else, implicitly, if muted is true, change muted to false. So it took a few puzzle pieces there, with the Ifs. But if the space bar is clicked, I'm just checking, well, if this variable is true, make it false. But if this variable is false, make it true. So it just toggles the value. Meanwhile, what's the purpose of this program on the right-hand side, apparently? It's a little cut off. Let me move it over slightly. What's this program on the right-hand side doing? It's making noise. It is forever barking. It's playing the sound, Sea Lion, unless muted is true. Because before it barks and plays that sound, it's saying, if muted is false, then play the sound. So if it's not muted, false means no, or zero. So if it's not muted, play the sound. Otherwise, what does it do? Is there an else? There isn't. There doesn't need to be. It can just be a one-way fork in the road-- either go down it or don't. You don't have to do something else. And then it just waits one second and repeats. So threading refers to the process of both of these programs running at the same time. And notice that they're sharing state, if you will, as we'll say, eventually, sharing a variable across them. And that's another way for two sprites in this case-- or rather, one sprite, but two scripts, to actually interact with each other. We can see another form of this, too. If you ever played the game in a swimming pool in the US, growing up, Marco Polo, where one kid is blindfolded, or closes his or her eyes, and then everyone else swims around him or her, and then you just yell, Marco. Everyone else is supposed to yell, polo. And with you eyes closed, you're supposed to, in a pool, very dangerously, go find someone, and tag them, until they then become it. So in other words, one human says, Marco. The other humans say, polo. How might we actually simulate this in a program here? Well, let me open this program, this one using two puppets. And notice how this works. I'm going to hit Play. And as before, if I hit the space bar, something's going to happen. Orange puppet says, Marco. Blue puppet says, Polo, but only once the orange puppet has said something. Marco, Polo-- so why is that? Well, it turns out that this puppet is using a different building block altogether. This puppet is saying this-- forever, if the space is pressed, say, Marco, and then broadcast an event. So it turns out the two sprites can't see or hear what the other one is doing. Just because the one on the left says, Marco, doesn't mean the other on the right can actually see the word, Marco, appearing on the screen. To talk to another sprite, you need to do something a little more secretly in programming, known as broadcasting an event. And this is just a simple example, but there's literally a puzzle piece in Scratch called Broadcast that literally sends a secret message to any one other sprite that might be listening. And if that other sprite is expecting it-- and notice this-- I'm currently looking at the orange puppet's scripts. If I instead click on the blue puppet, notice, all he's doing is this. He's not waiting for the green flag. He's instead waiting for a different type of event, literally the word, event, to be secretly uttered to him, if you will. So when he receives that broadcasted event, then and only then does he say, polo, for two seconds. And that word event could be anything in this case. It's just the result, now, of using two puzzle pieces. The broadcast event to sort of secretly send a message to all other puppets, and then "when I receive" instead of "when green flag clicked." All right, let's actually now take a look at one final sequence here. Let's take a look at how you might design, now, your own puzzle piece. It turns out that you're not limited to only what Scratch provides. You can actually do this. Let me go ahead and say this. If I want to go ahead and, when the green flag is clicked, let me go ahead and say something like "cough." I want Scratch, unfortunately, to have a bit of a cough. And then, after he coughs, I'm going to go ahead and have him, say, wait for one second. And I'd like him to do this a few different times. It turns out if you control-click or right-click, you can start duplicating blocks to save time, even though that's a little lazy of me right now. So all this program does is, instead of meowing, it has Scratch coughing, again, and again, and again. Now we already know that we can do better with a program like this. This is bad design. The moment you start copying and pasting, and in Scratch, the moment you start duplicating, odds are you're taking a shortcut, and just making more work for yourself than you should. What puzzle piece should I have used instead? Yeah, Repeat, as before. So let me quickly clean this up. Let me go ahead and detach this. Let me go ahead and repeat, three times, just two of these blocks. So now we have a tighter program. And it's tighter in the sense that now, if I wanted him to cough 10 times, I literally just change one value. I don't have to go and copy, and paste, and update a whole bunch of things-- which, at the moment, not a big deal for three. Once it gets to be 10 or more, you're literally just creating work for yourself, and making it harder to maintain the program. But you know what? The notion of coughing is kind of a nice verb, right? It would've been nice if Scratch just came with a puzzle piece, called Cough, that literally displays cough on the screen so I don't have to reinvent this all the time. Maybe I want a whole bunch of animals to be coughing in this particular game, or animation, or whatnot. So let me make this code reusable. I want to never ever again write code for making a sprite cough. So it turns out you can do this by way of your own blocks or puzzle pieces. If I click on My Blocks at the bottom, and I click Make Block, I get this little interactive window, where I can give it a name. I'm going to go ahead and name this block, Cough, and then I'm going to go ahead and click OK. And what I'm now going to do is this. Now I get this pink puzzle piece. I'm going to actually move all of this code from inside there, to over to that puzzle piece, so that now I have this new pink block that I just created, called Cough. So now, if you look at my program, this is really how you want to think about the program. I want to abstract away from those lower-level implementation details, and just say, repeat the following 10 times, Cough. And only if you actually care what it means to cough do you need to bother scrolling to the left, and actually look at the implementation details, so to speak, of Cough. So it's a nice abstraction. We never again need to bother thinking about how do you make something cough. You just use it on the right. But I can take this one step further. How could I improve the program on the right, and in turn, this function I've created, called Cough? What would be a nice new feature to add to it? AUDIENCE: Add a sound. DAVID MALAN: Do a count. AUDIENCE: [INAUDIBLE] DAVID MALAN: Oh, OK. We could actually add a sound. As as an aside, do we have-- OK, we can do this. Here we go, real quick. Turns out there's a non-academic feature here, known as recording. If you allow your mic-- [COUGHING] OK, that is what a cough looks like when you graph it. We'll call this, Coughing. Let me go back to my code. This was not the point of this exercise. But so be it. Let me go ahead and say cough and play-- not meow, but coughing. [LAUGHTER] OK, so be it. But I was thinking of something else. How else can we improve the functionality, give a little more-- AUDIENCE: Motion. DAVID MALAN: Give more emotion? AUDIENCE: No, no, make it move. DAVID MALAN: Oh, make it move, too. [COUGHING] OK, we could do that. Also not what I have in mind. Let me-- go ahead. AUDIENCE: Not a variable to cough, but [INAUDIBLE] DAVID MALAN: Yeah, so this was actually what I was thinking up to. But those are all great decisions, too. So Cough right now is just a verb. It doesn't take any inputs. But it could, right? I don't strictly need the repeat block there. I could make Cough just a little fancier. So let me do this. I'm going to go ahead and right-click or control-click on it, and just edit. I'm going to go back one step to redefine it. And I'm actually going to click this button, Add an Input, number or text. And I'm going to go ahead and just call it n. Computer scientists tend to call arbitrary numbers n in the absence of something else. And then just a label that says, no functional [INAUDIBLE].. I'm just going to say cough n times, just so that the puzzle piece has some words on it. So now notice, what's nice-- now, my puzzle piece is fancier. I can actually get rid of this repeat block, just attach this, and say, cough 10 times. And now this repeat block, if you will, can become part of the abstraction such that it repeats not 10 times here, but I can drag and drop this. So notice now, the notion of coughing, if I zoom in, got a little fancier. You now have a custom puzzle piece, called Cough n times, where you, the user or caller of this function, specify how many times you want it to cough, then you let the code therein do that for you, so that now your program on the right, which is all you cared about at the end of the day, doesn't have to get into the weeds of all of that complexity. You can instead just say, cough 10 times, and never again think about the lower-level implementation details. So this is an abstraction on top of what that actually is. Well, let's go ahead now and tie all of this together if we can, in some more sophisticated examples, another one implemented by a recent student. Let me go ahead and open up, not Pikachu's Pastry Catch, but this one here, the Gingerbread Remix. So this one is not a game per se-- although it sort of is-- it's more of a story. Let me go ahead and hit Play, and I'll play this one up here. [MUSIC PLAYING] All right. Shall we have an apple? Let me go ahead and type, yes. And consider what's happening. Yes, is probably now my input. It's probably getting stored in a variable. And then that variable with an equals sign is probably being compared against the word, yes or no, in a condition. Here we go, yes. [SOUND EFFECTS PLAYING] OK, bad decision. So let's play again. Here we go. Green flag. [MUSIC PLAYING] OK, I'm going to say, no. Ooh, cupcake-- yes. [SOUND EFFECTS PLAYING] OK, poor choice again. But again, a condition is probably at play. Let's play a third time. No, no. [WICKED LAUGHTER] [CRYING] [STUDENTS LAUGHING] OK, surprise ending. So that's a simple game, now, to give you a sense of the range of capabilities here. And I thought, why don't we take a look at one final example as to what you can do with these various building blocks, but consider exactly how it got to this point of complexity in each of these programs, from the simplest to the fanciest. There was not a student sitting down at his or her keyboard, and then immediately starting to program by trying this, or let me do this, and this, and this. They thought about a simple problem there. So for instance, with the gingerbread game a moment ago, odds are, the student just had the princess come on the screen first-- one sprite, no witch, no house, no complexity, and just saying words on the screen. Then maybe the witch came into play, and the witch actually used that Ask block, and the witch asked a question, yes or no. Then, the student probably wrote some more code that said, once you get an answer, that special puzzle piece to that question, then use a condition. If the answer is yes, then game over after a bit of animation. How did the animation work? Probably quite like the cat, bouncing across the screen, but this time, just one direction, no bounce. Then as soon as the witch's apple or cupcake got close to the princess, turns out there's a block that says if one sprite is touching another-- like in the vicinity of the other-- then something else can happen, and thus something came on the screen there, too. And so with problems that zero, ultimately, the homework is going to be quite simply, make almost any Scratch project of interest to you-- a game, an interactive art, an animation, or the like. But the key is to think about it from the ground level up. Make just one feature at a time-- one cupcake, one apple, one witch, one princess, and begin to layer on top of that complexity. For this last example, made just a couple of years ago, as CS50 at Yale was just getting off the ground-- could we have one final volunteer? Yeah, OK, come on up. What's your name? AUDIENCE: Alvin. DAVID MALAN: Alfred. AUDIENCE: Alvin. DAVID MALAN: Alvin, Alvin. Come on up, Alvin. All right, this is Ivy's hardest game, pitting not just Yale and Harvard, but other Ivys against each other. Nice to meet you. We're about to see the instructions on the screen. And odds are, we'll muster some support of the audience here. Here we go, just a keyboard-based game-- up, down, left, right. [MUSIC - MC HAMMER, "CAN'T TOUCH THIS"] Very nice. So now second level-- crimson's in the way. Level three, two crimsons. And again, think about the building blocks. Now we're up to what, five sprites on the screen? But each of them is operating independently, and bouncing. MIT's a little smarter. [LAUGHTER] Nice. Very similar to that cat following the cursor. Nice. Second-to-last level. [CLASS OOHING] [APPLAUSE] [CLASS GROANING] Try a couple more times. Two more lives. OK, no, round of applause would be good for Alvin. [APPLAUSE] OK, so that's it for today. The first homework assignment will be posted on the website tomorrow. We'll stick around for one-on-one questions. A pleasure to have you in the course. See you all soon. [APPLAUSE]