[MUSIC PLAYING] DAVID MALAN: This is CS50, Harvard University's introduction for the intellectual enterprises of computer science and the art of programming. My name is David Malan, and I actually took this course myself sophomore year some years ago. But I almost didn't. At the time, I was quite uneasy with the idea, frankly, of taking a computer science course, let alone this course. And so my freshman year, at least, I really gravitated toward courses and departments with which I was much more familiar. Computer science was well beyond my comfort zone at the time, and it was really these unfamiliar waters that I wasn't quite ready to shop, even my first year. But sophomore year, I finally got up the nerve to come through the door of CS50, and only because the professor at the time let me take the course pass/fail. I was that uneasy. And if only I had known at the time what I now know, which is that 2/3 of CS50 students have never taken a computer science course before. So if you are feeling similarly uneasy with the idea of trying something new, or even if you have prior background but are looking to fill in gaps in your knowledge, or if you're particularly self-taught, realize you are very much in good company. And ultimately, what matters in this course is not so much where you end up relative to your classmates, but where you end up relative to yourself when you began, which is, of course, today. So what, then, is computer science? And what was it that I was so uneasy with? Well, I dare say we can describe computer science as this. It's just the process of solving problems. And what does it mean to solve a problem? You've got some input. And the goal is to get some output, the solution, to that particular problem. And in between, really, is computer science. And we'll see what's in this literal black box on the screen as we begin to fill in some of those blanks. But when we consider a problem to be solved, we have to all agree from the get-go, especially if we're using machines, how are we going to represent these inputs and outputs? And so one of the first concepts we explore in computer science is how you represent information itself. And odds are you probably know coming into this course that computers only speak what language, so to speak? AUDIENCE: Binary. DAVID MALAN: Yeah. So binary. And if you've never heard that term before, fine, as well. But zeros and ones, somehow. But how do we get to that point? Well, even if you kind of know that computers speak binary, whatever that means, but you haven't necessarily thought about how that works, well, consider how most of us learn how to count maybe first on our hands. If I want to count the number of people in the room, I might do 1, 2, 3, 4, 5, putting up one finger for every person in the room. So that's what's known as unary notation. [? U, ?] or uno, implying 1 because I'm just putting up a finger or not to count people in the room. Of course, I can only count so high on just one hand. But thankfully, we have many symbols in our so-called human world of decimal. Dec meaning 10, we have digits 0 through 9. And from there, we can express any numbers with which we're all familiar. But computers don't have that many digits. They only have zeros and ones. And yet somehow, they're able to store not only numbers, but letters and images and videos and sounds and so much more. So how does that work? Well, let's take a quick look at just this to get everyone on the same page as to how you can build the phones in our pockets, the laptops on our desk today, using just zeros and ones. Well, these are just symbols on the screen here. What does this, of course, represent? 123, but why? I mean, these literally are just symbols or glyphs on the screen, sort of strokes of a pen that we all ascribe meaning to. We just see this as 123. But why is that? Well, if you're like me, you probably learned way back when to think of the rightmost digit as being in the ones place or the ones column, the middle digit as being in the tens place, and the leftmost digit as being in the hundreds place. So how do we get from this pattern of 1, 2, 3 to the number 123? Well, it's some quick mental math that we all just do instinctively. It's 100 times 1, plus 10 times 2, plus 1 times 3. That, of course, gives us 100 plus 20 plus three, or 123. So all of us just kind of take that process for granted now. But it turns out that there's a system at play here, a system such that we can figure out any number in the same way. So if we've got our ones place, tens place, and hundreds place, of course, in the decimal world, this is the number 1, this is the number 2, 3, 4, 5, 6, 7, 8, 9. Something interesting happens, of course, after 9. You sort of carry the 1. And why then does 010, or if we ignore the leading zeros as being insignificant, why does one 0 represent the number we all know obviously as 10? Well, just because it's 10 times 1 plus 1 times 0. So that's the system we've been using for years. And it turns out that these columns, realize, are just powers of 10. So 10 to the 0 is 1, 10 to the 1 is 10, and 10 to the 2 is 100. That's how we got ones, tens, and hundreds place. Now in the computer world, you don't have 10 digits, 0 through 9. You have just two digits, 0 and 1. So we can just make a little tweak to our mental model here, so to speak, and just now use 2, powers of 2, instead of powers of 10. So that means the right hand column is going to be 1, the middle column is going to be 2, the left column is going to be 4, and if we kept going, it'd be 8, 16, 32 instead of 1,000, 10,000, 100,000. But the idea is exactly the same. So I propose that computers only speak zeros and ones, of course. But how do they represent larger numbers than 0 and 1? Well, this is representing 0. This is representing 1. What pattern of symbols on the screen would represent the number we humans know as 2? Yeah. So 010. So you just spoke binary. So even if you just generally knew that binary is spoken by computers, it just means that a computer, to represent the number we know as 2, somehow stores a pattern of symbols of 010. How do they represent 3? 011, for the same reason. It's 2 times 1, plus 1 times 1, gives us, of course, three. And now, just as before when we meant 9 to 10, now we actually go from 3 to 4 by carrying the 1 now. So in binary, bi meaning two, hence the 0 and 1, 100 is not 100, per se, it is literally the number we know as 4. And we can keep going on up. This of course, now is 5. This would be 6. This would be 7. And what happens if we want to represent eight? Yeah. So we kind of have to solve this somehow. We need another digit. And that's fine, right? In math class, you would just add another place, another column, in order to get back the value that you want. So we need more zeros or ones, otherwise, now known as bit. If you've ever heard of the phrase bit, it just means binary digit, and a 0 or a 1 is just something we know as a bit. And why is this germane to computers? Well, as fancy as our Macs and PCs and phones are today, consider, after all, that at the end of the day, what do you have to do, typically, with your laptop, your desktop, your phone these days? What do you do at the very end of the day? Yeah, so you charge it, right? You plug it into some physical resource. That is the only physical resource into these computers that we use today. And that's kind of nice, because, of course, the core can either be plugged in or not plugged in. Or maybe we could call that a 1 or a 0, true or false, on or off, which is to say if electricity is our only input and there's either yes electricity or no electricity, well, that actually maps quite nicely to the idea of binary because we need just two symbols, 0 and 1, off and on, to represent that idea. Of course with a single bit, you can't do all that much. You can only count from 0 to 1, and that's it. So computers tend to use larger numbers of bits to represent information. And they do this ultimately physically. So it turns out that with both plug-in the wall, or even a light bulb or a switch thereof, you can represent a 0 or 1. But if you want to represent more zeros and ones, well, we just need, maybe, 8 bits at a time. And if you've ever heard of the expression byte, a byte is just a term describing eight bits, eight zeros and ones, a more useful measure instead. So given that, I think it's time, perhaps, to see if we can't solve the problem ourselves. Perhaps we could get, say, two volunteers to come on? OK. Saw one hand here and one hand over here. Come on down, if you want to meet me on the other end of the stage. Come on over here. Come on down. What's your name? PRIYANKA: Priyanka. DAVID MALAN: Priyanka, nice to meet you. David. Come on over and if you want to wait right here. And what's your name? CALVIN: Calvin. DAVID MALAN: Calvin? CALVIN: Yeah. DAVID MALAN: David. Nice to meet you. Come on over here where Priyanka is. So Priyanka, you raised your hand first, so you get to choose. Do you want to go first or second in this little challenge ahead? PRIYANKA: Uh, I'll go first. DAVID MALAN: OK. So Priyanka is going to go first. If you want to stand over there, Calvin. So the challenge at head here is could you go ahead and represent for us in binary, using each of these light bulbs and, in turn, switches, as zeros and ones, say, the number 50? So you might turn one light bulb on representing the 32s place. Might turn a light bulb on representing the eighth place. Our total count now is 32 plus not 8 plus 16, I think, which is going to give us 32 plus 16, which is 48. And so we get now a round of applause, if we could, for Priyanka. Thanks very much. Give us just a moment. So each of these light bulbs, then, represents just a switch or a bit. And inside of your computer, if you've ever heard the phrase transistor, a transistor is just a tiny little switch in our computers. So they have millions or billions of these switches that they use physically to represent information and store values, just like Priyanka did here. So if a computer were to represent the number 50, it would literally turn on three switches of sorts, store a little bit of electricity here, here, and here to represent the number 50, and it would leave off all of the other switches. The other five, in this case, if we're using eight bits or one byte. Calvin you raised your hand second, and so we have one other challenge ahead. Fortunately, these things are magnetic, so let's take things up a notch. And if you would, Calvin-- [LAUGHTER] --how about the number 13, if you will. How would a computer represent the number 13 where each of these light bulbs from 1 to 128 represents a bit? We had, of course, the ones place over here, the twos place, four, eight, 16, and so forth. So we can ask the audience, should we turn on, for instance, this bulb here? AUDIENCE: No. DAVID MALAN: No. Way too big. How about this one? CALVIN: No, too big. DAVID MALAN: OK. And you're in charge. Ask the audience. CALVIN: This one? AUDIENCE: Yeah. CALVIN: Yeah. DAVID MALAN: OK. So we have 1, 2, 4, 8. CALVIN: 4. DAVID MALAN: 4 gives us 8 plus 4 is 12. And another round of applause, if we could. Thank you. You got the tougher job. Thanks to you both. So at the end of the day, while this is a very large physical incarnation of the notion of binary, that's all that's going on inside of our computers every day when they represent information. But we only, thus far, have the ability to represent numbers, it seems. So how then does a computer allow you to send text messages and emails and compose documents and so forth? We need to all agree how we're going to go about representing characters or letters of an alphabet, be it English or something else, instead. And any intuition for how, if a computer only has millions or billions of switches that can be turned on and off, thereby representing numbers, we could possibly go about representing something other than numbers, like the letter A? Say it again? By a digit. So we maybe just need to agree as a group, you know what? Let's all agree that the letter A, in the context of a word processing program or a text message or email, just needs to be represented by a number, and we all need to agree what that number is. So maybe super simply, let's just say A is 1, B is 2, C is 3 and so forth. And you could imagine then having a computer turn on lots of little transistors to represent A and B and C, so long as the software on that computer, as we'll see, knows that it's a word processing program and not, say, a calculator or something that's meant to use numbers alone. So it turns out that computers don't actually use the number 1 for A or 2 for B. It's a little bigger than that. The world decided decades ago that the capital letter A is going to be represented by the number 65. 65, which is to say, if you have a byte of information in the computer, and this is the ones place, twos, four, eight, 16, 32, 64. If a computer were to store the capital letter A using eight bits or switches, it would just turn on those two, the 64s place and the ones place. And so when you have actually received a message in a text message or an email with a capital letter A, you have just received a pattern of zeros and ones somehow, wirelessly or via wires, representing that pattern. Specifically, this pattern here, if we draw it not as light bulbs, but as zeros and ones. So it turns out there are certainly more numbers than just A's and B's and C's. We have the whole alphabet plus punctuation, thanks to a system called ASCII, the American Standard Code for Information Interchange, which is just a fancy way of saying that there is a well-defined map that humans around the world agreed on years ago that looks a little something like this. So A is 65, an I is 73, and dot dot dot to both ends. So that is to say if you were to receive a message from a computer or from a friend saying 72, 73, 33, or the pattern of zeros and ones representing those digits , what message did you perhaps just receive? 72, 73, 33. Yeah. So, hi. So quite literally, if you were to text a friend, hi, they would receive a message that's essentially a pattern of zeros and ones, 72, 73, then something. It's actually not obvious from the chart what they are, but it turns out 33 was the number humans gave years ago to represent an exclamation point instead. And so any of the other punctuation symbols you might see on your keyboard, similarly have numbers that a computer would use, that all of us agreed on years ago, to represent that value. But of course, this is very American-centric at the moment. And indeed, the acronym ASCII has American in it. So it was biased early on to American English, for instance. But there's so many more characters in the world, of course, such as accented characters and other languages altogether. And frankly, there's also these things these days, which even though they look like pictures, you access them via your keyboard because they are indeed just symbols in an alphabet. There are zeros and ones, patterns of zeros and ones, that represent those characters, as well. That's what's known as Unicode, and that's, like, a superset of ASCII. Because ASCII, way back when, used only eight bits, which is not terribly many, to represent characters. Unicode uses 8 or 16 or 24 or even 32, which means we have a way many more possible patterns of zeros and ones with which to represent things like this. So this is face with tears of joy. As of 2019, it is the most popular emoji sent on iOS devices, at least. Does anyone want to hazard a guess as to what the decimal number is that represents a face with tears of joy? Not 65. Not 72. Not 73. 800. Higher than that. 10,000. Higher than that. It's 128,514. That's how many emojis await us down the road because the numbers are now getting this big. Or equivalently, this pattern of zeros and ones. So at the risk of taking all of the fun out of ever sending someone an emoji, when you send that face with tears of joy, you're literally just somehow having your phone send a friend's phone this pattern of zeros and ones. And Android or iOS are presenting it as that yellow picture. But that yellow picture, of course, itself is an image. And it's composed of lots of little dots. And odds are coming into this class, you're generally familiar with using images, certainly, and seeing the little dots that compose an image. Especially if they're of low quality, you can really see those dots. And so in a face like the emoji, we have lots of yellow dots. How does the computer represent each of those dots? Well, according to a system called RGB. Red, green, blue. So again, decades ago, people in a room decided, you know what? To represent colors, we still have to use just zeros and ones, little switches, mechanically. But let's just all agree what numbers represent what colors. So we just need another system for that. Now it turns out that RGB essentially composes any color of the rainbow by mixing together some red, some green, some blue. And by combining those colors one on top of the other, you can get any color of the rainbow you want. So this is to say to store any dot on the screen, one pixel, so to speak, in an image that you might take as a photo or send to a friend, you are actually storing three values. One, two, three. Three numbers, really, that, of course, at the end of the day, are zeros and ones. Those three numbers just tell the computer how much red, how much green, and how much blue to use to represent some dot on a screen. So suppose that coincidentally, a computer were storing the pattern 72, 73, 33, albeit with zeros and ones or light bulbs, back-to-back-to-back like this. Well, in the context of Photoshop or a browser or Apple photos or the like, in the context of a graphical program, your computer is going to interpret this same pattern of digits, and in turn, bits, not as high, exclamation point, but as some amount of red, some amount of green, some amount of blue. And it turns out if you combine this much red, 72, this much green, 73, followed by this much blue, 33, what you get when you combine all three of those is a shade of yellow. So for every single dot in that emoji, that face with tears of joy, every dot in this image-- and we can see it if we really zoom in-- is stored using three values. Some amount of red, some amount of green, some amount of blue that we can bind give you yellow or black or gray or anything else, depending on how you encode those values. Meanwhile, images or videos, things like this that you might see on the internet these days in the form of memes or anything else, are actually just images, but they're multiple images in the same file. If you've ever seen what's called an animated GIF, which this happens to be that happens to be looping, all our human eyes are seeing is one image after another after another after another really quickly, creating the illusion, therefore, of movement. But this cat is not actually moving. These are like five or 10 photographs of a cat in different positions just being looped endlessly. And that, too, is all a video is. A video is just a sequence of images flying past your eyes so quickly, we humans perceive it as actual movement. And so that's almost everything we use to represent information today in our computers. We have zeros and ones from which we get binary to which we then get decimal digits, but we can use those digits to represent, say, characters on the screen or colors on the screen and, in turn, now even the more interactive. Now what about something like music in a computer? Another type of information you might want to represent? Well, if we had a piano on the stage here, we could quantize the notes you're playing using just numbers, as well. What note you're playing, maybe it's A, B, C, D, E, F or G or some variant thereof. Maybe how long you hold the key down for, and if you hit it really hard, maybe how loud it is. So you could imagine using three values, the note, the duration, and the volume just to represent something like a piano song. [PIANO PLAYING] Might be one encoding of a song. And I might use different values if I want to play it even louder and longer. [PIANO PLAYING] And so forth. Which is to say that at the end of the day, no matter what media we use to represent information, it all reduces to zeros and ones. So once we have the ability to represent inputs, be it numbers or letters or colors or videos, now we can talk about outputs. So how do we get from inputs to outputs? That's what's inside this so-called black box, and this is where computer science comes in. An algorithm. Anyone know what this term is? What's an algorithm? You sort of read about it all the time these days, especially in the context of self-driving cars and Siri and Alexa and so forth. Yeah? A set way to do something, yeah. In the context of problem solving, an algorithm is just step-by-step instructions for solving some problem. So what might an algorithm be for a problem that we might want to solve? Well, consider this. This is an old school problem where you might have lots and lots of names and lots of lots of numbers, and those names are hopefully sorted alphabetically from A through Z in a book like this. And even though most of us don't really reach for this technology anymore, consider that it's really the same as your iPhone or Android phone or other device, which has all of your contacts top to bottom and you can scroll through them from A to Z, or you can search for them by typing into the little autocomplete box. How is even your phone solving this problem? Well let's consider a simple approach. I'm going to look at the first page and look for someone on the phone book. Suppose that person's name is Mike Smith, last name starting with S. Let me go ahead and look down. He's not here. Let me turn the page. Let me turn the page. Let me turn the page. This is an algorithm. It's a step-by-step process for solving a problem, finding Mike Smith. Is this algorithm correct, would you say? Yeah. I mean, it's pretty slow, it's pretty stupid, in that it's going to take, my God, forever, like, hundreds of page turns to find Mike Smith. But if he's there, I will find him according to this step-by-step approach. What if I speed things up a bit just because it's tedious, otherwise? So I do two, four, six, eight, 10, 12, 14, 16 and so forth. Is that algorithm faster? Absolutely. Literally twice as fast. Is it correct? AUDIENCE: No. DAVID MALAN: No. Why? [INTERPOSING VOICES] DAVID MALAN: Yeah, we might skip them. I might get unlucky and eventually, I might get to the S's. But darn it if Mike wasn't in between two pages as I turn them at once. So it's not a fatal flaw. That algorithm, I could fix by just saying if you hit the T section or maybe Sn instead of Sm, just back up one or so pages just to fix that bug or mistake, so to speak. But it, at least, is twice as fast. But if this phone book has 1,000 something pages, it's still going to take me maybe 500 pairwise turns just to find Mike Smith. That's a while just to look someone up. But most of us, if you've used this technology, instead, did what, back in the day? Go roughly to the middle if there aren't little letters on the side off which to cheat. So roughly into the middle. I'm in the M section. Now the M's, of course, mean that Mike is not this way, which would be the A's. He's probably this way toward the Z's because S, of course, is between the M and the Z. So at this point, I can literally tear the problem in half, throw half of the problem away very dramatically and unnecessarily, making the point that we've now gone from 1,000 some odd pages to what? 500. And I can do it again. Ah, I went a little too far. I'm now in the T section, so I can tear the problem in half again, throw that half away, and now I'm down from 1,000 to 500 to 250 pages only, after just two steps in this step-by-step process. And if I repeat this again and again and again, hopefully, I'll be left, ultimately, with, say, just one page on which Mike Smith either is or is not. And I can call him or quit. So that algorithm would get me to the solution so much faster. And we can appreciate this even if we just look at some of the numbers, ultimately, as follows. So if I start with, say, 1,024 pages total in the phone book, and I'm looking for Mike Smith, and I divide and conquer this problem, splitting the problem in half and in half and in half, I go to 512, I go to 256, 128, 64, 32, 16, eight, four, two, and one. After just 10 steps, I have found Mike Smith's page. By contrast, that first algorithm where I just did one page at a time, how many steps, maybe, might it have taken me to find Mike Smith? Yeah, like, 700, 800, roughly where the S's might be. So in the worst case, 1,000 pages, if I look through the whole thing. The second algorithm, maybe, 500 pages because I'm going twice at a time. But my God, 10 steps with this algorithm here. And odds are that would be the algorithm most of us in this room would reach for by default, which is to say that a lot of problem solving really, as we'll find, is just about harnessing your existing intuition and comfort with ideas that now you just need to translate in such a way that machines and other humans can understand. So how might we just think about how much better that algorithm is? Well, consider this first line here. On this y-axis, or vertical axis, let me describe this as the time to solve some problem. And on the horizontal, or x-axis, the size of the problem. So the number of pages in the phone book would get bigger as you go to the right and the number of seconds or page turns required would go up along the y-axis here. So that first algorithm, depicted here in red, suggests a one-to-one relationship between the number of pages in the book and the number of seconds to find someone. So you have this straight line. A slope of 1 over 1, if you will. And so if we consider the second algorithm, the second algorithm is also going to be a straight line, but that straight line is going to be lower on the graph. Why? Because for any size problem, it's going to take me half as much time to search that phone book because, of course, I'm going two pages at a time. So if we see this, for instance, if this dashed line represents some number of pages in the phone book, maybe 1,024, well, you can see that it might take this many seconds or page turns to actually find Mike Smith with that second algorithm. But in the first algorithm, that same number of pages would take way more time to solve, literally twice as much time in this case. Well what about the third algorithm? Well, even if your memory of what a logarithm is a little hazy, it just describes a fundamentally different shape. The green line describes that third and final algorithm whereby you divided the problem not one page at a time or two pages at a time, but 50% again and again and again. You have it again and again and again. And notice that as the number of pages in the phone book gets really large, you barely make an impact on how much time it takes to solve that problem. For instance, if Cambridge and Allston, two towns here in Massachusetts, merge next year and their phone books become one phone book that's twice as big, so not 1,000 pages each, but 2000 pages total, how many more steps might it take us to find Mike Smith in next year's phone book if it's got 2000 pages instead of 1,000? Just one more step. But the first two algorithms, that's another 1,000 steps, maybe, or another 500. These are fundamentally big differences in efficiency, so to speak. So let's translate this idea, this intuition, into the first example of code. There's a pseudo code. And there's no one formal definition of this. Pseudocode is code-like syntax that you write in English or your own spoken language that represents your ideas, but in a succinct way. And so I might propose that this algorithm for finding Mike Smith might be written in pseudocode English-like syntax as follows. Step one, pick up phone book, which was indeed the first thing I did. Step two, open to the middle of phone book, which is the next thing I did. Step three might be look at the page to see if someone's there and if Smith is on that page, what do I want to do? Well, my code is going to look a little different now, and I'm going to deliberately indent to make clear that there's a dependency here of some sort. I'm going to go ahead and step five and call Mike only if line four is true, that he's on the page. Else if Smith is earlier in the book, to the left, so to speak, I'm going to go ahead and open to the middle of the left half of the book, and then what am I probably going to want to do next? AUDIENCE: [INAUDIBLE] DAVID MALAN: So, yeah, this, ultimately. How do I do this again and again? Well, I already have some code, if you will, on line three that does that. Look at page and then make a decision to go left or go right. So I'll just say go back to line three after going to the middle of the left half of the book if Smith is indeed earlier in the book. The other scenario, of course, is the opposite. So else if Smith is later in book, let's open to the middle of the right half of the book, and then let's go to line three. Else, there's a fourth possible scenario or case. What else might happen in this algorithm? AUDIENCE: [INAUDIBLE] DAVID MALAN: He's not there. And so I probably want to anticipate that and just say quit if, indeed, he's not on the page, to the left of the page, or to the right of the page. So there is one way of expressing this pseudocode albeit now in just this English-like syntax. But in this syntax alone, there's some commonalities, some features we're going to see over the next several weeks not only in pseudocode, but in a language called Scratch, a language called C, a language called Python and more. There are certain constructs in programming, procedural programming, so to speak, that are going to be common among all of these languages. Highlighted in yellow here are what, henceforth, today and onward, we're just going to call functions. These are verbs or actions that just tell the computer, or in this case, the human, what to do. So those are functions. Now highlighted in yellow instead are what we're going to call conditions. These are branches, sort of forks in the road so you can either do this or you can do that or maybe this other thing as well. But to make those decisions, you have to ask yourself a question. And those questions, in computer science, are called Boolean expressions, after a mathematician named Boole. And a Boolean expression, highlighted now in yellow, are just questions that have yes or no answers or, if you will, true or false answers or, heck, now that we know binary, one or zero answers. So even in code, we see a hint of why ones and zeros are helpful. Lastly, there's this thing here. Go back to line three. We've used it in two places. That refers to something we'll call a loop. It's a cycle that does something again and again. So beyond those four ideas, functions, conditions, Boolean expressions, and loops, we're about to see a bunch of others, as well. Variables, reminiscent of what you might recall from algebra, but more powerful now in this context of programming. Something called threads and events. And we're going to do this by way of an actual programming language. But it's not yet going to be this one. Indeed, just a week from now will you actually understand what this means. Odds are 2/3 of you have no idea what this actually is, and that's OK. But it's a program written in a language called C-- more on that next time-- that quite simply says hello to the world. But we're going to do it today in the context of a graphical language from my MIT's Media Lab called Scratch. This is a language via which you can program a computer by dragging and dropping blocks or things that look like puzzle pieces that interlock together so that you can tell the computer exactly what to do, step-by-step. And we'll see in this language today, and for the first problem set or programming assignment, that you can express all of these ideas from pseudocode in an actual language like Scratch. So what lies ahead? Well at scratch.MIT.edu, which I'm about to pull up myself, is going to be where you spend time in the first problem set. And it's going to look quite like this when you open it up. On the left hand side of this website, this web-based programming environment from MIT, you're going to see on the left hand side a whole bunch of puzzle pieces, so to speak. And they're categorized according to some different colors there on the left. In the middle, there's just going to be a big white canvas, initially, onto which you can drag and drop those puzzle pieces and lock them together to make the program do something. What can you make it do? Well, on the top right here is the so-called stage in Scratch. By default, there's only one character, or sprite, on that stage. Scratch himself, and he can move up, down, left, right and do any number of other things if you tell him what to do by dragging and dropping those puzzle pieces. If you don't like that cat or you want many others, you can also add multiple sprites, or characters, by creating them in that area. So let's actually do this now with some sample programs such that we can actually begin programming using this environment. I'm going to go ahead now and open up a browser here. And in just a moment, you'll see on the screen scratch.MIT.edu itself. So if I go ahead and create by simply clicking up there, we'll see this editor, ultimately, that, by default, has this tutorial that I'm going to go ahead and dismiss. But now we see that same environment. And you'll see that above Scratch here over at top right, there's this green flag and this stop sign. The green flag is what you can click as the human to make the program go. The stop sign will make any program stop. So it turns out among all of these categories here, there's, for instance, some orange ones called Control. There's some yellow ones called Events. And we'll focus on this latter one first. If I go ahead and drag from events this puzzle piece here, this is how I can begin programming. When the green flag is clicked, do the following. What do I want to do? Well, let's have this cat just say hello. And from having used this program before, I know that under Looks, I can go ahead and say something like, say hello. And notice not only does the shape match the orange puzzle piece or yellow puzzle piece, notice that it magnetically wants to snap together, and if I let go, it will. And I'm going to say perhaps one of the most canonical things to say in your very first program, which is just, conventionally, hello world, and leave it at that. I'm going to now go ahead and click the green flag. And voila, our very first program. The same effect. [APPLAUSE] Thank you. Thank you. Very low bar so far, but we'll improve upon this next because this cat is pretty inanimate and is just now saying hello. What if we wanted him to do more than that and say not hello, but hello to me or hello to you? Well, it turns out we can do this a little differently, as well. I'm going to go ahead and throw this away by just dragging it over on the left. And the puzzle piece just goes away. And if I poke around a little further under these blue blocks, for instance, Sensing, there's a bunch of puzzle pieces related to Scratch's environment. And one of those is this one here, ask, what's your name? And wait. But that what's your name expression is in a white box that I can actually change. So you can ask any questions you want, but I'll go ahead and use that default. And now notice also over here in blue is Answer, which is another circular shape which represents what we're going to start calling a variable. That variable is going to store whatever the human types in when asked for his or her name. So what do I want to do when I actually get the person's name? Well, let me go back to Looks. Let me go ahead and say hello. And I'll go ahead and say hello and then another one, say hello again. But instead of this, I want it to say my name. But it would be incorrect to just type my name because then my name is always going to be David no matter who plays this game or is asked the question. So I don't want to do that. If I go instead to Sensing and then drag and drop this puzzle piece, notice this. It wants to magnetically snap in there. And it will grow to fit it. So now I can say hello and then I can say name. So let me go ahead and hit stop and play again. What's your name? I'll go ahead and type in David. Enter. And now David. Huh, I feel like we forgot the hello. This is my first bug. Any thoughts as to why? What did I do wrong? Yeah? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah. I mean, I told the computer via this algorithm to do three things, ask what's your name and wait, but then I just say said hello, say answer in such rapid succession. And my God, our Macs and PCs and phones these days are so fast, they're going to do so many things so quickly that it did say hello, it's just none of us really saw it because my name immediately overrode it. So I can fix this in a couple of ways. Let me go ahead and go back to Looks for just a moment, get rid of this puzzle piece, and maybe say hello for two seconds. Then let me go ahead and say my name or the user's name for two seconds as by dragging answer now into here. So that was my first bug in code, so to speak. Let me go ahead and play again, type in David, and now it's hello, David. All right. So better. It's a little weird because you typically don't greet someone by saying hello, David, two seconds later. So what if we kind of combine this expressions and say not hello world, but hello comma David? Well, we can do this in a different way. Let me go back over here and, for instance, get just one of those say blocks like this. I'm not going to worry about saying it for some number of seconds because I'm only going to say one thing now. But I somehow want to say hello comma and then the user's name. Well, if I poke around further, and you would only know this by having seen it before, it turns out there's this puzzle piece down here called Join. And it's a little weird that the default words are apple and banana, but those are just placeholders. If I go ahead and drag this over here, it grows to fill and it overwrites what was there. I can say hello comma and then instead of hello banana, let me go back to Sensing, drag the user's answer, and now we say hello comma so and so. So let's try this now instead. Green flag, type in my name, Enter. Hello comma David. So now the program isn't all that much more complicated, but notice that we're starting to nest these verbs, these functions. We're asking for a name and then we're saying the result of joining the following two things. So there's a few ideas to keep track of at a time. But this is actually quite like what we were doing from the get-go earlier as follows. For instance, if we want to just say hello world with this puzzle piece here, this actually maps perfectly to our fundamental definition of what problem solving is. The input to that puzzle piece is, of course, just hello world. The function or algorithm that you want to execute, step-by-step instructions for saying something, Scratch calls Say in purple, and the output you want, of course, is Scratch saying hello world. Now in the more sophisticated example, consider this. We asked what's your name? And then we waited. Well, that picture would look like this instead. The input to that question is, of course, what's your name? The algorithm, or in this case, function, via which we're solving that problem is to ask and wait, taking in that input. And the output we get back is now answer. And then lastly in that third example, where things got a little fancier and you had to start dragging and dropping and nesting these puzzle pieces, notice that this is the same idea. The input now is two things, hello and answer. Those go into a function called Join, the output of which should be hello comma David. But now we want to pass that output as the input to the Say block so that the final result is hello, David right out of the cat's mouth. So in this way, even with the simplest of puzzle pieces, does everything fit into this same model of problem solving. But let's now make things a little more interesting. Rather than just talk and text with this cat, let's go ahead and have it do some other things instead. Let me go ahead under Sound, for instance, and it looks like there's a block in pink here called Play Sound Meow until done. And now let me stop the old program and start the new. [CAT MEOWING] OK. A little piercing, but adorable. And if you want to hear it again-- [CAT MEOWING] --I can click the green flag-- [CAT MEOWING] --and I can click the green flag. Of course, this is a pretty boring cat if it goes lifeless after it said just one meow. How would we get it to perpetuate that sound and just meow every few seconds? What constructor idea might we want to use here? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, so some kind of loop. So it turns out in Scratch, there's a few ways to do this. But if I go down to Control, you'll see a couple of blocks here. Repeat some number of times, by default, 10, or forever. I'm going to go ahead and maybe do this forever. [LAUGHTER] And I'm going to drag and drop this now into here. Notice I can move things around wherever I want. And now I can reattach this up here. And now play. [CAT MEOWING REPEATEDLY] It's a very agitated cat at the moment. I can calm him down, perhaps, by dragging and dropping this. And notice even if there's no room, it will grow to fill. [CAT MEOWING SLOWED DOWN] One second. Now it's a happier cat, if you will. But now that we have the ability to have the cat do something forever, it doesn't have to just do the same thing again and again. It can interact with me or its environment. So instead of playing the sound here-- someone following along at home? So instead of playing the sound here, let me go ahead and try this. Let me go to Sensing and go ahead to-- what might I want to do here? Let's go ahead and under Motion, rather, under here, point toward mouse pointer. So point towards mouse pointer and then go ahead and move some number of steps. And I'm going to have it move one step or dot or pixel at a time. And here now we'll get this effect. It looks as though now he'll kind of follow me, right? And as I move my cursor, he is forever pointing toward the cursor then moving one step. Of course, he's a little slow. And let me go ahead and stop. If I make him take 10 steps at a time, or 10 dots or pixels on the screen, now it seems a little harder to avoid. And you can sort of-- he'll literally do as you move your cursor here. All right. So now that we have the ability to do something again and again, let's have something count up. For this one, let me go ahead and grab something from online. So on CS50's website, we'll always make available the examples and source code from each class. And this time, I want to go ahead and get this sheep here. So it turns out you don't have to just use a cat. You can use a sheep if you prefer. And let's see. By looking at this code first, what is this sheep going to do? When the green flag is clicked, there's this orange puzzle piece called Counter to one. What is that? That's an example of-- what might we call this? Yeah. It's called a variable. Now in algebra, we typically use x and y and z for variables. In programming, when you want to store some value in a placeholder like a variable, you typically give it more descriptive words because x, y, and z don't really tell the programmer or someone reading it what it's doing. So we call this variable Counter and we set it equal to 1. Now forever, the sheep is going to do what? It's going to say the counter for one second, it's going to then wait for one second, and then it's going to change, or add 1 to, the counter as its final step. So here we have, if you will, counting sheep whereby it will now just perpetually count up from 1 to 2 to 3. And probably, if we let this thing go, up to infinity. So once we have the ability now to do variables, what if we start to make our programs more interactive and start to remember information? Let me go ahead and into our examples from before, and grab another example here now instead. I'm going to go back to what's called a Studio in Scratch, where all of these examples currently are. And I'm going to go and open up an example called pet 0. Computer scientists typically start counting from zero because that's symbolic of all of the light bulbs being off. And so here's a program now that if I hit Play does not seem to do anything at first, but notice as I move my cursor over-- [CAT MEOWING] --I'm kind of petting the cat now, if you will. So how is this working? Well, he, too, is just forever listening or waiting for something to happen. It's forever doing this if Touching Mouse Pointer then Play Sound Meow until done. So now the cat is being responsive to the user input not following my cursor, but responding just if I'm actually hovering over him. We can, of course, change this up a little bit in version two of this, otherwise known as pet one because we started counting at 0. What should I not do with this program? [CAT MEOWING] Maybe don't pet this cat. Why? Well, this time it is forever checking if I'm touching the mouse pointer. And if so, it's going to apparently play a sound roar, else it plays the sound Meow, which seems to be happening. So here we go. [CAT MEOWING] [CAT ROARING] So don't pet the cat. And so that's just a condition asking a question, a so-called Boolean expression if Touching Mouse Pointer. Well, now let's do something a little fancier still. Let me go ahead here and do this. Let me go ahead and make this one from scratch, no pun intended. And I'm going to go ahead and start with an event. When the green flag is clicked, let me go ahead and grab some motion here. Let me go ahead and grab Set Rotation Style to left right just because this will make sure that he ultimately does as we intend. I'm going to go to Control. I'm going to do the following forever. Suppose I want the cat to just bounce back and forth on the screen. Well, the first thing I need to do is animate him and actually make him start moving. And the best way to do that, frankly, would just be to go to Motion and move some number of steps, maybe 10 steps to go quickly or one step to go slowly. But I can ask a question every time the cat moves. I can go and ask something like this. If something is true, go ahead and maybe do something else. So maybe bounce off the wall. So how do I say if you're touching the edge, go ahead and bounce backwards? Well, it turns out if you poke around, you'll see something like this. If touching Not Mouse Pointer, but notice this edge, I can use the little dropdown, change what the puzzle piece says. I can now move this Boolean expression into place. The condition will grow to fill. And what do I want to now do? Well, if he touches the edge, I'm going to go ahead and say turn not 15 degrees, which is the default, but I'll do it 180 instead. And now we have our own little animation where he's going back and forth and back and forth. Of course, this seems a little unrealistic that he's just bouncing happily so, so there is a non-academic feature we can now introduce. For instance, you can turn on your computer's microphone and say ouch. That is what Ouch looks like. If I go ahead and save this, call this Ouch, go back now to my code. Let's go ahead and into sound here and maybe play not the sound Meow, but maybe the sound Ouch, such that now this cat-- [OUCH SOUND PLAYING REPEATEDLY] OK. So maybe a little more dynamic. But it turns out he's really not walking or running. He's really just-- [OUCH SOUND] --sliding across the screen, right? His legs are never actually moving. Now, why is that? Well, it turns out that the costume that this sprite is wearing, that the cat is, it's just a picture. It's an image composed of lots of little dots. And you know what? To animate a character and bring some life to it, so to speak, all we really need is at least one more picture. After all, that's all an animated GIF or a video is, multiple pictures. So here's one, here's two. Here's one, here's two. And even though he's definitely making some leaps with each stride, if you do this fast enough, it would seem that the cat is actually making some motion and walking instead of just sliding. So how might I go ahead and do this? Let me go ahead and open up this example, which I've made in advance. This one's called bounce one. And in bounce one here, I have the following second costume. If I go ahead and click See Inside and click Play Now, you'll notice now he's kind of moving. It's a little jaggy because he's moving from one position to another really quickly, but now it's the illusion of movement. So if you've ever played a game or you've ever created some animation yourself or even a film, this really is what's been happening underneath the hood all this time. But you don't have to have just one cat or one sprite in a program. We can actually have multiple. Let me go ahead and open up another animal here. This one, a sea lion. So in this sea lion here, if I See Inside and see its code, there's a lot going on here. So let's see what this thing does first. If I go ahead and click the green flag-- [SEA LION BARKING] --it's really, really annoying. [SEA LION BARKING] Now, why is that? There's some loop in here, clearly, that's just doing the same thing again and again and again. How might, based on this code, I stop the sea lion from barking? Yeah. So that's the solution. Let's go ahead and hit the space bar. Why did that actually get him to stop barking? Well, notice this. There's two scripts in this program, which is a little different from before. Each of these represents a script or a program. Notice here there's a variable called muted, and by default, it's false. That is off. So muted is false, or off, which means it's not muted, which is why we hear it. Then it does forever the following. If the key space is pressed, go ahead and check the following question. If muted is true, change muted to false, else change muted to true. So this is a very common approach in programming where if you have a variable, like something called muted that's either true or false, 1 or 0, on or off, you can change its value by just asking that question. If muted is true, change it to false, else set it to true. Meanwhile, if we scroll up, there's another script here that was doing something again and again. And I'll zoom in on this one. When the green flag was clicked, the sea lion was also forever doing this. If muted is false, that is, if it's not muted, go ahead and play the sound sea lion and go ahead and say hi, hi, hi for two seconds and then wait for one second. And do that again and again and again. So in programming, as in Scratch here, you can do multiple things at a time sometimes with languages, such that they're both running together in parallel, if you will, or looping again. And they can somehow intercommunicate by using something like a variable. Let's look at one final example involving two different sprites, this one an old school game that you might recall growing up called Marco Polo. In this game of Marco Polo, one person yells out Marco and one or more other people yell out Polo. And the first of them is typically blindfolded, so you're trying to find that person based only on his or her voice's response. So in this program here, if I go ahead and click the green flag, notice that nothing happens yet until I hit the space bar. And we'll see that the orange puppet says Marco and the blue puppet says Polo. But how does that work? Well, here is the code for the orange puppet. Forever, he is doing the following. If the key space is pressed, that is the space bar, say Marco for two seconds, but then one other feature. And this is new. It broadcasts what's called an event. So it turns out that computers can't just see what another program or sprite is doing, but they can listen for something called an event. It's sort of a secret message from one program to another. So broadcast event is this other puzzle piece that can just say event. And now notice if I click not on the orange puppet down here, but on the blue, the blue puppet has even less code, but it is not waiting for the green flag to be clicked. Instead, it is waiting until it receives this so-called an event, a sort of invisible message from one sprite to another. And once he receives that event, it says Polo for two seconds. All right. So along the way, it turns out that there are better ways to solve some of these problems. And we can actually start to think now a little more in terms of design, the design of the quality of your code. I'm going to go ahead and do this. Under events, I'm going to go ahead and grab when green flag is clicked, and I'm going to go ahead and say something this time. Let's go ahead and say cough for one second like this. And then let me go ahead and wait for some number of seconds, like one. And then you know what? Let me go ahead and cough three times. It's not uncommon when you're coughing, in the real world, to cough three times. So I'm going to right click or Control click, I'm going to go ahead and duplicate, and just attach another one of those. And I'm going to right click or Duplicate and give me one of these. And now, of course, the cat is going to cough, cough, cough or meow, and three times in a row. Now this code is correct. It does cough three times and it waits one second after each, but it's not very good code. It's not well-designed, as a computer scientist would say. What could we do better with this code based on the ideas we've seen thus far? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah. So we can loop instead, right? And Copy Paste is rarely the solution when programming, be it in Scratch or in C or in Python or other languages. So I'm actually going to throw all of this away. Let me go ahead and just grab a repeat block, change that default ten to three. Let me grab these pairs of blocks and put them in here, drag and drop this up here. So now I'm going to go ahead and repeat three times, say cough for a second, and then wait one second. And now the program is just better designed. It is no different from before, but it's a little easier to maintain now for me or someone else because if I want to change how long something's happening or what's being said, I can change it now in one place instead of multiple. But there's this other idea in computer science, this notion of abstraction. Right now, this is a program that just so happens to implement the notion of coughing. But what if I want to use the same idea in multiple programs and I want to give myself a custom puzzle piece that does not come with Scratch called cough? Well, there's this one other feature up here I can do like my blocks, and I can make a block. And I'm going to go ahead and call this cough. And that puzzle piece, once I click OK, is going to give me this pink block here. I'm going to go ahead now, for instance, and move all of this down to the custom puzzle piece. And now notice because I've made a new block, I have this pink piece here. I can now move this over here. And frankly, out of sight, out of mind. I can literally ignore those puzzle pieces I created because now I have a new puzzle piece just called cough that says what it does. This is an abstraction in the sense that I don't care how you implement coughing, I just care that your program can cough. And so we have this notion of reusability that starts to make our code no less sophisticated, but much, much smaller and much less prone, potentially, to mistakes. And I can take this one step further. Let me go ahead and open up a different variant of this one altogether, this one in cough three. You can have these custom puzzle pieces even take arguments. You can have this puzzle piece called cough say, well, how many times do you want to cough, thereby taking an input. Then you can repeat that number of times cough for a second and wait one second. So if you want to now use this fancier puzzle piece up here, notice this now looks even simpler. Go ahead and cough three times. And everything has been abstracted away. If I scroll up and out of the way, you don't even know or have to care how or why cough was implemented. And so whereas we began this whole conversation just looking for Mike Smith and trying to find an answer to a problem correctly, we talked then about efficiency and finding that solution not only for sure, but also quicker. And now we've spoken a little bit to ideas that lie ahead when it comes to the design of the quality of your code. So where does that actually leave us? Well, let me go ahead and open up a couple of final examples here, one of them that I actually made back in my day. And so this, when I actually started using Scratch for the first time, it gave me this program here called Oscar Time. And Oscar Time, reminiscent of an old song from Oscar the Grouch singing, does this. [SINGING] There's this stage. Notice the lamp post here and the trashcan. And apparently, something falling from the sky that looks like a piece of trash, but it's just a sprite. It's what could have been a cat, but I changed the costume on the cat to be a piece of trash. But notice if I move my cursor and click and drag, notice that this piece of trash follows the cursor just like Scratch followed my cursor before on the screen. And notice if I move it over to the trash can, the trash can opens up, which is a Sensing question. If touching trash can, then open up. And open up probably just means change the costume to show a different image instead of the original, thereby a very simple idea of animation. And now notice when I let go, if touching trash can and let go, Oscar should come out of the trash can, count up to one, which is my score, and then the game continues. Now there's more trash falling. Let me go ahead and do this. And you'll see that these basic ideas of conditions and loops and variables and Boolean expressions together can compose a pretty interactive game. This game took me eight or more hours to make, and it's because I did not sit down and just make the whole thing at once. I took baby steps, so to speak. I first, frankly, did the easy part and I just found an image of Sesame Street, put it on the stage, and boom. At least version one, all it did was say Sesame Street. And it's not interactive at all. Then I added a sprite, which instead of being a cat, I changed the costume to be the trash icon. And I just figured out the code, the puzzle pieces, to make that puzzle piece fall from the sky and then stop when it's on the edge, just like the cat was able to make a decision to bounce when it touched the edge. And now things get a little crazy. The song gets more sophisticated. I added more and more sprites that just fall in lockstep with the music. So this was quite a few hours of effort, but it boils down to really the same principle, just as this other program here does, too. And for this, rather than me play it, let me invite one other volunteer to come on up who's got to be-- OK, I see your hand here. What's your name? MEGAN: Megan. DAVID MALAN: Megan. All right, Megan, we have a game for you called-- maybe I mentioned this-- [? IB's ?] hardest game. OK, come on up. Nice to meet you. This is a game by one of your former predecessors, who their problems said zero, implemented this. You'll see the instructions in just a moment on the screen. We'll see if we can't inspire some folks to root for you here. And after this, as is the tradition in CS50, we will adjourn for some cake. So Megan, we have here for you, [? IB's ?] hardest game. I'm going to go ahead and maximize the window. I'm going to go ahead and click Begin and we'll see the instructions. MEGAN: OK. DAVID MALAN: Good luck. MEGAN: Thanks. [MUSIC -MC HAMMER, "U CAN'T TOUCH THIS"] DAVID MALAN: Let's go ahead and raise the volume. Here we go. [MUSIC -MC HAMMER, "U CAN'T TOUCH THIS"] (SINGING) Can't touch this. DAVID MALAN: So you're going to move the arrow keys and navigate your way, essentially-- oh, yep-- through a maze. Notice Megan's not able to go beyond the black borders because if touching edge, logic. Now when you touch the other sprite, you advance to the next level. Two sprites now. Another Yale icon. (SINGING) From the Oaktown and I'm known as such. And this is a beat you can't touch. I told you, homeboy. DAVID MALAN: Nice. OK. [LAUGHTER] (SINGING) Yeah, that's how we living and you know. Can't touch this. Look in my eyes, man. DAVID MALAN: Nice. (SINGING) Yo, let me but the funky lyrics. Can't touch this. [LAUGHTER] DAVID MALAN: Nice. [AUDIENCE GASPING] [APPLAUSE] (SINGING) Cold on a mission, so pull them on back. Let them know that you're too much and this is a beat, uh, they can't touch. Yo, I told you. [LAUGHTER] Why you standing there, man? Can't touch this. Yo, sounds the bells. School is in, sucker. Can't touch this. DAVID MALAN: OK. Good. Nice. [AUDIENCE GASPING] [LAUGHTER] (SINGING) Or a tape to learn what's it going to take? And now he's going to burn the charts. DAVID MALAN: Oh! (SINGING) And you might as well quit. That's word because you know-- DAVID MALAN: No! That's OK. Oh. It's OK. Nice. Ah! [INAUDIBLE] Oh! Couple more lives. Nice. Oh! [AUDIENCE GASPING] OK. Yeah, you got it. MEGAN: Yes. Yep. Oh my God. DAVID MALAN: All right. One more life-- two more lives! Three more lives! Come on. (SINGING) Bring the bill. School's back in. Break it down. DAVID MALAN: Yes! [APPLAUSE] MEGAN: Up, up, up. (SINGING) Stop. Hammer time. DAVID MALAN: All right. Last life. Last life. Go, go! Here we go. All right. Nice, nice. Yes, yes. Ah! All right. A round of applause for Megan, if we could. Check her out. Here you go. [APPLAUSE] This, then, is CS50. Welcome aboard. Cake is now served.