[MUSIC PLAYING] DAVID MALAN: All right. This is CS50. And this is the end. 

All that remains here on out is really your final projects. And we cannot wait to see what you create. Today what we thought we would do is take a bit of a look back, but also we'll look forward so that you know exactly where and what you can do beyond CS50 itself. 

But first a word of thanks. We are, of course, here in the Loeb Drama Center with The American Repertory Theater, who have been our amazing hosts this whole semester. And truly, they have breathed new life, new lights, new animation, new sounds into CS50. And we are so grateful to have had such a privilege to work with the amazingly talented team here to indeed bring this whole stage to life and evolve it over the course of the semester. 

And then, of course, there's CS50'S team. And though I'm the only one here on stage with everyone else spread quite far apart this semester, it would not be without CS50's team that we have the videos that we have, the technology that we have, and all of the visuals that supplement, hopefully, everything that you yourselves have been doing hands on. So thank you truly to both teams for having made this semester all possible. 

These are suffice it to say, among the more unusual and difficult times. And we hope, if you're watching this now live, or in some time from now, that this finds everyone healthy and well. And that, indeed, we have helped you find your way along this path of learning something new. 

Of course, there's more folks even than that behind the scenes, CS50'S whole team. And when I look out on the crowd here, really, there is no crowd here in person. And if you've wondered what it looks like behind the scenes, pictured here is a photograph of exactly what it is I am seeing when we hold each of these classes. And indeed, if we Zoom in, when we're having these conversations or answering or asking questions, it really is just us and some TV screens here this year. But we do look forward to all reuniting before long. 

Now behind the scenes, there's indeed this whole team. In fact, pictured here are just most of, but not even all, CS50'S teaching Fellows, teaching assistants, and course assistants, both at Harvard and at Yale, without whom this semester would also not be possible. Because they are, indeed, the backbone of and the support structure for getting everyone ultimately to the finish line with problem sets, labs, and more. 

But it's worth noting that we are all fallible. And, indeed, I'm told it's fairly instructive when I do something completely wrong, or get a little befuddled here on stage and can't quite figure out why my own code isn't working, or can't quite answer a question off the top of my head. This all happens, certainly, to all of us. So even if you are feeling here, toward the end of the semester, that not everything quite clicked and you're still struggling sometimes to find that bug in your code, or you're still googling or searching for some answer to some smaller technical problem, rest assured, or take comfort in knowing, that that is never really going to go away. 

And in fact, to reinforce that, besides all of the mistakes I here have made on stage, we thought we would share a little bit of a clip, some bloopers if you will, from when the teaching staff some weeks ago prepared that passing of TCP/IP packets on video, which worked out wonderfully well, where folks were passing up, down, left and right. The goal of which was to get three TCP/IP packets from the bottom right-hand corner of Zoom to the top left-hand corner of Zoom. But we thought we would give you a glimpse of what actually went on behind the scenes and just how many takes it took us to get even that demonstration right. I give you some of CS50'S team. 

[VIDEO PLAYBACK] 

- There we go. Buffering. OK. Josh? 

- Hi. 

- Helen, oh! 

[LAUGHTER] 

- [INAUDIBLE]. No, wait. That was amazing, Josh. Um, Sophie? 

[LAUGHTER] 

Amazing. That was perfect. Moni? 

[LAUGHTER] 

I think I-- 

- [INAUDIBLE]. 

- Amazing. 

- Guy? That was amazing. Thank you all. 

- So good! 

[APPLAUSE] 

[END PLAYBACK] 

DAVID MALAN: So suffice it to say, computer science is hard for all of us. And so some of these feelings, some of these frustrations are never going to go away. But hopefully you have, indeed, all the more tools in your toolkit, all the more of a foundation now to build on so that you can take comfort in being a little uncomfortable as you forge ahead and solve new problems, learn new languages, and ultimately pick up new ideas and skills. But remember, for CS50 alone, what ultimately matters in this course is not so much where you end up relative to your classmates, but where you end up relative to yourself when you began. 

And consider, it wasn't all that long ago that you began. In fact, just some weeks ago was this perhaps, the biggest of your problems in CS50, just trying to figure out how to get the pyramid to align right, whether you did the less comfortable version or the more comfortable version, figuring out how to print spaces, how to shift the pyramid over and the like, figuring out how to nest loops, let alone getting all of the semicolons and compilation steps right. And then, fast forward to just a week or two ago when you built your very own web application, one that used a third party API and pulled in nearly real time data and generated views for the user, had a controller governing with the model exactly all of the data you were reading and writing and the like. 

Like, that is a huge way to have gone over the course of just a few months. So take comfort in that, too. Especially as you dive into your final project and might bump up against some more walls, those, too, will you ultimately push through. 

So what have we focused on over the course of this semester? A lot of the times we've spent time talking about and doing programming. But really, we'd like to think it's some of the higher level ideas and the takeaways that are what last you far longer than the particulars of these languages. Whether it's Scratch or C or Python or JavaScript or SQL, or any of the other practical tools that we looked at, all of those are eventually in some form going to be out of date. Or they might remain with us is older languages, but newer and better things will come along. 

And what we hope, then, is that over the past few months, you've walked away with the fundamentals and sort of a foundation on which you can bootstrap yourself to learn new things as they come out and really reduce new things to their basic building blocks, the puzzle pieces with which we began, first principles from which you can infer how some new system, some new piece of hardware, how some new language must surely work. Because underneath the hood, at the end of the day, it's still going to be, for some time, just 0's and 1's. 

And so we introduced in Week 0, recall, computational thinking, encouraging you to think more methodically, more algorithmically. But really, computational thinking is just a computer scientist's incarnation of what we might otherwise think of as just critical thinking. This process is taking as input information and producing as output some solution. And in between there, of course, are our algorithms, the black box that's doing something interesting and perhaps difficult. But at the end of the day, this is problem solving. And this isn't going anywhere, irrespective of the languages that you use or pick up or even forget somewhere along the way. 

And indeed, today, too, whether this is input and output in binary form, or it's just information and decisions or facts and conclusions, this process of taking input and producing as output correct answers, correct conclusions, correct decisions is hopefully going to be with you far longer than the particulars of C or Python or any of the more hands-on skills that we've spent time on this term. And recall, too, that at least within CS50, the tools with which we propose that you evaluate the quality of your approach to problem solving are these three axes, the first and foremost of which is surely correctness. Because if it doesn't work, what's the point of it all in the first place? So getting your code, your algorithm, your process from input to output to be correct is certainly paramount. 

But after that comes questions of design. If you actually want to build more complex systems, or solve more sophisticated problems, you really do want to design your solutions to those problems cleanly. You don't want them to be slow or inefficient. 

You don't want them to be a mess in real terms. You don't want your code to be completely undecipherable. Because that's just going to hamper you longer term to using those same tools, those same libraries to solve more interesting, more sophisticated problems. And it's surely going to make it harder to interface with other people, other collaborators, and other systems. 

And indeed along those lines, is style still important? It's perhaps the third in this trio for us. But it's the aesthetics of your code, and the indentation in the variables and all that, much like you might convey in our human language, put your best foot forward with punctuation and the like. It just helps other people understand you. 

And indeed, even though we spent a lot of our time interacting with computers, in a course like this, at the end of the day, you're really just communicating. And whether you're communicating to a machine or to another human, doing that cleanly and in a way that helps your ideas, your solutions, become adopted is surely no less important than some of these other ideas as well. 

But what about other basic building blocks that transcend the particular languages and pieces that we did? Well, abstraction, this idea of taking fairly complicated ideas and simplifying them so you don't have to worry about the lower level implementation details, you can focus only on the solution that that puzzle piece or that building block actually provides. And abstraction is everywhere around us. 

