[MUSIC PLAYING] [APPLAUSE] DAVID J. MALAN: This is CS50, Harvard University's introduction to the intellectual enterprises of computer science and the art of programming. Now if you are among those that every year are sitting here with a bit of nerves in your mind, such that you don't think you belong here, you think that most anyone sitting around you knows far more than you, is indeed more comfortable than you at computer science or computers more generally, realize that 78% of the students who now take CS50 have no prior experience. Indeed, there's 100 dots there on the display, 78 of which are solid green, which means you, if you're among that demographic, are in very good company here on out. And if you are instead among the 22% of CS50 students who do indeed have prior experience, whether in high school or some other program, realize that you, too, will be challenged in the course. Not only do we have different tracks for students less comfortable and more comfortable alike in sections, we also have so-called hacker editions of most problem sets that will challenge those students with that additional experience to explore similar material but from a more sophisticated perspective. But what is computer science? Well, ultimately, what's going to matter as you explore this field is not so much where you end up relative to your classmates, but where you yourself end up in week 12 versus where you begin here in week zero. Now computer science-- well, let's call it the science of computation-- where computation is really just a fancy way of saying, taking some input, producing some output, and doing so by running algorithms, sets of instructions for solving some problem on those inputs in order to produce some output or solution in which you are interested. So we recently had occasion to travel out to California to meet with an alumna. Her name is Susan Wojcicki. And she'd like to speak to you here on video to testify to just how applicable even just a taste of computer science at the introductory level can be. Even if you don't go on to pursue computer science as a field, or even engineering, or STEM more generally, you'll see, in fact, how a certain course so influenced her life. And she only just took it when she was a senior here at Harvard College. If we could dim the lights for Susan. SUSAN WOJCICKI: Hello, world. I'm Susan Wojcicki. I'm the CEO of YouTube. And I took CS50 when I was a senior at Harvard in 1990. I was actually a history and literature major. And my junior summer, I realized that maybe I wanted to learn something about computers. And so, I came back. I took CS50. It was hard, but it was the most amazing class I took. It changed how I think about everything. And when I graduated from Harvard in 1990, I went to Silicon Valley. And I got a job. And I've been working in tech ever since. DAVID J. MALAN: Now what Susan didn't mention in this video, that it was actually in her garage that Google itself was founded by Larry and Sergey. Now we also reached out to our friends at code.org, an organization that over the past year has been getting people particularly excited about computer science and programming, in particular. But it's worth noting that programming is not computer science per se. Computer science is not programming. Rather programming is just a tool-- with which all of you will be all too well familiar by semester's end-- such that you can apply not just to future courses in CS but to whatever fields from whence you're coming, in humanities, social sciences, natural science, or the like. Indeed, allow a few other alumni and their colleagues to speak to the applicability of the field that awaits. BILL GATES: I was 13 when I first got access to a computer. JACK DORSEY: My parents bought me a Macintosh in 1984 when I was eight-years-old. MARK ZUCKERBERG: I was in the sixth grade. SPEAKER 1: I learned to code in college. RUCHI SANGHVI: Freshman year, first semester, Intro to Computer Science. BILL GATES: I wrote a program that played tic-tac-toe. DREW HOUSTON: I think it was pretty humble beginnings. I think the first program I wrote asked things like, what's your favorite color? Or how old are you? ELENA SILENOK: I first learned how to make a green circle and a red square appear on the screen. GABE NEWELL: The first time I actually had something come up and say, hello, world. And I made a computer do that. It was just astonishing. MARK ZUCKERBERG: Learning how to program didn't start off as wanting to learn all of computer science or trying to master this discipline or anything like that. It just started off because I wanted to do this one simple thing. I wanted to make something that was fun for myself and my sisters. And I wrote this little program. And then basically just added a little bit to it. And then when I needed to learn something new, I looked it up, either in a book or on the internet, and then added a little bit to it. DREW HOUSTON: It's really not unlike playing an instrument or something or playing a sport. DAVID J. MALAN: All right. So let us now actually dive in a little deeper. What are these inputs and outputs that we're talking about here? So how about something simple? You probably know, even if you have no familiarity with computer science whatsoever, that computers somehow use and understands only zeros and ones. But how can that possibly be given how much today's desktops and laptops alike can do? The DNA of the day, the only alphabet that they understand is a zero or a one. Well, consider this. We, humans, tend to use the decimal system. "Dec" meaning 10. And that's 10 because we have 10 digits, 0 through nine. Now computers, by contrast, tend to use binary. "Bi" meaning two. So they tend to use only zero and one. But it turns out, that even just with zeros and ones, that is a sufficiently large alphabet with which to represent most any piece of data you want, whether it's a number, whether it's a letter, whether it's a graphic or video on the screen. Consider, for instance, how we humans typically interpret this number here. This is just three digits, one, two, three. But we know this number innately now as 123. But why is that? Well, if you think back to perhaps grade school, you probably were taught to think of these numbers as being in columns, where the one is in the hundreds place, the two is in the tens place, and the three is in the ones place. Why is that actually useful? Well, think about the super simple arithmetic that we all have been doing for years now. Effectively, if you've got a one in the hundreds place, you do the quick math 100 times 1 plus 10 times 2-- because two is in the tens place-- plus 1 times 3-- because three is in the ones place. So, of course, if we actually multiply this out, what we're really representing with this pattern-- one two three-- is 100 plus 20 plus 3, which, of course, is 123. Now binary, and computers really, fundamentally speak the same language that we do. They just have a smaller alphabet. So computers only have zeros and ones at their disposal. So whereas we humans have essentially powers of 10 in each of these places-- 10 to the zero, 10 to the one, ten to the two, giving you 110 and 100 respectively. Because computers only have two values they can understand, zero and one, they have to use different values in these columns, one, two, four. And if we kept going, eight, 16, 32, 64, and so forth. But the pattern and the mentality is exactly the same. So by this logic, anyone, how would I go about representing the number one in binary? If you've never even thought about this before, what's your gut say? AUDIENCE: One. DAVID J. MALAN: One. Exactly. We just need a one in the ones place because the zeros suffice to give us neither a four nor a two. So one times one equals one. Now things get a little interesting. If I want to represent in binary the number two-- but, again, even if you've never spoken this language before, how do we represent in binary the value we humans know as two? Zero one zero. Just put the one in the column that you want it. Now it's getting pretty easy probably now. So if I want to represent three-- there is no three's column. So, again, I can now add these values together by putting a one here. So 2 times 1 plus 1 times 1 is, of course, 3. Now things get a little fun in that the ones now become zeros. And to represent four, I get this. And if we increment slowly here-- that would be five. This would be six. This would be seven. But now I seem to have run into a problem. How might I go about representing eight-- would be the next value. Yeah, so we need a new bits. And, indeed, if you've heard this phrase before, bits, that's just short for binary digit, zero or one. And so I happen to be representing only three such bits here. But if I had a way of storing not three different bits, but four, surely I could represent eight, and then nine, and then 10, and even higher and higher. But that then calls into question how we can go about representing these things in the first place. It's one thing to draw them up here on a slide, but how do you represent them if you're a mechanical device? What is a computer doing to represent the inputs and outputs that fundamentally define computation at the end of the day? Well, what about something super simple like this? It's just a light bulb. And I can trigger this light bulb to go on by turning some electricity on and allowing electrons to flow through, which changes its state or its value, so to speak. For instance, this is an old school desk lamp here with one such light bulb inside of it. And right now it's not really doing anything useful. But as soon as I plug it into an electrical socket and then use this switch-- or we can even call it a transistor or think of it as such-- I can now represent either this value, where the light bulb's obviously off, or this value. This value or this value. This value and so forth. So inside of a computer, presumably, are much smaller pieces of hardware, but that at the end of the day simply have to use electricity-- perhaps capture it-- and then either keep something on or keep something off. Of course, this isn't particularly interesting to do with just a single light bulb. In fact, how high can I count in binary with this desk lamp here? AUDIENCE: One. DAVID J. MALAN: One, right? I need more desk lamps if I actually want to count higher. But we can do better than that. Because the light bulbs that we've put in these things are actually fancier light bulbs than yesteryear would allow. And they're actually networked light bulbs. And bunches of companies make these things these days. But it turns out that this one in particular comes with a feature whereby you can change its colors. So for instance, if you adorned your dorm room with a few of these light bulbs, depending on your mood, depending on who comes in, depending on the weather, depending on the time of day, you can actually change the colors of the bulbs in your room. And that's because these light bulbs and others like it have what's called an API, an application programming interface, which is a topic with which you'll be well familiar with by semester's end. And this is just a fancy, cryptic way of saying, you can program these light bulbs to do your bidding. You can send them messages just like you, a human, can send a message to a web server saying, give me today's news or give me my email. You can send more arcane messages to these light bulbs to say, turn on and turn off. But that's not all that interesting. You can say, turn on red, turn on green, turn on blue, all with the same light bulb. And you can even, with a bit more savvy, say, turn yourself to blue when it's a gloomy day outside, for instance. It can actually patch into a weather API and find out what the weather is, or the time of day, or other such triggers. So, in fact, two of CS50's own staff members, Dan Bradley and Ansel Duff here, kindly procured us a whole bunch of these light bulbs. And they built CS50's first ever binary bulbs, where we've represented here-- with these playful little magnets-- the various placeholders we alluded to just a bit ago. So way over here is the ones place, two, four. And we didn't see higher than that. But, of course, they're powers of two. Eight, 16, 32, 64, and 128. So if I now want to be a little fancier than using this old school switch, I have here on this iPad a super simple interface that Dan Bradley, a former student and now teaching fellow, programed using some HTML and JavaScript, which are markup and programming languages respectively. And you can probably see-- even in the back-- there's a big plus and a big minus, plus one button for each of these bulbs. And what this is going to allow me to do is, for instance, click the plus and now represent, of course, what number? One. And I can hit it again. Two. Three. Four. Five. Six. Seven. And here now we get that rollover, but we have a fourth bit this time, so now we have eight. So we could do this for quite some time. In fact, as an aside, how high could we count? Anyone? AUDIENCE: 255. DAVID J. MALAN: 255, right? Don't worry too much about the math for now, but that's a pretty decent number. But it actually does bound just how many pieces of information, like a letter, or a graphic that we could represent. But no matter for now. I'm going to go ahead and turn them all off. And if I could, I'd like to ask for a volunteer, our first volunteer-- oh, hello-- on stage. The catch is you have to be comfortable appearing, as you clearly are in front of all your classmates, as well as on the internet. And let me look a little beyond the-- how about here in the white shirt? And hand up. Come on up. What is your name? AUDIENCE: Jackie. DAVID J. MALAN: Jackie. Jackie, come on up. So what there is also on this iPad is a button called Game Mode. And this Game Mode is going to allow me to input in advance a particular decimal number, the numbers we humans are familiar with. And then you will be challenged here to use the buttons on the top-- one for each of these bulbs-- to actually figure out the pattern of light bulbs that represents the number in question. And I'm sorry, what was your name again? AUDIENCE: Jackie. DAVID J. MALAN: Jackie. All right. Good to meet you. So let me go ahead and program in for the world to see the number 15. We'll keep it small at first here. And I'm going to go into Game Mode. And I'm going to specify, give us the number 15. OK. And now with everyone watching-- if you want to maybe stand this way, because it will line up-- go ahead and toggle the eight buttons along the top to turn the bulbs on or off as you see fit. AUDIENCE: OK. DAVID J. MALAN: And no cheating by hitting plus 15 times. Oh, we are going to do that. AUDIENCE: Oh, wait. I'm so sorry. DAVID J. MALAN: You can also turn the light bulbs on individually with each of these buttons on top. AUDIENCE: Oh, OK. So it would be like-- DAVID J. MALAN: OK. So now we have eight. So let's pause for the audience to engage here. What number is Jackie currently representing? 11. So we're almost there. And excellent. So we have our first winner. Congratulations. And we thought we'd have some fabulous giveaways. If you'd like to be one such dorm room here on campus, you can yourself have a final project using now this API, thanks to Jackie. So now-- [APPLAUSE] --if we could, one more such around of this. Oh, now everyone wants some light bulbs. For the so-called hacker edition, we're going to ramp it up a-- oh, yeah, noncommittal. I think you're coming up now if your hand's going down. What is your name? AUDIENCE: Alex. DAVID J. MALAN: Alex, come on over here. So for Alex, we are going to program in a slightly larger number. Perhaps in order. The number 50. AUDIENCE: OK. DAVID J. MALAN: But, as I said-- and you might want to stand here so that the buttons line up as you would expect-- but I did call this the hacker edition. So-- good luck! [LAUGHTER] You will be able to turn them off if you-- OK. Excellent. Wonderful. Congratulations. [APPLAUSE] I suppose I should pay up. Congratulations to Alex as well. OK. So the ultimate takeaway here is hopefully, frankly, the simplicity-- the simplicity with which you can get some nice light bulbs, apparently in [INAUDIBLE]. But they represent, ultimately, the same ideas with which we humans are already all too familiar. So what might the next step be in the progression of trying to do something interesting with data and representing inputs that aren't just numbers but are maybe letters or more? Well, it turns out that the computer world, for many years, simply adopted an arbitrary but a consistent standard that maps numbers to letters of the alphabet. For instance, here is an excerpt from that mapping. It's called Ascii. A-S-C-I-I. And that is simply a table that maps uppercase letters-- in this case-- to decimal numbers. But what's the implication? Well, if you actually want to represent something like an email or some text on a web page, you obviously want to show the human letters of the alphabet, not numbers. So depending on the context of the program that a user is using, if it's a web browser or email client, numbers can certainly be interpreted as letters. That is to say, patterns of bits can easily be interpreted as letters. And so what we can have is the letter A being represented as 65, B being represented as 66. So if we have a super short word, like hi, what a computer would ultimately store in decimal but really in binary, using some sequence of bits, leveraging a bit of electricity in some way, would be the two numbers 72 and 73. But the pattern of bits that represents those values. So these then are how we can represent our inputs and outputs. And suffice it to say, we can do more complex representations ultimately with things like graphics, videos, music, and more as we'll see later this term. So that just leaves then algorithms, these sets of instructions with which we're solving actual problems. We're passing in inputs to algorithms. And those algorithms are producing outputs, hopefully correct outputs and hopefully, too, efficiently gathered outputs. In other words, it's one thing to implement something correctly. It's another thing to implement something well or efficiently. For instance, one demonstration that we're fond of in the course is this one. But these things are getting increasingly hard to find. But this is indeed an old school phone book, inside of which are 1,000 plus pages of names and telephone numbers. And if I wanted to look up someone in this phone book, I could simply do a very naive algorithm. I could open up to the first page, and I could start to look for, say, someone named Mike Smith. And if he's not on the first page, I progress to the second, and then to the third, and then to the fourth, and so forth, until I finally find Mike Smith. Now is that algorithm correct? AUDIENCE: Yes. DAVID J. MALAN: Yeah. If he's in there, I'll eventually find him. But it's arguably not very efficient, certainly not fast, because, my god, why am I wasting my time flipping through all of these pages when I could certainly do this physically faster? Well, a slight optimization, so to speak, might be not one page at a time, but two, four, six, eight, 10. Still correct? AUDIENCE: No. DAVID J. MALAN: So no if I for instance skip over Mike Smith. But so long as I back pedal one page, if I overshoot him, maybe we could correct what might otherwise be a gotcha. But is it better? Is it faster? I mean, yeah. It's literally twice as fast if I do two pages at a time. So if I originally had 1,000 pages, now I only have to flip 500 times, not fully 1,000 pages to get potentially in the worst case to the end of the phone book, where someone like Mike Smith or someone with a later name might actually be. But, of course, we humans certainly aren't going to be doing that, certainly not at this point in our lives. What is a reasonable human likely going to do? AUDIENCE: Go straight to the9 S's. DAVID J. MALAN: Go straight to the S's? How do I go straight to the S's? AUDIENCE: Rip it in half. DAVID J. MALAN: Well, there's no marking. So, yes, if there were indeed a label or a sticky tab for S, we should jump right there. But it's pretty innocuous. So the best I can do is roughly to the S section or maybe roughly into the middle. But the key takeaway now-- and the intuition that you've taken for granted for years probably-- is that what do you now know about this problem? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Mike Smith is surely not in this half of the problem because Smith comes after the middle which is roughly the M section, it seems to be. So as you might have seen at Visitas, we can now literally tear this problem in half. AUDIENCE: Woo! DAVID J. MALAN: It's getting easier and easier. [APPLAUSE] There you go. [LAUGHTER] And now I fundamentally have the same problem, but it's literally half as big. I'm still looking for Mike Smith. And I daresay, I can still look for him in the same way, splitting the problem in half again, tearing the problem again in half, which now leaves me with a problem a quarter of the size, dramatically throw that half away, and repeat this process again and again and again, glancing down at each point to see if Mike Smith is on the page in question. Now if I do this right, ultimately I'll find myself with just one page on which Mike Smith is if he's indeed in the phone book. Of course, I could never call Mike again. But the point here is that if we started with 1,000 pages, my first algorithm, flip the page, maybe 1,000 times-- definitely less because it's an S name and not a Z name, but as many as 1,000 pages potentially. Second algorithm, better. 500 pages. Third algorithm, though, how many steps would it take to divide a 1,000 page phone book in half like that? 10, give or take. So only by flipping through that phone book, diving and conquering, so to speak, 10 times, will I make my way down to just one single page. And so we can capture this intuition now a little bit graphically if you just consider this super simple graph. We're on the x-axis, or horizontal axis, is the size of my problem, the number of pages in the phone book. And computer scientists generally like to call the size of a problem n, where n is just some variable that represents-- in this case-- number of pages. The vertical, or y-axis, here is going to be the time to solve, maybe the number of page turns, maybe the number of seconds or minutes, whatever your unit of measure is. And so this red line represents the first algorithm, because there's a one to one relationship between number of pages and amount of time it takes. If Verizon doubles the number of pages in the phone book next year, my running time-- the time required to execute that first algorithm-- doubles in the worst case. But the second algorithm, where I'm flipping by two, requires less time for a given size problem. So if I have this many pages here-- notice that the yellow line suggests less time to solve. And indeed, it represents, we'll say, n over two. But what's the shape of the third and final curve going to look like? Yeah, it's indeed going to look-- I don't know what you were going to say. But let's see what you were going to say. AUDIENCE: Like that. DAVID J. MALAN: It's going to look like this, a logarithmic slope-- exactly-- whereby you have this curious slope. It's no longer a straight line. And what's compelling about that is that even though the graph is now cut off, you can extrapolate in your mind that that green line's not going to increase in height all that much as you proceed further down that horizontal axis. Indeed, Verizon, for instance, could double the number of pages in the phone book between this year and next year from 1,000 to 2000 pages, but no big deal. With this third and final, there's a intuitive algorithm of dividing and conquering. It's going to take me how many more steps next year to find someone like Mike Smith? AUDIENCE: One. DAVID J. MALAN: There's just one. And they can quadruple it, it's going to take me just two more steps and so forth. And so this is testament to just how some careful design and some appreciation for what your inputs are can do even better. Now we're cheating a little bit in the sense that we're leveraging an assumption. What is my assumption about our phone book that allowed me to divide and conquer in this intuitive and still correct way? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yeah. So it was ordered. It was alphabetized by the phone book company. If it were in random order, that would be a hell of a phone book, but it certainly wouldn't lend itself to the algorithm I used, because you would never just happen across Mike Smith if you kept dividing in half in that way by chance. So let's now formalize what's clearly intuitive. So something called pseudocode is where we'll begin some of our initial problems. And this is a generic way of describing an algorithm or a computer program, not using C, or C++, or Java, or any specific language, but just using English, with which any human might be familiar. And we might write the pseudocode for this problem as follows. Step one, pick up the phone book. Step two, open to middle of phone book. Step three, look at the names. Step four, if Smith is among names-- And now this is an interesting construct. It's a decision point. It's a fork in the road, if you will, a branch, so to speak. So I'm going to indent just by convention step-- not five-- which is to say, I'll call Mike. So this indentation, totally arbitrary human convention, but it's simply meant to convey semantically that if Smith is among names, then I should call Mike. Meanwhile in step six, notice that the indentation's gone. So else is the other fork in the road, the other road I might travel. So else if Smith is earlier in the book, what's my next step probably going to be here? AUDIENCE: You go to the left side. DAVID J. MALAN: Yeah, so go to the left half of the phone book. Throw away the right half if Smith is earlier in the book. So open to the middle of the left half of the book. And then step eight, go to line three. And this is a curious loop I'm inducing, a recursion so to speak. But more on that in the future. I'm using my same algorithm, my same pseudocode, to solve the same problem again because the only thing that's changed is the size of the problem, not my objective, and not the person I'm looking for. So I can reuse the algorithm that I've already defined. Else if Smith is later in book-- you might guess-- open to the middle of the right half of the book. And again, go to line three. Else-- what's the final line in this program going to be? If he's not among the names on the page I'm on, if he's not earlier in the book, and he's not later in the book, what do I know is true about Mike Smith now? AUDIENCE: He's not in the book. DAVID J. MALAN: He's not in the book. So the best I can do is just give up and stop this program. All right. So at this point, let's take a quick tour of some of what awaits. And in fact, I'm joined here by a number of CS50 staff. If these folks could all join me up here on stage. [APPLAUSE] Mind you, this is only a subset of CS50 staff, since each year we have nearly 100 staff members in roles of course assistants, teaching fellows, and more. Come on up. So they will join us here awkwardly for just a moment as we give a whirlwind tour of what you should expect here in the course. So first and foremost, we have SAT/UNS as the grading option in the course. This is meant deliberately to be an option whereby if you are a bit uneasy at being in the course, and you do fear failure-- even if frankly failure means hurting your GPA, getting a B and not an A-- that is precisely what, certainly for a gateway course like CS50 and other introductory courses, this grading option is meant to allow. I wholeheartedly encourage students-- especially if on the fence-- to start the course SAT/UNS, even remain SAT/UNS. But you can certainly switch to a letter grade by the fifth Monday in the term. Frankly, back when I was a freshman in 1995, I myself didn't even take CS50 because I didn't get up the nerve to actually step foot in the classroom. It seemed a domain far too unfamiliar to me and really only for those friends of mine, frankly, who had been programming since they were six- or maybe 10-years-old. And it was only because I was able to take CS50 in my day in the equivalent version of SAT/UNS-- pass/fail back in the day-- that even I took 50. And somehow or other, I'm here again with you today. Now meanwhile what else you should keep in mind about 50 is simultaneous enrollment. Contrary to rumors that you might have heard, you can, in fact, simultaneously enroll in CS50 and another class that meets at the same or some overlapping time as CS50's lectures right here. See the syllabus for the particulars of the implementation thereof. Lectures, meanwhile, contrary to what's officially in the catalog, will generally only meet for just an hour. On occasion we may run a little long. But keep in mind that the goal in CS50's lectures is to provide you with a conceptual overview, hopefully some demonstrations, maybe even some giveaways, of what awaits for the week that follows. And so in lectures, we'll explore those topics and examples together, bringing students up on stage, and staff up on stage as often as we can, for just a couple of hours each week. Sections, meanwhile, will be offered by these folks here-- many of them teaching fellows, some of them course assistants-- will be happening weekly. And what's key to keep in mind is that we do have-- not unlike First Nights, the music class-- different tracks of sections for students less comfortable, more comfortable, and somewhere in between. And frankly, you know if you're less comfortable. And you probably know if you're more comfortable. And if you're not really sure, you are by definition somewhere in between. So when it comes time to section in a week or so, per the syllabus, we'll ask you that question. And you can self-select based on your own comfort level and be with students-- be with green dots-- similar in comfort level to you. Meanwhile, we have problem sets, which will ultimately define your experience in this course. They're offered typically in multiple editions. A standard edition that we expect most every student in the course to tackle but also a so-called hacker edition that offers no form of extra credit outright but really the bragging rights to say that you tried and tackled the course's hacker editions that approach the similar material but from a more sophisticated angle. What we offer for the standard edition, for, again, a super majority of students, are not only walk-throughs, which are videos led by the course's staff that truly walk you through the course's problems and possible design implementations. And we also, after the fact, offer postmortems, whereby if you're wondering how you could have or should have solved some problem, the teaching staff will walk you through those on video as well. Meanwhile, what awaits too are five late days and the fact that we will drop your lowest problem set score. We certainly appreciate that in exchange for the workload that 50 expects of you, life gets in the way sometimes, if not five times. And so this will offer you a bit of flexibility, extending your deadline from, say, a Thursday at noon to a Friday at noon. See the syllabus for the implementation details thereof. Now what now awaits? And it's only occurring to me now just how long I'm having you guys stand here on stage. [LAUGHTER] DAVID J. MALAN: But we'll get to the climactic finish before long. So what awaits in terms of the problem sets? Well, perhaps a teaser of what we all did last year with your predecessors. In the first problem set last year, we introduced Scratch, a graphical programming language that lets you program literally by dragging and dropping puzzle pieces, like these, that are reminiscent of the constructs will see just one week hence, when we switch to a more traditional language, known as C. Last year we proceeded to this problem set, involving for cryptography, the scrambling of information to keep it from governmental or friends' eyes that you don't want to see it. Encoded in here is a message that soon you will be able to decrypt or de-scramble. Breakout was a problem set last year, wherein you use these new found programming skills to actually implement a game wherein-- as you may recall from childhood-- the goal was to bash the bricks that are atop the screen here, accumulating a score along the way, and implementing your own algorithms with which this solution ultimately lets you play the game. Meanwhile, later in the semester, we will give you a dictionary of 143,091 English words. And you will be challenged to write a program that spell checks, documents, by loading that many words into memory as efficiently as possible. Generally pitting you against your classmates if you opt into a bit of a challenge in leader board to see who can use the fewest seconds of running time, and the fewest number of megabytes of memory, and actually fine-tuning your programs to be incredibly resource efficient not just time. Last year, too, we looked at the end of the semester at web programming. And indeed, we'll do that again this year with multiple problem sets, introducing you to the techniques and the mindset with which you can apply these programming skills to websites, dynamic websites, websites that actually solve problems and behave differently and are not simply static sites with static information. The final project ultimately will define, though, the climax of the course for students, wherein you'll be challenged to implement most anything of interest to you, so long as it somehow draws upon the course's lessons. And as you saw in the video at the start, we will conclude the semester with the CS50 Hackathon, which if, unfamiliar, will begin at 7:00 PM one night and end at 7:00 AM the next morning. Around 9:00 PM, we'll order in first dinner. Around 1:00 AM, we'll order in second dinner. And if you're still standing at 5:00 AM, we will shuttle bus you to IHOP for breakfast. The CS50 Fair, meanwhile, is an event to which 2,000 plus faculty, students, and staff from across campus will come to see your accomplishments in the course and the final projects and creations that you create on your laptops, desktops, or perhaps even light bulbs. Meanwhile, office hours and the support structure. And now it would've been a better time to bring you all up. Office hours will take place four nights a week for multiple hours each night with generally 20 to 30 of the course's staff on duty at once to provide you with intimate one-on-one opportunities for support with the course's problem sets. Tutoring too will be available, particularly for students less comfortable-- or dare say least comfortable-- for whom office hours are not the most nurturing environment and are certainly not the most stress-free. Especially when deadlines are pressing, we will proactively pair you ourselves with a member of the staff to work with on some regular schedule as your needs and their schedule allows. And staff. Allow me to introduce Davon, Rob, and Gabriel, this year's heads. If you would each like to say-- [APPLAUSE] --a word. [APPLAUSE] Davon over here is the course's manager, which means in his full-time role he helps with the execution and logistics of CS50. DAVON: Yeah, hi, guys. You'll see a lot to me at office hours. I'll be teaching sections. And if you shoot emails ahead, I'll probably be responding. So I'll see lots of you all semester. And welcome to CS50. DAVID J. MALAN: And now Gabriel, who himself was just a freshman last year, but for the past couple of years has been operating his own version of CS50 in Brazil, whereby he downloaded all of the course's content-- which is clearly being filmed and placed online-- so that he could translate it to Portuguese and then teach more than 100 of his classmates over the course of a couple of years, teaching in his native tongue the course's curriculum. GABRIEL: Hello. [APPLAUSE] GABRIEL: Hi, I'm Gabriel. I'm the head TF of the course. And I hope you'll love CS50. This is CS50. DAVID J. MALAN: Now for Rob. Oh, you want introduction? ROB: No, I don't know. [LAUGHTER] DAVID J. MALAN: And Rob Boden. [LAUGHTER] ROB: Hi, I'm Rob. This is my fifth year involved with the course. Every year, it's just a better and better class, so you guys are clearly going to be awesome. I hope you all have fun with it. I'm going to have fun with it. So see you around. DAVID J. MALAN: And time won't permit us-- [APPLAUSE] Time won't permit us to introduce everyone on the stage and all of their colleagues who are shopping classes today. But allow me to introduce Belinda and CS50 Puzzle Day, which awaits this coming Saturday, which is the first of the course's large scale events. This one in particular meant to hammer home the point that computer science is ultimately not about programming, but rather about problem solving more generally. And Puzzle Day, as you'll see, will bring you and your classmates together-- we hope this Saturday. BELINDA: OK. Hi, guys. So thanks. So as our illustrious captain said, my name's Belinda. I am a sophomore at Quincy House. I, just like you guys, took CS50 last year, really loved it. I have a soft spot for you guys in the third row. And I'm proud to say, I'm now in a committed relationship with CS50 [INAUDIBLE]. OK. That was my lame version of a joke. Anyway, so moving on, just wanted to invite you guys all to the i-lab, or HBS hives. We're going to be having Puzzle Day from 12:00 to 3:00. And it's a great opportunity for you guys to meet your fellow CS friends, solve some non-CS puzzles, like Captain mentioned, and also eat some free food, earn some awesome prizes, like gift cards, $75 per person, and also-- what was it? Wii U or something? Wii U? Yes. For our raffle. Awesome. So I'll stick around after class. And if you guys have any questions, let me know. DAVID J. MALAN: And you'll see, beyond this there's nothing to do today. The first problem set will go out Friday. But to bring us home today, I'd like to introduce you to specifically one more member of the staff, Colton Ogden here, whose hands are now protected above you with this MIDI controller to hammer home the point further that computer science, too, has applicability far beyond engineering and STEM and computer science itself, extending even to such domains as music. Colton has kindly offered-- I thought one of them was going to fix the focus. Andrew, if we could summon focus over here for just a moment. What Colton has done in advance is program this device, this pad of buttons that you see pictured up here, as a MIDI controller, whereby each of those buttons is wired to a particular musical note or a sound, more generally a recording, such that by playing patterns of these buttons, much like patterns of bits, can represent other higher level concepts. Will he be able ultimately to take us home here today? Without further ado, if we could dim the lights, and turn on the screen behind Colton. AUDIENCE: Woo! DAVID J. MALAN: This is CS50. [MUSIC PLAYING] [APPLAUSE] That's it for CS50. We will see you Friday. Some cake awaits you in the Transept. [MUSIC PLAYING]