Placeholder Image

字幕表 動画を再生する

  • SPEAKER 1: All right, this is CS50, Harvard University's introduction

  • to the intellectual enterprises of computer science

  • and the art of programming.

  • And this was apparently me around the time

  • that I sat where are you guys now sitting thanks to a teaching

  • fellow who spent a little too much time trolling around Lemont Library, where

  • the 1995 freshman registers apparently still are.

  • And I point this out because this was a big deal for me

  • back when I was a freshman and ultimately

  • sophomore considering to take a class like this, CS50, but more generally,

  • computer science.

  • And if you, like me, have this perception of computer science

  • from high school or even middle school, you

  • might have the perception that it's entirely based about programming.

  • It's perhaps a bit antisocial.

  • It's perhaps the computer lab, heads down,

  • sort of coding away on something that you don't necessarily understand.

  • And yeah, I too had that perception freshman year in this course

  • and, dare say, the field more generally, really did

  • have this reputation to beware.

  • I certainly assumed that most everyone around me

  • certainly knew more than I did.

  • And this wasn't just true of CS for me.

  • This was true of most any field at Harvard in the course catalog

  • that I had no familiarity with.

  • And so I instead gravitated toward the more comfortable.

  • I took a lot of gov classes and economics and history

  • just because that's kind of what I knew and liked in high school.

  • I wouldn't say I loved it, but I knew it and it was within my comfort zone.

  • And it wasn't until sophomore year that I got up

  • the nerve to take this class, CS50.

  • And I only did because the professor at the time let me take it pass-fail,

  • now called SAT/UNSAT.

  • And that allowed me to get over this sort of mental hurdle

  • that I imposed upon myself, sort of fear of failure

  • or simply not doing as well as I might have been accustomed to.

  • And so I bewared a class like this until then.

  • And I always kind of regretted not exploring earlier on.

  • And that doesn't have to be this class.

  • It doesn't have to be CS but can be really any field more generally.

  • But those really were my takeaways around the time I looked like this.

  • And I've taken comfort since in taking over this class

  • and have found it inspiring that these days, 68% of the students in this room

  • and in this room last year had never taken a CS course before.

  • So if you do have that mental model of everyone to your left

  • and your right surely must know more than you, odds are it is not,

  • in fact, the case.

  • In fact, within CS50, we have these different tracks, different types

  • of sections for students less comfortable, students more comfortable

  • and students somewhere in between.

  • And there's no formal definition to these labels.

  • You just sort of know it if you are.

  • And if you kind of have one foot mentally out the door today

  • because you're not really sure this is for you,

  • you're probably among those less comfortable.

  • But as such, you're in the majority, 56% of last year's students.

  • If by contrast, you have been programming

  • since you were eight years old, 10 years old,

  • whatever but you're largely self-taught and therefore

  • maybe have lots of gaps in your knowledge

  • or don't really understand all the formalities,

  • you just kind of figure things out, you might be among those more comfortable.

  • And if not, maybe you're somewhere in between.

  • And so in CS50 sections, do we have similar students together,

  • similar comfort level, similar backgrounds,

  • so that everyone can kind of feel comfortable speaking up not knowing

  • things, knowing things, and beyond.

  • Because ultimately, the course is graded and assessed ultimately very much

  • manually, very much very delicately with respect

  • to students' prior background or lack thereof.

  • Indeed, what's most important at the end of the semester

  • is not so much where you end up relative to your classmates

  • but where you end up in week 11, our very last week, relative to yourself

  • today in week 0.

  • And in fact, thanks to CS50's own Haley James and a whole bunch

  • of CS50 team members-- this summer, they spent

  • a while traveling around the country bringing folks back

  • to campus, alumni and former students and staff who had some connection

  • taking or teaching CS50 in some form.

  • And if you'd like to see stories of some of your predecessors and folks who sort

  • have found their way-- accidentally, even--

  • to computer science finding challenge along the way,

  • check out this domain that the team put together-- project5050.org.

  • Now the course itself ultimately is not about programming per se.

  • That's indeed a tool that we'll use.

  • It's really about this.

  • And that's really what CS is, the field more generally.

  • Whether you're starting hardware or graphics or theory or any number

  • of fields, artificial intelligence these days, machine learning and beyond,

  • it's really just about solving problems.

  • And what's really cool about CS I found early on

  • is that it doesn't necessarily-- it's not an end unto itself.

  • It's this field that empowers you to go do more interesting, more powerful

  • things in the humanities, social sciences, physical sciences, the arts,

  • anything because you have this new mental model for how you can solve

  • problems better, more efficiently, how you can solve them correctly,

  • and how you can sort of analyze large datasets

  • or solve problems that might have otherwise been beyond your grasp.

  • So what does this mean?

  • What is problem solving?

  • Well we could perhaps distill it as simply

  • as this-- a big black box, some secret sauce,

  • into which go inputs, like the problem we want to solve,

  • and out of which comes outputs, the solutions that we want.

  • So a very generic way of describing it, but what's

  • pictured here in the black box is the so-called algorithms.

  • And we'll come back to that in just a bit

  • the actual ingredients for solving problems.

  • But how do we represent inputs and outputs?

  • Odds are even if you're not a computer person and don't really think like one,

  • you probably know that computers only understand a very limited vocabulary.

  • Like, what is the alphabet, so to speak, that they speak?

  • ASCII maybe, but more--

  • AUDIENCE: Binary.

  • SPEAKER 1: Binary, binary, bi meaning two for zeros and ones.

  • So whereas we humans typically use decimal--

  • dec meaning 10, 0 through 9-- as in our alphabet of letters,

  • computers of course, as you may have heard, only use zeros and ones.

  • Now why is this powerful?

  • Well, turns out as soon as you have at least two digits in your alphabet,

  • you can start to represent things much more powerfully and much more

  • efficiently.

  • For instance, how many-- if I wanted to count the people in this room,

  • how many of you could I count on just one hand?

  • Hopefully five.

  • So I could call five.

  • It would be one, two, three, four, five.

  • But you know what?

  • If I were a little more clever, I bet I could use the same hand

  • and count as many as 32, maybe 31 of you.

  • Well, how is that?

  • Well, right now, I'm kind of using the unary system, uno meaning one.

  • So it's just one digit in your alphabet-- the finger or no finger.

  • It's not quite the same as zero or one--

  • so one person, two, three, four, five.

  • But what if I instead permuted my fingers in some way

  • so that the pattern of fingers that are up actually matters,

  • not just the quantity?

  • So maybe this is still 0 this now is 1.

  • And instead of 2 being this, maybe two could be this.

  • So if my second finger is up, I'm going to call that two.

  • And if my first two fingers are up, I might call that three.

  • Somewhat offensively, if just this finger is up,

  • I might call this four and then five.

  • And then this gets kind of painful--

  • six, seven.

  • And what I'm actually doing is counting in binary.

  • Now that might have looked completely cryptic,

  • but it turns out as soon as you have two digits, that's

  • enough to represent anything you want and to do so pretty darn efficiently.

  • But why?

  • So odds are, if you're like me, you probably grew up learning,

  • of course, the decimal system, zero through nine.

  • And you might have written on the board some points like this number--

  • 123.

  • But why do you think of that as 123?

  • It's really just a pretty pattern of symbols--

  • glyphs, so to speak-- on the screen that we ascribe some kind of mathematical

  • meaning to--

  • 123.

  • But really, it's just like someone drew in ink on the screen some symbols.

  • Well, if you're like me back in grade school,

  • you probably learned that the right-most number here

  • is in the so-called what place?

  • The ones place, right?

  • And so if we wanted to label these things,

  • we might put ones place there and then of course the tens place

  • and the hundreds place, maybe the thousands, 10,000, and so forth.

  • So we had this sort of mental models for the columns.

  • And notice they happen to be powers of 10.

  • 10 to the 0 is 1.

  • 10 to the 1 is 10.

  • 10 to the 2 is 100 and so forth.

  • So that's the pattern even if your grade school teacher didn't

  • talk about exponentiation at the time.

  • So why is this number 123?

  • Well, it's because we have a one in the hundreds column--

  • so 100 times 1.

  • We have a two in the tens column.

  • We have a three in the ones column.

  • Them.

  • And of course, if we start to do the arithmetic now,

  • that's 100 plus 20 plus 3 or obviously 123.

  • And all of us take that certainly for granted these days.

  • You see a number, you know what it is mathematically.

  • But computers fundamentally work in the same way.

  • So even if you up until now have never thought of yourself as a computer

  • person or had no idea really what it means

  • for computers to speak just zeros and ones, all you have to do

  • is update the places.

  • Instead of powers of 10 dec, meaning decimal, we're going to powers of two

  • for binary.

  • So now we're going to have 2 to the 0 2 to 1, 2 to the 2, 2

  • to the 3, same idea.

  • It's just a different base.

  • We change tend to 2.

  • And so now we have places like this--

  • 1, 2, 4, and if we kept going, 8 16, 32, 64, and so forth.

  • So as such, what number is this on the screen in binary if you convert it

  • in your head to decimal?

  • It's just the number one, right?

  • Because you've got a 1 in the ones place and then a zero in every other place.

  • So it's just 1 times 1 equals 1.

  • Now if I were using unary or my hands, the sort of traditional way, two

  • would be this where you put up two fingers.

  • But not if you're trying to use patterns as well as quantities.

  • And so in binary, how do I represent the number two?

  • 010.

  • It's the equivalent of putting up just my index finger here.

  • And if I want to count to three, now I need to add a 1 to the mix.

  • So I add the ones place.

  • And now if you start to visualize this, it's

  • like one of those really old school clocks where

  • the numbers flip around and roll over.

  • Now those ones are going to kind of flip and become zeros

  • and the zero is going to become a one.

  • And so now we have five and then six and then seven.

  • And then dang it, how does a computer count to eight?

  • Yeah, you just need to add another place, right?

  • Just like we humans don't have an infinite number of numbers

  • when we write something down-- we sort of stop

  • when it's not necessary-- all we need is another bit.

  • We just need to add another 0 or 1 to the left, specifically a one.

  • Then all these ones can become zeros.

  • And we can do this toward infinity.

  • But where are these bits coming from?

  • This is all very abstract and just pictures on a screen.

  • Well, it turns out that we have one physical ingredient

  • to all of our computers.

  • Maybe it's your laptop or desktop or your cell phone.

  • At the end of the day, they're either driven these days

  • by batteries or like a cord into the wall where electricity comes from.

  • And even if you have little familiarity with electricity,

  • you probably know that it's like little electrons flowing.

  • So there's some kind of physical resource that can flow or not flow.

  • You can turn it on or off.

  • Well, much like these desk lamps here, here I

  • have three physical lights that are of course connected into the electricity.

  • So I have some physical input.

  • And now that I do, I can kind of implement my own computer

  • using these simple desk lamps.

  • If I want to represent some value, some input or output, OK, here's the zero.

  • This is zero in binary.

  • I just need to leave three light bulbs off.

  • If I want to represent a one, I need to turn this on.

  • And that's now the ones place.

  • If I want to represent two, I just need to turn this light on.

  • If I want to represent three, this one comes on.

  • If I want to represent four, that goes on.

  • 5, 6, seven, and then of course we need like 8,

  • if we want to represent and turn these off, four total bits together.

  • And so that's all that's going on inside of your phones and your computers.

  • Phones and computers and devices these days

  • have what are called transistors, which are tiny little switches that

  • are on or off.

  • And that's all we need if we have some source like electricity to just store

  • information.

  • We just need lots and lots of switches, lots and lots

  • of light bulbs, certainly much smaller in order to represent information.

  • But computers of course can do much more than represent numbers.

  • What about letters and e-mails and things like that?

  • Well, for that, we actually need to kind of decide

  • as humans how we're going to interpret things like these light bulbs.

  • In one context like a calculator, or they might represent numbers--

  • decimal numbers whatever.

  • But in an email program--

  • Microsoft Word, Google Docs--

  • you probably want those light bulbs or those transistors

  • in the computers storing not just numbers,

  • or else you could just do math.

  • You want them storing letters and sentences and paragraphs and so forth.

  • And so we need to have some kind of mapping.

  • And we'll do that as follows.

  • ASCII, which is just an acronym describing

  • a mapping from numbers to letters-- humans years

  • ago just decided, you know what?

  • In the context where we need letters, let's

  • just store a pattern of bits that's equal to the number 65

  • if we want the letter a.

  • Pattern of bits equal to the number, decimal number, 66

  • if we want to store the number b.

  • Fast forward to h and i.

  • If you want to store h or i, 72, 73, and just store that many bits.

  • And now I don't care any more in this story how you represent 65 or 73.

  • I just need to know that you can somehow with light bulbs

  • on stage, with transistors in my phone, or whatever the device may be.

  • We can begin to abstract away these low level details.

  • In fact, we're not going to spend much time

  • after today talking about binary in CS50 because here, we

  • have sort of electricity conceptually.

  • On top of that, we can build the notion of binary, zeros and ones.

  • And once we come up with this convention,

  • now we can start to talk about letters of an alphabet.

  • But that's not the only thing we can talk about.

  • We can also talk about graphics and videos and all the things

  • we take for granted these days.

  • For instance, and just to recap, what message have I

  • encoded here on the screen if you recall?

  • AUDIENCE: High.

  • SPEAKER 1: Yeah, it's high because 72 and 73 I claimed a moment ago

  • are just the numbers we humans came up with years ago to represent HI.

  • I don't really know what 33 is.

  • You'd have to look it up or be told it.

  • Turns out it's an exclamation point because indeed humans decided

  • to express in numeric codes as well all the keys on a keyboard.

  • Unfortunately, they weren't very far sighted early on.

  • They only used 7 bits total and later kind of 8 bits.

  • But even that, even though that gives us over 200 possible values, 256,

  • there's a lot of languages that aren't in like the English alphabet,

  • Asian languages and the like, that have many, many, many more

  • symbols than you can express with just seven or eight bits alone.

  • And so now ASCII has been succeeded by something called Unicode.

  • And long story short, humans have begun to solve problems that were initially

  • created by not anticipating, needing, or wanting even larger values than these,

  • but in another context like Photoshop or any graphics program,

  • you might see the same pattern of bits--

  • 72, 73, 33.

  • But in those programs, they know to interpret these numbers

  • as some amount of color.

  • If you've ever heard of RGB--

  • Red, Green, Blue-- this is just an acronym that

  • describes how you can mix together three different colors,

  • sort of in the spirit of paint or more technically light,

  • combine these three different colors, and get any color of the rainbow.

  • So each of these numbers I'll claim can be from 0 to 255 and 72 out of 255.

  • That's like a medium amount of red.

  • That's like a medium amount of green and just a little bit of blue.

  • And if you combine those three colors by mixing them together

  • into just one dot or pixel, as it's called in a computer,

  • you get this sort of murky shade of yellow.

  • But in the context of Photoshop or some graphics program,

  • that is what those same three patterns of bits would be interpreted as.

  • And it happens to be the case that talking in terms of single bits,

  • it's not all that useful.

  • With one bit, you can count as high as one.

  • So humans long ago also standardized on a nomenclature a byte, B-Y-T-E,

  • is just 8 bits.

  • And if you've ever heard of kilobytes and megabytes and gigabytes

  • and terabytes and the like, those are just multiples thereof,

  • typically orders of magnitude of 1,000 or 1,024, or more.

  • So with just three bytes, 24 bits, can we

  • represent letters, numbers, and the like.

  • And ultimately, these are just examples of abstraction.

  • And this is going to be a thing that permeates

  • not just this class, but computer science more generally-- taking

  • very simple ideas that really don't seem all that interesting at first glance.

  • But as soon as you use them as ingredients to solve a problem,

  • you can then sort of reuse that tool to build something more interesting,

  • reuse that tool to build something more interesting

  • still until you get to work application development

  • and solving real problems that you care about,

  • taking for granted the people that came before you

  • have solved a lot of these lower level implementation details, so to speak.

  • So what is inside this black box?

  • It is what we shall call algorithms.

  • And an algorithm, if familiar, is what?

  • It's kind of a fancy looking word, but it's a simple thing.

  • What is an algorithm if anyone knows?

  • AUDIENCE: Step by step instructions.

  • SPEAKER 1: Yeah, it's just step by step instructions for solving a problem.

  • That's it.

  • That is an algorithm-- step by step instructions for solving some problem.

  • So what might be a problem that we want to solve?

  • Well, I'm reminded of, and we've--

  • I'm reminded of fifth grade.

  • My homeroom teacher was trying to teach us

  • as effectively as she could how to follow directions correctly.

  • And at the time, it was a complete disaster.

  • But I always remember from that example the demonstration

  • that she did because it lent itself, although she didn't

  • use this word at the time, to this notion of computational thinking

  • or thinking like a computer, if you will,

  • whereby you want to solve something correctly.

  • But to do, so you need to be fed very precise instructions.

  • And this is easier said than done.

  • And so in fact, to recreate this, thanks to the team here, we have a plate.

  • We have a loaf of bread.

  • We have a jar of creamy Skippy peanut butter.

  • And we have a jar of Smucker's Concord gape jam,

  • and then for the invariable need, a whole lot of paper towel

  • and this one knife.

  • And so let me propose that for just a moment,

  • I'll play the role of a computer or maybe

  • in this form like a robot who's implementing some algorithm where

  • you guys are the programmer, the person who's supposed to feed me instructions

  • so that I can solve the problem.

  • And the problem here will be to, implement, perhaps no surprise,

  • a peanut butter and jelly sandwich-- easy to sort of do intuitively

  • if you grew up eating these things.

  • But if you've never really thought about how to teach someone else to do it

  • and that someone else is not as sort of forgiving as another human

  • where we humans have conventions of just reading between the lines--

  • computers can't do that.

  • They will only do what you tell them to do.

  • And as such, they are less powerful, in some sense, than we humans.

  • So what's the first step for making with these ingredients--

  • these inputs, if you will-- a peanut butter and jelly sandwich?

  • AUDIENCE: Open the bag of bread.

  • SPEAKER 1: Open the bag of bread, I heard.

  • AUDIENCE: That's wrong.

  • SPEAKER 1: Correct, but not really what you had in mind, perhaps.

  • But that's OK.

  • The bag is open.

  • So what might a more precise step two be?

  • AUDIENCE: Remove two slices.

  • SPEAKER 1: Say again?

  • AUDIENCE: Remove two slices.

  • SPEAKER 1: Remove two slices.

  • OK.

  • AUDIENCE: Put those two slices on the plate.

  • SPEAKER 1: Put those two slices on the plate.

  • AUDIENCE: Drop the knife.

  • SPEAKER 1: Drop-- what?

  • Drop the knife?

  • AUDIENCE: [INAUDIBLE]

  • SPEAKER 1: OK.

  • AUDIENCE: Unscrew the jam.

  • SPEAKER 1: Unscrew the jam.

  • OK.

  • AUDIENCE: Grab the knife.

  • SPEAKER 1: Grab the knife.

  • AUDIENCE: Put the knife in the jelly.

  • SPEAKER 1: Put the knife in the-- oh.

  • What?

  • AUDIENCE: Other end of the--

  • SPEAKER 1: Oh, thank you.

  • Right?

  • Grab the knife from the other end.

  • Someone from farther back, perhaps?

  • AUDIENCE: Stick the knife in the jam.

  • SPEAKER 1: Stick the knife in the jam.

  • What's that?

  • AUDIENCE: Take it out.

  • SPEAKER 1: Take it out.

  • OK.

  • Again?

  • AUDIENCE: Put the knife in the jam.

  • SPEAKER 1: Put the knife in the jam.

  • Ow.

  • Scoop it.

  • AUDIENCE: Yeah.

  • Dump it on the bread.

  • [LAUGHTER]

  • SPEAKER 1: OK, we're halfway there.

  • Now what?

  • AUDIENCE: Spread the jam with the knife across the bread.

  • SPEAKER 1: Spread the jam with the knife across the bread.

  • AUDIENCE: Evenly!

  • SPEAKER 1: Oh, evenly.

  • Let's be careful here.

  • OK, OK.

  • Next?

  • AUDIENCE: Do the same thing you did with the jam with the peanut butter

  • on the other slice of bread.

  • SPEAKER 1: OK, so I think we did this first.

  • AUDIENCE: And this time, don't get a lot of peanut butter.

  • SPEAKER 1: We did this, then we did that.

  • Then-- oh.

  • All right, I'll take some liberties.

  • OK, and now we put it in again.

  • AUDIENCE: Scoop a little bit out.

  • SPEAKER 1: "Scoop a little bit out" I heard this time.

  • AUDIENCE: Onto the other slice of bread.

  • SPEAKER 1: Onto the other slice of bread, thank you.

  • AUDIENCE: Spread it evenly.

  • SPEAKER 1: Spread it evenly.

  • Next time, have me use my right hand please.

  • OK, and--

  • AUDIENCE: Put the knife down.

  • Put the jam side on the peanut butter.

  • SPEAKER 1: Thank you.

  • Put the jam side on the peanut butter and--

  • delicious.

  • OK.

  • Thank you very much.

  • [APPLAUSE]

  • So a silly example, to be fair, but just realize how much opportunity there

  • was even in something as simple as that for ambiguity or scenarios

  • you didn't anticipate.

  • And indeed, among the things we're going to do today

  • as we begin to formalize these ideas with code, with programming code,

  • are how you think about breaking down problems into their constituent parts,

  • considering what happened-- what should I do if this happens?

  • What should I do if this happens?

  • What should I do if this happens?

  • Because unless you anticipate the kind of silliness

  • that I was deliberately acting out there,

  • who knows what the computer might end up doing?

  • After all, odds are everyone in this room

  • like me has seen like a spinning beach ball or an hourglass

  • on your computer or your Mac or PC freezes or crashes.

  • And almost always that's just the result of some human error.

  • Someone at Google or Microsoft or Facebook or wherever made some mistake.

  • He or she did not anticipate some situation,

  • didn't anticipate you typing in a word that you did,

  • didn't anticipate you running 20 programs at once,

  • didn't anticipate some scenario.

  • And so as such, the computer's behavior was effectively undefined.

  • And so the incorrect solution was outputted.

  • So how do we begin to think about this?

  • What would be ideal if we somehow--

  • if we somehow formalize this by way of actual code.

  • And we'll do that with sort of another old school

  • problem, one that's a lot more digital these days

  • but it's still with us today.

  • Whether you have an Android phone or iPhone or anything else,

  • odds are you have like a little app for your contacts or your address book.

  • And then there are a whole bunch of names,

  • probably alphabetical by first name or last name,

  • and a whole bunch of telephone numbers and maybe more information like emails

  • and so forth today.

  • But the physical incarnation of that icon on your phone

  • is this old thing, a phone book.

  • And if I wanted to look for an old friend like, say, Mike Smith, how might

  • I go about finding him in this old school phone book?

  • Well, just as in my digital form, I might just

  • scroll through the list looking for him.

  • So could I look at the first page, look down, not see him, turn the page,

  • look down, not see him, turn the page, look down, not see him, and so forth.

  • Is this algorithm correct?

  • AUDIENCE: Yes.

  • SPEAKER 1: Yeah, it's correct.

  • It's kind of dumb right because it's going

  • to take forever to get to Mike if there's like 1,000 pages here,

  • but it is correct.

  • And it's the equivalent really of sort of slowly methodically scrolling

  • through your list of contacts without the luxury of like searching

  • or autocomplete or the like.

  • Well, I could do a little better.

  • Back in grade school, I generally learned to count by two.

  • So I could instead do 2, 4, 6, 8, 10, 12.

  • I'm flying through the phone book now clearly faster.

  • But is that algorithm correct?

  • AUDIENCE: No.

  • SPEAKER 1: No why?

  • AUDIENCE: You might miss him.

  • SPEAKER 1: Yeah, I might miss him, right?

  • Like Mike, just by chance, might be sandwiched between--

  • so it is, no pun intended-- between the two pages then I'm flying past

  • and I might miss him.

  • But I can at least fixed this mistake or bug, so to speak.

  • A bug is a mistake in a program, just human error.

  • If I hit like the T section, t comes after Smith.

  • So I can maybe double back at least one page and solve that bug.

  • So it costs me a little bit more time to double back, but if I do it right,

  • it only costs me like one extra page turn.

  • So better and now correct.

  • But obviously no one in this room is going to look for Mike Smith

  • by starting on the first page.

  • Where are you going to roughly look?

  • In the middle, maybe a little toward the end because you know where S's are.

  • And so you open the book to the middle.

  • You look down and you see the M section.

  • So I haven't gone far enough.

  • But what's nice about this old school technology

  • is that we can now tear this problem in half, throw half of it

  • away, and be left with fundamentally the same problem but a smaller version

  • thereof.

  • This now is maybe not 1,000 but 500 pages, but it is the same problem.

  • And I can apply the same logic, go roughly to the middle, look down.

  • I went a little too far this time, the T section.

  • But I can again tear off almost a quarter of that problem,

  • leaving me now with a total size of the maybe 250 pages

  • after dividing it in half twice now.

  • And now I can repeat and repeat and repeat.

  • And so long as Mike is in the phone book,

  • I should ultimately find him once and only once

  • on the final page of the phone book, at which point I can call him.

  • So the real question then is how much better was this.

  • It's a little wasteful.

  • You can't sort of undo here in the analog world.

  • But let's consider how we can think about how good that algorithm was,

  • the one that we all probably took for granted and should have started with.

  • Well, if here's a simple plot and on the x or horizontal axis

  • is the size of the problem--

  • so the number of pages in the phone book, however you want to measure it--

  • and then the y or vertical axis is time to solve--

  • so maybe number of seconds, number of page turns,

  • however you want to count up the steps--

  • that's a relationship, size to time.

  • And the first algorithm I'm going to draw

  • like this-- a straight line in red.

  • And I'm going to call it n where n is just like the number of pages

  • in the phone book.

  • Computer scientists tend to use n as a variable so to speak, just a symbol.

  • And it's a straight line for the following reason.

  • If the phone book gets a little longer next year, a little longer next year,

  • by like one page, that means I might have

  • to spend one more step looking for Mike.

  • So the slope of this line is linear.

  • There's a one to one relationship between number

  • of pages Verizon or the phone company puts in the book and the number of page

  • turns I need to make.

  • The second algorithm, though, is also a straight line,

  • but it's lower drawn here in yellow.

  • And n over 2 means it's twice as fast or equivalently takes half as much

  • time because for a given size problem, if you kind of follow my hand straight

  • up, the yellow line should be below the red line

  • because I'm flying through the phone book two pages at a time.

  • So it should take me half as much time.

  • But if I use the first algorithm, I have to go all the way up

  • to the red, which measures that number of seconds.

  • But the third algorithm is a fundamentally different shape.

  • And this is where the sort of beauty of computer science and algorithms

  • specifically comes out.

  • It doesn't become straight ultimately.

  • It looks like it's gradually easing off.

  • But it's going to do this forever.

  • It's just becoming such a slow increase in time--

  • you can't even really see it especially if the screen were even wider.

  • We'll call this logarithmic, log n, more on that down the road.

  • But the shape is fundamentally different.

  • It's curved.

  • And what's powerful about this-- and you can think about it much more easily,

  • intuitively.

  • If Verizon next year doubles the size of the phone book

  • because like maybe Cambridge and another town

  • merge together into one book, no big deal

  • because if Verizon doubles the size of the phone book next year,

  • how many more page turns do I need to find Mike?

  • AUDIENCE: Just one.

  • SPEAKER 1: Just one, right?

  • Because I just split the problem in half one more time, no big deal,

  • instead of flipping through an additional 1,000 or 500 pages.

  • And so this intuition with which you entered Sanders today,

  • odds are you can harness it already to solve problems more effectively so

  • long as you start to notice the patterns and the sort of useful inputs

  • with which you can solve problems.

  • But we need to begin to formalize the process.

  • We need to be able to express ourselves a little less organically than we

  • did with the peanut butter and jelly.

  • So how might we more methodically express

  • that algorithm with the phone book for which we probably nonetheless

  • have an intuitive understanding?

  • Well, let me start counting at zero just because programmers and computer

  • scientists tend to start counting at zero

  • because that's like all the light bulbs are off.

  • So you might as well start there.

  • And then step zero would be pick up phone book.

  • It's sort of an action.

  • Do this.

  • Step one is open to the middle of the phone book.

  • That's pretty much what I did a moment ago.

  • Step two is look at the names--

  • another action or verb

  • Step three, if Smith is among names.

  • So this is a different construct.

  • And that key word here is going to be if.

  • It's a question you're asking yourself.

  • It's kind of a proverbial fork in the road.

  • If Mike is among the names on the page you're looking, then call Mike.

  • And I've deliberately indented it because in many computer languages,

  • indentation means logically that you should only

  • do step four if line three were true.

  • Or the answer to that question is yes.

  • Else, if Smith is earlier in the book, he's meant to my left, then step six,

  • open to the middle of the left half of the book.

  • So that's when I tore it in half, threw it away, and then repeated

  • on the left half.

  • Else, if Smith-- oh, sorry.

  • Then go back to step two, a key step.

  • Now that I've divided the problem in half

  • and I'm looking in the middle of the left half,

  • the problem is fundamentally the same as I claimed before.

  • Just do the same thing but on a smaller problem.

  • And what's beautiful about this algorithm-- it's recursive,

  • so to speak, as we'll see down the road to--

  • is that you keep doing the same thing, same thing, same thing,

  • but because the problem keeps getting smaller,

  • eventually you're not going to do this forever.

  • You're going to find the answer you're looking for.

  • And so we go back to step two.

  • Step eight, else if Smith is later in the book, to my right,

  • open to the middle of the right half of the book

  • and then again go back to step two.

  • Else-- what's the fourth scenario to consider?

  • AUDIENCE: [INAUDIBLE]

  • SPEAKER 1: Yeah, what if Mike isn't in the phone?

  • He's unlisted.

  • We'd better anticipate that less my program crash or my computer freeze

  • because, like, it doesn't know what to do if Mike isn't there.

  • So I'll quit in this particular case.

  • And now let's tease this apart by highlighting

  • in yellow those operative verbs or actions.

  • Henceforth, we're going to call things like these yellow words functions,

  • so to speak, in a programming language.

  • These are verbs or actions, and I'll call them out, albeit in English

  • because there's no one language here.

  • This isn't like a formal vocabulary we're introducing.

  • It's just my most distinct way of expressing that algorithm.

  • And that's what pseudocode is.

  • It's English like syntax that anyone in the room

  • should hopefully be able to follow if you're

  • nice and clean and precise about it.

  • But there's another type of keyword in here

  • and that's the if and the else if and else if and the else.

  • These are the keywords that languages typically

  • use to represent these forks in the road-- go left,

  • go right, go here, go there, do different things.

  • And each of those decisions, if you will, is based on the answer

  • to a question.

  • And these questions we're going to call Boolean expressions named

  • after a person named Bool years ago.

  • And a Boolean expression is just a question with a yes or no answer

  • or really more technically a true false answer.

  • And notice the fact that everything falls into like buckets of two--

  • yes, no, true, false--

  • means we can use those light bulbs really to our advantage.

  • Maybe off shall be no or false.

  • Maybe on will be true or yes.

  • Just using a one light bulb can we represent any of these answers

  • to these questions.

  • And so those are Boolean expressions.

  • And then lastly, there is these things--

  • go to step two, which is perhaps the most explicit.

  • It's inducing some kind of loop or cycle.

  • Do something again and again.

  • And all of these ideas, functions, conditions, Boolean expressions, loops,

  • and more are going to permeate several languages that we explore over

  • the course of the semester.

  • But of course this unto itself is not yet real code.

  • And today in just a little bit, we're going to dive

  • into real programming code, albeit graphically using a language

  • called Scratch, and then follow that on later next week with a programming

  • language called C.

  • But before that, let me make just a couple of introductions.

  • Behind CS50 and its lectures and sections and office hours and more

  • is a whole team, nearly 100 staff every year,

  • that are here to make this course successful for you

  • so that irrespective of your prior background or lack thereof,

  • you too can succeed, especially if you are among those 68%.

  • And allow me to invite up Maria and Brian and Doug and Rob

  • to come say hello from the course's staff.

  • DOUG LLOYD: Good morning, everybody.

  • My name is Doug Lloyd.

  • I'm the course's senior preceptor and course manager.

  • 12 years ago now, I sat figuratively where you sat.

  • It was in Lowell Lecture Hall just across the street.

  • I was among those less comfortable.

  • I had never programmed before in my life.

  • I took CS50.

  • It totally changed the way I thought about problem solving.

  • I switched to CS major shortly thereafter,

  • and I've been on the staff with David for 11 years now.

  • So it's great to be here once again.

  • Thank you all for being here.

  • MARIA: Hi, everyone.

  • My name is Maria.

  • I'm a senior living in Cabot, and it's my fourth year in the course.

  • I took it as a freshman at an awesome time, and it's my third year on heads.

  • And I've absolutely loved it.

  • The staff is amazing.

  • Working with all of us amazing and I can't

  • wait to have an amazing senior year with you guys.

  • BRIAN: Hi, everyone I'm Brian.

  • I am the course's head course assistant.

  • I am a junior living in Winthrop, and I took the class my freshman year

  • two years ago now.

  • And really glad that all of you are here and really looking forward

  • to a fantastic semester and working with all of you.

  • ROB: Hey, guys.

  • I'm Rob.

  • I'm a fourth year PhD student living in Thayer,

  • and this is my eighth year with the course.

  • And every year, I think the course gets better.

  • And we put a lot of effort into the course over the summer

  • and building new tools and making new curriculum.

  • And I really think that you guys are going to enjoy it.

  • [APPLAUSE]

  • SPEAKER 1: Thank you.

  • We have a tradition in CS50 of ending the first week with cake or cupcakes.

  • And so after today's lecture, you're welcome to join us

  • in the transept to meet even more of the course's staff.

  • But first, and before we transition to one of these first actual programming

  • languages, we thought we'd dim the lights

  • and paint a picture too of not just the course's support structure,

  • but also its culture or community, which is something

  • we've increasingly focused on in recent years so that students in the class

  • feel that it's not only an opportunity to get an introduction to computer

  • science but also an introduction at Harvard

  • and, as you've seen at Yale and beyond there, a community of support

  • so that you can lean on each other as you tackle the week's problems

  • and ultimately exit having had a very shared similar experience.

  • This is CS50's community.

  • [MUSIC PLAYING]

  • SINGER: [SINGING] [INAUDIBLE] Stop rocking the beat.

  • Come on!

  • [INAUDIBLE]

  • SPEAKER 1: All right, so before--

  • so before long, this is what code is going to look like.

  • And frankly, it's pretty darn cryptic and it's pretty darned

  • distracting with the semi-colons, as we'll see, and curly

  • braces and parentheses and the like.

  • And frankly, these kinds of syntactic distractions

  • tend to get in the way of learning what's really

  • the interesting intellectual content about programming and computer science

  • more generally.

  • And so we instead begin today before transitioning next week

  • to that language with Scratch, an adorable language that

  • was invented down the street at MIT's Media Lab

  • some years ago that wonderfully has all of the concepts we've looked

  • at thus far in the form of Mike Smith, in the form of peanut butter and jelly,

  • and yet more ideas and allows us to program

  • today by dragging and dropping puzzle pieces,

  • really, that only interlock if it makes logical sense to do so.

  • And coincidentally too, as you may have glimpsed as part of CS50's community,

  • is as you may have seen door drop this week's CS50 Puzzle Day,

  • an opportunity to not solve problems using computers and programs but rather

  • peers and forming teams of two or three or four across the river

  • at the iLab for CS50 Puzzle Day.

  • Grab one of the invites on your way out, the goal

  • there being to message the computer science itself is indeed not

  • about programming but ultimately about problem solving

  • and, in this case, pizza and prizes as well.

  • So this here is Scratch.

  • And what's nice about scratch is that via this language,

  • can we distill that previous, more cryptic program

  • into just a couple of puzzle pieces?

  • And let's see the comparison.

  • If we look back just a moment ago, there's

  • this program in C, a fairly old programming language.

  • But it's nice in that it's fairly small.

  • We'll see that we learn almost every aspect of this language before long.

  • But what do you think it does?

  • Especially if you've never programmed before

  • and don't even recognize some of the words on the screen,

  • what operative word maybe does jump out at you?

  • What is the-- prints.

  • So it's technically prints f, which I don't really

  • know what that means right now.

  • But printing sounds familiar.

  • And what's it going to print?

  • AUDIENCE: Hello world.

  • SPEAKER 1: Probably hello world.

  • When I run this program on my Mac or PC, odds are,

  • it's going to print, quite simply, hello world.

  • How?

  • Don't know yet, but we'll get there.

  • But for now, the same program in this other language,

  • Scratch, can be implemented graphically by dragging and dropping two puzzle

  • pieces together so that scratch has, you'll soon meet as a cat,

  • says hello world in a cartoon-like bubble on the screen.

  • And so in fact, we'll be able to explore with Scratch all of these same ideas--

  • functions, conditions, Boolean expressions, and loops--

  • and then bunches of others as well that we'll then see again in C and later

  • in the semester in Python and later in the semester in SQL and JavaScript

  • and beyond.

  • And so we'll begin by exploring them as follows.

  • Let me go ahead and open up this program Scratch.

  • It exists in two forms-- an offline version

  • that I tend to use in class just so we don't have Wi-Fi issues,

  • but then an online version at scratch.mit.edu

  • which you'll use for the course's first assignment problem set zero.

  • And this is what the environment looks like.

  • On the top left where this cat here is, we'll call this Scratch's stage.

  • This is his two dimensional world wherein he can move up,

  • down, left, or right.

  • In the middle is a whole bunch of categories of puzzle pieces.

  • This one here says move 10 steps, turn 15 degrees, and so forth.

  • And up at the top are different color coded other categories of other puzzle

  • pieces we might want to use.

  • And then at right here is a so-called scripts area.

  • This is where I can program.

  • This is where I'll drag and drop these puzzle pieces.

  • And down here if I want more than one cat or some other character,

  • I can create other sprites or characters as well.

  • So how do I program in this case?

  • Well, notice first that Scratch's world has a green arrow and a red stop sign.

  • Green arrow is going to mean go.

  • Stop sign's going to mean stop.

  • So that's how I start and stop my program up here just above Scratch.

  • Meanwhile, if I want to start programming, I'm going to do this.

  • And I know this only from having used Scratch before where things are.

  • If I click on the Events category, notice this puzzle piece here--

  • when green flag clicked.

  • I can drag and just drop that puzzle piece anywhere on the right.

  • And my program's not going to do anything

  • because I haven't finished the thought.

  • But if I now go to looks, a different category in purple,

  • I might say something like, say--

  • and now notice when I get close enough, they're sort of magnetic.

  • They want to interlock.

  • So I can let go and then type in here hello comma world.

  • I'll zoom out now, move my cursor over to the green flag, and click.

  • And now I've written my first program.

  • It's not all that complex, certainly.

  • All I did was drag and drop a couple of graphics.

  • But logically, it's doing exactly what I told it to do.

  • Well, before we proceed further, let's see what some of these blocks

  • are fundamentally going to look like so that we

  • have a mental model for these various color coded categories.

  • In purple, we're going to see functions-- actions, or verbs, like we

  • saw with the phone book example.

  • Here, we're going to have conditions.

  • It's a few more puzzle pieces, but they very beautifully interlock together.

  • And this is a branch or a condition.

  • And notice too just like in my textual program,

  • I indented things by hitting the space bar or tab key.

  • So here is it kind of indented because the yellow wraps

  • around the whole puzzle piece.

  • So it's only going to say x is less than y if those orange puzzle pieces

  • x and y, which we'll call variables, which just like an algebra hold values

  • like one or two or three or four.

  • We're going to say x is less than y in that case.

  • Meanwhile, we can nest these things.

  • So even though they look like a fixed size,

  • they'll actually grow to fit other blocks if you want to cram more in.

  • So here, we have a three way fork in the road just by combining these ideas.

  • If x is less than y, then say x is less than y.

  • Else if x is greater than y, then say x is greater than y.

  • Else the third scenario, of course, is x must be equal to y.

  • So this is how we'll program.

  • We'll just drag and drop these puzzle pieces together.

  • What is this green block here called generally speaking?

  • AUDIENCE: [INAUDIBLE]

  • SPEAKER 1: Well, the condition we'll technically

  • call the yellow that's using this green block.

  • AUDIENCE: Boolean.

  • SPEAKER 1: Yeah, it's a Boolean expression,

  • and it is because it's a yes/no or true/false answer.

  • x is less than y is either true or it's false.

  • It can't be both.

  • And so we might have more generally is i less than 50.

  • You don't have to compare variables.

  • Just like in math, you can compare numbers against variables.

  • But here is a different concept.

  • We call this a loop, some kind of cycle that does, in this case,

  • something forever like, say, hello world.

  • Or we can do it a finite number of times-- like, 50 times say hello world

  • and then stop.

  • Here's how we might set a variable.

  • This orange block says set a variable called i by convention because i

  • stands for integer like a number.

  • Set it equal to 0.

  • And then these two things are demonstrative of a more powerful

  • feature that Scratch and languages tend to have of multi-threading.

  • This is a fancy way of saying a program can be written in such a way

  • that it does two things at once.

  • How?

  • Just use two of these puzzle pieces so that when you click the green flag,

  • multiple things happen at a time, thus our supported threads.

  • And then there's this, an even fancier feature

  • but that's relatively easy to use.

  • It's called event handling, and we'll come back to this

  • when we introduce web programming later in the semester.

  • Broadcast and when I receive just mean this.

  • One sprite, one character, like the cat, can kind of

  • sort of whisper to another sprite in the program

  • and send it a message that it can hear or, more properly, receive

  • and then do something based on it.

  • So rather than have your program do something only

  • when you click the green flag, you can have

  • one sprite talking to another telling it when to begin

  • or something along those lines.

  • And so with just these fundamentals are we

  • able to begin implementing any number of programs.

  • In fact, let's go ahead and do this.

  • Let me go ahead make this more interesting by not just

  • saying it on the screen.

  • Let me go ahead and go to sound and play sound meow.

  • [MEOW]

  • With slightly more volume.

  • [MEOW]

  • Oh, With slightly less volume.

  • [MEOW]

  • Adorable.

  • It's a simple program.

  • And if I want it to meow three times--

  • [MEOW]

  • --I just have to hit it three times.

  • But I can do better than this.

  • I don't want to rerun the program.

  • What's the construct that would let me meow three times?

  • Yeah, a loop or repeat.

  • So let me go to control.

  • I'll zoom in.

  • Repeat-- by default, it's 10 times.

  • So I'm going to change that to three.

  • I can drag this away and now put it inside.

  • Notice it wants to connect inside and it grows to fit.

  • And now I can let it connect there.

  • Let me hit play again.

  • [MEOW]

  • Hm, what's happened there?

  • My first bug.

  • This is subtle, but it's the kind of thing

  • that should give you pause, especially if encountering this on your own.

  • Turns out I should have thought a little more closely about what blocks to use.

  • The hint is kind of on the screen, though it's very subtle.

  • Until done-- like, there's this alternative block.

  • And you know what?

  • I don't know why this is going to be true yet, but let me do this

  • and get rid of this by just dragging it away.

  • Let's see if this fixes the problem even if we're not sure why.

  • [MEOW]

  • [MEOW]

  • [MEOW]

  • It's not a very natural sounding cat, but it kind of fixed the bug.

  • So can we infer retrospectively why it was previously buggy

  • and how it was buggy?

  • AUDIENCE: It played all three at once.

  • SPEAKER 1: Yeah, it kind of played all three at once.

  • Not technically at the exact same time, but my Mac

  • is so darned fast these days, right?

  • Intel inside-- you've got a gigahertz CPU or brain

  • inside of the computer or 2 gigahertz.

  • Those numbers literally mean your Mac or PC can do a billion things at once or--

  • sorry, a billion things in a second, which

  • just still pretty good, or 2 billion things in a second,

  • which is still pretty good.

  • So certainly it can meow three times and the things

  • just kind of trip over each other.

  • But if we instead use the block that says play it until done,

  • then you'll actually hear all three.

  • And we can actually do a little better than that

  • because that was not a very normal cat.

  • I can drag this block, wait one second, and let's see

  • if this is a little now more natural.

  • [MEOW]

  • [MEOW]

  • OK.

  • [MEOW]

  • So not bad-- pretty darn adorable.

  • But what if we want to add in some motion now?

  • Let me go ahead and remove this.

  • And let me do a forever block so I don't have to figure out

  • in advance how long to do this.

  • And let me go to motion and move 10 steps and now click the green flag.

  • Ah, OK.

  • Thankfully, MIT realized that this could be bad.

  • So they give us just enough access to his tail to pull him back.

  • But this is not the best program.

  • It would probably be better if he bounces off the side or detects--

  • collision detection, right?

  • We're living in a world now of self-driving cars, apparently.

  • It would be nice if things--

  • well, maybe they don't bounce off of each other,

  • but they avoid things altogether.

  • So that's OK.

  • I have the vocabulary with which to do this.

  • Let me zoom in.

  • And what is the construct I want to solve this?

  • Like if you hit the edge, turn around.

  • It's some kind of if, right?

  • So let me pull this out and then say, oh, OK.

  • If-- now I have to finish the sentence, and I can do this more quickly just

  • from experience.

  • So I'm going to go to sensing.

  • And then I'm going to grab this Boolean expression in blue.

  • And notice it's way too big, but it will grow to fill.

  • And now from this dropdown, I can actually ask this question instead.

  • If touching edge, what might I want to do?

  • Maybe turn like this.

  • And I'm going to turn like 180 degrees just to completely wrap around.

  • And now I need to move this back in.

  • And again, it looks like it might not fit, but it will grow to fit it.

  • Else go ahead and move 10 steps.

  • So let me go ahead and hit play now.

  • OK, still a little buggy, but at least it's dynamic

  • and it's doing this forever.

  • Now we can stray from the academics of this example

  • and do something silly like this just so you know what features it has.

  • This is a microphone.

  • That was me recording this is a microphone.

  • Here we go.

  • Ouch!

  • OK, that's what the word ouch looks like as a waveform.

  • Let's now call this ouch.

  • And now I need sound.

  • Whoops-- scripts.

  • Sound, play sound ouch logically.

  • So just to give you a sense of what we did, if touching edge play sound ouch,

  • turn around.

  • Ouch.

  • Ouch.

  • Ouch.

  • It's a little bit of a delayed reaction, but we've now

  • sort of combine these different ideas.

  • And already we've kind of moved quickly beyond where we started.

  • All we did initially was say something.

  • Then we move the cat.

  • Now we moved it forever.

  • Then we moved it forever unless you hit the edge in which case

  • you should turn around.

  • So just by building on these very simple ideas can

  • we make more complicated programs still.

  • And let's fast forward for just a moment before we tease apart

  • some of the more sophisticated features to take a look back at actually

  • the very first program I myself wrote back in graduate school

  • when Scratch first came out.

  • I called it Oscar Time since I always loved Sesame Street.

  • And this was the program I made that combines many, many, many, many hours

  • after first starting with Scratch a whole bunch of these same ideas.

  • And rather than I playing this, it would be more fun

  • if someone else perhaps plays.

  • Could we get a brave volunteer maybe a little farther back?

  • Yeah, what's your name?

  • AUDIENCE: Mansi.

  • SPEAKER 1: Mansi, come on up, Mansi.

  • All right, thank you to Mansi.

  • [APPLAUSE]

  • And you have to be comfortable being on the internet

  • now since there are cameras.

  • Nice to meet you.

  • SPEAKER 2: Nice to meet you too.

  • SPEAKER 1: Come on over.

  • And so with Oscar time here, notice there's a whole bunch of sprites.

  • So you'll see a bunch of things happening at once.

  • And realize I did not start writing this program by implementing this game.

  • I implemented just pieces of it at a time until the net effect many, many,

  • many hours later was the game you're now about to see.

  • Let me go ahead and full screen it.

  • And we'll see some directions on the screen in just a moment

  • and you can control with the keyboard.

  • Drag as much falling crash as you can to this cash down.

  • OSCAR: [SINGING] Oh I love trash.

  • Anything dirty or dingy or dusty.

  • Anything ragged or--

  • SPEAKER 1: Very good.

  • OSCAR: [SINGING] --or rusty.

  • SPEAKER 1: So as she plays, let's consider what some of the building

  • blocks are of this program.

  • So the first thing I think I did when I implemented

  • this game, which is about to get more and more complex, is I just

  • figured out how to move a piece of trash from the top to the bottom.

  • And that's kind of what we just did with the cat

  • albeit a top bottom instead of left or right.

  • And then after that, I think I probably implemented part of Oscar.

  • And Oscar is very sort of simply animated.

  • This is not like a video.

  • This is like three or so different images.

  • So the trash can is closed.

  • It's partly open.

  • It's fully open.

  • He pops out.

  • It's just a bunch of different images or costumes, as MIT calls them,

  • that I play like a half second apart in order to create

  • the illusion like those old school flip books of something

  • happening in animated fashion Meanwhile, he's counting clearly.

  • So that using variable, one of those orange puzzle pieces we previously saw.

  • There's some kind of randomness.

  • It turns up programs, and Scratch included,

  • can use pseudo randomness-- kind of sort of random values

  • so that the trash sometimes falls here or here or here.

  • And lots of video games do this, right?

  • A lot of the games you might have grown up playing

  • would be pretty lame if they are the exact same every time you play them.

  • You want the computer or CPU to do things

  • a little differently or randomly.

  • OSCAR: [SINGING] Now look at this rest of this junk.

  • A clock that won't work and an old telephone, a broken umbrella--

  • SPEAKER 1: Now keep in mind, this song is like three minutes long

  • and having just one bug partway through this program

  • was an absolute nightmare to debug waiting the minute or two until it

  • happened again.

  • OSCAR: [SINGING] Oh I love trash, anything dirty or dingy or dusty.

  • SPEAKER 1: It never really stops.

  • So congratulations.

  • Thank you.

  • Let me thank you with a little CS50 stress ball.

  • No less as well.

  • So that then is Oscar Time.

  • But what's nice about it, beyond being my baby,

  • is that it gives us an opportunity to consider how you might build up

  • something pretty complex looking and hopefully pretty fun at the end

  • but just out of these constituent parts.

  • And let's see what other ingredients, for instance, we actually have.

  • Let me go ahead actually and open up, for instance, Sheep.

  • This is an example.

  • And this, like all of today's, are on the course's website

  • if you want to play.

  • I changed the cat to a sheep in this case.

  • And if I hit Play, you'll see what happens here is the sheep--

  • whoops, the sheep does not count at all.

  • Let me go ahead and grab a different version of the sheep

  • since I broke it a moment ago.

  • Apologies.

  • Sheep is coming up now.

  • So here we have a sheep with a very simple script.

  • That is also missing his program.

  • How embarrassing.

  • And here, we have the online version of Scratch.

  • And of course since every browser in the world now blocks flash,

  • we have to enable it.

  • Here we go.

  • And now finally we have the sheep counting, so very anti-climactic.

  • This is literally just a counting sheep.

  • OK.

  • So I put a lot of time into this.

  • So I'm glad we got it working.

  • So at the top right, though, you can consider the parts that went into this.

  • When green flag clicked, set a counter which is just a variable.

  • It's more interesting than calling it x or y.

  • I called it counter.

  • Set it equal to 0.

  • And then forever say the counter for one second

  • like in the little cartoon bubble, wait one second,

  • and then change the counter by 1 by simply adding 1 to it.

  • And we get this effect of perpetual counting up by using this variable.

  • We can do something else as well, for instance.

  • Let me go ahead now and have a bit of dynamic input

  • from a character like a cat again.

  • And this one is called Pet the Cat.

  • So in Pet the Cat here, we have the following--

  • nothing, even though I hit play.

  • But wait a minute.

  • Let's look at the program.

  • How do I make this program do something?

  • AUDIENCE: Pet the cat.

  • SPEAKER 1: Oh, pet the cat, right?

  • So there's an if condition there that's asking the question

  • if you're touching the mouse pointer.

  • So let's try it.

  • [MEOW]

  • Ah.

  • [MEOW]

  • It's kind of nice.

  • We can do--

  • [MEOW]

  • --kind of the opposite, though with don't pet the cat.

  • You'll see that I have an if else so that by default, the cat now--

  • [MEOW]

  • [MEOW]

  • --meows.

  • [MEOW]

  • But if you pet this cat--

  • [MEOW]

  • [MEOW]

  • [GROWL]

  • --so don't put this cat.

  • How does this work?

  • Well, you just need another fork in the road.

  • If you're petting the cat, make the lion sound.

  • Else just meow in a much nicer, more tranquil way.

  • And we can go beyond this too.

  • Let me go ahead and now open up threads, which

  • is an example of a program doing multiple things at a time.

  • In this case here, we have another type of cat and a bird.

  • And which seems to be the smarter of the two?

  • The cat kind of knows a bit more than the bird about what's going on--

  • a sort of AI if you will.

  • [GROWL]

  • OK, so same sound there.

  • But notice now we have interaction between the two.

  • The cat, frankly, is kind of cheating.

  • It's not really AI.

  • It's just point at the bird.

  • And so here we have a puzzle piece that says forever if touching the bird,

  • play the lion sound.

  • So that's how the program ends.

  • But at the bottom there, point towards bird, move one step.

  • Point toward bird, move one step.

  • And so what does this do if I get a little sort of impatient and I give

  • the cat some god-like powers here just--

  • [GROWL]

  • --to speed it up moving 10 steps at a time.

  • And that's all, again, animation is.

  • Instead of moving one dot or pixel at a time,

  • move 10, the effect of which to us humans

  • is that it actually moves a lot faster.

  • Of course, we can give the bird an advantage.

  • So the bird is apparently moving three steps at a time.

  • Lets up that to 30.

  • [GROWL]

  • That did not work out very well either.

  • But in this case, the two sprites are interacting

  • because one is checking whether or not it's touching the other.

  • Meanwhile, you can do this.

  • Let me introduce events, which is another program too.

  • It's not very long, but it again has two sprites, two little puppets here.

  • And if I hit Play here, nothing happens until I hit the space bar.

  • When if you played this game growing up, one says Marco and then the other

  • says Polo.

  • But one is saying Polo in response to the other saying Marco.

  • Let me look at the sprite for the orange puppet here and you'll see this.

  • Forever do the following.

  • If key Space pressed-- so if the space bar is pressed--

  • then say Marco for two seconds and then broadcast an event.

  • And an event for our purposes today, it's like a whisper.

  • Whisper something that only other sprites can hear, not humans.

  • Meanwhile if I look at the blue puppet, it's not much going on there.

  • When you receive that event, that whisper, say polo.

  • And so we have interaction between these two sprites

  • much like Oscar was responding to the trash being dragged and dropped

  • over his trash can.

  • Finally, we have this one here-- hi, hi, hi--

  • which combines some of these ideas as well that allows you--

  • [SEAL BARKING]

  • --to implement perhaps a familiar idea--

  • [SEAL BARKING]

  • --from like a video game on your phone or the computer.

  • [SEAL BARKING]

  • This is very annoyingly barks in perpetuity--

  • [SEAL BARKING]

  • --until you figure out how it works.

  • How do I make this stop?

  • [SEAL BARKING]

  • Yeah, so if you look at the code at top right--

  • [SEAL BARKING]

  • --it mentions to the space bar and it stopped.

  • Why?

  • What does hitting the space bar actually seem to do logically?

  • It's in this left hand program.

  • If key Space pressed, what am I doing?

  • If-- yeah, if muted, which looks like a variable because it's an orange block.

  • If muted is 0, set muted to 1.

  • Else set muted to 0.

  • So what does this mean.

  • Well, this is kind of the programming equivalent of this.

  • If the light bulb is off, turn it on.

  • Else turn it off.

  • And so it's just a way of changing state or changing the answer

  • from false to true or true to false.

  • And then I'm using that information to decide on the right if muted is zero.

  • So zero means off or false.

  • So if it's not muted, if muted equals 0 means not muted,

  • play the sound sea lion.

  • And that's how the program stops until I do it by actually--

  • [SEAL BARKING]

  • --hitting that.

  • So we have all these puzzle pieces, if you will, of these ingredients--

  • [SEAL BARKING]

  • --and all of these abilities to weave these ideas together.

  • And you can do ultimately some pretty amazing things.

  • And in fact, in the spirit of bringing our two campuses

  • together both here and in New Haven, we thought

  • we'd conclude with one final game here for which

  • we need one additional volunteer to play for us here Ivy's hardest game.

  • Let's have you come up because your hand was up last time too.

  • What's your name?

  • LUKE: Luke.

  • SPEAKER 1: Luke, come on around.

  • So here comes Luke to play Ivy's hardest game.

  • This was written by one of your own CS50 predecessors, a former student.

  • And you'll see the instructions here on the screen in just one moment.

  • Here we go, full screen.

  • I'm going to go ahead and play for you and you'll

  • use the arrow keys in this game.

  • Here we go Luke.

  • [MUSIC PLAYING]

  • [MUSIC - MC HAMMER, "U CAN'T TOUCH THIS"]

  • MC HAMMER: [RAPPING] You can't touch this.

  • You can't touch this.

  • SPEAKER 1: [INAUDIBLE]

  • MC HAMMER: [RAPPING] You can't touch this.

  • SPEAKER 1: Very good.

  • Ah, you can.

  • That's OK.

  • MC HAMMER: [RAPPING] My, my, my music hits so hard.

  • That's what I'm saying, oh my lord.

  • Thank you for blessing me.

  • SPEAKER 1: Very nice.

  • Notice the two variables at top.

  • Level three has death zero.

  • Meanwhile, there's of course, multiple sprites on the screen.

  • Three Yale ones.

  • They, like the cat, are bouncing off the edge.

  • Very n-- oh!

  • Keep going, keep going.

  • Death is now one.

  • Death is now two.

  • Infinite.

  • It's OK.

  • Very nice.

  • Level six.

  • Nice.

  • Clearly there's an if near Harvard, move away.

  • Nice.

  • Come on, you can do it.

  • Second to last level.

  • Death is up to seven.

  • Nice.

  • Last level!

  • Just a couple more tries.

  • Nice.

  • One more time.

  • Let us end on that note.

  • This is CS50.

  • Cake with the staff is now served.

  • We'll see you next week.

SPEAKER 1: All right, this is CS50, Harvard University's introduction

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

CS50 2017 - 読書0 - スクラッチ (CS50 2017 - Lecture 0 - Scratch)

  • 364 9
    Amy.Lin に公開 2021 年 01 月 14 日
動画の中の単語