Certainly in code, we saw functions like get_string as an abstraction. I don't know. I don't really remember exactly how get_string is implemented underneath the hood, let alone a function that comes with C, like printf. But I know that it works. And I know that it takes input. I know that it produces output. And I can therefore build my own ideas, my own software, on top of that building block, abstracting away those particulars. 

And in the real world, too, we abstract things-- we abstract away things all of the time, taking a complex idea or a process and assume that that will be done. Someone else might do that. And I can therefore build on the output of that process, even if I am myself am no expert in the underlying implementation details thereof. 

But then there's precision, this other idea where it's super important, certainly when writing code, but also when talking to another human, to be precise and make super clear what you mean. And to consider the corner cases, to consider the inputs that you might not otherwise expect, but might nonetheless happen so that you don't err and have some unexpected behavior, as we certainly did more than once in actual code. And sometimes, abstractions and precisions are kind of at odds with one another. Because abstraction would sort of have you think at and talk at a fairly high level, whereas precision would suggest that you really should get into the weeds and really go step by step by step when it comes to giving someone else or a computer instructions. 

And we thought we would bring this to life, perhaps, with a couple of examples. And we thought we would try to involve as many people as we can in this, albeit from afar, by having everyone, if you can, take out a piece of paper and a pen or pencil. It's OK if you don't quite have that available. You can do this on a computer, too, if you'd rather draw on a notepad or a tablet, or something like that totally fine. 

But ideally, taking out now something with which to draw and something to draw on. We're going to go ahead and try to apply some principles of computational thinking and see just how helpful or hurtful it is to use abstraction or precision at one level or another. So I think to do this, Brian, we're going to need a helping hand from the audience. I think we're going to need for one person out there to volunteer to write instructions verbally for everyone else. We're going to treat everyone in the audience, or really, n minus 1 people in the audience as the computers today who are going to be programmed. 

And we need one human volunteer to be the programmer. And that programmer is going to be Daniel. So Daniel, thank you for volunteering. Brian, could we go ahead and share with Daniel, and only Daniel, a picture of something that we want everyone else to draw? So Daniel, what you should see on your screen in a moment, if you haven't already, is a picture. Don't tell anyone else what it is. 

You may use any words in a moment that you want. You should not use your hands or any gestures like that. But the goal is going to be to write an algorithm verbally for everyone else in the room, step by step, so that ideally they draw what it is you see. And you can say anything you want, but just no physical gestures. Does that make sense? 

- Got it. And do you want to say a little bit about yourself first to the group before we begin? 

STUDENT: Sure. My name's Daniel. I'm from Ezra Stiles College at Yale University. And I really CS50 this semester. 

DAVID MALAN: Oh, wonderful. Thank you for volunteering. And let's go ahead and have everyone else with their paper and pencil or pen ready. Daniel, what should be the first thing everyone does, step one. 

STUDENT: OK. So the first thing we're going to draw is a hexagon. So it's a regular hexagon. And we're going to make sure that we draw it so that one of the vertices is on the very bottom of the hexagon, and one of the vertices is at the very top of the hexagon. So one side is not laying flat. You're doing-- 

DAVID MALAN: Wup, dut, dut dut. No hand gestures. 

STUDENT: No hands, no hands. Right. One vertice at the very top, one vertice is at the very bottom. And you've got your other four vertices on the sides. 

So once you've got your hexagon, your next step is going to be find your midpoint of the hexagon. And so once you've found your midpoint, you're going to draw three lines from a vertices to that midpoint. The vertices that you're going to choose to draw from are the very bottom to the midpoint and then from the midpoint to the vertices that are on the left and right of the top vertices. 

DAVID MALAN: All right. Any final instructions? 

STUDENT: I think, hopefully, that should be it. 

DAVID MALAN: [INAUDIBLE]. Those were very long steps one and two. But yes. All right, well, let's go ahead and reveal. This will be a little bit of a hack. 

But if anyone everyone is comfortable picking up their piece of paper or their tablet and holding it in front of their Zoom camera steadily for five or 10 seconds, we'll see exactly what everyone has drawn. If you go into gallery view, you'll be able to see everyone else. Daniel, hopefully you're seeing some familiar pictures? I think we definitely have range. Are you seeing one or more that match what you had in mind? 

STUDENT: Yeah. They all look pretty good. 

DAVID MALAN: They all? All right, so good. Let me go ahead, then, and share on my screen in just a moment what it is Daniel was describing. So what Brian had shared with Daniel in advance was this picture here, which I dare say is a cube. 

But indeed, it's composed of a hexagon and then the additional lines that Daniel described. And Daniel, I did happen to see, maybe on pages two and three of the Zoom window, there were definitely some that weren't quite cubes. What was going through your mind as to how you approached the algorithm that you provided? 

STUDENT: I wanted to-- to me, the first thing that went through my head was a cube. But I knew that there's so many ways to draw a cube. I didn't want to describe it as a cube. Because if I said just draw a cube, I knew that we would get tons of different results. 

So I wanted to be as clear as possible. And I knew that if I could describe it in sort of a mathematical way, describing it with a hexagon and describing it with the vertices in the midpoint, that hopefully more people would be able to draw a precise shape. 

DAVID MALAN: Yeah. Really well said. Now if we had everyone's volume on, odd are, you'd hear a bit of chuckling now, perhaps, or maybe a little bit of awkwardness. And I daresay not all of the pictures quite turned out that way, but that's a perfect example of where maybe abstractions can kind of get us into trouble. 

Because if Daniel had just said, draw a cube, right, some of you might start drawing immediately a cube. But many of you would have a question, well, what should the orientation be? What should the size be? What should the position be? And so there, precision becomes increasingly important. 

But the more precise it gets, odds are some of you just kind of got overwhelmed with the amount of detail and sort of lost track where your pen or pencil was supposed to be at one point because you were operating at a much lower level. So there's this tension, then. But I think we did get some of you to that finish line. 

Let's see if we can't now take the pressure off of all of you, and thank you to Daniel, in particular, let's see if we can't now have all of you collectively program me, if you will. So I'm going to go ahead and pull up my screen here where I have the ability to draw with my mouse and cursor on my screen here. And Brian, if you don't mind, could you share with everyone else a picture that I promise I have not seen in advance. So we will see how this goes. So I'm the only one right now in the Zoom room that has not seen this picture. 

But Brian has gone and provided only you all with the URL. So pull that up on your screen. And then, Brian, if we could perhaps iteratively call on some volunteers. Why don't I try to draw what people tell me to do, step by step? 

BRIAN YU: All right. David has not seen this. I just picked this out, like, five minutes ago. And you're all going to raise your hand if you want to give him, like, one instruction for what to do next. And let's start with George. 

STUDENT: So you're going to start by drawing a circle near the top of the screen. 

DAVID MALAN: OK. A circle near the top of the screen. And let me make clear, I have no delete abilities on the computer. So once I commit, we're in. So drawing a circle near the top of the screen. OK. Thank you, George. Brian, step two? 

BRIAN YU: All right, let's go to Sophia next. 

STUDENT: Then, in the very center of the screen, door a black, filled in circle, which is approximately a tenth of the size of the circle at the top. 

DAVID MALAN: OK. A black, filled in circle, I heard, that's a tenth of the size. So I'm going to do something like this, and then just kind of shade it in. All right, thank you, Sophia. Step three? 

BRIAN YU: Let's go to Santiago. 

STUDENT: You're going to draw another circle. But it's not actually going to be a circle, it's more of an ellipse, that's going to be bigger than the first one. So it's going to be in the middle. And it's going to enclose that filled in circle and leave some room in the bottom. 

DAVID MALAN: OK. So it's an ellipse. It's bigger than the first circle. But it encloses the smaller one? All right, so I heard kind of this. OK. Step 4? 

STUDENT: Under that smaller ellipse, you're going to want to draw a bigger circle underneath it and act as if the circle is going through that ellipse, but don't actually show the lines going through the ellipse. So that is, we draw a bigger circle underneath, but without having the lines go through. It looks like it will kind of be going through the edge of it. 

