SPEAKER 1: All right, this is CS50, Harvard University's introduction to the intellectual enterprises of computer science and the art of programming. And this was apparently me around the time that I sat where are you guys now sitting thanks to a teaching fellow who spent a little too much time trolling around Lemont Library, where the 1995 freshman registers apparently still are. And I point this out because this was a big deal for me back when I was a freshman and ultimately sophomore considering to take a class like this, CS50, but more generally, computer science. And if you, like me, have this perception of computer science from high school or even middle school, you might have the perception that it's entirely based about programming. It's perhaps a bit antisocial. It's perhaps the computer lab, heads down, sort of coding away on something that you don't necessarily understand. And yeah, I too had that perception freshman year in this course and, dare say, the field more generally, really did have this reputation to beware. I certainly assumed that most everyone around me certainly knew more than I did. And this wasn't just true of CS for me. This was true of most any field at Harvard in the course catalog that I had no familiarity with. And so I instead gravitated toward the more comfortable. I took a lot of gov classes and economics and history just because that's kind of what I knew and liked in high school. I wouldn't say I loved it, but I knew it and it was within my comfort zone. And it wasn't until sophomore year that I got up the nerve to take this class, CS50. And I only did because the professor at the time let me take it pass-fail, now called SAT/UNSAT. And that allowed me to get over this sort of mental hurdle that I imposed upon myself, sort of fear of failure or simply not doing as well as I might have been accustomed to. And so I bewared a class like this until then. And I always kind of regretted not exploring earlier on. And that doesn't have to be this class. It doesn't have to be CS but can be really any field more generally. But those really were my takeaways around the time I looked like this. And I've taken comfort since in taking over this class and have found it inspiring that these days, 68% of the students in this room and in this room last year had never taken a CS course before. So if you do have that mental model of everyone to your left and your right surely must know more than you, odds are it is not, in fact, the case. In fact, within CS50, we have these different tracks, different types of sections for students less comfortable, students more comfortable and students somewhere in between. And there's no formal definition to these labels. You just sort of know it if you are. And if you kind of have one foot mentally out the door today because you're not really sure this is for you, you're probably among those less comfortable. But as such, you're in the majority, 56% of last year's students. If by contrast, you have been programming since you were eight years old, 10 years old, whatever but you're largely self-taught and therefore maybe have lots of gaps in your knowledge or don't really understand all the formalities, you just kind of figure things out, you might be among those more comfortable. And if not, maybe you're somewhere in between. And so in CS50 sections, do we have similar students together, similar comfort level, similar backgrounds, so that everyone can kind of feel comfortable speaking up not knowing things, knowing things, and beyond. Because ultimately, the course is graded and assessed ultimately very much manually, very much very delicately with respect to students' prior background or lack thereof. Indeed, what's most important at the end of the semester is not so much where you end up relative to your classmates but where you end up in week 11, our very last week, relative to yourself today in week 0. And in fact, thanks to CS50's own Haley James and a whole bunch of CS50 team members-- this summer, they spent a while traveling around the country bringing folks back to campus, alumni and former students and staff who had some connection taking or teaching CS50 in some form. And if you'd like to see stories of some of your predecessors and folks who sort have found their way-- accidentally, even-- to computer science finding challenge along the way, check out this domain that the team put together-- project5050.org. Now the course itself ultimately is not about programming per se. That's indeed a tool that we'll use. It's really about this. And that's really what CS is, the field more generally. Whether you're starting hardware or graphics or theory or any number of fields, artificial intelligence these days, machine learning and beyond, it's really just about solving problems. And what's really cool about CS I found early on is that it doesn't necessarily-- it's not an end unto itself. It's this field that empowers you to go do more interesting, more powerful things in the humanities, social sciences, physical sciences, the arts, anything because you have this new mental model for how you can solve problems better, more efficiently, how you can solve them correctly, and how you can sort of analyze large datasets or solve problems that might have otherwise been beyond your grasp. So what does this mean? What is problem solving? Well we could perhaps distill it as simply as this-- a big black box, some secret sauce, into which go inputs, like the problem we want to solve, and out of which comes outputs, the solutions that we want. So a very generic way of describing it, but what's pictured here in the black box is the so-called algorithms. And we'll come back to that in just a bit the actual ingredients for solving problems. But how do we represent inputs and outputs? Odds are even if you're not a computer person and don't really think like one, you probably know that shooters only understand a very limited vocabulary. Like, what is the alphabet, so to speak, that they speak? ASCII maybe, but more-- AUDIENCE: Binary. SPEAKER 1: Binary, binary, bi meaning two for zeros and ones. So whereas we humans typically use decimal-- dec meaning 10, 0 through 9-- as in our alphabet of letters, computers of course, as you may have heard, only use zeros and ones. Now why is this powerful? Well, turns out as soon as you have at least two digits in your alphabet, you can start to represent things much more powerfully and much more efficiently. For instance, how many-- if I wanted to count the people in this room, how many of you could I count on just one hand? Hopefully five. So I could call five. It would be one, two, three, four, five. But you know what? If I were a little more clever, I bet I could use the same hand and count as many as 32, maybe 31 of you. Well, how is that? Well, right now, I'm kind of using the unary system, uno meaning one. So it's just one digit in your alphabet-- the finger or no finger. It's not quite the same as zero or one-- so one person, two, three, four, five. But what if I instead permuted my fingers in some way so that the pattern of fingers that are up actually matters, not just the quantity? So maybe this is still 0 this now is 1. And instead of 2 being this, maybe two could be this. So if my second finger is up, I'm going to call that two. And if my first two fingers are up, I might call that three. Somewhat offensively, if just this finger is up, I might call this four and then five. And then this gets kind of painful-- six, seven. And what I'm actually doing is counting in binary. Now that might have looked completely cryptic, but it turns out as soon as you have two digits, that's enough to represent anything you want and to do so pretty darn efficiently. But why? So odds are, if you're like me, you probably grew up learning, of course, the decimal system, zero through nine. And you might have written on the board some points like this number-- 123. But why do you think of that as 123? It's really just a pretty pattern of symbols-- glyphs, so to speak-- on the screen that we ascribe some kind of mathematical meaning to-- 123. But really, it's just like someone drew in ink on the screen some symbols. Well, if you're like me back in grade school, you probably learned that the right-most number here is in the so-called what place? The ones place, right? And so if we wanted to label these things, we might put ones place there and then of course the tens place and the hundreds place, maybe the thousands, 10,000, and so forth. So we had this sort of mental models for the columns. And notice they happen to be powers of 10. 10 to the 0 is 1. 10 to the 1 is 10. 10 to the 2 is 100 and so forth. So that's the pattern even if your grade school teacher didn't talk about exponentiation at the time. So why is this number 123? Well, it's because we have a one in the hundreds column-- so 100 times 1. We have a two in the tens column. We have a three in the ones column. Them. And of course, if we start to do the arithmetic now, that's 100 plus 20 plus 3 or obviously 123. And all of us take that certainly for granted these days. You see a number, you know what it is mathematically. But computers fundamentally work in the same way. So even if you up until now have never thought of yourself as a computer person or had no idea really what it means for computers to speak just zeros and ones, all you have to do is update the places. Instead of powers of 10 dec, meaning decimal, we're going to powers of two for binary. So now we're going to have 2 to the 0 2 to 1, 2 to the 2, 2 to the 3, same idea. It's just a different base. We change tend to 2. And so now we have places like this-- 1, 2, 4, and if we kept going, 8 16, 32, 64, and so forth. So as such, what number is this on the screen in binary if you convert it in your head to decimal? It's just the number one, right? Because you've got a 1 in the ones place and then a zero in every other place. So it's just 1 times 1 equals 1. Now if I were using unary or my hands, the sort of traditional way, two would be this where you put up two fingers. But not if you're trying to use patterns as well as quantities. And so in binary, how do I represent the number two? 010. It's the equivalent of putting up just my index finger here. And if I want to count to three, now I need to add a 1 to the mix. So I add the ones place. And now if you start to visualize this, it's like one of those really old school clocks where the numbers flip around and roll over. Now those ones are going to kind of flip and become zeros and the zero is going to become a one. And so now we have five and then six and then seven. And then dang it, how does a computer count to eight? Yeah, you just need to add another place, right? Just like we humans don't have an infinite number of numbers when we write something down-- we sort of stop when it's not necessary-- all we need is another bit. We just need to add another 0 or 1 to the left, specifically a one. Then all these ones can become zeros. And we can do this toward infinity. But where are these bits coming from? This is all very abstract and just pictures on a screen. Well, it turns out that we have one physical ingredient to all of our computers. Maybe it's your laptop or desktop or your cell phone. At the end of the day, they're either driven these days by batteries or like a cord into the wall where electricity comes from. And even if you have little familiarity with electricity, you probably know that it's like little electrons flowing. So there's some kind of physical resource that can flow or not flow. You can turn it on or off. Well, much like these desk lamps here, here I have three physical lights that are of course connected into the electricity. So I have some physical input. And now that I do, I can kind of implement my own computer using these simple desk lamps. If I want to represent some value, some input or output, OK, here's the zero. This is zero in binary. I just need to leave three light bulbs off. If I want to represent a one, I need to turn this on. And that's now the ones place. If I want to represent two, I just need to turn this light on. If I want to represent three, this one comes on. If I want to represent four, that goes on. 5, 6, seven, and then of course we need like 8, if we want to represent and turn these off, four total bits together. And so that's all that's going on inside of your phones and your computers. Phones and computers and devices these days have what are called transistors, which are tiny little switches that are on or off. And that's all we need if we have some source like electricity to just store information. We just need lots and lots of switches, lots and lots of light bulbs, certainly much smaller in order to represent information. But computers of course can do much more than represent numbers. What about letters and e-mails and things like that? Well, for that, we actually need to kind of decide as humans how we're going to interpret things like these light bulbs. In one context like a calculator, or they might represent numbers-- decimal numbers whatever. But in an email program-- Microsoft Word, Google Docs-- you probably want those light bulbs or those transistors in the computers storing not just numbers, or else you could just do math. You want them storing letters and sentences and paragraphs and so forth. And so we need to have some kind of mapping. And we'll do that as follows. ASCII, which is just an acronym describing a mapping from numbers to letters-- humans years ago just decided, you know what? In the context where we need letters, let's just store a pattern of bits that's equal to the number 65 if we want the letter a. Pattern of bits equal to the number, decimal number, 66 if we want to store the number b. Fast forward to h and i. If you want to store h or i, 72, 73, and just store that many bits. And now I don't care any more in this story how you represent 65 or 73. I just need to know that you can somehow with light bulbs on stage, with transistors in my phone, or whatever the device may be. We can begin to abstract away these low level details. In fact, we're not going to spend much time after today talking about binary in CS50 because here, we have sort of electricity conceptually. On top of that, we can build the notion of binary, zeros and ones. And once we come up with this convention, now we can start to talk about letters of an alphabet. But that's not the only thing we can talk about. We can also talk about graphics and videos and all the things we take for granted these days. For instance, and just to recap, what message have I encoded here on the screen if you recall? AUDIENCE: High. SPEAKER 1: Yeah, it's high because 72 and 73 I claimed a moment ago are just the numbers we humans came up with years ago to represent HI. I don't really know what 33 is. You'd have to look it up or be told it. Turns out it's an exclamation point because indeed humans decided to express in numeric codes as well all the keys on a keyboard. Unfortunately, they weren't very far sighted early on. They only used 7 bits total and later kind of 8 bits. But even that, even though that gives us over 200 possible values, 256, there's a lot of languages that aren't in like the English alphabet, Asian languages and the like, that have many, many, many more symbols than you can express with just seven or eight bits alone. And so now ASCII has been succeeded by something called Unicode. And long story short, humans have begun to solve problems that were initially created by not anticipating, needing, or wanting even larger values than these, but in another context like Photoshop or any graphics program, you might see the same pattern of bits-- 72, 73, 33. But in those programs, they know to interpret these numbers as some amount of color. If you've ever heard of RGB-- Red, Green, Blue-- this is just an acronym that describes how you can mix together three different colors, sort of in the spirit of paint or more technically light, combine these three different colors, and get any color of the rainbow. So each of these numbers I'll claim can be from 0 to 255 and 72 out of 255. That's like a medium amount of red. That's like a medium amount of green and just a little bit of blue. And if you combine those three colors by mixing them together into just one dot or pixel, as it's called in a computer, you get this sort of murky shade of yellow. But in the context of Photoshop or some graphics program, that is what those same three patterns of bits would be interpreted as. And it happens to be the case that talking in terms of single bits, it's not all that useful. With one bit, you can count as high as one. So humans long ago also standardized on a nomenclature a byte, B-Y-T-E, is just 8 bits. And if you've ever heard of kilobytes and megabytes and gigabytes and terabytes and the like, those are just multiples thereof, typically orders of magnitude of 1,000 or 1,024, or more. So with just three bytes, 24 bits, can we represent letters, numbers, and the like. And ultimately, these are just examples of abstraction. And this is going to be a thing that permeates not just this class, but computer science more generally-- taking very simple ideas that really don't seem all that interesting at first glance. But as soon as you use them as ingredients to solve a problem, you can then sort of reuse that tool to build something more interesting, reuse that tool to build something more interesting still until you get to work application development and solving real problems that you care about, taking for granted the people that came before you have solved a lot of these lower level implementation details, so to speak. So what is inside this black box? It is what we shall call algorithms. And an algorithm, if familiar, is what? It's kind of a fancy looking word, but it's a simple thing. What is an algorithm if anyone knows? AUDIENCE: Step by step instructions. SPEAKER 1: Yeah, it's just step by step instructions for solving a problem. That's it. That is an algorithm-- step by step instructions for solving some problem. So what might be a problem that we want to solve? Well, I'm reminded of, and we've-- I'm reminded of fifth grade. My homeroom teacher was trying to teach us as effectively as she could how to follow directions correctly. And at the time, it was a complete disaster. But I always remember from that example the demonstration that she did because it lent itself, although she didn't use this word at the time, to this notion of computational thinking or thinking like a computer, if you will, whereby you want to solve something correctly. But to do, so you need to be fed very precise instructions. And this is easier said than done. And so in fact, to recreate this, thanks to the team here, we have a plate. We have a loaf of bread. We have a jar of creamy Skippy peanut butter. And we have a jar of Smucker's Concord gape jam, and then for the invariable need, a whole lot of paper towel and this one knife. And so let me propose that for just a moment, I'll play the role of a computer or maybe in this form like a robot who's implementing some algorithm where you guys are the programmer, the person who's supposed to feed me instructions so that I can solve the problem. And the problem here will be to, implement, perhaps no surprise, a peanut butter and jelly sandwich-- easy to sort of do intuitively if you grew up eating these things. But if you've never really thought about how to teach someone else to do it and that someone else is not as sort of forgiving as another human where we humans have conventions of just reading between the lines-- computers can't do that. They will only do what you tell them to do. And as such, they are less powerful, in some sense, than we humans. So what's the first step for making with these ingredients-- these inputs, if you will-- a peanut butter and jelly sandwich? AUDIENCE: Open the bag of bread. SPEAKER 1: Open the bag of bread, I heard. AUDIENCE: That's wrong. SPEAKER 1: Correct, but not really what you had in mind, perhaps. But that's OK. The bag is open. So what might a more precise step two be? AUDIENCE: Remove two slices. SPEAKER 1: Say again? AUDIENCE: Remove two slices. SPEAKER 1: Remove two slices. OK. AUDIENCE: Put those two slices on the plate. SPEAKER 1: Put those two slices on the plate. AUDIENCE: Drop the knife. SPEAKER 1: Drop-- what? Drop the knife? AUDIENCE: [INAUDIBLE] SPEAKER 1: OK. AUDIENCE: Unscrew the jam. SPEAKER 1: Unscrew the jam. OK. AUDIENCE: Grab the knife. SPEAKER 1: Grab the knife. AUDIENCE: Put the knife in the jelly. SPEAKER 1: Put the knife in the-- oh. What? AUDIENCE: Other end of the-- SPEAKER 1: Oh, thank you. Right? Grab the knife from the other end. Someone from farther back, perhaps? AUDIENCE: Stick the knife in the jam. SPEAKER 1: Stick the knife in the jam. What's that? AUDIENCE: Take it out. SPEAKER 1: Take it out. OK. Again? AUDIENCE: Put the knife in the jam. SPEAKER 1: Put the knife in the jam. Ow. Scoop it. AUDIENCE: Yeah. Dump it on the bread. [LAUGHTER] SPEAKER 1: OK, we're halfway there. Now what? AUDIENCE: Spread the jam with the knife across the bread. SPEAKER 1: Spread the jam with the knife across the bread. AUDIENCE: Evenly! SPEAKER 1: Oh, evenly. Let's be careful here. OK, OK. Next? AUDIENCE: Do the same thing you did with the jam with the peanut butter on the other slice of bread. SPEAKER 1: OK, so I think we did this first. AUDIENCE: And this time, don't get a lot of peanut butter. SPEAKER 1: We did this, then we did that. Then-- oh. All right, I'll take some liberties. OK, and now we put it in again. AUDIENCE: Scoop a little bit out. SPEAKER 1: "Scoop a little bit out" I heard this time. AUDIENCE: Onto the other slice of bread. SPEAKER 1: Onto the other slice of bread, thank you. AUDIENCE: Spread it evenly. SPEAKER 1: Spread it evenly. Next time, have me use my right hand please. OK, and-- AUDIENCE: Put the knife down. Put the jam side on the peanut butter. SPEAKER 1: Thank you. Put the jam side on the peanut butter and-- delicious. OK. Thank you very much. [APPLAUSE] So a silly example, to be fair, but just realize how much opportunity there was even in something as simple as that for ambiguity or scenarios you didn't anticipate. And indeed, among the things we're going to do today as we begin to formalize these ideas with code, with programming code, are how you think about breaking down problems into their constituent parts, considering what happened-- what should I do if this happens? What should I do if this happens? What should I do if this happens? Because unless you anticipate the kind of silliness that I was deliberately acting out there, who knows what the computer might end up doing? After all, odds are everyone in this room like me has seen like a spinning beach ball or an hourglass on your computer or your Mac or PC freezes or crashes. And almost always that's just the result of some human error. Someone at Google or Microsoft or Facebook or wherever made some mistake. He or she did not anticipate some situation, didn't anticipate you typing in a word that you did, didn't anticipate you running 20 programs at once, didn't anticipate some scenario. And so as such, the computer's behavior was effectively undefined. And so the incorrect solution was outputted. So how do we begin to think about this? What would be ideal if we somehow-- if we somehow formalize this by way of actual code. And we'll do that with sort of another old school problem, one that's a lot more digital these days but it's still with us today. Whether you have an Android phone or iPhone or anything else, odds are you have like a little app for your contacts or your address book. And then there are a whole bunch of names, probably alphabetical by first name or last name, and a whole bunch of telephone numbers and maybe more information like emails and so forth today. But the physical incarnation of that icon on your phone is this old thing, a phone book. And if I wanted to look for an old friend like, say, Mike Smith, how might I go about finding him in this old school phone book? Well, just as in my digital form, I might just scroll through the list looking for him. So could I look at the first page, look down, not see him, turn the page, look down, not see him, turn the page, look down, not see him, and so forth. Is this algorithm correct? AUDIENCE: Yes. SPEAKER 1: Yeah, it's correct. It's kind of dumb right because it's going to take forever to get to Mike if there's like 1,000 pages here, but it is correct. And it's the equivalent really of sort of slowly methodically scrolling through your list of contacts without the luxury of like searching or autocomplete or the like. Well, I could do a little better. Back in grade school, I generally learned to count by two. So I could instead do 2, 4, 6, 8, 10, 12. I'm flying through the phone book now clearly faster. But is that algorithm correct? AUDIENCE: No. SPEAKER 1: No why? AUDIENCE: You might miss him. SPEAKER 1: Yeah, I might miss him, right? Like Mike, just by chance, might be sandwiched between-- so it is, no pun intended-- between the two pages then I'm flying past and I might miss him. But I can at least fixed this mistake or bug, so to speak. A bug is a mistake in a program, just human error. If I hit like the T section, t comes after Smith. So I can maybe double back at least one page and solve that bug. So it costs me a little bit more time to double back, but if I do it right, it only costs me like one extra page turn. So better and now correct. But obviously no one in this room is going to look for Mike Smith by starting on the first page. Where are you going to roughly look? In the middle, maybe a little toward the end because you know where S's are. And so you open the book to the middle. You look down and you see the M section. So I haven't gone far enough. But what's nice about this old school technology is that we can now tear this problem in half, throw half of it away, and be left with fundamentally the same problem but a smaller version thereof. This now is maybe not 1,000 but 500 pages, but it is the same problem. And I can apply the same logic, go roughly to the middle, look down. I went a little too far this time, the T section. But I can again tear off almost a quarter of that problem, leaving me now with a total size of the maybe 250 pages after dividing it in half twice now. And now I can repeat and repeat and repeat. And so long as Mike is in the phone book, I should ultimately find him once and only once on the final page of the phone book, at which point I can call him. So the real question then is how much better was this. It's a little wasteful. You can't sort of undo here in the analog world. But let's consider how we can think about how good that algorithm was, the one that we all probably took for granted and should have started with. Well, if here's a simple plot and on the x or horizontal axis is the size of the problem-- so the number of pages in the phone book, however you want to measure it-- and then the y or vertical axis is time to solve-- so maybe number of seconds, number of page turns, however you want to count up the steps-- that's a relationship, size to time. And the first algorithm I'm going to draw like this-- a straight line in red. And I'm going to call it n where n is just like the number of pages in the phone book. Computer scientists tend to use n as a variable so to speak, just a symbol. And it's a straight line for the following reason. If the phone book gets a little longer next year, a little longer next year, by like one page, that means I might have to spend one more step looking for Mike. So the slope of this line is linear. There's a one to one relationship between number of pages Verizon or the phone company puts in the book and the number of page turns I need to make. The second algorithm, though, is also a straight line, but it's lower drawn here in yellow. And n over 2 means it's twice as fast or equivalently takes half as much time because for a given size problem, if you kind of follow my hand straight up, the yellow line should be below the red line because I'm flying through the phone book two pages at a time. So it should take me half as much time. But if I use the first algorithm, I have to go all the way up to the red, which measures that number of seconds. But the third algorithm is a fundamentally different shape. And this is where the sort of beauty of computer science and algorithms specifically comes out. It doesn't become straight ultimately. It looks like it's gradually easing off. But it's going to do this forever. It's just becoming such a slow increase in time-- you can't even really see it especially if the screen were even wider. We'll call this logarithmic, log n, more on that down the road. But the shape is fundamentally different. It's curved. And what's powerful about this-- and you can think about it much more easily, intuitively. If Verizon next year doubles the size of the phone book because like maybe Cambridge and another town merge together into one book, no big deal because if Verizon doubles the size of the phone book next year, how many more page turns do I need to find Mike? AUDIENCE: Just one. SPEAKER 1: Just one, right? Because I just split the problem in half one more time, no big deal, instead of flipping through an additional 1,000 or 500 pages. And so this intuition with which you entered Sanders today, odds are you can harness it already to solve problems more effectively so long as you start to notice the patterns and the sort of useful inputs with which you can solve problems. But we need to begin to formalize the process. We need to be able to express ourselves a little less organically than we did with the peanut butter and jelly. So how might we more methodically express that algorithm with the phone book for which we probably nonetheless have an intuitive understanding? Well, let me start counting at zero just because programmers and computer scientists tend to start counting at zero because that's like all the light bulbs are off. So you might as well start there. And then step zero would be pick up phone book. It's sort of an action. Do this. Step one is open to the middle of the phone book. That's pretty much what I did a moment ago. Step two is look at the names-- another action or verb Step three, if Smith is among names. So this is a different construct. And that key word here is going to be if. It's a question you're asking yourself. It's kind of a proverbial fork in the road. If Mike is among the names on the page you're looking, then call Mike. And I've deliberately indented it because in many computer languages, indentation means logically that you should only do step four if line three were true. Or the answer to that question is yes. Else, if Smith is earlier in the book, he's meant to my left, then step six, open to the middle of the left half of the book. So that's when I tore it in half, threw it away, and then repeated on the left half. Else, if Smith-- oh, sorry. Then go back to step two, a key step. Now that I've divided the problem in half and I'm looking in the middle of the left half, the problem is fundamentally the same as I claimed before. Just do the same thing but on a smaller problem. And what's beautiful about this algorithm-- it's recursive, so to speak, as we'll see down the road to-- is that you keep doing the same thing, same thing, same thing, but because the problem keeps getting smaller, eventually you're not going to do this forever. You're going to find the answer you're looking for. And so we go back to step two. Step eight, else if Smith is later in the book, to my right, open to the middle of the right half of the book and then again go back to step two. Else-- what's the fourth scenario to consider? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah, what if Mike isn't in the phone? He's unlisted. We'd better anticipate that less my program crash or my computer freeze because, like, it doesn't know what to do if Mike isn't there. So I'll quit in this particular case. And now let's tease this apart by highlighting in yellow those operative verbs or actions. Henceforth, we're going to call things like these yellow words functions, so to speak, in a programming language. These are verbs or actions, and I'll call them out, albeit in English because there's no one language here. This isn't like a formal vocabulary we're introducing. It's just my most distinct way of expressing that algorithm. And that's what pseudocode is. It's English like syntax that anyone in the room should hopefully be able to follow if you're nice and clean and precise about it. But there's another type of keyword in here and that's the if and the else if and else if and the else. These are the keywords that languages typically use to represent these forks in the road-- go left, go right, go here, go there, do different things. And each of those decisions, if you will, is based on the answer to a question. And these questions we're going to call Boolean expressions named after a person named Bool years ago. And a Boolean expression is just a question with a yes or no answer or really more technically a true false answer. And notice the fact that everything falls into like buckets of two-- yes, no, true, false-- means we can use those light bulbs really to our advantage. Maybe off shall be no or false. Maybe on will be true or yes. Just using a one light bulb can we represent any of these answers to these questions. And so those are Boolean expressions. And then lastly, there is these things-- go to step two, which is perhaps the most explicit. It's inducing some kind of loop or cycle. Do something again and again. And all of these ideas, functions, conditions, Boolean expressions, loops, and more are going to permeate several languages that we explore over the course of the semester. But of course this unto itself is not yet real code. And today in just a little bit, we're going to dive into real programming code, albeit graphically using a language called Scratch, and then follow that on later next week with a programming language called C. But before that, let me make just a couple of introductions. Behind CS50 and its lectures and sections and office hours and more is a whole team, nearly 100 staff every year, that are here to make this course successful for you so that irrespective of your prior background or lack thereof, you too can succeed, especially if you are among those 68%. And allow me to invite up Maria and Brian and Doug and Rob to come say hello from the course's staff. DOUG LLOYD: Good morning, everybody. My name is Doug Lloyd. I'm the course's senior preceptor and course manager. 12 years ago now, I sat figuratively where you sat. It was in Lowell Lecture Hall just across the street. I was among those less comfortable. I had never programmed before in my life. I took CS50. It totally changed the way I thought about problem solving. I switched to CS major shortly thereafter, and I've been on the staff with David for 11 years now. So it's great to be here once again. Thank you all for being here. MARIA: Hi, everyone. My name is Maria. I'm a senior living in Cabot, and it's my fourth year in the course. I took it as a freshman at an awesome time, and it's my third year on heads. And I've absolutely loved it. The staff is amazing. Working with all of us amazing and I can't wait to have an amazing senior year with you guys. BRIAN: Hi, everyone I'm Brian. I am the course's head course assistant. I am a junior living in Winthrop, and I took the class my freshman year two years ago now. And really glad that all of you are here and really looking forward to a fantastic semester and working with all of you. ROB: Hey, guys. I'm Rob. I'm a fourth year PhD student living in Thayer, and this is my eighth year with the course. And every year, I think the course gets better. And we put a lot of effort into the course over the summer and building new tools and making new curriculum. And I really think that you guys are going to enjoy it. [APPLAUSE] SPEAKER 1: Thank you. We have a tradition in CS50 of ending the first week with cake or cupcakes. And so after today's lecture, you're welcome to join us in the transept to meet even more of the course's staff. But first, and before we transition to one of these first actual programming languages, we thought we'd dim the lights and paint a picture too of not just the course's support structure, but also its culture or community, which is something we've increasingly focused on in recent years so that students in the class feel that it's not only an opportunity to get an introduction to computer science but also an introduction at Harvard and, as you've seen at Yale and beyond there, a community of support so that you can lean on each other as you tackle the week's problems and ultimately exit having had a very shared similar experience. This is CS50's community. [MUSIC PLAYING] SINGER: [SINGING] [INAUDIBLE] Stop rocking the beat. Come on! [INAUDIBLE] SPEAKER 1: All right, so before-- so before long, this is what code is going to look like. And frankly, it's pretty darn cryptic and it's pretty darned distracting with the semi-colons, as we'll see, and curly braces and parentheses and the like. And frankly, these kinds of syntactic distractions tend to get in the way of learning what's really the interesting intellectual content about programming and computer science more generally. And so we instead begin today before transitioning next week to that language with Scratch, an adorable language that was invented down the street at MIT's Media Lab some years ago that wonderfully has all of the concepts we've looked at thus far in the form of Mike Smith, in the form of peanut butter and jelly, and yet more ideas and allows us to program today by dragging and dropping puzzle pieces, really, that only interlock if it makes logical sense to do so. And coincidentally too, as you may have glimpsed as part of CS50's community, is as you may have seen door drop this week's CS50 Puzzle Day, an opportunity to not solve problems using computers and programs but rather peers and forming teams of two or three or four across the river at the iLab for CS50 Puzzle Day. Grab one of the invites on your way out, the goal there being to message the computer science itself is indeed not about programming but ultimately about problem solving and, in this case, pizza and prizes as well. So this here is Scratch. And what's nice about scratch is that via this language, can we distill that previous, more cryptic program into just a couple of puzzle pieces? And let's see the comparison. If we look back just a moment ago, there's this program in C, a fairly old programming language. But it's nice in that it's fairly small. We'll see that we learn almost every aspect of this language before long. But what do you think it does? Especially if you've never programmed before and don't even recognize some of the words on the screen, what operative word maybe does jump out at you? What is the-- prints. So it's technically prints f, which I don't really know what that means right now. But printing sounds familiar. And what's it going to print? AUDIENCE: Hello world. SPEAKER 1: Probably hello world. When I run this program on my Mac or PC, odds are, it's going to print, quite simply, hello world. How? Don't know yet, but we'll get there. But for now, the same program in this other language, Scratch, can be implemented graphically by dragging and dropping two puzzle pieces together so that scratch has, you'll soon meet as a cat, says hello world in a cartoon-like bubble on the screen. And so in fact, we'll be able to explore with Scratch all of these same ideas-- functions, conditions, Boolean expressions, and loops-- and then bunches of others as well that we'll then see again in C and later in the semester in Python and later in the semester in SQL and JavaScript and beyond. And so we'll begin by exploring them as follows. Let me go ahead and open up this program Scratch. It exists in two forms-- an offline version that I tend to use in class just so we don't have Wi-Fi issues, but then an online version at scratch.mit.edu which you'll use for the course's first assignment problem set zero. And this is what the environment looks like. On the top left where this cat here is, we'll call this Scratch's stage. This is his two dimensional world wherein he can move up, down, left, or right. In the middle is a whole bunch of categories of puzzle pieces. This one here says move 10 steps, turn 15 degrees, and so forth. And up at the top are different color coded other categories of other puzzle pieces we might want to use. And then at right here is a so-called scripts area. This is where I can program. This is where I'll drag and drop these puzzle pieces. And down here if I want more than one cat or some other character, I can create other sprites or characters as well. So how do I program in this case? Well, notice first that Scratch's world has a green arrow and a red stop sign. Green arrow is going to mean go. Stop sign's going to mean stop. So that's how I start and stop my program up here just above Scratch. Meanwhile, if I want to start programming, I'm going to do this. And I know this only from having used Scratch before where things are. If I click on the Events category, notice this puzzle piece here-- when green flag clicked. I can drag and just drop that puzzle piece anywhere on the right. And my program's not going to do anything because I haven't finished the thought. But if I now go to looks, a different category in purple, I might say something like, say-- and now notice when I get close enough, they're sort of magnetic. They want to interlock. So I can let go and then type in here hello comma world. I'll zoom out now, move my cursor over to the green flag, and click. And now I've written my first program. It's not all that complex, certainly. All I did was drag and drop a couple of graphics. But logically, it's doing exactly what I told it to do. Well, before we proceed further, let's see what some of these blocks are fundamentally going to look like so that we have a mental model for these various color coded categories. In purple, we're going to see functions-- actions, or verbs, like we saw with the phone book example. Here, we're going to have conditions. It's a few more puzzle pieces, but they very beautifully interlock together. And this is a branch or a condition. And notice too just like in my textual program, I indented things by hitting the space bar or tab key. So here is it kind of indented because the yellow wraps around the whole puzzle piece. So it's only going to say x is less than y if those orange puzzle pieces x and y, which we'll call variables, which just like an algebra hold values like one or two or three or four. We're going to say x is less than y in that case. Meanwhile, we can nest these things. So even though they look like a fixed size, they'll actually grow to fit other blocks if you want to cram more in. So here, we have a three way fork in the road just by combining these ideas. If x is less than y, then say x is less than y. Else if x is greater than y, then say x is greater than y. Else the third scenario, of course, is x must be equal to y. So this is how we'll program. We'll just drag and drop these puzzle pieces together. What is this green block here called generally speaking? AUDIENCE: [INAUDIBLE] SPEAKER 1: Well, the condition we'll technically call the yellow that's using this green block. AUDIENCE: Boolean. SPEAKER 1: Yeah, it's a Boolean expression, and it is because it's a yes/no or true/false answer. x is less than y is either true or it's false. It can't be both. And so we might have more generally is i less than 50. You don't have to compare variables. Just like in math, you can compare numbers against variables. But here is a different concept. We call this a loop, some kind of cycle that does, in this case, something forever like, say, hello world. Or we can do it a finite number of times-- like, 50 times say hello world and then stop. Here's how we might set a variable. This orange block says set a variable called i by convention because i stands for integer like a number. Set it equal to 0. And then these two things are demonstrative of a more powerful feature that Scratch and languages tend to have of multi-threading. This is a fancy way of saying a program can be written in such a way that it does two things at once. How? Just use two of these puzzle pieces so that when you click the green flag, multiple things happen at a time, thus our supported threads. And then there's this, an even fancier feature but that's relatively easy to use. It's called event handling, and we'll come back to this when we introduce web programming later in the semester. Broadcast and when I receive just mean this. One sprite, one character, like the cat, can kind of sort of whisper to another sprite in the program and send it a message that it can hear or, more properly, receive and then do something based on it. So rather than have your program do something only when you click the green flag, you can have one sprite talking to another telling it when to begin or something along those lines. And so with just these fundamentals are we able to begin implementing any number of programs. In fact, let's go ahead and do this. Let me go ahead make this more interesting by not just saying it on the screen. Let me go ahead and go to sound and play sound meow. [MEOW] With slightly more volume. [MEOW] Oh, With slightly less volume. [MEOW] Adorable. It's a simple program. And if I want it to meow three times-- [MEOW] --I just have to hit it three times. But I can do better than this. I don't want to rerun the program. What's the construct that would let me meow three times? Yeah, a loop or repeat. So let me go to control. I'll zoom in. Repeat-- by default, it's 10 times. So I'm going to change that to three. I can drag this away and now put it inside. Notice it wants to connect inside and it grows to fit. And now I can let it connect there. Let me hit play again. [MEOW] Hm, what's happened there? My first bug. This is subtle, but it's the kind of thing that should give you pause, especially if encountering this on your own. Turns out I should have thought a little more closely about what blocks to use. The hint is kind of on the screen, though it's very subtle. Until done-- like, there's this alternative block. And you know what? I don't know why this is going to be true yet, but let me do this and get rid of this by just dragging it away. Let's see if this fixes the problem even if we're not sure why. [MEOW] [MEOW] [MEOW] It's not a very natural sounding cat, but it kind of fixed the bug. So can we infer retrospectively why it was previously buggy and how it was buggy? AUDIENCE: It played all three at once. SPEAKER 1: Yeah, it kind of played all three at once. Not technically at the exact same time, but my Mac is so darned fast these days, right? Intel inside-- you've got a gigahertz CPU or brain inside of the computer or 2 gigahertz. Those numbers literally mean your Mac or PC can do a billion things at once or-- sorry, a billion things in a second, which just still pretty good, or 2 billion things in a second, which is still pretty good. So certainly it can meow three times and the things just kind of trip over each other. But if we instead use the block that says play it until done, then you'll actually hear all three. And we can actually do a little better than that because that was not a very normal cat. I can drag this block, wait one second, and let's see if this is a little now more natural. [MEOW] [MEOW] OK. [MEOW] So not bad-- pretty darn adorable. But what if we want to add in some motion now? Let me go ahead and remove this. And let me do a forever block so I don't have to figure out in advance how long to do this. And let me go to motion and move 10 steps and now click the green flag. Ah, OK. Thankfully, MIT realized that this could be bad. So they give us just enough access to his tail to pull him back. But this is not the best program. It would probably be better if he bounces off the side or detects-- collision detection, right? We're living in a world now of self-driving cars, apparently. It would be nice if things-- well, maybe they don't bounce off of each other, but they avoid things altogether. So that's OK. I have the vocabulary with which to do this. Let me zoom in. And what is the construct I want to solve this? Like if you hit the edge, turn around. It's some kind of if, right? So let me pull this out and then say, oh, OK. If-- now I have to finish the sentence, and I can do this more quickly just from experience. So I'm going to go to sensing. And then I'm going to grab this Boolean expression in blue. And notice it's way too big, but it will grow to fill. And now from this dropdown, I can actually ask this question instead. If touching edge, what might I want to do? Maybe turn like this. And I'm going to turn like 180 degrees just to completely wrap around. And now I need to move this back in. And again, it looks like it might not fit, but it will grow to fit it. Else go ahead and move 10 steps. So let me go ahead and hit play now. OK, still a little buggy, but at least it's dynamic and it's doing this forever. Now we can stray from the academics of this example and do something silly like this just so you know what features it has. This is a microphone. That was me recording this is a microphone. Here we go. Ouch! OK, that's what the word ouch looks like as a waveform. Let's now call this ouch. And now I need sound. Whoops-- scripts. Sound, play sound ouch logically. So just to give you a sense of what we did, if touching edge play sound ouch, turn around. Ouch. Ouch. Ouch. It's a little bit of a delayed reaction, but we've now sort of combine these different ideas. And already we've kind of moved quickly beyond where we started. All we did initially was say something. Then we move the cat. Now we moved it forever. Then we moved it forever unless you hit the edge in which case you should turn around. So just by building on these very simple ideas can we make more complicated programs still. And let's fast forward for just a moment before we tease apart some of the more sophisticated features to take a look back at actually the very first program I myself wrote back in graduate school when Scratch first came out. I called it Oscar Time since I always loved Sesame Street. And this was the program I made that combines many, many, many, many hours after first starting with Scratch a whole bunch of these same ideas. And rather than I playing this, it would be more fun if someone else perhaps plays. Could we get a brave volunteer maybe a little farther back? Yeah, what's your name? AUDIENCE: Mansi. SPEAKER 1: Mansi, come on up, Mansi. All right, thank you to Mansi. [APPLAUSE] And you have to be comfortable being on the internet now since there are cameras. Nice to meet you. SPEAKER 2: Nice to meet you too. SPEAKER 1: Come on over. And so with Oscar time here, notice there's a whole bunch of sprites. So you'll see a bunch of things happening at once. And realize I did not start writing this program by implementing this game. I implemented just pieces of it at a time until the net effect many, many, many hours later was the game you're now about to see. Let me go ahead and full screen it. And we'll see some directions on the screen in just a moment and you can control with the keyboard. Drag as much falling crash as you can to this cash down. OSCAR: [SINGING] Oh I love trash. Anything dirty or dingy or dusty. Anything ragged or-- SPEAKER 1: Very good. OSCAR: [SINGING] --or rusty. SPEAKER 1: So as she plays, let's consider what some of the building blocks are of this program. So the first thing I think I did when I implemented this game, which is about to get more and more complex, is I just figured out how to move a piece of trash from the top to the bottom. And that's kind of what we just did with the cat albeit a top bottom instead of left or right. And then after that, I think I probably implemented part of Oscar. And Oscar is very sort of simply animated. This is not like a video. This is like three or so different images. So the trash can is closed. It's partly open. It's fully open. He pops out. It's just a bunch of different images or costumes, as MIT calls them, that I play like a half second apart in order to create the illusion like those old school flip books of something happening in animated fashion Meanwhile, he's counting clearly. So that using variable, one of those orange puzzle pieces we previously saw. There's some kind of randomness. It turns up programs, and Scratch included, can use pseudo randomness-- kind of sort of random values so that the trash sometimes falls here or here or here. And lots of video games do this, right? A lot of the games you might have grown up playing would be pretty lame if they are the exact same every time you play them. You want the computer or CPU to do things a little differently or randomly. OSCAR: [SINGING] Now look at this rest of this junk. A clock that won't work and an old telephone, a broken umbrella-- SPEAKER 1: Now keep in mind, this song is like three minutes long and having just one bug partway through this program was an absolute nightmare to debug waiting the minute or two until it happened again. OSCAR: [SINGING] Oh I love trash, anything dirty or dingy or dusty. SPEAKER 1: It never really stops. So congratulations. Thank you. Let me thank you with a little CS50 stress ball. No less as well. So that then is Oscar Time. But what's nice about it, beyond being my baby, is that it gives us an opportunity to consider how you might build up something pretty complex looking and hopefully pretty fun at the end but just out of these constituent parts. And let's see what other ingredients, for instance, we actually have. Let me go ahead actually and open up, for instance, Sheep. This is an example. And this, like all of today's, are on the course's website if you want to play. I changed the cat to a sheep in this case. And if I hit Play, you'll see what happens here is the sheep-- whoops, the sheep does not count at all. Let me go ahead and grab a different version of the sheep since I broke it a moment ago. Apologies. Sheep is coming up now. So here we have a sheep with a very simple script. That is also missing his program. How embarrassing. And here, we have the online version of Scratch. And of course since every browser in the world now blocks flash, we have to enable it. Here we go. And now finally we have the sheep counting, so very anti-climactic. This is literally just a counting sheep. OK. So I put a lot of time into this. So I'm glad we got it working. So at the top right, though, you can consider the parts that went into this. When green flag clicked, set a counter which is just a variable. It's more interesting than calling it x or y. I called it counter. Set it equal to 0. And then forever say the counter for one second like in the little cartoon bubble, wait one second, and then change the counter by 1 by simply adding 1 to it. And we get this effect of perpetual counting up by using this variable. We can do something else as well, for instance. Let me go ahead now and have a bit of dynamic input from a character like a cat again. And this one is called Pet the Cat. So in Pet the Cat here, we have the following-- nothing, even though I hit play. But wait a minute. Let's look at the program. How do I make this program do something? AUDIENCE: Pet the cat. SPEAKER 1: Oh, pet the cat, right? So there's an if condition there that's asking the question if you're touching the mouse pointer. So let's try it. [MEOW] Ah. [MEOW] It's kind of nice. We can do-- [MEOW] --kind of the opposite, though with don't pet the cat. You'll see that I have an if else so that by default, the cat now-- [MEOW] [MEOW] --meows. [MEOW] But if you pet this cat-- [MEOW] [MEOW] [GROWL] --so don't put this cat. How does this work? Well, you just need another fork in the road. If you're petting the cat, make the lion sound. Else just meow in a much nicer, more tranquil way. And we can go beyond this too. Let me go ahead and now open up threads, which is an example of a program doing multiple things at a time. In this case here, we have another type of cat and a bird. And which seems to be the smarter of the two? The cat kind of knows a bit more than the bird about what's going on-- a sort of AI if you will. [GROWL] OK, so same sound there. But notice now we have interaction between the two. The cat, frankly, is kind of cheating. It's not really AI. It's just point at the bird. And so here we have a puzzle piece that says forever if touching the bird, play the lion sound. So that's how the program ends. But at the bottom there, point towards bird, move one step. Point toward bird, move one step. And so what does this do if I get a little sort of impatient and I give the cat some god-like powers here just-- [GROWL] --to speed it up moving 10 steps at a time. And that's all, again, animation is. Instead of moving one dot or pixel at a time, move 10, the effect of which to us humans is that it actually moves a lot faster. Of course, we can give the bird an advantage. So the bird is apparently moving three steps at a time. Lets up that to 30. [GROWL] That did not work out very well either. But in this case, the two sprites are interacting because one is checking whether or not it's touching the other. Meanwhile, you can do this. Let me introduce events, which is another program too. It's not very long, but it again has two sprites, two little puppets here. And if I hit Play here, nothing happens until I hit the space bar. When if you played this game growing up, one says Marco and then the other says Polo. But one is saying Polo in response to the other saying Marco. Let me look at the sprite for the orange puppet here and you'll see this. Forever do the following. If key Space pressed-- so if the space bar is pressed-- then say Marco for two seconds and then broadcast an event. And an event for our purposes today, it's like a whisper. Whisper something that only other sprites can hear, not humans. Meanwhile if I look at the blue puppet, it's not much going on there. When you receive that event, that whisper, say polo. And so we have interaction between these two sprites much like Oscar was responding to the trash being dragged and dropped over his trash can. Finally, we have this one here-- hi, hi, hi-- which combines some of these ideas as well that allows you-- [SEAL BARKING] --to implement perhaps a familiar idea-- [SEAL BARKING] --from like a video game on your phone or the computer. [SEAL BARKING] This is very annoyingly barks in perpetuity-- [SEAL BARKING] --until you figure out how it works. How do I make this stop? [SEAL BARKING] Yeah, so if you look at the code at top right-- [SEAL BARKING] --it mentions to the space bar and it stopped. Why? What does hitting the space bar actually seem to do logically? It's in this left hand program. If key Space pressed, what am I doing? If-- yeah, if muted, which looks like a variable because it's an orange block. If muted is 0, set muted to 1. Else set muted to 0. So what does this mean. Well, this is kind of the programming equivalent of this. If the light bulb is off, turn it on. Else turn it off. And so it's just a way of changing state or changing the answer from false to true or true to false. And then I'm using that information to decide on the right if muted is zero. So zero means off or false. So if it's not muted, if muted equals 0 means not muted, play the sound sea lion. And that's how the program stops until I do it by actually-- [SEAL BARKING] --hitting that. So we have all these puzzle pieces, if you will, of these ingredients-- [SEAL BARKING] --and all of these abilities to weave these ideas together. And you can do ultimately some pretty amazing things. And in fact, in the spirit of bringing our two campuses together both here and in New Haven, we thought we'd conclude with one final game here for which we need one additional volunteer to play for us here Ivy's hardest game. Let's have you come up because your hand was up last time too. What's your name? LUKE: Luke. SPEAKER 1: Luke, come on around. So here comes Luke to play Ivy's hardest game. This was written by one of your own CS50 predecessors, a former student. And you'll see the instructions here on the screen in just one moment. Here we go, full screen. I'm going to go ahead and play for you and you'll use the arrow keys in this game. Here we go Luke. [MUSIC PLAYING] [MUSIC - MC HAMMER, "U CAN'T TOUCH  THIS"] MC HAMMER: [RAPPING] You can't touch this. You can't touch this. SPEAKER 1: [INAUDIBLE] MC HAMMER: [RAPPING] You can't touch this. SPEAKER 1: Very good. Ah, you can. That's OK. MC HAMMER: [RAPPING] My, my, my music hits so hard. That's what I'm saying, oh my lord. Thank you for blessing me. SPEAKER 1: Very nice. Notice the two variables at top. Level three has death zero. Meanwhile, there's of course, multiple sprites on the screen. Three Yale ones. They, like the cat, are bouncing off the edge. Very n-- oh! Keep going, keep going. Death is now one. Death is now two. Infinite. It's OK. Very nice. Level six. Nice. Clearly there's an if near Harvard, move away. Nice. Come on, you can do it. Second to last level. Death is up to seven. Nice. Last level! Just a couple more tries. Nice. One more time. Let us end on that note. This is CS50. Cake with the staff is now served. We'll see you next week.