[MUSIC PLAYING] This is CS50-- Harvard University's introduction to the intellectual enterprises of computer science and the art of programming. And my name is David Malan, and I was just thinking this morning, it's been amazingly 20 years today since I last sat where you guys do now. It was 1996. I was a sophomore, and I was taking CS50 for the very first time. And I hadn't even gotten up the nerve to take it myself freshman year, partly because of the time. Computer science to me was kind of like, meh. I was a bit of a geek growing up, but I didn't really have any intellectual interest in what appeared to just be a whole bunch of people programming all the time. And I was scared to be honest. The course and computer science more generally had and to some extent, still has this reputation of a field to beware, if only because so many of us are unfamiliar with it and unsure of it. And it really wasn't until I shopped this class that sophomore fall-- and even then, I only enrolled because the professor-- one of my first mentors, Brian Kernighan now at Princeton-- allowed me to take the class pass fail. And indeed, that's why today we allow and encourage students to take this class sat/unsat. And only then, by the end of the semester did I realize like, wow, this wasn't such an unfamiliar field. Indeed, this was a very empowering field, and more excitingly, especially later on, as I took courses in Dramatic Arts 101 and Latin A and then eventually grad school archeology, did I really start to see the intersections of this field, computer science, with the humanities, natural sciences, the arts, medicine, and the like. And so that's what's just so neat about computer science ultimately, as we hope you'll see-- is its applicability to these other fields, and how you can take some of today's and the semester's ideas and practical skills back to your own domain, and actually explore this intersection of the liberal arts and the sciences. So 73% of you, if last year is any indication, have never taken a CS course before. So if, like me, you are feeling a little bit scared, or frankly you're not really sure why you're even here. Perhaps you just followed some friends over to Sanders right now. That's totally fine. The goal here is to hook you and to reassure you that if you do look to the left and to the right, you're going to see classmates with as little or as much experience that you yourself might have. And indeed, we'll share some statistics later today as to what the demographics of the class typically look like. And as added reassurance-- and this we do mean since I took over the course some years ago-- in the course's syllabus is this-- that what ultimately matters in this course is not so much where you end up relative to your classmates, but where you in week 11, the end of the semester, end up relative to yourself in week 0, which is where we are here today. And this is what I realized all those years ago. And I know a lot of classes say this, but it's especially true in computer science. At the end of the day, this field is unfamiliar as it was to me and might be to you, is really just about problem solving. And as such, it does have this applicability to get other fields. And in fact, if we tried to distill what this means, this is problem solving in its essence, I daresay. There's input-- so whatever it is that you're trying to solve. There's output, which is hopefully the solution to that problem. And then, as we would say in computer science, there's this black box in the middle that you don't necessarily have to care about how it works. You yourself eventually might implement what's inside that box. But for today's purposes and more generally in life, all you care about is that these problems get solved. And what this course is ultimately about is exploring the intersection of these inputs and outputs, and these so-called algorithms, as we'll soon see, that implement what is underneath there, the hood. But these inputs and these outputs-- what does that actually mean? Well, at the end of the day, we need some way of representing information. This is especially true in a computer, which as fancy and complex as it might seem, is a pretty dumb device. It takes electricity-- whether from a cable or a battery as input-- and then it produces some preprogramed responses on the screen. But how do we get from start to finish there? Well, what's a problem to be solved? Well, maybe we might, at the start of any semester, try to take attendance in a room like this. So I might do like one, two, three. Or maybe, if I did it to sort of keep track of myself-- to keep track of things-- I could quickly run out of fingers. So I might just make hash marks-- one person, two, three, four, five, six, seven, eight. And all of us have probably done this, whether on your hands or on a piece of paper. And this is actually just something called unary notation-- where if you only have one letter in your alphabet, one or hash mark in this case, for every input you want to count, you need to put down one of these letters-- one of these marks. All right. That's all fine and good and not all that complicated. But computers aren't all that much more complicated. Indeed, most of you probably know even if you've not really considered what this means, that computers only understand zeros and ones-- the so-called binary system. We humans, by contrast, are so much more sophisticated insofar as we understand zeros through nines. But even if binary is, at first glance, not all that familiar, it turns out it's just like the systems and the ideas that we already know. So for instance, consider this. This is just a sequence of symbols. And all of you, when glancing at it, probably think 123-- nothing really interesting there. But why is it this number, 123? These are just glyphs on the screen-- just patterns that someone might have drawn or typed. But if you're like me, you probably remember from grade school that there are sort of columns or places here. There's the one's place and the ten's place and the hundred's place. And the reason that this is 123 and not just a pattern of three symbols is because, of course, if we have a one in the hundreds place, you do the math of 100 times one, and then two in the ten's place. So that's 10 times 2, and then three in the one's place and that's 1 times 3. And when you add all of those up, of course, you get 100 plus 20 plus 3. So we started with just a pattern of symbols-- an alphabet-- but then we mapped meaning onto it by way of these columns. Well, it turns out that computers are really not all that different from you and me. But instead of using powers of 10, so to speak-- 1, 10, 100, 1,000, 10,000 place and so forth-- they actually just use powers of 2-- so one, 2, 4, and then if we put more digits, 8, 16, 32, 64, 128, and so forth. And so this is how a computer would represent the number 0, just like we humans. 0, 0, 0-- and you can probably guess what pattern of zeros and ones, if a computer can only speak 0 or 1-- what pattern is going to represent the number we humans know as 1? Yeah-- 0, 0, 1. All right. So 0, 0, 1 is how we represent 1, so you might be inclined then to represent the number 2, if you have the four's place and the two's place as the one place, you might say, well, if we had a 1 in the one's place, and now we want to count up to 2, you might do this and leave this to be a zero. But of course this is not how the decimal system works either. If you put a digit in both of those columns, you've got to do the arithmetic. So what number did I accidentally just represent? So it's 3, because 2 times 1 plus 1 times 1, of course, gives us three. So this would be two. The bit sort of flips, so to speak, as 0 becomes a one, much like a 9 roles over and becomes a 0 when you carry the 1. This then would be three of course. Four-- another interesting thing happens, where the ones roll over and you carry the 1, so to speak. So this, of course, is 4. But if you fast forward now, what's the biggest number going to be that a computer can represent? So it's just seven in this case, right? Because you have a one in the four, a one in the two, a one in the one. So that's 4 plus 2 plus 1. So that gives you seven. And indeed, it would seem at first glance that computers can count no higher than this. But this of course is not true. What do we humans do when we want to count higher than like 999? Just carry the one and just add a fourth digit to the left. And so indeed we could. We could have an eight's place and a 16th's place, and a 32's place, 64, 128-- and you can just keep going on up to infinity. So these zeros and ones-- the so-called binary system-- are what a computer scientist would generally call a bit, or binary digit. But now, how do we get from the concept or the graphics of these things to an actual computer? We seem to be skipping a step here. Well, the only input at the end of the day, to my laptop here is this flow of electricity. Even if it's been a long time since you thought about or never thought about how electricity works, there's electrons flowing in or out, and that's my kind of input. So if that's all that we're getting as input here, what can we do with that information? Well, we might think of a zero as just an absence of electricity. Nothing is flowinw, nothing is moving, nothing is happening. That's just the default state-- zero. But if there is electricity flowing, why don't we just arbitrarily, but globally consistently, call that a one. So simply by having no power, we have a zero, yes power, we have a one-- no power, yes power. And in that way, using something more physical or electronic we start to implement this notion of something either being one or a zero. Indeed, we could just do it over here. So here, I have not three but eight light bulbs, each of which has its own switch. And so if I wanted to represent the number seven here, I might turn on these three light bulbs. And indeed, inside of my computer is millions, billions of things that are just smaller than that, called transistors, switches, that you just turn on and off. So these are big-- relatively big-- switches inside my laptop-- are many, many, many, many more switches. But all they do is exactly that-- turn something on, turn something off. And as such, a computer can represent, with those millions or billions of transistors, lots and lots of zeros and ones. And there's other hardware still that lets you store information long-term, so that when you pull the plug, you don't lose it. But that's a story for another day. So what can we do with these bits? Might we just to take the pressure off of me-- might someone want to come up here and offer up a demo? I saw this hand first. What's your name? MADAY: Maday. DAVID MALAN: Maday, come on up. Nice to meet you. MADAY: Nice to meet you. DAVID MALAN: Come this way. I won't have to lip you up. All right. So here, we have, notice-- one, two-- we'll edit that out-- one, two, four, eight, 16, 32, 64, 128. This is deliberate. There's eight bits here-- binary digits-- zeros and ones. And a bit is a useful unit of measure-- not as useful a unit of measure onto itself. Usually you want at least eight of these things, a.k.a. a byte. So we have a byte of bits here. So if we wanted to challenge you with, for instance, spelling out, in binary, this value here-- 42. Want to take a stab at that? MADAY: [INAUDIBLE]. DAVID MALAN: Yeah, just push the little white switches in front. And you want to spell out 42, and up for grabs is this CS50 stress ball if you get this. All right. So you have 32. We're going to need 42. So that's an eight, so that's 40. And excellent-- very nicely done. Thank you. [APPLAUSE] All right. So we have one more stress ball. Let's do this once more if we may. One other volunteer? Free stress ball, free stress ball. OK. Over here in the middle, do you want to come down? All right. I know. There we go. So the numbers here-- come on down. What is your name? DAVEY: Davey. DAVID MALAN: Davey. OK. Come on up, Davey. Nice to meet you. And what we're going to have you spell-- if you could linger there for just one moment-- is the number 50. But, but, but but, but, these are grade school magnets for a reason. Just got a little harder, all right? There's still eight. All right. So what do we have on there? We have 32. Nice. 32 plus 16 gives us 48-- so close. And wonderful. Congratulations to Davey as well. [APPLAUSE] All right. So we can do this all day long, and it doesn't get all that much more interesting and more challenging. But that's really the point-- is how relatively simple it is, at the end of the day, what a computer does to store information, to store inputs and ultimately store or represent those outputs. But numbers alone aren't all that interesting. So humans, some years ago, decided, you know what? It would be nice if computers were not just calculators for arithmetic operations, but actually could do things like word processing, or email, or more modern incarnations of these kinds of technologies. And so the world decided arbitrarily, but universally, that if you want to store the capital letter A in a computer, you know what? Let's just all agree to store some pattern of zeros and ones-- bits-- that ultimately represents the decimal number 65. We'll just all agree on that. 66 would represent B, 67 would represent C, and there's bunches of other patterns of zeros and ones, or underlying numbers, that would represent other letters still. So if you kind of mentally absorb this for a moment, I deliberately put up A through I, where H a 72 and I is 73. If a computer then, in the context of a word processing program or an e-mail, revealed underneath the hood to have these patterns of bits-- pattern of bits representing 72, then 73, then 33-- what might this spell in that program? So hi, and then something. We don't necessarily know, but indeed 33-- not on the chart earlier-- was simply an exclamation point. So 72 was H, 73 is I, 33 happens to be an exclamation point still. But that's all fine and good, and in fact nowadays, rather than just use seven or eight bits, thanks to something called Unicode as opposed to Ascii back in the day, we actually can represent even more interesting characters than just these original English biased letters. But we can also represent even neater things like colors. If you've ever heard the acronym RGB, red, green, blue, that just means that a computer typically uses three sets of bits-- some number of bits that represent a number for how much red you want, another set of bits for how much green you want, and another set number for how much blue you want. So a big number means lots of red, small number means no red. And so these are kind of middle values here. So give me some red, give me some green, and give me a little bit of blue. And if you mix those three shades of color together, in this case, you get this murky shade of yellow or brown. But that pattern of eight plus eight plus eight-- so 24 bits-- left to right, is how a computer would represent that particular color. Now this is just a dot on a screen. If you look really close at your TV your computer, you'll see dots or pixels. And if you have a whole grid of pixels, horizontally and vertically, you have images. And then if you take an image and then wash show yourself another image, another image, another image, another image, really fast, you of course have movies. And so notice where we started. We started with these zeros and ones. We worked from there to decimal numbers, how we represent them. Now we have letters of the alphabet. But in other contexts wait, we can use a few more bits and represent colors. As soon as you have the ability to represent colors, you have the ability to represent photographs and animated gifs and other such characters on the screen. And when you have a whole bunch of images flying by the human at once, it looks like motion pictures, and so you get videos as well. So using these very simple primitives do we have the way of representing ultimately all of these forms of media. And we've abstracted again and again and again, until we get from the lowest level to this highest level. So that gives us this general idea of abstraction. But we started here. Here now, we might represent in a computer our inputs with zeros and ones, our outputs in zeros and ones, but what goes inside the box? That's where computer science gets interesting. That's where you actually bring your own minds to bear to solve problems. We can now stipulate, for the rest of the semester, yes. I know how binary works. I remember how Ascii or Unicode-- the mapping to letters-- works. And it certainly stands to reason that we could represent red and green and blue, and represent multimedia as well. But this is the interesting stuff. This is what makes someone capable of solving problems. And one such problem we like to do, indeed, is taking attendance, or doing this algorithmically. And again, I might do this. I might do one, two, three, four five, six, seven, eight nine. And I could write it down to keep track of it. But that's just how I would represent the information. Or I could do this faster-- two, four, six, eight, ten, 12, 14, 16, 18, 20, 22-- it feels like twice as fast but it's still going to take a whole lot of time. But it turns out, if we leverage yet another resource-- and indeed computers these days have multiple CPUs or brains. It turns out computers can do lots of things at once, and indeed we, in this room, might represent exactly this. So it's a little socially awkward, but if you would humor me for just a three-step process, let me ask everyone in place there just to stand up for a moment. Stand up. So think to yourself, number one-- so everyone in this room, except the people who didn't oblige, are thinking number one. So that is your number right now. That is the first step, or as a computer scientist or a programmer would typically do, we're going to start counting at zero. If the smallest number we can represent with those light bulbs is zero, by just leaving them all off, I might as well just start counting from zero is instead of one. And so that's what computer scientists do. So step zero, stand up and think of the number one. The next step is this-- pair off with someone standing and add your numbers together. Wonderful. So at this moment in time, literally everyone participating is thinking of the number 2, except for one odd person if we have an odd number of people in the room. And now the third step here is going to be this-- one of you should sit down. One of you should sit down, and if you're still standing, go back to step one. All right. All right. So more and more people should be sitting down. Notice that this has induced a loop-- some kind of cycle. Some of you should be awkwardly stuck, going back and forth between step one and two, one and two, one and two. That's OK. Our first bug. We'll deal with that. All right. Let me try to spur things along. In theory, only one person is standing as everyone continues to pair off. But let me speed things up with the people still standing. What number are you thinking of? 46. OK. Go ahead and sit down. You guys are still standing. Who's still standing? What number are you thinking of? OK. So we'll come back to you. In the back? What is that? 22. OK someone else up top-- yeah? 34. OK. Over here on my right-- up here? 132, very nice. 22? OK. And who's still standing? Over here? 46, very nice. 72. I can't stall much longer. Yeah? 30, nice. Over here? 23? 23. And I think that's everyone except you guys, no pressure. Oh, wait. 28? Just eight. OK. Just eight. Down here? 30. 23. 24. 18. This is the worst implementation of this algorithm ever. OK. So anyone else? Anyone else? OK. One more. 16? OK. 16. All right. So if I haven't missed anyone in the glare here, when I hit Enter, we will see, algorithmically, the total number of people in Sanders. Because again, it's as though everyone as you sat down, passed your number off to someone else, to someone else, to someone else, so that in theory, in the end, only one awkward person should be left standing. But that's fine. We sped things up manually. It's especially hard to see in this particular space. And the total number of people we think there are here is 546. The total number I was handed by the teaching fellows, who did it the old school slow way, was 820. [LAUGHING] [APPLAUSE] That's OK. So surely then, there are these bugs. And that's fine. And so think back on this the first time something you write doesn't necessarily work. This has happened to me here as well. But let's now consider how we might apply this same idea to something you might have seen before, which is this old school technology here-- a really big phone book. And suppose that this phone book has 1,000 pages and 1,000 names and numbers alphabetically inside of it. Well, we could kind of apply a similar idea to this very physical problem, just using me. I just kind of cheated by leveraging all of you with lots and lots of different CPUs or brains executing some algorithm. But if it's just little old me, I can still leverage that same essence of an idea of dividing and conquering that problem again and again, whereby half of you, half of you, half of you, half of you, theoretically kept sitting down, until we were left, theoretically, with just one person. So in this old school technology-- we don't need this map-- this old school technology, we might start looking for someone like Mike Smith, one page at a time. And I see that no, Mike is not here. I'm still in the A section. Eventually, I find myself in the B section. And this is an algorithm-- step-by-step instruction. Start at the beginning and one page at a time, look for Mike Smith. Is this correct-- this algorithm or approach? Yeah, it's correct. If Mike's here, eventually I'll get to him. But it's not efficient. It's obviously very slow. So I can leverage the same twosies approach. I can do sort of two, four, six, eight, 10, 12. It's twice as fast. I'm going to get to Mike faster if he's there. Is it correct? Yes, but I heard a little-- no. Now I heard a no. Yeah. There's a bug potentially. Maybe Mike just accidentally gets sandwiched between two pages, because I'm flying through this two at a time. So at least we need some kind of conditional fix. I need to say, hey, if I hit someone whose name starts with a T instead of an S, I better double back at least one page. So buggy at first, but fixable. But none of us are going to look for Mike Smith through a 1,000 page phone book one page at a time. What's a normal person going to do? You're going to go to the S's, if you knew where the S's. You might go roughly to the middle or slightly skewed towards the end. And I look down here and I'm in the M section. But what do you know about this problem now, that we didn't necessarily know before with all of us just counting ourselves equivalently? Well, Mike is clearly going to be in this half of the book if he's here at all because it's sorted. And so you can very dramatically-- [GASPING] I know. [APPLAUSE] It's actually really easy if you do it down the spine there. But you can then throw half of the problem away. Now, I'm left with the same problem-- find Mike Smith in a phone book-- but now the phone book starts at M and goes to Z, but it's half as big. But this is what's impressive. Just like in theory, you guys, when you all sat down only half at a time, the problem got half as big, half as big, again and again. So has this problem become the same problem but half as big. Now it's a 250 page problem. As soon as I realize, oh, I'm in the T section accidentally. I've gone too far. I can throw that half of the phone book away. Now, I'm down to a quarter of the problem. And you can repeat, repeat, repeat until, in theory, you're left with just one page. And if Mike is on that page, I can now solve this problem. But how quickly did I solve it? In the first case, it took me like maybe 1,000 steps to find Mike Smith. It might have taken me-- I picked up the phone book and I started looking one page at a time, and Mike might be 1,000 pages later. Second approach maybe takes me 500 steps, because I'm flying through two at a time. And the third approach though, it's especially powerful. But let's consider what we actually did with this third approach. I'll have what I'll call just these statements here, one at a time. Pick up a phone book. Open to the middle of the phone book. Look at names. And then things get a little more intellectually interesting, if still simple. If Smith is among the names on that current page, then do something conditionally. It's like a fork in the road. Call Mike. If Mike is among the names on that page, called Mike. But only do line four if line tree, if you will, is true. The answer to that question is yes. Else if Smith is earlier in the book-- in other words, if I'm in the M section and I'm looking for someone to the left, then what I should do is something very similar. Then I should open to the middle of the left half of the book. So go left, and then go back to step two. Look at the names there. So in other words, do the same thing, but on a problem that's been halved. You know what else? If Smith is later in the book based on the page I'm looking at, open to the middle of the right half of the book and then go back again to step two, else-- there's a fourth possibility here. Mike's either here or to the left or to the right or not there. And here we better consider this. And in fact, if you've ever had your computer just crash on you, that is sometimes, but not always, the result of just a human programmer not realizing, oh shoot, there's actually this fourth scenario. And if you don't write code to handle that scenario, sometimes you don't know what the computer might do. And indeed a program might crash. But in this case, I thought about it, and I said, else quit, because that's the fourth logical possible scenario. Now, let's just add some vocabulary so we can start to toss around terms that are otherwise pretty intuitive. All of the things I've just highlighted in yellow here, I'm just going to the functions or procedures. They're just kind of actions. So pick up, open to, look at, call, open, open, quit-- these are just actions, or we'll call them more formally, functions. Meanwhile, now in yellow, I've highlighted things that-- let's just start calling them conditions or branches. These are decision points where you might go this way, this way, or some other direction still. So those will be conditions. And now this one's a little fancier. Let's call these questions Boolean expressions, after someone with a last name Bool. And a Boolean expression is just something that's either true or false, yes or no. So it's the question whose answer you care about, so as to in a condition make a decision-- get back an answer, and then go left or right, or something else altogether. And then lastly, these lines here-- go back to step two, go back to step two-- we could implement this idea in different ways. And then those of you with programming experience might have done or can imagine doing this differently. But for today's purposes, it's just the idea that matters. This is inducing what we'll generally call a loop-- some kind of cycle, because it's making me do something again. So now, let's just consider how good this algorithm is. It's correct. If Mike's in the book, it's one of those four scenarios-- again and again and again, we'll find him. But how good is it? Well, we don't have to be too formal here. But let's just plot something, x and y, to get a sense of the shape of this problem. On the x-axis here is the size of my problem. And they a y-axis here will be the time to solve. So maybe this is number of pages. Maybe this is seconds or page turns-- whatever. However you want to count is what this picture will represent. And that first algorithm, I'm going to describe as just a straight line. If there's n pages in the phone book, then it might take me as many as n steps to find Mike. If Verizon or the phone company adds one more page next year, it might take me one more step-- one more unit of time to find Mike. So there's just this one to one ratio. It's a straight line slope. Meanwhile, that second algorithm-- if I'm going two at a time-- two, four, six, eight, or double-- going through the pages twice at a time, two at a time, it's still straight line. There's now a one to two ratio, but just a little lower. So if there's this many pages on the chart here in yellow, that might take me this many steps or seconds, otherwise it's going to take me twice as many on the red line. But the green line is the real takeaway. This is what we generally call a logorithm-- log of n, where n is the number of pages. But it's the shape that matters today, because we don't have to even think about plotting points. Think about an extreme scenario. Suppose Verizon tomorrow doubles the number of pages in that phone book, from 1,000 to 2,000. In the first algorithm, I might waste an extra 1,000 steps looking for Mike, just because Verizon doubled the size of the book. The second algorithm-- it might take me an extra 500 steps. 1,000 more pages, I go two at a time-- 500 more steps to find Mike. But that third algorithm is kind of magical. Verizon doubles the number of pages from 1,000 to 2,000, but how many more steps does it take me to look for Mike? It's just one, because I can just tear the phone book one more time from a 2,000 page problem to a 1,000 page problem, and voila. I've taken a massive bite out of it. And if you go really extreme, suppose that the phone book company had something crazy like a 4 billion page phone book. Well how many steps might it take to find Mike Smith in a 4 billion page phone book? It's a big number, but just 4 billion to 2 billion to 1 billion to 500 million, 250 million-- still sounds like big numbers, but I'm very quickly getting to smaller values. And in fact, if I do the math right, I can only divide 4 billion by roughly 32 times before I get down to just one. So if that phone book were 4 billion pages long, no big deal. Within a few seconds, maybe 32 seconds, I could divide it in half and eventually find Mike or conclude that he's not there. And that's the essence of an algorithm-- a good algorithm. And that's one of the goals of a class like this, is trying to figure out how do I solve the problem not just correctly, like I always knew how to do it one page at a time-- but correctly and well. How do I design good solutions to problems? So let's take a moment here and give you a sense now of CS50 the course itself-- introduce a few course's staff members. Just before 2:00, we'll take a short break so that those of you who are shopping can duck out and take a look at some other class and watch the rest of this online. But for now, let me introduce CS50, the class itself, and particularly what is new. So the past spring, we spent quite a bit of time-- the course's staff and I-- thinking about what it is we want CS50 to be, and going back to first principles, so to speak, to consider what it is we want this course to look like and be like for its students. And so you'll see in problem set zero as well, an invitation to take a look at that URL which summarizes some of the motivations behind the following characteristics of fall 2016. So as you may have gleaned from the TL:DR handout, the syllabus today as well as from the course catalog, this year in CS50, you're only expected to attend today-- so job well done-- and the last lecture on November 21st. And you're welcome but not expected to attend those lectures in the middle, because what we're doing this year, is shooting in real-time the course's material. So everything will stay current and incorporated as best we can-- current events and conversations that folks might be having in industry in the world, but making that material available, as a result, even earlier-- complete with full text transcripts and searchability and links to other resources. And indeed, we've been claiming for some time and we do now believe this, that we can create, digitally, a more immersive, a more compelling educational experience, as opposed to gathering here some 23 times in person, hearing someone like me simply talk about computer science, as opposed to engaging more actively. So you'll see in the course's syllabus a sketch of the semester here, along with when lectures will be filmed, to which you're welcome but not expected, and when they will be released on the course's website. And what we'll do here on Wednesdays starting next week, is a lot more intimately, with only those folks who want to participate, is a so-called walk through, where I and the course's heads will actually make things a little more intimate down here in the orchestra section, still have some technology and walk through the current week's problem set, and offer you particularly-- if among those less comfortable-- all the more guidance that you might want or need for the week's challenge. And similarly, for those who can't attend those in person, no big deal. There will be similarly led by one of the course's senior staff, Zamalya, the same opportunity embedded in the problem sets themselves. Problem sets this year will be released on Fridays and no longer do seven days later, but 10 days later-- deliberately overlapping with each problem set, so as to better accommodate, we hope, ebb and flow in student schedules, especially when midterms or athletics or academics or extracurriculars tend to come and go especially mid-semester. That should give you a little more discretion as to whether you front load your week with CS50 or back load it on the following weekend instead. So look to the course's syllabus here for the schedule thereof. And you'll notice too among the changes this year, for those more familiar with programming in the past, we'll start the semester as we will today in Scratch, focus especially on the language called C, and then transition not to PHP, but to a language called Python towards the end of the semester in the context of web programming, along with SQL and JavaScript, HTML, CSS, and yet more. And in answer to an FAQ, it's indeed the case that CS is not as scary as I once thought it was, but it is as much work as I had heard it might be. But this is the say that here are some statistics from fall 2015 student body, whereby the horizontal blue lines represent the average number of hours reported. And you'll see an average of six to 10 to 12-- maybe 16 or so and so forth, but with high variance to be clear. And so realize that there is not only students more comfortable and less comfortable in the course, but a corresponding support structure to get those students through the semester successfully. Indeed, in answer to an FAQ, should you take CS50 as a first year? Absolutely. And in fact, I do regret not having found my way or found a new field that first year as well. And should you take CS50 with other courses, certainly as well-- and the general advice we might give students, that CS50's probably not the kind of class or intro class that you should take with three other or four other p-set classes. But if you're taking two other p-set classes, something else, and CS50, absolutely manageable. I've had many students in the past done so quite successfully. And to get you toward that finish line successfully, does the course have sections-- different tracks for students less comfortable, more comfortable, and somewhere in between, whereby in the course's first problem set, you'll be asked to describe yourself. And if you are among those less comfortable, it's the kind of thing that you just rather know. And indeed, that's been the growing demographic in CS50 for quite a few years. As of last fall for instance, 58% of the class described themselves as among those less comfortable, with 9% among those more comfortable, and then the other students there in red describing themselves as somewhere in between. And you'll see here the topics overall and schedule of sections, all of which are offered in person, in real time, with the course's amazing staff of teaching fellows and course assistants, some of whom you'll meet in just a moment. Sections themselves, as you'll see, will be Mondays and Tuesdays and Wednesdays, so as to allow you to dive in after engaging, if you so choose, in the course's lecture earlier that week. And then office hours, which certainly, with each passing year, have been no less of a challenge for the course. And this year, we're planning not only to hold office hours-- one on one opportunities for help for students on Wednesdays Thursdays and Sundays, the last of those being in the afternoon by design to reduce some of the stress that invariably arises with late night p-settting with a deadline looming-- but office hours will also be offered on Mondays and Tuesdays and Wednesdays, and Fridays and Saturdays, thanks to our friends at HSA. CS50 now has its own space for students and CS50 staff, atop 67 Mount Auburn Street, right there in Harvard Square. The vision for which is that CS50's TFs and CAs throughout the week, pretty much throughout most days, will be there for support. So if you've got some question on a p-set or you're feeling a little blocked or a little confused, and heck, you've got an hour or half an hour between classes, especially in the square-- can you pop in and have that question answered of have that confusion clarified-- very much in the spirit, you're familiar, of the math department's own math questions center, but pretty much around the clock per [? Gcal ?] that we will post online. Tutoring is also available for those students, freely from the course's own staff if you would like more intimate one on one, or two or three classmates only, working with one of the course's staff members. And indeed, these here are just some of the course's staff members, a few of whom you'll meet in just a moment. In fact, CS50's own head teaching fellow, and head course assistant, and preceptor, could come on up, allow them to say hello. [APPLAUSE] SPEAKER 1: [INAUDIBLE]. [APPLAUSE] SPEAKER 2: [INAUDIBLE]. [APPLAUSE] SPEAKER 3: [INAUDIBLE]. [APPLAUSE] DAVID MALAN: And allow us to bring on board two of CS50's most senior staff, Rob and Zamayla as well. [APPLAUSE] Indeed, both Rob and Zamayla have been with us for so long, that I was able to go into CS50's archives and find this very SD footage of them participating on stage themselves some years ago. ROB: [INAUDIBLE]. [APPLAUSE] ZAMAYLA: [INAUDIBLE] [APPLAUSE] DAVID MALAN: Thank you. So in addition to these team members here, CS50 has a team of nearly 100 staff members, all of whom will be available for sections and office hours and so much more. And as Rob says too, this is the most significant overhaul of CS50 in the 10 years that I've been in [INAUDIBLE]. [INAUDIBLE] focused especially in providing a support structure, trimming away a lot of the bulk that's been accumulated in 10 years of iterative developments on the course's problem sets. So this year, not only in class but also in the form of the course's problem sets, should you find things to be more streamlined, trimmer, much more manageable than in years past, as we shed some of the baggage that's developed by nature of evolving year after year and iterating. So the new and improved begins today. You'll meet some more of the course's staff out in the [INAUDIBLE] at 2:30, where we serve, as a tradition, cake. There's a bit more cake than that, but you'll meet Erin and Tobias and others still. And let me give you a tour before we hear from some of the other staff members in the class, of what awaits as well. In fact, we always start CS50's semester this coming Saturday, with what's called CS50 Puzzle Day. It has nothing to do with computer science per se, but with about problem solving more generally. And if you so choose to partake, per some of the invitations, you might have seen door dropped or on the stage here, it's an opportunity in teams of two or three or four, to participate for puzzles and pizza and prizes and more-- this Saturday, stay tuned for more. You'll find too that every Friday, at Fire and Ice, does CS50 bring a whole bunch of students to lunch, to make a large class feel more intimate, and generally bring together alumni and friends from industry to talk about what they've been up to since graduating. Similarly, this year, will we inaugurate the first ever CS50 50 coding contest-- a mid-semester opportunity to allow everyone on an opt in basis, to have a challenge of wits against classmates, again in teams of two or three or four, using only that programming savvy that you then have under your belt after just six or seven weeks of the class, and participating in this kind of competition online-- if you'd like to hone your own skills all the more in that challenge. At the end of the semester is the so-called CS50 Hackathon-- an opportunity that begins at 7:00 PM ends at 7:00 AM, and along the way are 12 evening hours in which to dive into the course's final project-- an opportunity to design and implement most anything of interest to you with your teaching fellow's guidance. Around 9:00AM do we typically serve pizza, 1:00 AM, Philippe's, and the few of us who are still awake at 5:00 AM, are shuttle bussed down the road to IHOP for breakfast. And then a few days later is the so-called CS50 fare-- an end of semester exhibition in celebration of just how far so many of CS50 students have come from week zero all the way to week , and keeping in mind that 73% of those classmates and yours this year have never taken a CS class before. In fact, to reemphasize as much, here is a few more faces from CS50's staff. SPEAKER 4: [INAUDIBLE]. SPEAKER 5: [INAUDIBLE]. SPEAKER 6: [INAUDIBLE]. SPEAKER 7: [INAUDIBLE]. SPEAKER 8: [INAUDIBLE] SPEAKER 9: [INAUDIBLE]. SPEAKER 4: [INAUDIBLE]. SPEAKER 10: [INAUDIBLE]. SPEAKER 11: [INAUDIBLE]. SPEAKER 12: [INAUDIBLE]. SPEAKER 13: [INAUDIBLE] SPEAKER 14: [INAUDIBLE]. SPEAKER 13: [INAUDIBLE]. SPEAKER 15: [INAUDIBLE] SPEAKER 16: [INAUDIBLE]. SPEAKER 11: [INAUDIBLE] SPEAKER 5: [INAUDIBLE]. DAVID MALAN: Some of the team are themselves shopping classes. But if those members of CS50 staff are here, could come on up for just a moment. CS50's TFs and CAs and [? staff ?] members here-- these are just a few of the faces-- one of whom you just saw, and a few other-- and a few others still. Why don't we go ahead and allow you guys a five minute break. If you need to duck out to shop classes, that's fine. And in five minutes, we'll resume, taking a look at Scratch-- the first of our programming language, meet the course's staff here some more, and focus ultimately on problem set zero. So we'll be back in five minutes. [APPLAUSE] All right. So we are back. And in our remaining time today, the goal is to level the playing field in terms of some terminology, in terms of some ideas. Because indeed, as per some of the charts earlier, there is going to be a range of levels of experience in the class, some of whose students have taken some programming before, some of whom haven't. And so with this first problem set and with this first language do we have an opportunity to start to take for granted after today some common vocabulary and idea. And we'll do this by way of the course's first languages-- in addition to C and Python and JavaScript and SQL and HTML and CSS, we'll be focusing initially and just for problem set zero on this graphical language, called Scratch, developed by MIT'S Media Lab down the road, to help students and kids especially express themselves algorithmically-- in a way more consistent with what we might call computational thinking. And it's a useful language because very quickly next week in week one, do we transition to a more traditional and arcane language called C, which is purely textual. You only use your keyboard in order to write instructions like these on the screen. But even if you've never seen a programming language before, in just glancing at this, all be it cryptic, you can probably guess that probably prints Hello World. But there's a lot of syntactic overhead there. There is the weird hash symbol or hash tag up top. There's the angle brackets, some parentheses, curly braces, semi-colon-- there's just so much visual syntax that gets in the way. We start the course with Scratch so as to get past all of those intellectually uninteresting distractions, and focus instead on the ideas. In fact, this might be before. This, for this, week shall be after. This, in this graphical language Scratch, is how you would implement that same program-- a program that when run, simply says hello world. And what's nice about Scratch is that it's this graphical programming environment that uses puzzle pieces or blocks, that only interlock together if it makes logical sense to do so. And with Scratch can you develop animations and interactive games and art, and any number of things that you might imagine in your own mind, and implement them simply by dragging and dropping puzzle pieces. And indeed, we'll have the ability to express some of the same ideas that I just mentioned a moment ago in the context of Mike Smith and searching a phone book-- things like functions, just actions, things like loops that do things again and again, variables, which is something we'll introduce, but it's familiar perhaps from algebra-- just some kind of placeholder to store some value you might need later-- Boolean expressions, where those yes no or true false questions from before. Conditions are those forks in the road-- those branches so to speak. And then there are some fancier features we'll see even today, called arrays and threads and events, that we'll then revisit over time in different languages. But Scratch allows us to explore all of these. So here in Scratch, this purple block is what a function is typically going to look like. This purple puzzle piece that has some word like say, which is the action, and then it might have an argument or a parameter-- some way of kind of customizing what that block does so that it's not pre-determined by MIT what this purple block says. In fact, you'll see in a moment that I'm able to type the words like hello world, or hello David, or hello Zamayla, or whatever I want, in the argument to that puzzle piece-- the white box there. Meanwhile, if I want a loop, we'll see that there's puzzle pieces that look a little orange like this. And their shape kind of suggests that something happens again and again in a cycle. So if I wrap a say hello world block with a forever block in Scratch, it's just going to keep saying hello world forever, quite literally. Meanwhile, there's another type of loop in Scratch that we'll see-- a repeat block-- where, if you know in advance how many times you want the loop to execute a finite number of times in fact-- you can specify that by typing in a number or even plugging in a variable, like x or y as we'll see. In fact, variables like i in this case, which is a common name for an integer variable that just stores a number-- an integer might be, to use this orange block here to set a variable like i to zero. Here's an example in green of a Boolean expression in Scratch. Even though this looks like a math formula, math inequalities like this really are Boolean expressions. This is either true or false. I is less than 50. It's either a yes or no answer or true or false answer. And we'll generally call those Boolean expressions. And it doesn't have to be 50. It can be x less than y, greater than y, equal to y-- any number of other questions might be asked. Now, at first glance, this might look suddenly quite bold here, and it is. But concept wise, it's pretty familiar from before. If x is less than y, than say as much. Else if x is greater than y, then say as much. Else say x is equal to y. So we have an example there of a third scenario-- the only third possibility-- x is either greater than, less than, or equal to. So we have a three way fork in the road. And notice what's cool here-- Scratch, it would seem, has just one puzzle piece, in this case, in if else block. And yet that would seem to imply you can only have a two way fork in the road. You can go left or right, but what about that third scenario? What if x equals y? No big deal. Take one puzzle piece, put another one inside of it to create the semantic equivalent of if, else if, else-- and now you have your three way fork in the road. And as we'll see, the Scratch puzzle pieces can be stretched and grow, so as to cram more stuff in them. You don't have to fit everything in its default size. This is something we'll soon see is called an array. It's like a list-- some way of storing multiple pieces of information in a variable, not just a number. These we'll see a representative of something called multi-threading. In fact, all of your Macs and PCs these days support multi-threading, which means you can literally do multiple things at a time. You can have Microsoft Word up in the foreground, working on some essay. You might have a browser in the background opening G-mail or Facebook or the like. Your computer can do multiple things today because it is multi-threaded, and programs they're in in particular are also multi-threaded. There's things called events as well in the world of Scratch, and then there's a way too, to make our own custom puzzle pieces if things don't actually exist in advance. So let's motivate this as follows. Some years ago, when I first discovered Scratch, when I was actually a grad student at MIT, we ourselves were tasked to make homework. And I implemented-- which, in retrospect, was a very poor decision because it's the most infuriating song in the world to listen to for eight hours while working on your homework-- but something I had called Oscar Time, which is perhaps a familiar song. CS50s own Jordan Hayashi, one of our more senior staff members, has upgraded it for 2015 and now 2016, since back in the day, I had everything just going into Oscar's trash can. Now we support recycling and composting. But to paint the picture of what we can do here and to motivate some of the lower level examples, could we get one other volunteer to just come on up and play my first homework assignment ever? Come on up. What's your name? HENRY: Henry. DAVID MALAN: Henry, come on up. Come on up. Head either way, and you'll see in a moment, I'm going to go ahead and hit the green flag in the top right hand corner, which means go. The little stop sign icon is going to say stop, and that's when you start and stop the program. Nice to meet you. All right. So we're going to see the instructions on the screen in just a moment. And just by playing this game for a few seconds-- trust me, we're not going to want to play all the way to the end-- you will get a sense of what the program does. And more than just focus on Henry being good or bad at this game, focus and how was it implemented by me originally and then by Jordan. In other words, where are the variables? Where are the loops? Where are the functions? And we'll see if we don't see those underneath the hood. Just click and drag trash to the appropriate bin. [MUSIC PLAYING] All right. That's very good. Why don't we stop it there. Thank you. Congratulations to Henry. Thank you. [APPLAUSE] Just imagine debugging that program. If there's a problem two minutes into the song-- but so what's going on here really? As complicated as it might start to seem to get over time, indeed more and more stuff started falling, what's interesting about this kind of example-- and we'll see a few others-- is that if you look past the complexity or the sophistication of the game, there's a very simple building blocks that play-- all of which, if you distill them to those building blocks, are very accessible and implementable unto themselves. For instance, it's been some time, but I'm pretty sure what I initially did when making this game for the first time was I completely like procrastinated. I didn't focus at all on the logic or the puzzle pieces, I focused on the graphics and finding the street post and the trash can and all of that. But those were requisite ingredients at first. And once I finished procrastinating and laying out the overarching framework, I decided, let me just make one piece of trash fall from the sky. And we'll see Scratch supports things called sprites-- characters that can have different costumes on so they look different. And so I put a trash costume on one such sprite. And I just needed it to fall from the sky. And so it turns out, Scratch, like most programming languages, supports random numbers or technically pseudocode random numbers, so that by dragging and dropping certain puzzle pieces, I was able to have the trash come from the left at first. And then the next time it fell, from the right and then from the middle. And all the game did was just have trash falling from the sky. You couldn't point at it or click on it. You couldn't open the trash can. You couldn't do anything. But it was a baby step toward my ultimate vision. And after that, I actually implemented some kind of sensing so that if you did click and drag on the piece of trash over the trash can, Oscar's lid would open and close. Nothing would happen to the trash, but at least the lid would open and close. So then check, step two of two. And this is what's going to be key in both problem set zero and in programming more generally, is to take these very deliberate baby steps. Because not only does it allow you to feel honestly accomplished much more quickly-- it's the worst thing in the world to try to implement all of Oscar Time, then hours later hit the green flag, and nothing works as expected because where do you even begin to debug or to troubleshoot that program? It's just overwhelming. And so truly embracing this idea of taking steps-- baby steps again and again-- building up something that's, in the end, really impressive and complex, but at first, is not nearly as much so. In fact, let's do this. Let me go ahead and-- Scratch itself exists on the web at Scratch.MIT.edu, and you'll be told as much again in problem set zero, the specification for which is already on CS50's website. But this is what Scratch itself is. And there's really just three primary areas. At the top left there is the so-called stage. This is Scratch. The default costume is a cat. And this is the rectangular world in which you can move-- up, down, left, right and some other stuff. In the middle here are our categories or our pallets of puzzle pieces, and different colors mean different things. And if you poke around, you'll see things like loops and conditions and variables and other ingredients. And then over here is the scripts area. This is where I can drag and drop those puzzle pieces to do things. So let's do one such thing. Let me go ahead and-- and I know where it is. So I'm going to immediately click on where I know things are ready to be, but pointing and clicking and poking around are inevitable. So when green flag clicked, what do I want to do? I'm going to do this. I'm going to drag this purple puzzle piece, say hello for two seconds, and let me zoom in. And I'm going to change this to be what I want it to be-- hello world for two seconds is fine. Now, I'm going to click the green flag, or if I really want, I can full screen it and then come back. It will just keep everything in one window. Green flag-- hello world. All right. Not all that interesting. So let me go ahead and do this. Let me try another one. When green flag clicked-- let's do something like a sound. And notice that out of the box for free you get a cat sound, as is the default sprite. So now let me go ahead and hit the green flag now. [MEOWING] Aw. That's adorable. I'm programming. So what have I done? This is the equivalent of a program. It's obviously super simple. It didn't really take all that much effort and MIT did most of the work, but I have called a function. I have used a function. I've made some action, using just that one purple puzzle piece. Well, if I want to do three meows in a row? Let me go ahead and do two and three. And notice that when you hover nearby a puzzle piece, a little white line appears sort of magnetically, and it will snap together when you let go. Let's see what happens here. [MEOWING] There's a bug. I only hear one meow. Why might that be? Yeah? Yeah. We don't really hear it, but that's good intuition. They're all playing at the same time. Why? Well, the computer is just going to do what you tell it to do. So if you say, play sound, play sound, play sound, but you don't tell it to play until you're done, play until you're done, it's going to blow through the program really fast and do only what you tell it to do. So I actually need to fix this in a couple of ways. I could just do this, get rid of this. Let me try this other puzzle piece-- play sound meow until done, and then drag three of these and click Play. [MEOWING] It's not really very-- thank you-- very natural. So why don't I-- let me go to control here. Nice. Wait one second, and now let me go back to sounds, and play sound until done, and then let me get wait one second. And then let me go and get one more sound, and here we go. [MEOWING] A little more natural, but this is not very efficient. Like I was getting bored, all be it briefly, clicking back and forth and really duplicating my work-- pretty much copying and pasting. Indeed, if I Control clicked or right clicked, I could have just copied and pasted. What would be a better construct to use? What idea from before? Yeah, so a loop. And in fact, if we poked around, we might find exactly that. Let me go to Events or rather Control. So repeat-- I don't want it to be 10 times. That's going to get annoying quickly. But I will repeat three times. Let me go back to sound and play the sound until it's done. Let me go back to Control and just wait one second. And notice, you might think it doesn't fit, but again if magnetically you let it snap in place, it will grow to fill. What's it play now? [MEOWING] OK. Nice. And this is what would be called a program that's also correct. It meowed three times fairly naturally, but it's better designed. I'm using less redundancy. I didn't copy and paste anything. I just used a better idea. Now, this is still not all that interesting with Scratch not doing anything. So let's do something else instead. Let's do something forever. And you know what? Motion seems interesting. Let's have him move 10 steps and hit play now. OK. Well we can kind of drag him back, and he's still running because he's doing this forever. So the loop is doing what it's saying to do, but this isn't all that interesting. Let's do this. Let me add a control block, and use one of those conditions for the first time. So it's going to move 10 steps-- 10 dots, 10 pixels on the screen-- then it's going to ask this question. If something is true, then do something inside this block. So it turns out sensing has a whole bunch of Boolean expressions-- questions of the yes no or true false form-- let me do this. If touching-- and then there's this little drop down menu. I can parameterize it. If touching the edge-- let's do something like that. So if touching edge-- let me go back to motion. And why don't we just turn around 180 degrees? All right. So forever, move 10 steps. If you're touching the edge, turn 180 degrees. And that's not the end of the program because you're in a forever block, so it's going to go again and again and again and again. So let's see what happens. OK. A little buggy, but kind of cool. And we can add to this some silly things that aren't all that intellectually interesting. But if we hit this little microphone button-- ouch. Let me clean this up. Let me enhance this as they would say on TV. Clean that up, Save, and now go up to scripts. And now, let me go to sound. Let me give it a name. I'll call this ouch. And now play sound ouch. Notice it appears in the little drop down menu. Let's see. [OUCH] [LAUGHING] But we can change t his on the fly. We can be twice as annoying. [OUCH] Or if we make it like 1,000 steps at a time-- OK. So we're going to leave that one alone. So again, building blocks-- I started with something super simple, and then I added a feature, added a feature, added a feature. And I no longer need to worry about how the first of those features was implemented as I continue to layer things on top. So in fact, let me do one other here. Let me go ahead and open a file that I brought in advance, called Sheep. So it has a slightly different character that looks like this. And let me see if I can't do something using a counter in this case-- a so-called variable. I'm going to go ahead and under Events-- let me get a green flag clicked. Then let me go to Data, which I know from just playing around before, is where variables are. And I'm going to go ahead and drag this. So a variable called counter, and I'm going to initialize it to zero. I can call it anything-- x or y or z-- but in programming, calling something in a semantically useful way, like counter, that describes what it is, it's a lot easier to read your code later. Let me go ahead and get a forever block here. And let me go to the looks page and do a Say block. But what's cool about variables is I don't have to just type in something like hello world, which we've already done, I can instead go to Data and drag my variable, and even though the shape doesn't quite look like it should fit, it will grow to fill. And I'll just say the counter for one second-- spoiler-- he's going to count. We'll say it for one second. Then I'm going to go and have him wait for one second, so it doesn't count up too fast. And then lastly, change counter by one-- in other words, increment the counter by one additional value and do this forever. So the sheep too, like a programmer, counts from 0. And if we wait long enough, he will do this forever. But that's not exactly true, because in fact, as we'll discover in week one, integers and computers more generally, technically have only a finite-- well, rather computers, when they represent integers, only have a finite number of bits. Those light bulbs there can only count so high before you're out of light bulbs. And a computer too, only has so much memory, only has so many transistors, so it can only count so high. So it turns out that the sheep, I think, can count to 2 billion or something pretty big. So we're not going to wait for this to happen. But eventually some bug will happen that can have some very real world ramifications. But beyond the sheep, that just introduces a variable. Let's go ahead and open up something I made in advance here called Pet the Cat-- Pet the Cat over here. And notice here it's few blocks, but when green flag clicked, forever doing the following. If you're touching the mouse pointer-- so the cursor on the screen, the arrow-- play sound meow and then wait two seconds. And just do this forever. Just constantly wait to see if the pointer-- if the cat is touching the pointer. So I hit play. Nothing's happening. But as I move the cursor over the cat, [MEOWING] And if I move it away, not petting the cat anymore. So some conditional logic nested inside of a loop. How about this example, deliberately called Don't Pet the Cat? What's this going to do? [MEOWING] Why should you not pet the cat? [MEOWING] OK. So this is an example of an if else. It's a decision point and because it's sitting in the loop, they're both getting checked. Is this true? Is this true? Is this true? Is this true? And eventually, one of those is going to apply and so you hear either the meow or the roar of the lion in that case. Well, let's do a slightly more fancy one that I made in advance too-- threads. So a thread is just one thing that a computer can do. So a multi-threaded program is a program that can do multiple things at once. And all of these examples thus far have had just one script, so to speak-- one program like this up here. But notice this program has two sprites, two characters. One is a bird. One is a cat. And notice when I click on these down left, they each have their own scripts or programs associated with them. And both of those programs, notice, start with when green flag clicked-- let's look at the cat-- when green flag clicked. And so indeed, when I hit play now, two things are going to happen at once. The cat and the bird are both going to operate simultaneously to create this effect. And you might imagine what's happening. There's a loop and the bird and the cat are in a loop. The bird is just bouncing like I was before when I said ouch. But the cat clearly has an advantage. There's another sensing block that points the cat deliberately to the bird in this case here. So we could tease apart, by looking through those blocks, what's happening. But the key ingredient here is one. The bird, so that this game isn't completely boring-- or this animation-- starts at a random direction. And the computer is picking a number between 90 and 180 essentially, so that it's a slightly different animation each time. And then notice here, if the cat is touching the bird, then play the lion four sound-- the roar. But meanwhile in the bird's palette, we have this. Forever, if not touching the cat, just keep moving three steps. And then here's another puzzle piece. If you're on the edge, bounce. So the bird is just kind of minding its own business, just flying around and bouncing, and it's really the cat that had the conditional logic to determine if it had caught the bird. All right. So let's do one other here, this one being called Hi Hi Hi. And this one here just does this in a forever loop. But notice-- how do we stop this very annoying program? Hit the space bar. Because if I do that, the left hand program-- notice it's constantly listening-- is the key space press. If the space bar pressed, and if so, what does it do? It does a very common technique. It sets a variable equal to some value. But it toggles that value. [? So appearance ?] based on the shape-- I have a variable that I wrote in advance called Muted, which just says yes or no. Is the sound muted or not? True or false? And notice, I'm saying this-- if muted is zero, then change to one, else set mute it to zero. So just flip the value from zero to one. I could have done-- change it from two to three and three to two or four to five or four to six. But it doesn't matter what numbers I use, so long as I keep changing it the opposite. And most any programmer would just choose zero and one-- false and true, off and on-- to represent this. And this is still running. If I hit the space bar again [SEAL SOUNDS] The program is still running. Because there's this other script that says, forever do the following. If the muted variable equals zero-- so if you're not muted is the logic-- if it's false or no, then play the sound, because you're not muted. You should play the sound and then think hi hi hi for two seconds and then wait, and do it again and again and again. And so in this way do we have a way for people to-- for programs to interact. And they don't have to be as dated as others. In fact, poking around-- no pun intended-- someone spent a huge amount of time on the internet implementing PokemonGo in Scratch. It even geolocates you in Cambridge or Allston here. So if you want to see too what people can do is this-- very fancy menu. Click on here. This is me with my arrow keys now. I'm going to go after this. Click. And now you click the PokeBall. I mean, I think you're supposed to click the PokeBall. All right. So I did that. I can go over here. And this person implemented some more PokeBalls over here-- three PokeBalls. We'll post a link to this online so you can play. But notice there's just some basic building blocks. It looks a lot fancier, and it is. This is impressive and more than we would typically expect, certainly for problem set zero. I have no idea how long this person spent online. But it's all just a loop. There's a sound playing. There's some kind of loop listening for whether I'm hitting the up arrow or the down arrow or the left and the right, and then if so, it's moving it some number of pixels. And then if I click on another sprite, there's some kind of if condition there. Yeah, this is getting too intense. We're going to stop. It's all those basic building blocks. There are no other ingredients other than the ones we've looked at already. And yet here, let me do one final set of examples that paints a picture too of what you can do here. Here's a very simple program that just does this-- cough, cough, cough. And based only on what we've looked at thus far, where is the obvious opportunity for improvement. This program is correct. It coughs three times, which is what I intended. But it's poorly implemented. It's badly designed. Why? Yeah. It's not a loop. And it's not so much that it's not a loop, it's that there's a lot of redundancy. There is copied and pasted code, so to speak. And the solution probably is indeed a loop. So let me go ahead and improve upon that. And I'm going to drag these over here. Let me go ahead and get a repeat block, change this to three. I'm going to throw away some of those blocks. And you'll notice it's pretty intuitive. You drag and drop and things appear and disappear eventually. And I can just drag this in here, and now I have a cleaner version still. But you know what? There's this opportunity now for abstraction-- to start to define new vocabulary that MIT didn't anticipate. There's wait and repeat and forever and if, but what if I want to introduce the word cough as a block? What if I want a puzzle piece whose purpose in life is to cough? Well, let's look at this version here, which I made as follows. Magically, I have created this puzzle piece here, which Scratch allows you to do. And indeed C and Python and JavaScript are going to allow you to do this as well. You can create your own custom pieces that you call what you want. In this case, cough feels like a reasonable definition. And then with these pieces down here can you define what it means. I dragged and dropped from this palette here-- more blocks-- this big purple block, where I typed in cough as the name of my new puzzle piece. And then I'm saying any time a user calls this new cough puzzle piece, do a say and a wait. And so up here in my repeat block, I can just cough three times. And I would argue, especially if now you hide this detail. Who cares how cough is implemented? All I care about as a programmer that I can cough. I don't care how say is implemented. I just care that the cat can say something. I can abstract away that detail and only focus on what's on the screen here. But I can take this one step further. Notice that here, I have implemented the loop three times. But what if instead I grab this version? And what if instead in this version here, I just change my puzzle piece to take an argument and input unto itself? And that input can be a number like three. So now, if I am writing a program and I want the cat to cough, I can actually tell the puzzle piece how many times to cough, because at the bottom here, a fancier version of these custom puzzle pieces lets me specify that cough actually takes an input-- takes an argument like this. And you know what? Maybe I realize, wait a minute. Coughing is the same-- it's fundamentally the same idea as sneezing. It's just a different word on the screen. I can abstract away further and implement this final version of a cough, which at first glance is way more complex looking. But notice what I've done. I have now generalized-- genericized really-- this puzzle piece to be called say word n times. And now I have two new puzzle pieces down here define cough n times. And what does the cough function do? What does my custom puzzle piece do? It just calls the say block, passing in the word I want to say, passing in the number of times I want to say. Because now I can implement sneeze by simply saying achoo, in this case, some number of times. And so I'm layering and layering. And again, the key here is not how I implemented it, but the fact that if I just literally move these off the screen, look how simple if not pretty my program now looks. Because it does what it says, I've abstracted away what is inside that black box. it happens to be a purple box here, but I've obstructed away what's inside because I don't care how it works. I just care now that it works. And indeed, in problem set zero, this is exactly the kind of layering of ideas you'll have the opportunity to explore. It's exactly the opportunity to apply problem solving techniques, to what's probably an unfamiliar environment. And whether you've not programmed before or programmed before, you'll find that there's a little something in this environment for everyone. And with problem set one in a week's time, we'll be transitioned to focusing on a higher level language called C-- or rather a lower level language called C-- that's even more powerful, even though it's a little more cryptic at first glance. And you'll realize per today's TL:DR, that this problem set has a shorter window of time than future ones, simply because you should find it fairly accessible. And not to worry if you add the class late. We'll address that before long. And before we adjourn for cake, let's finish with just a two-minute look at what awaits you here in CS50. [MUSIC PLAYING] All right. That's it for CS50. We will see you soon. Cake is now served. [MUSIC PLAYING] SPEAKER 17: Have you heard of a sabbatical, Chief? SPEAKER 18: Perhaps there's more under the hood.