DAVID MALAN: OK. I'm a little worried here, but what I heard was like this, maybe? Step five? 

BRIAN YU: All right, let's go to [INAUDIBLE] next. 

STUDENT: So in that kind of middle ellipse, you know, like, when kids act like they're an airplane, and then they make, like, airplane noise, then they do that weird thing with their arms? 

DAVID MALAN: Uh huh. 

STUDENT: So draw those kind of, like, arms in that middle ellipse, coming out of the big middle ellipse. 

DAVID MALAN: In the middle ellipse? This lower one? 

STUDENT: The one outside of it. 

DAVID MALAN: Oh, this big ellipse? 

STUDENT: Yeah, the outer bound. Yeah. 

DAVID MALAN: All right, so I should draw some hands like a kid would have when-- OK. I'm not sure this is going to end well. 

BRIAN YU: All right. We need some more volunteers to help David finish this. Let's go to Gabrielle. 

STUDENT: OK. Try to draw a-- 

DAVID MALAN: Try is the operative word. 

[LAUGHTER] 

STUDENT: You've got a bigger ellipse that's at the very bottom, that's bigger than both the top and middle one, but showing no overlapping lines between the middle one and the one that you're trying. 

DAVID MALAN: So show no overlapping lines. So I heard an even bigger ellipse. So, like, oops, sorry. This? OK? 

STUDENT: Good job. 

DAVID MALAN: Thank you. OK. Good. Keep the positive reinforcement coming. Final couple steps? 

BRIAN YU: All right. [? Ika? ?] 

STUDENT: One other step you would have to do is draw a small, filled in circle, slightly smaller than the one you already drew, right in the center of the first circle you drew right at the top. 

DAVID MALAN: OK. Right in the center of the first circle. OK. And I think this is starting to take shape for me. And I regret some of my earlier decisions. 

BRIAN YU: [INAUDIBLE], you want to provide an additional instruction? 

STUDENT: Another circle in between the last one you just drew and in between the edge of the circle, so to the left of that circle you're going to draw another circle. 

DAVID MALAN: To the left of this circle? 

STUDENT: Mhm. 

DAVID MALAN: OK. 

BRIAN YU: And Ryan? 

STUDENT: Underneath, you're going to want to repeat the same process, except draw a circle on the right side. 

DAVID MALAN: OK. Little loop. 

BRIAN YU: I think we've got maybe one or two more steps left. Let's go back to Sophia. 

STUDENT: Underneath the filled in circle, that's in the middle ellipse, you want to draw two replicas of that circle below the original one in the middle ellipse. 

DAVID MALAN: In the middle ellipse, so here, OK. I think I know what this is. 

BRIAN YU: And Jason, how about one last instruction? 

DAVID MALAN: All right. 

STUDENT: Underneath, in the top most circle, under the three, so the row of three circles, draw a wide V, sort of shaped with two straight lines. 

DAVID MALAN: A wide V with two straight lines. OK. That part, I think, I nailed. Shall I switch over and reveal? 

So this is the URL I believe all of you were given. I have not visited it yet. But if I go and visit this now. Hey, that's not all that bad. All right, I definitely took a detour partway through. 

But here's another example. Had you just started with draw a snowman as follows, like, that might have helped orient me, truthfully, similar in spirit to Daniel's design that would have given you a mental model of what I, or given me a mental model of what it is I should have been drawing. So here, too, abstraction is hard. And even precision is hard and figuring out the right level of detail to operate at is kind of part of the process of problem solving. 

Though, now that I look at it, that's actually not half bad. Like, I definitely did the wrong thing over here. But very well done to all of our volunteers online. 

So remember these kinds of details when you're trying to explain some process to someone, when you're giving someone instructions, even if it's for something mundane in the real world, like going to run errands or pick up supplies at the market, being precise is certainly important, but the more precision you provide, the much easier it is for the person to get lost in those weeds. And so sometimes a higher level list of details is all that someone might need. 

So now that you have this ability to program and to do things that we've shown you in lectures and problem sets, and indeed, have the ability to figure out how to do things that we haven't even shown you, we wanted to take a moment to consider just whether you should do those things and, if you should, how you should do them. But beyond just answering these questions with your own instincts, we thought we would invite some of our colleagues from the Philosophy department to propose a more formal framework, a thought process by which we can approach problems when it comes to technology and the writing of code to help us decide, ultimately, just because I can code something, should I, and if so, indeed, how should I do that? So allow me to introduce our colleagues from the Philosophy department, Meica Magnani and also Susan Kennedy. Meica? 

MEICA MAGNANI: So hi. I'm Meica Magnani. I am a philosophy postdoc with the Embedded Ethics Program here at Harvard. 

SUSAN KENNEDY: Hi. I'm Susan Kennedy. And I'm also a philosophy postdoc with the Embedded Ethics Program at Harvard. 

MEICA MAGNANI: And before we get started, I'll just say a few things about the Embedded Ethics Program. So we are an interdisciplinary team of philosophers and computer scientists working together to integrate ethics into the computer science curriculum. The idea behind this approach is to embed tools of ethical reasoning into computer science courses themselves. 

The reason for this is that when making decisions about the design, deployment, or development of a piece of technology, one is, whether or not one realizes it, making ethical decisions. That is, making decisions which stand to have social, political, or human impact. At Harvard, we think it's important for computer scientists to be equipped with tools for thinking through these implications. 

SUSAN KENNEDY: Technology holds a lot of power and influence over us. And that means, by extension, that the people who design technology do, too. Now that you're starting to think about what responsibilities you might have as computer scientists, so you can avoid notable mishaps, like face mash, for instance, we're going to turn your attention to the topic of social media platforms and how they affect the distribution of and engagement with news and information. It would seem that this topic is especially relevant now, given the recent US presidential election, where political content has been dominating the internet and television broadcasts and controversy has played out on social media, garnering attention from around the world. 

Undoubtedly, technology has completely revolutionized the way information and news is both disseminated and consumed. Instead of a paper boy shouting, get your news here on the street corner, just about everyone uses the internet to stay up to date with what's happening, not just locally, but around the world. And in the past few years, social media platforms, in particular, have started to play a huge role in how people access, share, and engage with information. For instance, research shows that 44% of US adults report getting the news from Facebook. 

It's safe to say a lot has changed in recent years, owing to developments in technology. And this matters when we consider what's at stake, namely, the ability for the public to engage in discourse that supports a well-functioning democracy. So I'll first present you a brief overview of where we came from and where we are now, owing to technological developments and then consider what challenges we're faced with today. 

Before the internet, news and information was almost entirely in the hands of a few major broadcast stations and print media outlets, otherwise known as the mass media sphere. Since a few organizations were responsible for disseminating all the news, information was essentially filtered through a narrow lens or narrow aperture from organizations to a wide public audience. The journalists who are responsible for researching and writing the content for these organizations all shared a professional ethos. They were concerned with truth, representation of social groups, creating a forum for criticism, clarifying public values, and offering comprehensive coverage. And notably, since the aim was to produce content that appealed to a wide audience, there was less polarization and extremist commentary than we see today. 

But the journalists responsible for news coverage were very uniform in a lot of ways. There were relatively affluent, highly educated, mostly white, male, and so forth. And this had effects on the coverage of racial politics, economic policy, and views about the role of the US in the world. 

Moreover, there were seldom opportunities for the audience to respond, to develop new themes or topics, or level criticism against the mass media sphere. There weren't any likes and comment sections for the newspaper or television broadcasts. If you didn't like it, well, tough luck. 

This all started to change in recent years, as news coverage not only moved online, but onto social media platforms. We now live in a digitally networked public sphere. So instead of having a narrow aperture of communications, or just a few organizations to disseminate information to the public, we now have a digital sphere with a wide aperture, where lots of people can share news and information. 

