[MUSIC PLAYING] BENEDICT BROWN: So welcome to CS50 at Yale. My name is Benedict Brown. I'm a new lecturer in the department here. I came from the University of Pennsylvania, and so I'm really excited to be joining this in the third year. And we have, of course, a team from Harvard as well. We are currently about 25% larger than last year, which we're really excited about. [CHEERS] We'd love to see at the end that we're 100% larger, but that's our job-- to convince you that you want to be here. So what I'd like to do at the start is just tell you a little bit about what's different this year and introduce you to the team here at Yale, before I'll pass it off to David Malan for the opening lecture. If you've heard from your friends about CS50 in the last couple of years, especially last year, not a lot has changed. So it's pretty good advice that you'll be getting. One of the changes, the biggest change probably this year-- we've got a staff of 40 TAs that we're really excited about, a fantastic group. So you'll have lots and lots of support, just like you have in the past. In addition, after this week most of the lectures-- there will be two more that are done at Yale, and the rest of them are recorded at Harvard, and you'll be watching online. But during this Thursday time slot, I will be here and talking about enrichment, complementary information, maybe going into a little more depth on some of the applications, talk about ways that you might use them or they might connect to other fields. So these are areas that are not going to be on the exam. They're not going to be graded. They're totally optional, but they should be fun, help you give a little more context, learn a little more about what's going on in computer science in the field in general and how you might use that in other areas than we can fit into the course proper. And so I hope that a lot of you will enjoy coming, and we'll see you at those. And with that, I'd like to also bring up Natalie Melo, who will be the course manager and co-head of the course with me-- [APPLAUSE] -- and our wonderful head TA, [INAUDIBLE].. [APPLAUSE] And I'm going to bring up also Natalie's counterpart at Harvard, Doug Lloyd, who you will not see much here at Yale. But you will see his name a lot. He's very involved also in creating the course, and so he's a good person to have in mind. And with that, since you'll get to see me all semester long, I'm going to turn it over to David. [APPLAUSE] [INAUDIBLE] DAVID MALAN: Thanks, [INAUDIBLE]. So thank you so much to Benedict and the whole team. This has been a really special collaboration over the past three years now, and this is indeed the third time we're all gathering here together. And perhaps most pointedly for me, and for Benedict too, is he and I actually go way back. We were undergrads together, and I was good friends with one of his roommates. And I had a habit of going to their room a lot, perhaps more often than mine. And for whatever reason, these guys were really into ordering pizza. And back in the day, before there really was Domino's as as popular of a thing, there was a pizza ring, which-- in Cambridge, for $8 you could get a double-decker pizza. And it was about the quality you would expect for $4 for a large pizza. And these guys, and with Benedict's blessing, photographed this, even before there were cell phones. And so this was the number of pizzas they accumulated over the course of a semester, maybe, or so forth. And if you enhance there, you'll see Benedict himself. So we go some 20 years back, and it's especially special for us, I think, to be now collaborating across these two towns. But today we introduce CS50 itself and, in turn, computer science. The overarching goals of this class is to give you an introduction to the fundamentals of computer science, so that if you're interested in going on to studying higher-level classes, whether it's in artificial intelligence, or graphics, or hardware, or software, or theory, you have that basis with which to proceed. But it's also meant to be a terminal course for those of you who are perhaps non-majors or who simply are coming from some other field in the sciences, the arts, natural sciences, social sciences and beyond, who want to bring some technical savvy and comfort to your own field so that when you have a large data set, you can do something interesting with it. When you're working on your thesis and you want to compute data, you have the tools and the techniques and the mindset with which to do that. And so this course, ultimately, is for majors and non-majors alike. And that means something in particular. In fact, years ago CS50 at Harvard was the very first CS class I ever took. And as I've often related to others, I was frankly pretty daunted by taking a CS class, let alone this particular introduction, which for years-- ever since my day and Benedict's day-- has had this reputation to sort of beware. And daresay, a lot of students feel that way about computer science. It's an unfamiliar field. They don't have any prior experience. It feels like everyone else in the room must surely know more than they, and so these are barriers to actually putting your toe in unfamiliar waters. And I felt that way freshman year. I didn't have the nerve to shop the class, so to speak, freshman year. And it was only sophomore year that I finally got up the nerve to go into CS50's first lecture. And even then, it was only because the professor allowed me to take it pass/fail and actually sign that sheet. And that helped me get over the mental hurdle. And I found, of all things, that I actually loved this world. And it was so empowering that just with my laptop-- which for years I'd been using to write essays and other mundane things-- it's just so empowering to be able to create something with that device. And I had initially strayed away from this. I had studied government initially, and I had banged out half of the requirements for the major at Harvard. And I gravitated toward government only because, frankly, I was familiar with it. In high school I liked history and constitutional law, and those kind of felt like the closest fit to political science or to government. And so I just stayed on this familiar path, and it was only once I stepped off of it, so to speak, that I found this new world where homework was genuinely fun. And I felt challenged and sort of inspired to be able to create things from truly nothing, everything now digital. And if it's any reassurance, 68% of you here and in Cambridge have never taken a CS class before. So if you're among those who, like me, was a little timid about considering some new field or a class like this, realize that a majority of the people around you are feeling exactly the same way. And in fact, in CS50 we've long had this tradition of different tracks, so to speak, or comfort levels within the class-- for those less comfortable, those more comfortable, and those somewhere in between. And these are just unofficial labels that you kind of know it if you are. If you sort of have one foot halfway, mentally, out the door because you're not sure if this is for you, you're probably among those less comfortable-- never programmed before. You're not a computer person and so forth. If you've been programming since you were six years old, but it was a lot of self-teaching, and you have a lot of gaps in your knowledge, maybe you're among those more comfortable, or you're indeed somewhere in between. And these percentages-- about 56% less comfortable was the breakdown from students just a few years ago. And in fact, this past summer some of our team from Harvard and Yale spent a while traveling around and visiting former teachers and students of CS50 and discussing with them the challenges that they faced in computer science or as an on-ramp there to-- the kinds of exposure they had or lack thereof to the field. And so you'll see this in the course's first problem set next week, but you'll see at project5050.org. We have a lot of these stories or vignettes about folks who have come before you, if you'd like to get a sense of folks with similarly disparate backgrounds that may have come through here before-- and later on, some Spotify. So what's most important, though, is this-- this is perhaps the most telling statement in the course's syllabus, which you probably received on the way in, which is that what ultimately matters in this course is not so much where you end up relative to each your classmates, but where you, in week 11, the end of the semester, end up relative to yourself in week 0, right now and here. So far as grades go, so far as progress goes, the course really does very deliberately and very manually consider that delta, from now until the end of the semester, independent of any knowledge or experience or lack thereof that you might have. But toward that end, and to put our toes in these waters, let's consider what computer science is really about. Odds are, if you're like me, you probably had this perception in high school that it's programming. And in fact, I still remember kind of looking through the glass door of our computer science classroom in high school, seeing all of my friends with their heads down, typing away at the keyboard. And it seemed completely asocial. It seemed completely uninspiring. The door was literally closed, fluorescent lights, desktop computers back in the day. It just didn't seem at all appealing to me. But if you take a step back from that and consider it's really computer science, a field about problem solving-- and yes, we have tools, both in our pockets, and on our laps, and on our desk these days that make it easier to solve problems quickly. At the end of the day, it's all about cleaning up your thought process and trying to think a little more precisely so that you can express yourself not only correctly but efficiently when it comes to making a computer do something, or even writing more persuasive arguments in English or any other native language. And to give you a sense of the kinds of problems we used in the class last year as the backbone via which to explore some constructs, some of which we'll dive in today, last year we started the semester with Scratch, a graphical programming language. And we'll see a little bit of that today. That allows you to drag and drop puzzle pieces, not unlike the adverts you might have in your hands here for CS50's tradition of Puzzle Day this weekend, that lets you program by interlocking these puzzle pieces. We then introduced C, a fairly old language, but a small language that's pretty Greek-like, so to speak, for those who don't actually speak Greek. And you have the ability in C to go even closer to the computer's hardware and make things move around in memory very, very digitally, as we'll soon see. And then we introduced the world of cryptography, the art of scrambling or enciphering information to keep messages secure or safe. Game of 15, that little up, down, left, right puzzle piece thing that you might have gotten in a party favor as a kid, where you try to order the numbers-- that lends itself to a discussion of algorithms, procedures for solving problems. Forensics-- we often take photos, either from online or from a digital camera, and accidentally delete them, and then hand you a forensic image, so to speak, of the memory card and have you write software in C to recover those images, something that you yourself might have had occasion to need, if you've ever had corrupted or deleted files accidentally. Misspellings-- deliberately misspelled there, because we give you a dictionary of 150,000 English words and challenge you to write code to load all of those words from a big file into your computer's memory and somehow spell-check really big files quickly, much like Microsoft Word and Google Docs does for you, but thinking about how you can actually determine if something is spelled rightly or wrongly. And then we transition to web programming, sort of a more modern paradigm, certainly what you and I all interact with pretty much daily these days, anything in a web browser. And we introduce you to Python, and JavaScript, and SQL, and a few other languages too. And we have you implement, for instance, your own stock-trading web site, talking to Yahoo Finance, getting real-time stock quotes and actually simulating the process of buying and selling stocks and then mashing up, ultimately, Google News and Google Maps and creating visualizations of information. So all of this, especially those 68% of you with no prior background, will have been completed by you in just three months' time. And we'll have a scaffolding process and a step-wise approach to this. But ultimately you'll find, hopefully, as I did long ago, that this process of problem solving accelerates once you learn these basics here, and then assume those from the prior week and build on top of them, build on top of them, build on top of them. And you'll be struck by just how far you've come by the end of one semester. So let's consider what we mean by problem solving itself. We could, perhaps, distill it pretty simply as just this, like a black box. So we don't know what's inside of it. We don't know how problems are going to be solved. But at the end of the day, what's a problem? It's something that's got input, and the goal is to get output. You want to solve that problem-- a very generic way, but a very simple way of describing what it means to solve a problem. Now, the secret sauce is going to be what's inside that box. But we'll come back to that in just a moment. First, we have to consider how to represent inputs and outputs, right? At the end of the day, you have a laptop on your lap or desk. You've got a phone in your pocket, maybe some kind of smart watch and other devices. And you probably know, even if you're not a computer person, that these computer devices only speak one language, so to speak, at the end of the day. What is that-- yeah? AUDIENCE: Binary. DAVID MALAN: Binary, so binary-- bi, meaning two, and that alludes to the fact that computers only understand two digits, 0's and 1's, though you could call them anything you want. But humans decided years ago to think of it as 0 and 1. Now, why might that be the case? Well, it's kind of handy that the physical input to computers, whether it's from a plug in the wall or if you've pre-charged a battery-- you have some form of electrons, the ability for electrons to flow. That too is kind of a physical input that you could either visualize or just proceed with some kind of measure. And if we visualize this with something like this, my phone right now, with the flashlight off, might be representing a 0. And if I, instead, just turn the flashlight on, now I might be said to be representing a 1. And so long as I have a physical resource like electricity, I can turn something on or off, and therefore represent a 1 or a 0. So already, even though I have no idea really how my computer works, or my phone, or any other such electronic device, I know I have to plug it in once in a while. And I know that gives me electrons or electricity from the wall. That is the physical resource that we can somehow now map, so to speak, to just 0's and 1's, off and on. But what can we now do with this kind of information? How do computers represent numbers, and letters, and graphics, and videos, and all these fancier things we now have? Well, let's consider what we already know, which might be this-- computers, of course, speak binary. We humans speak, as you probably recall, decimal-- dec meaning 10, so we have 0 through 9 in our vocabulary. But what does it mean to actually represent numbers? So this number 123-- why do all of us have a very intuitive notion of what that is, upon seeing these symbols on the board? 1, 2, 3-- it's just a pattern of symbols, glyphs that I've drawn artistically on the board. But why do they have meaning? Well, if you're like me, back in grade school, you probably learned that the 3 is in the what's place, so to speak? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, so it's in the ones place or the ones column. And then this is the tens place, and this is the hundreds place. And then the reason that this is 123 and not just some artistic pattern of symbols anymore-- it has a mathematical meaning-- is because if this 1 is in the 100s place, this is like 1 times 100. And this is now 2 times 10, and this is now 3 times 1. This, of course, is 100 plus 20 plus 3. And of course, at the end of the day, we still write it the same way. But now you think of it as an aggregate-- 123. Well, if you're on the same page as me with this, if everyone in the room is already comfortable, certainly, with these fundamentals that we've long taken for granted, let's just change the paradigm a little bit. We had powers of 10 a moment ago-- ones, tens, hundreds, thousands, ten thousands, hundred thousands if we kept going. Those are all powers of 10. Specifically, it's 10 to the 0, 10 to the 1, 10 to the 2, 10 to the 3, and so forth. And that's because we have 10 digits in the decimal system that we humans tend to use. But of course, in the binary system, we have two. So if we have powers of 2, what should these values be? 2 to the 0, 2 to the 1, 2 to the 2-- so what should this rightmost column represent? 2 to the 0 in this case, so that's just the ones place still. 2 to the 1 is the twos place, and 2 to the 2 is now the fours place, and so forth-- 8, 16, 32, 64, 128, 256. You can go on forever, but it's just the same thing. So what then, in binary, does this represent? What decimal number does a pattern of three 0's in binary represent? It's just 0, because it's 0 times 4 plus 0 times 2 plus 0 times 1. All right, that's surely quite easy. What about this? What's this number in binary, if you convert it to decimal? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, it's just the number 1. And then, of course, if we just change this, it's the number-- AUDIENCE: [INAUDIBLE] DAVID MALAN: OK, good, it's 3, all right? You might be inclined initially to say 2, because it's like hash marks on the board. But that's not quite the same thing, because we have a 0 in the fours, 1 in the twos, 1 in the ones. And so this means we now have the ability to count to 3. And if we want to change this to 2, we're going to have to change this back to a 0. And if we really quickly erase all of this, and just do this, what's the highest we can count with just three places? Not eight per se, but-- AUDIENCE: [INAUDIBLE] DAVID MALAN: 7, and it's not 8, because we're starting at 0. So it's eight total values, but 7 is the highest one that we can actually go. And so after this, just to be clear, we might have the eights place, the sixteens place, the thirty-twos place, and the-- damn it. We've run out of room for a byte, so we'll do this again. And we have the hundred-and-twenty-eights place, 64, 32, 16, 8, 4, 2, 1. And just to take, maybe, the pressure off me for a second, could a brave volunteer come on up and answer one problem-- not only in front of everyone, but on the internet as well? And we can sweeten it with a little CS50 stress ball. Oh, there we go, OK, come on up. What's your name? AUDIENCE: [? Mikhail. ?] DAVID MALAN: [? Mikhail, ?] come on up. All right, so this shall be yours if-- AUDIENCE: [INAUDIBLE] DAVID MALAN: Nice to meet you. Go ahead and represent for us in binary-- so 0's and 1's-- the number 50, using a piece of chalk and putting a number in each of those columns, the number 50. And now as he does this, it's no coincidence that I deliberately made room for 8 bits on the screen. If you've ever heard of a byte, B-Y-T-E, a byte is just 8 bits. It's a collection of eight 0's and 1's together. Why is it a convention? It's just a nicer number to deal with than individual bits. Eights is a nice unit of measure. And [? Mikhail ?] here, indeed, gave us 32 plus 16, which gives us 48. Toss in another 2, and you get a stress ball-- congratulations, thank you very much. [APPLAUSE] So what's the take-away here? So if you've ever known that computers speak binary, 0's and 1's, you probably vaguely knew something like that. But it's actually not all that inaccessible. If you didn't even know this before, it's just a step away from what we all grew up with. And binary and decimal aren't even the only two. We'll see hexadecimal down the road. There's base-64, and there's base- any number you want-- it's just some of these conventions tend to be more popular than others. So it suffices to say now that computers can clearly count from 0 to 1 or even much higher, just by using multiple bits. In fact, if you wanted to count even higher than this, we just need a 256 place, a 512 place, and so forth. So we can just keep doing what we do in the human world, just keep adding more and more numbers to the left. But numbers are just one thing. Computers, of course, let me send emails these days, and I can see pictures and movies on the screen. So how do we get from 0's and 1's-- or, really, electricity-- to 0's and 1's, to numbers, and now sort of a higher-level notion of a letter? Well, humans some time ago essentially decided to standardize things, whereby the world decided that, you know what? If you're writing a program, and you want to show the user the capital letter A, you simply want to use 8 bits-- technically 7, but generally 8 bits these days-- arranged in a pattern that represents the decimal number 65. And so if the user is using a program like Microsoft Word instead of a calculator, he or she will see the letter A instead of the number 65, for instance. So it's just context sensitive, depending on the type of software the human is actually using. If you want a B, number 66. If you want an H, 72, 73 for I, and so forth. And the dot, dot, dot just suggests that someone thought it all through, so we've got lowercase-- we've got punctuation and a few other symbols. But they didn't really leave them that much room. In fact, if you're using 8 bits, how many total possible values can you represent with 8 bits, each of which can be a 0 or 1? It turns out it's like 2 times 2. It's 256 total possible values. If you've got 1 byte or 8 bits, it's only 256 possible values. And if that's not immediately obvious, totally fine-- just take on faith that it's 256. There's a lot more than that many characters in other languages than, say, English or romance languages. In a lot of Asian languages, you need many more symbols or glyphs than that allows. And so now the world has not just ASCII, but something called Unicode, which uses not 8, but maybe 16 or even more bits, as needed. So we've solved at least that problem, but it doesn't just have to be letters that we encode. Consider this as well-- here's a pattern of 3 bytes, I claim. It's not that much fun to see things in binary all the time, because it would take me a while to figure out what the pattern represents. So we're just going to use decimal for now. And if you see 3 bytes, which represent 72, 73, 33, what message might be embedded on the screen here? These are three ASCII or Unicode characters. What message is encoded if it's 72, 73, 33? You can get at least 2/3 of the answer. What have we said? Yeah? AUDIENCE: Hi. DAVID MALAN: Yeah, so it's hi, H-I, and then something. And you wouldn't know unless you looked this up or knew it in advance. 33 happens to be the exclamation point, so what we've represented here in, say, Microsoft Word or an email, or a text message, or whatever is the message "HI!"-- simply by storing 24 bits, 8 bits, 8 bits, 8 bits, each of which represents those values. But suppose you don't want to send an email or write a message. You actually want to use Photoshop or something or a graphics program more generally. Well, it turns out if, at the end of the day, your computer only understands 0's and 1's, you have to decide on a mapping sort of a translation between 0's and 1's and things like colors. And so humans decided some years ago that very often-- certainly for very colorful images-- we will use 24 bits for colors instead, 8 of which represent how much red you want on the screen, 8 of which represent how much green, 8 of which represent how much blue you want. Thus was born RGB, for red, green, blue. And so together, if you have 0 red, it would just be all 0 bits. All the light bulbs are off, so to speak, in the computer. If you want a lot of red, it'd be 8 1's-- all the light bulbs go on in the computer, and that means give me a lot of red. Then you say give me some amount of green, some amount of blue, and then you mix them together like waves of light. And you get, ultimately, one color. And it turns out, if you actually combine 72 out of 256 or 255 of red and 73, which are medium amounts, and then just a little bit of blue, because 33 isn't that big of a number, you get this very hard to see, on this projector, shade of yellow or brown. And so it's using the same pattern of 0's and 1's, the same pattern of bits. But in a different context, these bits, barely, are representing a big square of yellow. And if you've ever looked on your computer screen really close or your phone, you might see these tiny, tiny little squares or dots called pixels. And those are, indeed, each generally using 24 bits-- some red, some green, some blue-- to give you some color of the rainbow. So these sort of baby steps that we've taken, starting with electricity and then 0's and 1's and then letters of the alphabet-- or in another context, images, or rather colors-- is all about abstraction-- taking pretty simple, if not uninteresting ideas, and then using them as ingredients to build up more interesting notions. So electricity is just flowing from the wall. What could I possibly do with that? Well, if I let it flow, I claim I'm going to represent a 1. If I turn it off, I'm going to represent a 0. That now gives me a vocabulary, the binary alphabet. Once I have 0's and 1's, we've seen, just like [? Mikhail, ?] we can put patterns of them together-- 8 different light bulbs. And turning them on and off in different permutations lets me represent much bigger numbers than 1, like the number 50. And of course, if we now just decide as humans that, hmm, some of those bits represent red, some of them represent green, some represent blue, we can all decide that, oh. Well, I'm looking at, really, a pattern of 1's that's a color. And I never again-- after today, frankly-- never again need to know or care what binary is or how electricity works. But I know that it exists, and I know that I've abstracted away on top of that to come up with higher-level ideas that are actually interesting to me. If I'm an artist dealing with colors, I don't care how you represent it. I want them to exist, but what we'll do in this kind of class is peel back those layers, look underneath the hood, so to speak, so that you at least understand these building blocks. And so even though today you might look at software on your computer or projects that your friends are working on as well beyond your own familiarity, that's just because they've been layering, maybe for more weeks or more semesters than you. And it just takes some step-wise approach to building up that same knowledge yourself. So that's how we might represent inputs and outputs. But what's inside the black box, the secret sauce to which I alluded earlier? This is the so-called algorithm. And an algorithm, in someone's own words, is what? What's an algorithm, if you're familiar-- yeah? AUDIENCE: A step-by-step process for solving something? DAVID MALAN: Yeah, a step-by-step process for solving something-- so it's like step-by-step instructions. Step 1, do this; step 2, do that; step 3, do this; and so forth. It's just-- that's an algorithm. It's a process for solving problems, albeit under the guise of some fancier word. So how do we go about using algorithms in interesting ways? Well, at the risk of being a little overboard, let me move this over here. And we have come prepared with some supplies here. We've got some paper towel, we've got some white Wonder Bread, we've got some creamy Skippy peanut butter. And we've got some Smucker's grape jelly and a knife-- and, I discovered too late, no plate. So we're going to use some paper towel here and see if we can't craft an algorithm together, all right? I learned this in fifth grade, when my homeroom teacher, back in fifth grade, used this as an example to teach us how to follow instructions correctly. But the reality is, it's actually wonderfully demonstrative too of how precise and how correct you need to be when feeding instructions to a computer, because computers, at the end of the day, as fancy as they might seem, are pretty dumb devices. After all, they were designed by and programmed by us humans and our own limitations, and so they can only do exactly what we tell them to do. So suppose that what I want a computer to do is make a peanut butter and jelly sandwich. I'll take on that role, for the sake of discussion. Consider me, for the moment, a computer or a robot if having some kind of form helps. And you guys will be the programmers, verbally. So if we were to make a peanut butter and jelly sandwich here, step 1 in this process might be what? You want to begin for us? What's your name? RACHEL: Rachel. DAVID MALAN: Rachel, what might step 1 be for-- RACHEL: Open the bag with the bread in it. DAVID MALAN: Open the bag with the bread in it. So I, taking this completely literally, simply do what Rachel has said. It's correct, but probably not the program you intended. So it's OK-- we're now one step closer to something. But let's see if we can't now make step 2 ever-more precise-- step 2, someone else, yeah? AUDIENCE: Manipulate plastic-- DAVID MALAN: Manipulate plastic, OK. [LAUGHTER] AUDIENCE: [INAUDIBLE] DAVID MALAN: And take out what? AUDIENCE: A whole slice. DAVID MALAN: Take out a whole slice of bread, after manipulating the plastic, OK. OK, good, we've got the bread out-- step 3, yeah? AUDIENCE: Get a knife, but not by the sharp end. DAVID MALAN: OK, get a knife-- thank you-- but not from the sharp end-- step 4? Step 4-- yeah? AUDIENCE: Put the bread on the paper towel. DAVID MALAN: Put the bread on the paper towel, OK-- step 5? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, over here? AUDIENCE: Pick up the jar of peanut butter. DAVID MALAN: Pick up the jar of peanut butter, and then-- AUDIENCE: Yeah, unscrew the lid from the peanut butter. DAVID MALAN: Thank you, unscrew the lid from the peanut butter-- OK, next step? AUDIENCE: Remove film from the jar. DAVID MALAN: Thank you, remove film from the jar-- all right, next, yeah? AUDIENCE: Plunge your knife into it. [LAUGHTER] DAVID MALAN: Thank you, next step? We're not that much closer to a sandwich yet-- next step, yeah? AUDIENCE: Remove [INAUDIBLE] [LAUGHTER] DAVID MALAN: OK, 100 grams, here you are-- what's next? AUDIENCE: Put down the jar. DAVID MALAN: Put down the jar [INAUDIBLE].. OK, literally correct. AUDIENCE: Place the peanut butter on the knife onto bread. DAVID MALAN: Place the peanut butter on the knife onto the bread. AUDIENCE: Evenly. AUDIENCE: Gently. DAVID MALAN: Evenly and gently, lovely, OK, that's pretty good-- nice, now what? AUDIENCE: Place knife down. DAVID MALAN: Oh, sorry, wait-- thank you, place knife down. AUDIENCE: Open the [INAUDIBLE]. DAVID MALAN: Open the jar of jelly. AUDIENCE: Repeat the exact same thing as you just did [INAUDIBLE].. DAVID MALAN: OK, so we manipulated the plastic, OK. [LAUGHTER] We put this down. We plunged the knife-- 100 grams of jelly. We gently and evenly spread the jelly, nice-- and? AUDIENCE: Put the bread together. DAVID MALAN: Put the bread together-- AUDIENCE: [INAUDIBLE] DAVID MALAN: In the peanut butter and jelly side, yeah. OK, [INAUDIBLE] pretty good. [APPLAUSE] Thank you, so for the first time-- we did this once before, a few months ago, and someone was one step ahead of me and, I think, added, "Smear peanut butter on your face." Thank you, all right, so anyhow, this was a little-- this was certainly organic, and it wasn't necessarily as precise as could be. And even though I was being a bit histrionic, I was really taking the instructions literally, which suggests even in something as trivial as this, that we humans take for granted in real life, there are certainly opportunities to be ambiguous, which probably isn't a good thing, and to be imprecise, which probably yields unexpected results. And frankly, in our human world, when you're using a Mac, or a PC, or your iPhone, or your Android, and maybe you see a spinning beach-ball or an hourglass, or the thing just freezes or crashes, those are unforeseen circumstances. Odds are there was a human who wrote some code at Apple, or Microsoft, or Google, or wherever, and he or she did not anticipate some situation, did not anticipate you clicking over there, did not anticipate you doing this so quickly, or some other unforeseen circumstance, because they weren't thinking through all of the possible scenarios, just as we weren't necessarily a moment ago. So it's ever-more important to be precise and to express yourself in some kind of standard way. We were just using English pretty organically. But of course, computers, as you may know, have some kinds of programming languages. But there's a generic one that we might call simply pseudocode. Pseudocode is not a formal language. There's no book about it. It's just a very general sort of casual way, but precise way when possible, of expressing yourself using as few words in English or your native language as possible. So let's consider an actual problem that isn't quite as messy as that. Here is an old-school technology called a phone book. It's increasingly dated, of course, and most of us-- these are hard to find, physically. But we'll use it as demonstrative of, frankly, a technology we're still using. All of us in this room probably have an iPhone or an Android or whatever that has a contacts application. And in your contacts are probably all of your friends and family and so forth alphabetically-- maybe by first name, maybe by last name. And all of those folks have phone numbers and maybe email addresses and more these days. So that's really the same thing, right? This is a physical form of that app these days, but I have a whole bunch of names, a whole bunch of numbers that are somehow alphabetized. So even though this problem is solved by computers more digitally, we can see it in the human world a little more graphically with this older format. So here is a phone book, and suppose I want to find an old friend of mine, like Mike Smith. I could certainly simply open the beginning of the book, look down at the page, and look for Mike Smith-- not there, obviously, because this is probably the A section. And so I might turn the page and look, turn the page and look. I'm still not seeing Mike. Maybe I eventually hit the Bs, but I'm not going to see Mike really until I get to the S section, for Smith, way back when. So this is correct or incorrect, this process for finding Mike Smith-- starting at the beginning and looking one page at a time? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, it's correct. It's kind of stupid, but it's correct. It's just very inefficient, because it's going to take me forever, especially when I know a little something about S in the alphabet. So at least I learned in grade school too, if I can do something faster, I could do it by twos-- so 2, 4, 6, 8, 10, 12. Still going to take me a while, but it's literally twice as fast. Is it correct? AUDIENCE: No. DAVID MALAN: No, why not, or kind of why? AUDIENCE: [INAUDIBLE] DAVID MALAN: Right, so it's a bit faster, but it's not fast enough, because if I counted this high by twos, we're still going to be here forever. AUDIENCE: You might [? skip Mike ?] [? Smith. ?] DAVID MALAN: Yeah, and it's also buggy, so to speak. A bug in a computer program is a mistake, something you didn't anticipate. And what if Mike, when I'm going by twos, just happens to be in between those two pages, such that I fly by him and never notice him? So at least I've got to have a little bit of a check here. If I hit the T section, definitely gone too far. So maybe I should backpedal at least one page to check if Mike is there. So it's incorrect if I'm just going by twos, but we can fix it by just going back a little bit in the phone book. But this, too, is naive and silly, even though it's correct. What would be the more intuitive approach that most of us use, if we ever do this anymore-- yeah? AUDIENCE: Flip it open to where you know [INAUDIBLE] probably be, and then go back [INAUDIBLE]. DAVID MALAN: Yeah, flip it open to roughly the section, and maybe I didn't go far enough. I landed in the M section, so roughly halfway through. What do I know about the problem in front of me right now? Where is Mike? AUDIENCE: [INAUDIBLE] DAVID MALAN: He's to your left side, or he's my right side. And so I know the M through Zs are here, and the As through Ms are here. But what's nice about this technology is we can literally tear the problem in half, which is very easy when you do it down the spine. You can tear the problem in half, throw half of-- if I may-- the problem-- sorry-- half of the problem away. But I'm left with now, fundamentally, the same problem, right? I might have had 1,000 pages a moment ago, but now I have the same problem. It's just half as big, 500 pages. And if I do it again, now I went a little too far. Now I'm in the T section, and so I can tear the problem in half again, find myself with a quarter of the problem-- 250 pages. And I can repeat, and I can repeat and repeat, until finally I'm probably left with just one page. So how much faster is this algorithm? Before, by twos, it didn't feel much faster. But can we quantify or describe how much faster this third algorithm was? What's happening every time I tear the phone book in half? AUDIENCE: [INAUDIBLE] DAVID MALAN: Say again? AUDIENCE: You split the problem in half. DAVID MALAN: I split the problem in half. And so that invites the question, how many times can you split the problem in half? I went from 1,000 pages, to 500, to 250, to 125, and so forth, as opposed to our first two algorithms, which was-- I went from 1,000 to 999, to 998, to 997, or even the second approach from 1,000, to 998, 996, 994, and so forth. It's still much, much slower. And we can visualize this as follows-- we don't need to get too formal here, but let me go ahead and pull it up as follows. Here might be a depiction-- let me dim the lights a little bit. Here might be a depiction of just an x, y graph where on the x-axis, the horizontal is the size of the problem. So the farther right you get, the bigger the problem, so the more phone book pages there are. On the y-axis or vertical I call it "time to solve." So that might be the number of seconds it takes you to find someone in the phone book. So the higher you go on the y-axis, the more time it's going to take. The relationship between size and time in the first algorithm is just linear. It's a straight line. And you can think of it as follows-- if Verizon or whoever the phone company is, tomorrow, adds one more page to the phone book because more people moved into New Haven, well, it's going to take you maybe one more step to find Mike Smith, because the phone book's one page longer. So there's this linear slope, a straight line. The second algorithm is still linear, because if Verizon adds two pages tomorrow, it's going to take you one more second. Or if they add one page, it's going to take you a half second. But it's this constant difference, so we still have this straight line. But notice the yellow line is below the red, because for a given size problem, which should be faster-- the first algorithm or the second algorithm? AUDIENCE: The second [? algorithm. ?] DAVID MALAN: The second, and the speed of the algorithm, again, is based on the y-axis. So because the yellow line is below the red line, that just implies that it's faster. There's less time required for the second algorithm. But what's amazing about that third algorithm-- which, frankly, all of us probably intuitively would have done in the first place, had I not coaxed us through the more naive approaches-- looks like this. This green line, among the three, is the best objectively, in so far as it's a fundamentally different shape. Notice it's not even a straight line. It's curved, and though it looks like it's kind of flattening out, it never actually flattens out. It just grows ever, ever more slowly the bigger the problem gets. But it requires massively less time. Why is that? Well, in this third algorithm, Verizon, for instance, tomorrow could double the size of the phone book. Instead of 1,000 pages, they may be merged the town over, and so it's 2,000 pages in the phone book. That's huge, but how many more steps is it going to take if you're dividing and conquering the problem by tearing the phone book in half? It's going to take just one more step. And if Verizon quadruples the size of the phone book, no big deal-- two more steps. Put another way, let's consider a ridiculously large phone book. If you've got a phone book with, like, 4 billion pages, which is huge, how many times might I have to tear a 4-billion-page phone book in half before I'm left with one page, on which Mike Smith is or simply isn't? Well, how many times can you divide 4 billion in 2? 4 billion, to 2 billion, to 1 billion, to 500 million, to 250-- we could keep going, but I'm pretty quickly going to get to one page, because you can only divide 4 billion roughly 32 times before you're left with just one page. And that's where computer science, and that's where algorithms start to get interesting and powerful, but also accessible. This intuition you've long had is already something you have a grasp over for solving problems. It's just a matter now of deploying these ideas in the context of computers and deploying them in the context of a computer that you can be ever so precise with, per this mention of pseudocode. What would it mean for me to solve that problem a moment ago? Well, let's not just talk about it. Let's actually apply a couple of steps more methodically in an English-like syntax, pseudocode. My first step, otherwise known as 0-- and computer scientists tend to number things at 0, just because that's the lowest you can count, instead of our more human convention of 1. Pick up the phone book-- just do this. It's an action or a verb. Step 1, open to middle of phone book. That's what I did for that third algorithm too. Step 2, look at names-- that's a third action I did. If Smith is among names-- now, this phrase is fundamentally different from the first three. It starts with the key word if, so this is kind of a decision point. If Smith is among names, maybe do this, and if he's not, maybe do this. So it's like this proverbial fork in the road, or a condition, or a branch. And so we're going to call Mike if he is among the names on the page. And I've indented it here, as is common in programming, to imply that you should only do step 4 if step 3 is applicable-- is true, so to speak. Otherwise, step 5, if Smith is earlier in the book-- to the left, so to speak-- what should I instead do, if Mike is to the left of the book? AUDIENCE: [INAUDIBLE] DAVID MALAN: Say again? If Mike is to the left-- AUDIENCE: Rip the book in half [INAUDIBLE].. DAVID MALAN: Yes, rip, right, so before I do the ripping, jump to the middle of the left half, open to the middle of the left half of the book, and then go back to step 2. Rip, because I've already done that in the past, so if I go back to step 2, that's look at names. So I've jumped to the middle of the left half, and now I'm looking for Smith again. So that's when I said earlier, it's the same problem. It's just gotten a little smaller. You can still use the same algorithm, the same process, or the same code. Else, if Smith is later in the book, to the right, what do you want to do instead? You can open to the middle of the right half of the book and then go back to step 2 again, look for Mike. You've divided the problem in half. Else, what's this final branch in the road? If he's not among the names, and if he's not to the left, and he's not to the right, AUDIENCE: [INAUDIBLE] DAVID MALAN: He's not there, and so we might as well just give up or quit the program altogether, so four possible scenarios. And again, if you've ever seen your phone or your computer just have a spinning beach-ball or it freezes or does something unexpected, maybe it's simply because that program, or a Google, or Facebook, or wherever just forgot that there's four possible scenarios. Maybe he or she only thought of three of them or two of them, and so when you don't think about all the possible cases or scenarios, undefined behavior might happen. Computer might crash, computer might hang, or something else all together. Now, in reality, this pseudocode could be written in any number of ways. But what I've highlighted here in yellow is a few of the fundamental constructs that you'll see in pseudocode, in C, in Python, in Scratch and other languages still-- pick up, open to, look at, call, open, open, quit. These are verbs. These are actions. Henceforth, we're going to call them functions. These are built-in capabilities of a computer that allow you to just do something actionable. In yellow now are different keywords if, else if, else if, else, and these are the keywords in many programming languages via which you make decisions. You go left or right, or you choose some other fork in the road. Now in yellow here is what we're going to call a little more fancifully Boolean expressions, named after, literally, a person named Boole. And Boolean expressions are simply questions that have yes or no answers or, more geekily, true or false answers. So for instance, Smith among names, question mark-- true or false, he either is or isn't, yes or no, true or false, 1 or 0, if you will. If Smith is earlier in the book, that too is a yes/no or a true or false question. It's a Boolean expression, and same for the other things in yellow. And then lastly, we have this. Go back to step 2. There's different ways, as we'll see, of expressing things that happen again, and again, and again. But this is perhaps the most literal-- go back to step 2, where you already were. And just conceptually, that suggests you're going to do something again, because you're going back in your sets of instructions. So with that said, let's transition now to actually using this programmatically, writing a program. Now, in just a few days' time, our programs are going to pretty quickly look like this, which is the Greek to which I alluded earlier. This is a programming language called C. And C is a fairly arcane or traditional language. It's purely textual, uses a lot of funky punctuation like curly braces, and parentheses, and semi-colons, things that you might not type super commonly. But they've probably been on your keyboard all this time. But even though this might not look familiar to you, if you've never programmed before, just take a guess. If you've never programmed, what does this program, once run on a Mac or PC, probably do-- yeah? AUDIENCE: [INAUDIBLE] DAVID MALAN: Oh, sorry, go ahead. AUDIENCE: It says, "Hello, world." DAVID MALAN: It says, "Hello, world." I don't quite know what printf means, but it sounds like print. And so printf hello world probably does exactly that. It shows the phrase "Hello, world" on the screen. And indeed, that's exactly what it does. But for now, let's actually do things a little more graphically, not to make things unnecessarily childlike, but because it allows us to now not worry about the parentheses, not worry about the curly braces, the semi-colons, all of these frankly stupid syntactic details that get easier and more familiar after some time. But the ideas needn't be-- they needn't be a distraction in the face of ideas. This is, in a programming language called Scratch, the equivalent program. So our friends down the road in Cambridge at MIT's Media Lab have a group called the Lifelong Kindergarten group. And this is a research group that some years ago created this graphical programming language called Scratch. And it is assembled via these puzzle pieces that have puzzle-piece-like shapes to them that you can drag and drop and interconnect in order to make the computer do something. And specifically, if I go ahead and open this up, you'll see here-- the program itself, Scratch, it turns out it exists in two forms. There's a downloadable version, which I tend to use on my computer in class, just so that we don't have Wi-Fi issues. But you can also go to scratch.mit.edu, which you will for the course's first homework assignment, problem set 0. And you'll see this user interface, whether you're online or offline. In the top left-hand corner here-- let me just dim it for a moment-- you'll see the so-called stage for Scratch. This is his little two-dimensional world, and cat is the character by default that we can manipulate. It's a sprite, so to speak, a character in a computer program. And he can move up, down, left, right and do other things too. In the middle is a palette of all of our puzzle pieces. And if I zoom in here, you'll see a few things. This puzzle piece says move some number of steps. This puzzle piece says turn some number of degrees. If I zoom out and go to Control, which is just a different category and color of blocks, notice some other blocks-- Forever, and Repeat, and Wait, and If. And even though these might not be wholly familiar, you can probably just kind of use your intuition to understand what these things are doing. And even though they're a fixed size, we'll see that they can grow to fill shapes. So I'm going to do this, and it's quick for me just because I've done this before. But if I go to the Events category and drag this piece-- when green flag clicked-- this is a special puzzle piece that starts the program, because as you can see, at top left there's a green flag, and there's a stop sign. Green flag means go. Stop sign means stop, and that's how you can start and stop a program written in this language called Scratch. So literally, when the green flag is clicked, I want the program to do something. I want it to do something pretty simple, so I'm going to do this. I know from having tinkered before that the Looks category has things like this-- "say hello"-- and I'm going to double-click on the white box there and say "hello world." And let me go ahead and zoom out, and now if I click the green flag, I've written my first computer program. It's not all that interesting, but I didn't have to type anything out on the keyboard. All I had to do was drag and drop these puzzle pieces, and it actually did something for me. Well, let's go ahead and do something a little more interesting. But first, we need a few more constructs. So let's just introduce some of the fundamental pieces that we have at our disposal. I said earlier, we have functions or actions, like verbs. We have conditions, like forks in the road-- Boolean expressions, which, just to be sure, are what? AUDIENCE: [INAUDIBLE] DAVID MALAN: Yeah, just true/false statements-- it's a question that has a true or false, or yes or no, answer. Loops, things that happen again and again-- there's even more features to languages like this-- variables like in algebra, x, and y, and z. You can actually store values, so you can count up and down and do other things with them. Things called threads-- turns out programs and computers can kind of sort of do multiple things at once in any number of different ways. And that's great because, frankly, it's nice to be able to check your email while something is printing or someone is sending you a Facebook message in another window. Computers can give the illusion at least or actually do multiple things at a time. And threads are generally the feature of computers that make that possible. And then there's events, like sometimes you get a little notification in your browser or on your Mac or PC, saying you've got new mail, or you've got a message, or any other kind of reminder. And those events can get triggered too. So these are all things you've seen on your computer, but we can now express them in a language like Scratch. So let's take a look at a few samples. This purple puzzle piece here is like printf a moment ago, in that language called C, which we'll come back to next week. But "say hello world" shall be, henceforth, a function. And functions, it turns out, can themselves take input. It's like a mini program. The input here is whatever's in that white box. And as we guessed earlier, when you print something or say something, the output is something visual on the screen. Maybe it's in a window on your computer or on Scratch's stage, so to speak. So a function does some action, but we can do this conditionally. Here I've taken two puzzle pieces, one of which is kind of wrapping the other. And I'm saying if x is less than y-- I have no idea in this context what x and y is, because it's just an example. But suppose x is a number and y is a number, and I ask the Boolean expression, is x less than y? That's true or false. And if it's true, go ahead and do what's, effectively, indented inside of it. Previously, I used the space-bar for the black-and-white code for finding Mike Smith. Here you just physically have a yellow block, and then you have the purple block here, indented a little bit to the right. You're only going to say x is less than y if, indeed, it is mathematically. You can do fancier things. You can nest these things. And earlier I said you can actually grow these blocks, so they don't have to be this big. They'll grow to fit whatever you put into them. So you can take multiple if/else blocks, and an if/else is like a two-way fork in the road. But if you put a two-way fork in the road inside of a two-way fork in the road, you can effectively make it a three-way fork, just as I've done here. If x is less than y-- say x is less than y-- else, if x is greater than y, say x is greater than y. Else, it must be the case logically that they're equal, and so that's the third and final case there. What else can we do? This is the Boolean expression on its own, out of that context. You can do specific numbers, like is i some other variable less than 50? You can forever say hello, just keep saying hello, world; hello, world; hello, world; hello, world; ad nauseum, never stopping. Or you can do it just 50 times or any number of times. The Repeat block lets you type in a number there. Set i to 0-- this is an orange block that lets you define a variable. x or y or z or i is very common, because it's an integer or a number. And you might start counting at 0, and then 1, and then 2. You might have two of these things. If you want your program, as we'll see, to do multiple things at once in parallel, so to speak, we'll just attach some of the blocks to the left, some of the blocks to the right, and let the computer do both at the same time. Meanwhile, there's this, a fancier feature still-- one sprite, one character can actually broadcast a message sort of inaudibly in some sense, and the other can receive it or hear it, as though they're whispering to one another. So one program or one cat could communicate with another on the screen too. So there's a way to make even fancier programs still. So if we take these all together, we get some pretty cute results. For instance, if I go ahead and make a new program here-- File, New-- I'm going to go ahead and grab a "When green flag clicked." This time I'm going to go to sound and drag this-- "play sound meow." And notice how it works. They're sort of magnetic. As soon as you get close enough, a little white bar appears. And if you let go, they snap together. And if I now click the green flag-- [COMPUTER MEOWING] -- you get a very sickly cat on these speakers. [COMPUTER MEOWING] OK, this is not really a good program if every time I want the cat to emote, I have to start the program again. I could instead do something like this, Control, and just do this forever. [LAUGHTER] No, not good? OK, well, here, if you don't like that one-- meow-- OK, that's what meow looks like on a wave form-- my meow. So now I can change it. Sometimes the blocks have little drop downs, so you can change their inputs or their parameter, so to speak. [RECORDING OF DAVID'S MEOW PLAYS] OK, that's no better. OK, but it's a better program written that way than it would be if I instead did this. A sort of a lazy approach might have been to do this if I wanted it to keep playing the same sound. But this, of course, kind of looks stupid, and indeed it is. There comes a point, and it's not necessarily always a well-defined point, but where a smart person is going to look at your program and say, hmm, it's correct. It does meow, what, five times. But it's not well designed-- we can do better than that. And to do better, I could do it forever, if that's really my goal. Or I can go repeat, say, five times, grab just one of these. And notice, it grows to fill. And this now would be a better-designed program. But now, we can very quickly escalate things and go to a fancier program. In fact, just for old time's sake, let me go ahead and open up one program that I, myself, wrote the very first time I saw Scratch years ago, which is this one here. Could we get a quick volunteer? You don't need to say too much. You just need to be really good at picking up trash with an adorable song. Come on up. What's your name? TUCKER: Tucker. DAVID MALAN: Tucker, come on up, Tucker. All right, so you'll see here a game that, frankly, took me all day. So it didn't just come out-- nice to meet you-- like meowing a few times did. But you'll see that it's made up of a whole bunch of pieces. I'm going go ahead and full-screen it here, just so we can see it a little better. [COMPUTER PROGRAM - MUSIC PLAYING] And your goal is to drag and drop the falling trash. And let's consider, as Tucker plays this game, what it is that's happening. So there's probably some kind of loop that's making the trash fall, right? How does trash fall? That's just a picture, in this case, of a shoe. And it's really just moving maybe one pixel at a time, one dot on the screen at a time. But if you do it again, and again, and again, just like one of those old-school flip books, you can create the illusion of animation, having a picture move, and move, and move. Meanwhile, Tucker is using my track-pad and the mouse, really, and he's clicking. So the computer is listening. If clicked on trash, do something different. Follow the mouse to the trash can. Meanwhile, Oscar is clearly counting. How is he counting? He's probably got a variable-- x, or y, or z, or i, or whatever. And indeed, I had a puzzle piece that's a variable that's counting up, and up, and up. And of course, finally, there's probably a condition-- any time Tucker is dragging the trash over to Oscar's trash can, the lid is popping up. So what is that? That's a branch in the road. If trash touching trash can, change the picture to look like the trash can is actually above the trash can. OK, the song goes on forever, so maybe a round of applause for Tucker here. [APPLAUSE] Very nicely done, here you go, here. TUCKER: [? Thanks. ?] DAVID MALAN: As you'll soon learn, one of the inherent aspects of programming, whether you've been doing it briefly or forever, is debugging-- finding mistakes in your program. And I swear to god, all these years later, I still remember playing that song for like 12 hours on loop, trying to get all of the timing right. Thankfully, most of the programs we write won't have quite as much sound. But we can do things now incrementally. And indeed, I didn't just sit down and write Oscar Time. It took me hours. But what I started with was, how do I make a piece of trash fall? I just had a big, white, empty window, and I downloaded a piece of a trash icon or something, or maybe it came with Scratch. And I just had it start at the top of the screen, and it turns out there's puzzle pieces that let you position things at an xy coordinate, like up here and over here. And then I just had it move one pixel, move one pixel, move one pixel. And I put it in a Forever block, so it just did it on its own for me. And I had a condition that said if the trash is touching the bottom of the screen, stop falling, because it would be kind of an annoying game if the trash just kept falling, and you could never pick it up. So at some point, you have to stop the animation too. So that was one step in that process, or one building block. And once I figured that out, I added something else. I probably added Oscar at that point, because it was just adorable. And I figured out, how do I make his trash can go up and down, up and down? It looks like animation, but really that's just two or three different pictures. And when Tucker was moving his mouse over the trash can, I changed the picture from the default one, where the trash can is closed, to one where the lid is open, to a third one where Oscar is popping out of it. And that's all animation is, is a sequence of images. It's a sort of a simple video, if you will. So what are these kinds of building blocks that we can actually do? Well, let's open just a few of these here. We have on the course's web site a few examples that you can play with later, beyond the ones I just made. But if I go ahead, for instance, and open up this one, Counting Sheep, you'll see that you didn't have just cats in your world. You can have this adorable guy here. And it's a pretty simple program, and it's kind of a re-take on the notion of counting sheep. This time, it's a sheep counting. And what is he doing? Well, let's just zoom in on his program, and that's, indeed, what these puzzle pieces are. When green flag clicked, set counter to 0. Counter is apparently a variable, and it's a better name, frankly, than x or y or z, which has no meaning to really anyone. But Counter is more descriptive word, so that's better design. Forever just means keep doing the following-- do what? Say Counter for one second. So I don't have to hard code a word like "hello." I can drag the Counter variable block so that it prints out a number. I can wait one second, change the counter by one, by incrementing it by one, and then just let it repeat. And so now I have a sheep that's counting in perpetuity. We can add this example, a little bit of interactivity now, with Pet the Cat. So this is an unnaturally sounding cat at the moment, but notice nothing's happening here. But if I zoom in, what should be happening, or how can I make something happen on my screen-- yeah? AUDIENCE: If you move the mouse to the [INAUDIBLE] then the cat might start meowing. DAVID MALAN: Yeah, if I move the mouse to the cat, it seems to start to meow. So let's try. Here we go. [COMPUTER PROGRAM MEOWING] Yeah, so it's Pet the Cat, in the sense that as soon as the mouse touches the cat, he's meowing. So what about Don't Pet the Cat, which is another take on things? This one looks like this, similar appearance. [COMPUTER PROGRAM MEOWING] But there's a forever loop that, by default, is meowing. And I realize this is annoying, so let's quickly not pet the cat by moving closer, and closer, and closer. [COMPUTER PROGRAM GROWLS] OK, so don't pet the cat. Well, how did that happen? Well, this time there's a two-way fork in the road. If touching cat, play the lion sound-- else, just play the cuter meow sound. So it's an interactive program this time, because I'm actually detecting the presence of that mouse. I can take things one step further. In threads here-- which, a thread is just-- a computer can use multiple threads, so to speak, to do multiple things at a time. Here we have a bird and a different cat, and you can kind of infer that the cat is using AI, artificial intelligence, to figure out the bird. And that's kind of an overstatement, because it's really just pointing himself perpetually at the bird. [COMPUTER PROGRAM GROWLS] OK, but he honed in on the cat as follows-- notice, down here I now have two sprites. In the past examples, we've just had one, but you can have two, just like Oscar Time did. And the bird, notice, is just going in some specific direction at first. I just tinkered with this-- negative 150, positive 150. That's just the xy coordinate on the grid. Point in a 45-degree direction, and then forever, if you're not touching the cat, move three steps. And then if you're on the edge, bounce. So this is just the bird kind of futzing around, and if he hits the edge, he bounces. But he's completely not aware of the cat until he's actually touching it. But I can change this. What if I make the bird go 10 steps at a time? You'd think he kind of has the advantage, but not really, because the cat's program-- if we zoom in on this-- is to do what? He starts off in a random direction. This computer program, like many, can use random number, sort of guess a number, so to speak-- more on that down the road. If touching bird, play the lion sound and then stop. Else, he's kind of cheating with that blue puzzle piece-- point toward the bird, and then move one step. It's one step, though. That's pretty slow. What if I give him a bit of an advantage? What if I stop the program? Let's give him 20 steps at a time. [COMPUTER PROGRAM GROWLS] And the program executes much more quickly. And we can do one final example here involving what are called events, whereby one script can signal, somehow, to another as follows. If you've ever played the game Marco Polo, you might have had this. If I hit the space-bar, the little purple Muppet says Marco. And then the blue one says Polo, without me hitting the space-bar again. What's going on? It's a simple idea, but let's see the orange Muppet's scripts first. Forever do the following-- if the key space is pressed-- so a weird way of saying, if the space-bar is pressed, then say Marco for two seconds. And then broadcast an event. And I could have called the event anything, but it's like this whisper, so to speak, that you can't hear, we can't hear, but the computer sprites can hear. And it's broadcasting it, waiting for another sprite or character to hear it. And indeed, if I go to the blue Muppet here, when he receives that event, that whisper, go ahead and say Polo. So it's not the same program. They're fundamentally independent, but these processes are somehow intercommunicating. And that's ever-important too with software today, where you want one program to interact with another so that your software can do fancier and fancier things still. Now, let's look at one final idea that comes full circle, back to the notion of functions, because it's not enough to just implement a function. There's good ways and bad ways to do it, and we'll see that this is demonstrative of the kind of sophistication we'll soon have in another language like C. Here is a program that simply has the character on the screen cough three times-- cough, cough, cough. This is correct, if my goal is to have him cough three times. But I would argue it's not well-designed-- why? Why is it not well designed-- yeah? AUDIENCE: [INAUDIBLE] use a loop. DAVID MALAN: Yeah, I can use a loop, right? Why use six blocks when I, instead, could use two or three if I just use a looping construct? So let me open a different example. That was cough 0. Let me open cough 1, which looks a little different, but is much tighter, so to speak-- it's better-designed code that still does the same thing. If I click the green flag, it's cough, cough, cough, but I'm using less code. It's, therefore, easier to read and it's easier to maintain. If I want to repeat this now, not 3 times, but 10, I don't have to copy and paste a lot of blocks or code, so to speak. I can just change that number. But you know what? There's an opportunity to kind of factor code out, and we'll see this more and more in the weeks to come. There's an opportunity to now do this-- a custom block. Now, notice this. Let me drag this off the screen for the moment and claim that this is the program. When green flag is clicked, repeat the following three times-- cough. That's interesting, but the purple block there did not come with Scratch. I invented it myself by using the More Blocks category here. And what I did was dragged and dropped the requisite pieces to give me this construct, this design-- define cough. That's the name of my new verb, the name of my new function. And its purpose in life is to do two things-- say cough for one second and then wait for one second. Henceforth, I can abstract that idea away. I don't know how cough is implemented. I wrote this like a year ago, no recollection, and that's fine. I can literally hide it off the screen, because the name is descriptive enough and abstract enough that I don't care how this thing coughs. I just want it to cough. And so again, to this point of layering, and layering, and layering-- we started with electrons and 0's and 1's today, and we're already now, in some sense, at the level of coughing, which has a very well-defined meaning. If we really dug into it, we could really define it formally. But we don't care, because it's a useful abstraction, a generalization that communicates a shared idea that all of us here understand. So I thought we should do one thing here. That last game wasn't quite as interactive as would be ideal, and one of our favorite games was written in the very first year of this offering. One of your predecessors thought it would be fun to make something a little competitive. And for this, we have an opportunity for one final volunteer today before we conclude with a summary and a teaser. Yeah, what's your name? [? ABEERAH: ?] [? Abeerah. ?] DAVID MALAN: Ameerah? [? ABEERAH: ?] [? Abeerah. ?] DAVID MALAN: [? Abeerah, ?] come on up. Come on up, [? Abeerah. ?] So here we have "Ivy's Hardest Game" remixed by one of your predecessors-- and [? Abeerah, ?] did you say? [? ABEERAH: ?] Yeah. DAVID MALAN: OK, come on up, nice to meet you. [? ABEERAH: ?] Nice to meet you. DAVID MALAN: The goal here is to navigate your way through a maze of sorts, per the instructions we're about to see. [COMPUTER PROGRAM - MUSIC PLAYING] [AUDIO OUT] So the goal is to get Yale through the maze. And again, consider-- we want to make this a little academic-- what's happening. She's hitting the mouse key, so there's probably a loop listening for the mouse key or the arrow key, instead of the space-bar. And it's moving the character for as long as the [? Abeerah ?] is holding down the right arrow or the left arrow-- nice. [COMPUTER PROGRAM - MUSIC PLAYING] Nice, and presumably, the Yale icon is moving more steps, more pixels at a time. And that's why it's faster than that Harvard shield. [COMPUTER PROGRAM - MUSIC PLAYING] [AUDIENCE GASPS] Very nice, notice we have two variables-- Level, at top left, and Death, currently at 0. Oh! [AUDIENCE GASPS] We don't care about 0. [APPLAUSE] Very nice-- there's some randomness there. He's just kind of moving around. [LAUGHTER] He seems to have a condition that says if near Yale, move away. [LAUGHTER] Nice. [? ABEERAH: ?] I don't like this game. [LAUGHTER] DAVID MALAN: Princeton seems to be picking a direction. [AUDIENCE GASPS] Notice her variable of Death got incremented. Nice, two Princetons, so the sprite has cloned itself or duplicated itself-- second-to-last level-- nice. [AUDIENCE GASPS] [? ABEERAH: ?] [INAUDIBLE] DAVID MALAN: Oh! [? ABEERAH: ?] [INAUDIBLE] DAVID MALAN: All right, a big round of applause for [? Abeerah. ?] [APPLAUSE] Very nicely done, here you go. Here you go. We'll post a link online so that you can take a look at that as well. Before I turn things back over to Benedict, just a couple of final remarks-- one, for 10 years we've had a tradition of ending class with cake, which is a nice opportunity to get to know some of the TAs and CAs, all of whom will greet you outside if you have a few minutes in just a moment. But we also wanted to paint a picture in words that the syllabus elaborates on, that you have in your hands, of the support structure in this class. It's undoubtedly a lot of work and challenging for many students, but you'll have at your disposal innumerable resources, among which we see here. And then there's also, finally, this cultural aspect to the class, more than just a typical class, we hope. We hope that you find this, ultimately, to be a shared experience and really a community of students, 68% of whom are in the exact same boat as you. And by way of a number of events and traditions that we've carried on for some time in both Cambridge and now New Haven alike, will you experience some of these opportunities ahead. [VIDEO PLAYBACK -- MUSIC PLAYING] BENEDICT BROWN: Meow, meow, meow-- so thank you all for coming. Those of you who came in a few minutes late, I'm Benedict. I am the instructor lead here at Yale, and, again, I encourage you all to come on Thursdays during this time slot. I'll be talking about things related to the material we're doing, but not specifically how to go over your homework. We will have times in office hours for that. But I also wanted to tell you, just quickly, a couple of things. Next Thursday what I'll be talking about is how to be successful in CS50. If you've heard from your friends, oh, this is an impossible class-- it's 20 hours a week-- there are ways that this gets much better, understanding the best ways to use the resources of office hours, of the website, of all the different aspects of the course. So especially if you're one of the 68% of students who have no previous programming or computer science experience, and also for all of you who are freshmen, I really, really strongly urge you to come to this. You will find it helpful. It will save you a lot of time and learn more to navigate the course. Also, we have not posted the regular office hours for Natalie and me yet, and we won't start the office hours in the library before homework 0 is due. Now, this is in Scratch. It's a lot of having fun and exploring. But Natalie will be holding office hours tomorrow. And if it's busy, I will join her from 11 o'clock to 2:00. That's tomorrow in the computer science building, which is called AK Watson hall, and it's right around the corner on Prospect Street, 51 Prospect Street, in room 201. So if you have any questions about the class, any questions about P set 0, feel free to stop by. We'll look forward to meeting you and talking with you. And now it's time for cake. [APPLAUSE]