More specifically, the sources of content are not just organizations and the professional journalists they employed, but the public and particularly, social media users. Anyone can tweet or post on Facebook, and anyone can read those tweets and posts. It's not only resulted in greater diversity of content, but greater access to information as well. 

If you want to follow the news, there are a ton of options and free places online you can access with just a few mouse clicks. These prospects of increased diversity and access are what led many people to believe that the digital sphere held great promise for improving the public discourse that supports a well-functioning democracy. And in some ways, this has been true. 

For example, thanks to Twitter and Facebook, we saw the mobilization of social justice movements, like Me, Too and Black Lives Matter. And the increased diversity of perspectives made it possible for individual researchers and scientists to weigh in on the CDC'S claims about coronavirus. So while the CDC did not initially say coronavirus was characterized by airborne transmission, leading to community spread, they ended up revising their stance after scientists took to Twitter with evidence proving that this was the case. 

While the digital sphere has brought about some improvements, it's also exacerbated some problems and created new challenges. For example, since anyone can create content, fact checking and monitoring have become much more difficult. People are left to fend for themselves when it comes to figuring out whether something they read online is trustworthy. We've also seen increased personalization with respect to news and information, where specific content could be targeted to specific users by the means of curated news feeds on social media and cable news stations cropping up that take a particular angle on the news that they cover. 

This is significant. Because we end up with a somewhat paradoxical effect. Despite a greater diversity in the content that's available, there's less diversity in the news and information people actually end up consuming, with the personalization of information having a tendency to reinforce a person's viewpoints, rather than challenge or broaden them. Additionally, in the absence of centralized sources of news, we've also seen different aims expressed by those creating and sharing content. Some have bypassed a concern for truth in an effort to garner more views and likes with extremist content or fake news. And fake news became a huge issue around the time of the 2016 presidential election, as there were concerns that the massive spread of misinformation on social media could influence or sway individuals political views. 

While the spread of misinformation has always been an issue, it's truly been exacerbated by the digital public sphere, with social media platforms essentially pouring gasoline on the fire. The dissemination of fake news explodes on social media because the structure of digital environments, from likes to retweets, allows a single post on fake news to go viral, reaching the screens of millions around the world. And there are serious worries about how fake news has played a role in amplifying political polarization. 

So while technology has made possible unique advantages, it's also brought on unique challenges. One major question that we're faced with now is figuring out how content should be regulated on social media platforms, if at all. Given the scale of the problem, some might be skeptical, believing that any form of content regulation would be impossible. 

There's just too many people posting online to fact check them all. And fake news spreads so quickly, it's hard to stop before it's already reached a huge audience. There's also worries that attempts to regulate content could end up becoming a form of censorship that violates the right to freedom of speech. 

But some people are more optimistic about the possibilities of designing social media platforms in a way that promotes and preserves democracy. In particular, there's a possibility that with responsibly designed algorithms and user interface choices, we might be able to slow the spread of fake news and more generally improve the ways information is disseminated and engaged with on social media. For example, some people believe that companies like Facebook, Twitter and YouTube have a responsibility to regulate content because of the enormous influence they have over us. In particular, it's thought that social media platforms have a responsibility to police fake news and reduce the power of data driven algorithms that personalize the user experience, even if doing these things would come at the cost of user engagement, resulting in less time spent on the platform and less advertising revenue. 

It's clear that the path going forward in terms of content regulation on social media platforms is going to be tricky. Whether or not we promote democratic ideals or undermine them will come down to the particular design choices we make. In order to use technology to create solutions to the problems we're facing today, we'll need to make informed decisions about design choices. And this requires some critical thinking about ethics and philosophy to figure out the best way to do this. But we're hoping that students like you, taking CS50, can harness your creativity, technical knowledge, and ethical reasoning to design technology in a responsible way. So I'm now going to pass things over to Meica, who will tell you about some philosophical concepts that'll help you think proactively about particular design choices and algorithmic tools that can be implemented to structure social media platforms in a way that promotes democratic public discourse. 

MEICA MAGNANI: In Democracy and The Digital Public Sphere, an article which offers a fantastic diagnosis of our situation, and from which Susan and I are drawing heavily upon for this lecture, the authors Joshua Cohen and Archon Fung, tell us that the bloom is off the digital rose. As Susan was describing, we had such high hopes for the democratizing potential of social media and the internet. But now we face an environment in which fake news runs rampant, citizens appear to be dramatically polarized, information swirls in its own isolated bubbles, and hate speech reaches appalling levels of vitriol. All of which stand to threaten, or so people speculate, the conditions required for an effective democracy. 

So the following questions arise, in what ways are the conditions of democracy threatened? What can or should be done about it? Is the structure of our technology responsible? Or is it just us, as human beings, creating these problems? 

In this module, we're focusing specifically on the issue of content regulation. Social media companies like Twitter, Facebook, and YouTube are now all in the game of trying to address these problems through platform design and features. From one angle then, they are acting in the service of protecting democracy by trying to get control over the spread of misinformation, the amplification of hate speech, and the deepening of polarization. 

However, from another angle, they're stepping in to shape the distribution of information. And depending on the particular design choices, might be set to be regulating or silencing speech, which of course, is at odds with democratic commitments to free speech and discourse. The point of this module, then, is to give you some tools to think through these issues, tools for understanding the problem, diagnosing the sources of the problem, and brainstorming solutions. 

In the remaining 10 or 15 minutes, I'm going to provide an overview of the main tools which you will find detailed in the readings. They are also the tools you will be asked to analyze in this week's lab. So first then, we need to think clearly about what is required for a healthy democracy. 

If we're going to be making claims about how tech threatens democracy, we better understand A, what a democracy is, and B, what sort of conditions support democracy, such that those conditions could come under threat. In their article, Archon Fung, who is a professor in political science here at Harvard, and Joshua Cohen, who is a political philosopher now working with the faculty at Apple University, provide us with these tools. 

So behind the idea of democracy is an ideal of what political society should be. Fung and Cohen reduce this ideal to three elements. First, the idea of a democratic society, a society in which the political culture views individuals as free and equal. Even though it is likely that these people have different interests, identities, and systems of belief, as citizens, they are committed to arriving m through reflection and discourse, principles that will enable them to work together while respecting their freedom and equality. 

Second is the idea of a democratic political regime, which is characterized by regular elections, rights of participation, along with associative and expressive rights that make participation both informed and effective. Third and lastly is the idea of a deliberative democracy, according to which political discussion should appeal to reasons that are suitable for cooperation amongst free and equal persons. So in justifying a policy, you cannot appeal to, say, your own religion, given that others do not necessarily hold those same beliefs. You can appeal to the notion of, say, religious freedom, but not the particular beliefs contained within the religion itself. 

So democracy, then, is basically an ideal that we govern ourselves by collective decision making, decision making that respects our freedom and equality. This decision making consists not only of the formal procedures of voting, elections, and legislation, it is also informed by the informal public sphere, that is, citizens identifying problems and concerns, discussing and debating problems, expressing opinions, challenging viewpoints, and organizing around causes. This is an absolutely critical part of the democratic decision-making process. It is where we, as the public, form, test, disperse, exchange, challenge, and revise our views. 

The flow of information, along with user engagement on Facebook, YouTube, and Twitter, are all part of this informal public sphere. In order that individuals can participate as free and equal citizens in this arena of public discourse, Cohen and Fung lay out a set of rights and opportunities that a well-functioning democracy will require. And these are the tools of analysis on offer. 

So first, rights. "As citizens of a democracy, we have rights to basic liberties, liberties of expression and association. The right to expressive liberty is important not only for the freedom of the individual, so that he or she will not be censored, but also for democracy itself. It enables citizens to bring their ideas into conversation with one another and to criticize and hold accountable those who exercise power." 

Second is the opportunity for expression. "Not only should we be free of censorship, but we should have fair opportunity to participate in public discussion. It shouldn't be the case that because someone is, say, wealthier or more powerful, that they have more opportunity to participate." 

Third is access. "Each person should have good and equal access to quality and reliable information on public matters. That is, if we make the effort, we should be able to acquire this information. Effective participation in decision making requires being informed." 

Fourth is diversity. "Each person should have good and equal chances to hear a wide range of views. We need access to competing views in order to have a more informed and reasoned position" 

And lastly, number five, communicative power. "Citizens should have good and equal chances to explore interests and ideas in association with others. And through these associations, to develop new concerns that might challenge the mainstream view." 

These rights and opportunities together provide critical conditions for enabling participation in public discussion. They might seem like a lot to keep track of initially, but if we're going to think through how social media threatens democracy, and more concretely, how platform design might promote or hinder democracy, these are valuable tools. We can use, say, the access condition, the idea that we should all have access to reliable information, as a lens of analysis. 

Does our platform prevent certain groups or users from accessing reliable information? Or we can use the diversity condition, the idea that we should all have access to a plurality of conflicting views as a lens of analysis. So for example, we might ask ourselves, does our platform create a filter bubble in which individuals are no longer confronted with opposing views? 

In addition to understanding what conditions support a democratic society, we also need to understand the purported problems before we can propose effective interventions. Consider fake news. Why are people so gullible when it comes to fake news? Why do they often repost without proper critical assessment? 

Regina Rini, in the reading, proposes that in order to understand the phenomenon of fake news, we should think about it as a form of testimony. When another person shares information with you, you typically take it to be true. This is because of the norms governing our practice of testimony. 

When you assert something, passing it on to others, you typically take responsibility for its truth. It is assumed that you have either acquired evidence for yourself or you've received this information from a source that you deem reliable. Most of our knowledge about the world comes through this practice. We could not possibly acquire evidence for all the beliefs we hold. So we often have to rely on sources we deem and hope to be credible. 

But social media, Rini points out, has unsettled testimonial norms. When someone posts a piece of news, we seem to hold two conflicting views. On the one hand, we see it as an active endorsement. The person posting has taken some degree of responsibility for the accuracy of their post, the same way one would before passing on information in a conversation. 

On the other hand, though, it's just a share. We see this attitude coming through when Donald Trump, called out on one of his questionable tweets, retorts with, eh, it's just a tweet. 

To fight fake news, then, Rini argues that we need to stabilize social media's norms of testimony so that, as she says, the same norms that keep us honest over cocktails will keep us honest in our posts. We need people to be held accountable for, or to have a sense of responsibility, for the information that they share with others. Her concrete proposal, give users a credibility score. 

So in practice, this would be an amendment to Facebook's system, using independent fact checking organizations, Facebook flags problematic news and warns users before they repost it. When a user tries to post something that has been identified as false or misleading, a pop up appears that explains the problem and identifies the original source. It then asks the user to confirm that they would like to continue with their repost. 

A user's credibility score, for Rini, would depend on how often they choose to ignore these warnings and pass on misleading information. Quote, "a green dot by the user's name could indicate that the user hasn't chosen to share much disputed news. A yellow dot could indicate that they do it sometimes. And a red could indicate that they do it often." Unquote. 

The idea, then, is that a credibility score would incentivize users to take responsibility for what they share and would also give others a sense of their reliability as sources. So Rini comes up with this solution through a careful analysis of why we are so gullible to fake news. I will leave it up to you to consider this proposal in light of the various rights and opportunities required for a democratic public sphere. 

Does Rini's proposal violate or threaten freedom of expression? Does it promote or hinder our access to reliable information, our access to diversity of views, or does it promote or hinder our communicative power? It is these sorts of questions that we hope that you will start to ask yourself when thinking through the following sorts of issues. 

What problems do fake news, hate speech, polarization, et cetera pose to democracy? How successful are various attempts by companies like Twitter, YouTube, and Facebook to address these problems? And how might particular design features of social media platforms promote or hinder these particular rights and opportunities? Whether as a future computer scientist, a tech industry leader, or just as a user of these technologies, we hope asking these sorts of questions will help you navigate these tricky issues with a more critical eye. 

SUSAN KENNEDY: We're really looking forward to the sorts of design choices that you'll be making in the future. 

MEICA MAGNANI: Great. Thanks so much for having us here today. And best of luck to everybody. 

DAVID MALAN: Well, thank you so much to Susan and Meica for joining us. Indeed, in this coming week's lab, we'll have an opportunity to consider some of these issues in the context of some very specific real world scenarios. So we now thought we would take a look forward at what you can do and how you can do it after CS50 when it comes to the more practical side of things beyond computational thinking alone. 

So programming, of course, for many of you, this will be by design the only computer science or programming course that you take. And that's certainly OK. Indeed, we hope that you'll be able now to return to your own domains of interest in the arts and humanities, social sciences, or sciences and actually be able to have a concrete set of practical skills be it in Python or C or any of the other technical languages we looked at and can actually solve problems in your own preferred domain. And if you're interested in learning more about computer science itself and moving on in that world, we hope that you'll walk away with a solid foundation for further theoretical and systematic explorations of this particular field. 

But very practically speaking, we hope now that you can not only program, but also ask questions better, whether that's in the technical world or even in just the real world. Odds are, if you've ever asked a question on CS50's discussion forums, the teaching fellows or I might have very well responded with questions asking you to clarify. Or better yet, you would have provided us, in anticipation, with answers to all of the questions that we might have. 

And if you've noticed on Ed, we deliberately have this sort of template via which you're coaxed to answer, well, what are the symptoms that you are seeing? What's the error message that you're struggling with? What steps have you tried to resolve the problem? 

Because if we imagine in the real world, even just reaching out to some random company's customer service line, those are exactly the kinds of questions that someone else is going to have to ask you to better understand a problem from your own perspective. And so we would encourage you to think about, as you emerge from CS50 itself, just how to ask better questions of people. If you've got more information than they, how can you succinctly but correctly convey that information to them so that they can help you more efficiently. 

But also, finding answers. Like, we absolutely understand that many of CS50's weeks, all of CS50's weeks, maybe, have been quite the frustration. Because you quite often feel like, well, we didn't cover that in lecture. Or I didn't see that in section. 

And I see some noddings of the head. So this seems to be the case. And much as I would love to reassure otherwise, like, that was very much the intent. Because the last of the training wheels of any course like this now really do officially come off. And in the coming weeks, while we'll still be with you to lend a hand with final projects and answer questions along those lines, there's of course no specification for the final project telling you exactly what to do, or in what language to do it, or what libraries to use. 

Undoubtedly, in the coming weeks, you will run into error messages you haven't even seen before. And frankly, maybe I, maybe Brian, maybe the teaching assistants, and the course assistants haven't even seen those errors before. But the goal, of course, is to get you over those hurdles in a way that you can figure out how to do those things on your own. 

And so when it comes to just using the internet, be it Google, or Stack Overflow, or interacting with other humans, just finding answers when it comes to the world of programming or really just the world of problem solving more generally, we hope that is actually a lasting skill. And we hope that you've been able to do that with admittedly frustration, but with the safety net of the course underneath you all these months. But here on out, we hope you'll be more comfortable, again, being uncomfortable as you figure out new things. 

And part of that is just reading documentation. And here, too, this is a frustration that may very well never go away. Like, some documentation out there for certain languages or libraries, just isn't good. It was written by people that just don't think like you or I do, don't think with the same form of empathy as you might hope. 

And therefore, it's written at a very low level of technical detail, and they don't just tell you what does the function do. Or conversely, it's written at such a high level that, my God, you have to start looking at the source code of the library to even figure out how to use it. And you will see both extremes. But getting comfortable with reading things like Python's documentation, like some API's documentation is just going to empower you, we hope, all the more to just do much cooler things and solve more powerful problems on your own, ultimately. 

And then lastly, and this is perhaps the biggest one, teaching you how to teach yourself new languages. There is a reason we didn't spend that much time on Python. And we spent even less time on JavaScript. And about an equal amount of time on SQL. 

We spent a number of weeks on C, not because C is more important than any of those languages, but because along the way, many of you, most of you were just learning programming itself. And even as the language has changed and evolved as the course went on, the ideas didn't go away. There were still functions, and conditions, and loops, and even events by terms. 

And, again, so we hope that you walk away from a class like this not thinking that, oh, I learned how to program in C. Or oh, I learned how to program in Python. Because none of us have been experts at those things yet. But you certainly are now more expert at just being a programmer and figuring out what holes you need to fill in in your knowledge, what gaps you need to fill in order to figure out, oh, what is the syntax for this same approach in this language as I've already seen in another. 

And that's, indeed, why we compared so many of these languages side by side to just reinforce that the ideas are no different, even though the syntax is going to require a bunch of Googling, a bunch of asking. And that, too, is something we hope you'll be able to do on your own as the next and best thing comes along well after these languages. 

Well, speaking of training wheels, you're welcome and encouraged to keep using CS50 IDE for your final project. And heck, you can use it even after that for other courses or projects. But at the end of the day, this, too, is probably a training wheel that you should take off for yourself. 

The IDE is designed to be representative of a real world programming environment. But we definitely did a lot of things for you. We installed all the libraries you might need over the course of the semester for you. We've got these nice commands that end in the number 50. Those don't tend to exist in the real world when you're at your first job, or you're going back to your own department and solving some problem in code, there's not going to be a help50 longer term. 

And so what we thought we would do, too, is spend just a few minutes giving you a sense of what are some of the more industry standard tools that you should consider using, playing with, perhaps over break or in the months to come, so that you know exactly how to do the same kinds of things you did this term, but on your own Mac or PC or some other device. 

So for instance, if you would like to install a set of command line tools on your Mac or PC, turns out some of them are already there. Indeed, I mentioned at one point that Mac OS has under its applications folder utility's terminal a terminal window. And Windows has an analog as well. 

But there's other commands that don't necessarily come with your Mac or PC, for instance, a compiler for C or some other tools. And so we would encourage you to visit URLs like these on your Mac or PC, respectively, if you'd like to just install more of the command line tools that you saw and used in CS50 in your own environment. 

Another tool we would recommend that you read up on, or in this case watch, a video by Brian, is Git. Git is an example of version control, a fundamental building block of any good software practice these days. 

We kind of use Git in CS50, but we hide this detail from you. Any time you have run check50 or submit50, we underneath the hood, have been running an open source command called Git, which pushes your code, in this case from CS50 IDE to GitHub.com, which is just one of several popular websites via which you can host code, share code, collaborate on code, run automated tests, and the like. But Git itself can be used to put an end to the convention that you probably have, even with things like Microsoft Word or Google Docs, where when you want to save something or another copy of a file, maybe you just changed the end of the file name to 2, and then the next time to 3, or to 4. Or maybe you do dash Sunday night, dash Monday morning. 

I mean, I'm still guilty of this sometimes when I want to version my files. There are better ways to do that. And so if you find yourself in the future, doing something that you think there's got to be a better way, Git is an example of one of those better ways. And if you watch this particular video, read up a bit more, it will help you not only maintain multiple versions, in essence, backups of your own code, it will also empower you ultimately to collaborate with others. 

As for text editors, the tool that you might use to actually write code, perhaps one of the latest and greatest and most popular out there these days is something called VS Code. This is an open source tool that you can download on your own Mac and PCs. Increasingly, it's available on the web as well. 

But this is one of the most popular tools, certainly, out there today. But it's just a text editor. And there are absolutely alternatives to each and every one of these tools that you're certainly welcome to take a look at as well. 

Well, if you're interested in the web side of things, and you want to host a website, like a static website, just your own personal homepage, GitHub pages is a thing. Netlify is a thing. And dot dot dot, there are so many other web hosts out there, many of which offer free or student level accounts so that they don't necessarily need to even cost anything. 

But static is different from dynamic. And if you actually want to host a web application that actually takes user input, stores things in a database, does more interesting things than a static website, you might want to use something called Heroku, which is just a popular third party service that also has a free entry level account that you can use to start playing with, quite commonly used by students for final projects. And then there's other providers out there, bigger cloud providers, so to speak, like Amazon, and Microsoft, and Google, for which the learning curve's perhaps a little higher. But they, too, are really good typically about providing discounts or free accounts for student uses as well. 

How to stay abreast of topics in technology. We focus, of course, in a class like this really on fundamentals. But you're not going to be able to pick up the news in any form down the road and not see something that's technology related. And if you'd just like to keep your fingers on the pulse of things in the tech world more generally, here's just a few places that you might enjoy staying abreast of. 

So Reddit has a couple of different communities, or subreddit, specifically about programming, both for experienced programmers and those of us who are still learning. Stack Overflow, of course, you've probably used to solve small problems over the course of the past term. Server Fault is similar in spirit to that, but it's focused more on administration, Linux-type stuff as well. 

Techcrunch is a popular place, not just for consumer-focused news, but just really anything that's trending in tech. And then a website called Hacker News on YCombinator's site that also is a place to just glance at once in a while because you'll see the latest and greatest libraries or something that's quite nascent. So if in general you just want to get a sense of what's new and what's trending out there in the tech world, things that you should just be aware of even if you don't care to get into the weeds of doing those things hands on, these are all good sites and surely others out there as well. 

And then, CS50, of course, has its own online community, some of which some of you have been part for some time, in high school or even prior. Please feel free to keep in touch with us in some way, or give back a little something to your successors who might take this or another course down the road and participate not only in asking questions in these communities here, but also in answering others' questions as well. 

So we thought we would do a little less of the talking now and turn things around for a sort of final community activity together. Thanks to many of you who have contributed questions over the past couple of weeks. Thanks to Brian, we thought we'd put together a CS50 quiz show on which to end this final lecture. 

These are questions written by you, by the staff, by Brian. And it'll be an opportunity for everyone to buzz in with their answers to some 20 questions that we have prepared in advance. Time is of the essence. So your score will be higher if you buzz in more quickly. So it's important not only to be correct, but also to be fast for this particular one as well. 

And in just a moment, I'm going to go ahead and share my screen. And, again, we'll have some 20 questions here, all of them drawn from, inspired by CS50 in some form. And after each question, depending on how many people get it right or wrong, we'll take a moment to at least explain where it is you went right or where it is you went wrong. 

All right, Brian. Ready on your end? 

BRIAN YU: We are ready to go. 

DAVID MALAN: All right, well, let's go ahead and take a look with the first question here. What are the steps for compiling source code into machine code? 

Preprocessing, compiling, assembling, and linking? Writing, compiling, debugging, and testing? Processing, creating, asserting, and clang? Or make? Go ahead and buzz in on your phone or laptop or desktop, using that same URL that Brian provided. 

You've got 20 seconds for each question, two of which now remain. That's it for time. Let's go ahead and take a look at the results here. 

It looks like 70% of you said preprocessing, compiling, assembling, and linking. Brian, would you like to tell us if that's right? 

BRIAN YU: Yes. That is the correct answer. Preprocessing first, compiling, assembling, and linking, all of that is behind the scenes. So you don't necessarily think about every time you compile. But those are, indeed, the steps. 

DAVID MALAN: And to be fair, make is arguably an abstraction for all of that insofar as it just kicks off the whole process. But I think a little more precisely, an answer to steps would be, indeed, those four things there. 

All right, let's take a look at the scoreboard here. We have a whole number of guest accounts. Guest number 200 is in the lead, but tied with several other guests here. So those of you with 1,000 points buzzed in really quickly. So again time is of the essence. 

Next question, what is the runtime of binary search? Is it O of 1, O of log n, O of n, or O of n squared? 15 seconds remain, the runtime of binary search. 

Recall, this was one of the first algorithms we looked at. It was first incarnated with a phone book, even if we didn't call it that by name early on. Brian, let's take a look at the results. Looks like 61% of you say log n. Brian? 

BRIAN YU: Log n is the correct answer. If you remember that phone book, the question really came down to how many times can we divide that phone book and half again and again and again, until we get down to just one page. And that turns out to be log of n if three are n pages in the phone book. 

DAVID MALAN: Indeed, and sort of pro tip moving forward in life, any time you see something happening in half and half and half and half, odds are there's going to be an algorithm involved somewhere in the analysis thereof. All right, next leaderboard here, guest 200 slipped down a little bit. But we have a whole bunch of people tied in first place for 2,000 points now. 

Next question, which of these animals was the first to be mentioned in a CS50 lecture? Llama, python, duck, cat. 15 seconds remain. Which was mentioned first in a CS50 lecture? 

And let's see the results. Looks like cat just barely eked out duck with 51%. Brian? 

BRIAN YU: And cat is, in fact, the correct answer. Llamas showed up in Lab 1, but they were not mentioned in lecture. The duck didn't show up until a little bit later when we talked about debugging. And Python was briefly mentioned at the end of the lecture. But it was after we introduced ourselves to Scratch. And the main character in Scratch is, of course, the cat. 

DAVID MALAN: All right, we're probably going to see a bit of spread here soon. We have a whole bunch of people with 3,000, though. But the names are starting to vary. 

Let's move on to the next question. Every time you malloc memory, you must also be sure to-- realloc, return, free, or exit? Every time you malloc memory, you should also be sure to realloc, return, free, or exit? Recall that malloc was the source of a lot of segmentation faults mid-semester. 

The responses now are 78% said free. Brian, do you concur? 

BRIAN YU: And they are all correct. Whenever you malloc memory, ask the computer for some memory dynamically. When you're done with it, you should give it back to the computer by calling free. 

DAVID MALAN: Indeed, and Brian, as a teachable moment, why is it that we never had a call free forget_string, which we now know underneath the hood is using something like malloc to allocate memory? 

BRIAN YU: So get_string was a function in CS50's library. And CS50's library takes care of that memory management process for you. So you didn't have to worry about freeing all of that memory yourself. 

DAVID MALAN: Indeed, but anytime you call malloc, you must call free. All right, the leaderboard here looks like we have guest 600 still in the lead with 4,000. Next question. 

What is a race condition? When conditions are nice out for racing? When two things happen at the same time and produce an unexpected result? When a line of code is executed too quickly? When a line of code is executed too slowly? What is a race condition? 

Ah, things just escalated quickly. But you'll recall this came up in the context of SQL. And databases, 0 seconds, let's see. 85% said when two things happen at the same time and produce an unexpected result. Brian? 

BRIAN YU: That is the correct answer. I appreciate that at least 1% of people said when conditions outside are nice for racing. But in the context of computer science, at least, when two things happen at the same time and could produce an unexpected result, that is what we would refer to as a race condition. 

DAVID MALAN: Indeed, recall that's how Brian and I ended up with too much milk in the refrigerator. Because we both inspected the state of that variable at essentially the same time. 

All right, the leader board here. Now we have a whole bunch of people with 5,000 points. Let's move on. 

Does zooming in on a photo let you enhance it to generate more detail? Yes, just like in CSI. No, a photo only has a certain amount of detail. Does zooming in on a photo let you enhance it to generate more detail? 

And I will admit, I was watching some show recently and thought of you all when they literally said, enhance. All right, 0 seconds. Looks like 93% of you said, no, a photo only has a certain amount of detail. 7% of you said yes, just like in CSI. Brian, can you help us reconcile the two? 

BRIAN YU: The 93%, in this case, are correct. A photo only has a certain number of pixels. And if you keep zooming in on one pixel, you're not going to be able to generate additional detail that wasn't there before. 

DAVID MALAN: And to be fair, that's kind of sort of changing. Or at least the answer is getting a little harder nowadays with machine learning or artificial intelligence, where algorithms sort of figure out what level of detail could or should be there. But that really is just statistical inference, that is not actually recovering information that was ever stored on the camera or some other device. 

All right, the leaderboard now is at 6,000 points with these folks tied. Which of the following is not a characteristic of a good hash function? Deterministic output, randomness, uniform distribution, efficiency. Things just got real again. 

Which of the following is not a characteristic of a good hash function? Recall we used hash functions in the context of hash tables when talking about data structures. All right? One second. 

The answers are more spread this time. 62% don't like randomness. Brian, should they? 

BRIAN YU: And that is the correct answer. Randomness is not a characteristic of a good hash function. You want your hash function to always give you the same output given the same input. That way you can rely on whatever the output of it is. If it's random, it's going to be hard to use. 

DAVID MALAN: Indeed, consider a spellchecker that randomly says yes or no. This is a word, probably not a property you want. 

All right, the leaderboard now, we're eking our way up to 7,000 points, but finally starting to see some spread. So a few of you haven't been quite quick or correct enough. 

Next question, what does FIFO stand for? FIFO. Is it a common dog's name, your credit score, first in, first out, function input, file output? What does FIFO stand for? 

I'll be curious to see the spread here. Let's see. 80% of you said first in, first out. Brian? 

BRIAN YU: That is correct. And that was what we were using to describe what would be called like a queue, where the first thing in the queue is the first thing that comes out of the queue. So it obeys that FIFO ordering. 

DAVID MALAN: Indeed, let's see the leaderboard here. All right, we have some 8,000s, but more in the 7,000 range. Next up is a more colorful question. 

Which of the following would represent pink using RGB values? And I'll let you read these on your own. And surely, there's some Googling happening behind the scenes now. 

But that's OK. In fact, Google is pretty smart. If you type in a hexadecimal code, it might even show you a little color wheel or swatch. 

All right, let's take a look at the results. Looks like 55% of you said ffd0e0. Brian? 

BRIAN YU: And that is correct. So those RGB values are like six different values, where each two correspond to one color, two for red, two for green, two for blue. This is all in hexadecimal. 

And pink would be a lot of each of them. Because it's very close to white, which is, like, all red, all green, and all blue. But it's more red than it is green and blue. And so that one, ffd0e0, is a lot of red, a little bit less green, and a little bit less blue. 

DAVID MALAN: Indeed. All right, let's see where we're at here. We're now up to-- interesting. No one has a perfect score anymore. But guest 200 is still in the lead with just shy of 9,000 points. 

In C, which of the following lines of code allocates enough memory for a copy of the string s? I'll let you read these. In C, which of the following lines of code allocates enough memory for a copy of the string s? 

Bunch of viable choices here, it would seem. And time, let's take a look at the results. Looks like 46% said malloc of size s. But Brian, 33% said malloc of strlen of s plus 1. Who is right? 

BRIAN YU: And in this case, the minority, the 33% are correct here. Malloc, remember, takes as its argument the number of bytes of memory that you want to allocate. And if you have a string and you want to figure out how many bytes you need, first thing you need to know is figure out how long is that string. strlen will tell you how many characters are in that string. 

But you do need one additional byte, because at the end of every string, we have that null terminating character. And we need one byte of memory for that. So strlen of s will give you the length of the string plus 1. That's how many bytes you need for memory. 

DAVID MALAN: Indeed. And see, you get nothing for free. Anything you want you need to do yourself. And indeed, the plus 1 is a problem for you to solve. 

The distribution now, guest 200 still in the lead with just shy of 10,000 points. That was question 10. We're in the second half of the game. 

How should you organize your clothes to be cool? This is number 11. Stack, queue, dictionary, binary tree. How should you organize your clothes to be cool? 

You might recall Jack and Lou, who taught us this one. Two seconds remain. And it looks like 48% said queue, Brian. 

BRIAN YU: And that is correct. So from that video with Jack and Lou, there were different ways of organizing the clues. But the conclusion of that video was, you want to put your clothes in a queue. So that after you're done with one, you put it at the end of the queue. And you use something else before you go back to the one you already wore. 

DAVID MALAN: Indeed. All right. And the leaderboard now, looks like guest 10 broke 10,000. But so did a bunch of other people. 

Next question, what is a segmentation fault? When a computer runs out of memory, when our program tries to read an empty file, when a program tries to access memory that it shouldn't, when an earthquake happens. Looks like a lot of these could be pretty close. Two seconds. 

And let's see. Looks like 80% said when a program tries to access memory that it shouldn't. Brian? 

BRIAN YU: That is the correct answer. Segmentation fault can happen if you're trying to touch memory that you're not supposed to have access to inside of a program. 

DAVID MALAN: And for the 13% of people who said when a computer runs out of memory, why is that not quite the answer here? 

BRIAN YU: So the computer could run out of memory. Where when you call malloc, malloc might return null, because there's no available memory to allocate. But as long as you check for that, and we try and encourage you, whenever you're mallocing memory, to check to see if the value you get back is null. That can help you to avoid those types of errors. 

DAVID MALAN: So let's take a look at the board now. 11,000 something for guest 200. Let's now proceed with this question. Which of the following types of overflow can result from recursion without a base case? Heap overflow, integer overflow, stack overflow, buffer overflow. 

And all forms of overflow, indeed, came up. One of them is also, of course, the name of a popular website. But all of these are actual things. But which is correct? 

All right, let's see the results. Looks like 61%, 60% went with stack overflow. Brian? 

BRIAN YU: And that is correct. Every time you call a function, you end up getting a little bit of memory on the stack for that function. And if you keep calling that function recursively over and over and never stop, because there's no base case, then you can run out of stack space. And we call that a stack overflow. 

DAVID MALAN: Indeed. All right, let's see the leaderboard now. Guest 200, still the one to beat. But guest 216 is not too far behind. 

Next question. In the town of Fiftyville, what were the names of the three people who witnessed the rubber duck robbery? I'll let you read these. In the town of Fiftyville, what were the names of the three people who witnessed the rubber duck robbery. A new problem this year, recall that he disappeared altogether from the IDE for that week. 

All right, let's see the results. Brian, this one is close. 33% said Ruth, Eugene, and Raymond. 

BRIAN YU: And Ruth, Eugene, and Raymond is correct. They've got more responses than any of the others. It was tricky. But yeah, that's the correct answer. 

There wasn't a whole lot of reason behind the names. I put a lot of thought into the story itself. But not a lot of thought to the names. Those were kind of just randomly selected. But those were the names of the witnesses. 

DAVID MALAN: Indeed. And the leaderboard now, we still have guest 200 is the one to beat. This is question 15. So we are nearing the end, still chance to pull ahead. 

Which of these command line programs checks your code for memory leaks? Valgrind, clang, mkdir, make. Notice that none of these have 50 on it, which means these are all real world commands that you would continue to see on your own Mac or PC or some future Linux system. 

And let's see the results. Here we have valgrind, the clear winner, 78%. Brian? 

BRIAN YU: And that's the correct answer. That's the program you can use in order to check your program to see if you have any memory leaks, to see if you're touching memory you shouldn't, if you're forgetting to free something. Valgrind is useful for all of that. 

DAVID MALAN: And if I may, I feel like 5% of you are just messing with us now. Hopefully, but we shall see. 

All right, last five questions to go. After taking a look at the leaderboard now, guest 200's still up at the top. Which of the following exists in C, but not Python. Boolean expressions, do-while loops, recursive functions, floating-point numbers. 

Which of the following exists in C, but not Python? An interesting comparison between two languages that goes beyond syntax. All right. 

Time's up. Let's take a look. Looks like 68% went with do-while loops. Brian? 

BRIAN YU: That is correct. Python has for loops. Python has while loops. But it doesn't have do-while loops in the same way that C does. You'd have to find some other way of trying to achieve that same kind of logical idea. 

DAVID MALAN: Indeed. And Brian, what was the approach that we took when we tried to recreate that some weeks ago? 

BRIAN YU: Yeah. So one approach to it is having an infinite loop, while true, that will just always repeat. And then when you reach a point where you can exit the loop, you can use the command break to get out of the loop and move on to the rest of the program. 

DAVID MALAN: Indeed. All right, let's take a look at the board. Guest 200 still now at 15,938, but still a few close folks behind. 

What HTTP request method should you use when sending private information like a password? GET, POST, SELECT, or TEXT? Which HTTP request method should use when sending private information like a password? 

Take a look at the results. All right. And the distribution is a lot of people said POST, Brian, 74% 

BRIAN YU: And they are correct. Yeah, if it was a get request, then you would end up with sensitive information inside the URL that might show up in your browsing history, for example. So to be secure, you want to be sure to use the POST request method for that type of stuff. 

DAVID MALAN: And to be clear, don't do this. Get is possible, and we saw how to do that. But of course, that then ends up in your history and other exposed places. SELECT and TEXT were not HTTP verbs. So POST is indeed spot on. 

All right, only three questions remain. Guest 200 is still the one to beat, followed by guest 216. What data structure allows for constant time look up for words in a dictionary? A linked list, a binary search tree, an array, or a trie? 

Recall that a dictionary was an abstract data type, insofar as you could implement it in different ways. But to get constant time look up, you might want to use one of these over the others. Let's see the results. Interesting. Brian, 32% said trie. Can you help us out here? 

BRIAN YU: Yeah. The trie is the correct answer. For all of the others, the linked list, the binary search tree, and the array, as you have more and more words in the dictionary, it's going to take longer and longer to find a word, as you have to either linear search through it or you have to go down through various nodes in the binary search tree. The trie on the other hand, it only depends upon the length of the word that you're looking up. It doesn't matter how many words are in the dictionary. You just follow one node for each letter in the word you're looking up. And you'll find that word in constant time. 

DAVID MALAN: And Brian, if constant time, Big O of 1 is so good, why not use tries, then, for everything? 

BRIAN YU: Well, there are trade offs for everything. The trie gives you theoretically constant time. But one of the big trade offs is memory. That tries end up using much more memory to be able to store a dictionary than many of those other data structures would. 

DAVID MALAN: Indeed. Let's look at the results. And guest 200 still at the lead. But guest 752 is now nipping at their heels. We have two final questions. And speed, again, does matter. 

What is a cookie? Data used to identify your computer to websites, a delicious snack, both of the above, or none of the above. This is a tough one, Brian. 

Especially if there's only one right answer. We might see a bit more of a split. Which of these is a cookie? 

All right, let's see the results. Data used to identify your computer to websites with 60%. Both of the above was 35%. Only 2% of you like cookies alone. Brian? 

BRIAN YU: Both of the above was the correct answer. I'll remind that all of these questions were written originally by students and the answer choice of students selected as the correct one was both of the above. 

DAVID MALAN: All right. And now the second to last leaderboard, Guest 200 is still in the lead. But there's been some variance toward the bottom there. Very last question of CS50 itself. What's your comfort level now? And we'll let you decide among these answers, too. 

All right. Answers are all in. Let's take a look at the distribution. Looks like 43% of you said you're among more of those more comfortable. 24% of you went with the second. 19%, very fascinating distribution from top to bottom. 

But the point is that you are all indeed now officially inducted into those more comfortable. Thank you so much for joining us in CS50. We cannot wait to see your final projects. This, then, is the end. And this was CS50. 

[MUSIC PLAYING]