Placeholder Image

字幕列表 影片播放

  • >> [MUSIC PLAYING]

  • >> This is CS50-- Harvard University's introduction

  • to the intellectual enterprises of computer science

  • and the art of programming.

  • And my name is David Malan, and I was just thinking this morning,

  • it's been amazingly 20 years today since I last sat where you guys do now.

  • >> It was 1996.

  • I was a sophomore, and I was taking CS50 for the very first time.

  • And I hadn't even gotten up the nerve to take it myself freshman year,

  • partly because of the time.

  • Computer science to me was kind of like, meh.

  • I was a bit of a geek growing up, but I didn't really

  • have any intellectual interest in what appeared

  • to just be a whole bunch of people programming all the time.

  • >> And I was scared to be honest.

  • The course and computer science more generally had and to some extent,

  • still has this reputation of a field to beware, if only because so many of us

  • are unfamiliar with it and unsure of it.

  • And it really wasn't until I shopped this class that sophomore fall--

  • and even then, I only enrolled because the professor--

  • one of my first mentors, Brian Kernighan now at Princeton--

  • allowed me to take the class pass fail.

  • And indeed, that's why today we allow and encourage

  • students to take this class sat/unsat.

  • >> And only then, by the end of the semester

  • did I realize like, wow, this wasn't such an unfamiliar field.

  • Indeed, this was a very empowering field,

  • and more excitingly, especially later on,

  • as I took courses in Dramatic Arts 101 and Latin A

  • and then eventually grad school archeology,

  • did I really start to see the intersections of this field, computer

  • science, with the humanities, natural sciences, the arts, medicine,

  • and the like.

  • And so that's what's just so neat about computer science

  • ultimately, as we hope you'll see-- is its applicability

  • to these other fields, and how you can take some of today's and the semester's

  • ideas and practical skills back to your own domain,

  • and actually explore this intersection of the liberal arts and the sciences.

  • >> So 73% of you, if last year is any indication,

  • have never taken a CS course before.

  • So if, like me, you are feeling a little bit

  • scared, or frankly you're not really sure why you're even here.

  • Perhaps you just followed some friends over to Sanders right now.

  • That's totally fine.

  • The goal here is to hook you and to reassure you

  • that if you do look to the left and to the right,

  • you're going to see classmates with as little or as much experience

  • that you yourself might have.

  • And indeed, we'll share some statistics later today

  • as to what the demographics of the class typically look like.

  • >> And as added reassurance-- and this we do mean since I took over the course

  • some years ago-- in the course's syllabus

  • is this-- that what ultimately matters in this course

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

  • but where you in week 11, the end of the semester, end up relative to yourself

  • in week 0, which is where we are here today.

  • And this is what I realized all those years ago.

  • And I know a lot of classes say this, but it's

  • especially true in computer science.

  • At the end of the day, this field is unfamiliar as it was to me

  • and might be to you, is really just about problem solving.

  • And as such, it does have this applicability to get other fields.

  • And in fact, if we tried to distill what this means,

  • this is problem solving in its essence, I daresay.

  • There's input-- so whatever it is that you're trying to solve.

  • There's output, which is hopefully the solution to that problem.

  • And then, as we would say in computer science,

  • there's this black box in the middle that you don't necessarily

  • have to care about how it works.

  • You yourself eventually might implement what's inside that box.

  • But for today's purposes and more generally in life, all you care about

  • is that these problems get solved.

  • >> And what this course is ultimately about is exploring

  • the intersection of these inputs and outputs,

  • and these so-called algorithms, as we'll soon see,

  • that implement what is underneath there, the hood.

  • But these inputs and these outputs-- what does that actually mean?

  • Well, at the end of the day, we need some way of representing information.

  • This is especially true in a computer, which as fancy and complex as it

  • might seem, is a pretty dumb device.

  • It takes electricity-- whether from a cable or a battery as input--

  • and then it produces some preprogramed responses on the screen.

  • >> But how do we get from start to finish there?

  • Well, what's a problem to be solved?

  • Well, maybe we might, at the start of any semester,

  • try to take attendance in a room like this.

  • So I might do like one, two, three.

  • Or maybe, if I did it to sort of keep track

  • of myself-- to keep track of things-- I could quickly run out of fingers.

  • So I might just make hash marks-- one person, two, three, four, five, six,

  • seven, eight.

  • And all of us have probably done this, whether on your hands

  • or on a piece of paper.

  • And this is actually just something called unary notation--

  • where if you only have one letter in your alphabet, one or hash

  • mark in this case, for every input you want to count,

  • you need to put down one of these letters-- one of these marks.

  • >> All right.

  • That's all fine and good and not all that complicated.

  • But computers aren't all that much more complicated.

  • Indeed, most of you probably know even if you've not really

  • considered what this means, that computers only understand zeros

  • and ones-- the so-called binary system.

  • We humans, by contrast, are so much more sophisticated insofar

  • as we understand zeros through nines.

  • >> But even if binary is, at first glance, not all that familiar,

  • it turns out it's just like the systems and the ideas that we already know.

  • So for instance, consider this.

  • This is just a sequence of symbols.

  • And all of you, when glancing at it, probably

  • think 123-- nothing really interesting there.

  • But why is it this number, 123?

  • These are just glyphs on the screen-- just patterns

  • that someone might have drawn or typed.

  • But if you're like me, you probably remember from grade school

  • that there are sort of columns or places here.

  • There's the one's place and the ten's place and the hundred's place.

  • And the reason that this is 123 and not just a pattern of three symbols

  • is because, of course, if we have a one in the hundreds place,

  • you do the math of 100 times one, and then two in the ten's place.

  • So that's 10 times 2, and then three in the one's place and that's 1 times 3.

  • And when you add all of those up, of course, you get 100 plus 20 plus 3.

  • >> So we started with just a pattern of symbols-- an alphabet--

  • but then we mapped meaning onto it by way of these columns.

  • Well, it turns out that computers are really not

  • all that different from you and me.

  • But instead of using powers of 10, so to speak-- 1, 10, 100, 1,000,

  • 10,000 place and so forth-- they actually

  • just use powers of 2-- so one, 2, 4, and then

  • if we put more digits, 8, 16, 32, 64, 128, and so forth.

  • And so this is how a computer would represent the number 0,

  • just like we humans.

  • >> 0, 0, 0-- and you can probably guess what pattern of zeros and ones,

  • if a computer can only speak 0 or 1-- what

  • pattern is going to represent the number we humans know as 1?

  • Yeah-- 0, 0, 1.

  • All right.

  • So 0, 0, 1 is how we represent 1, so you might be inclined then

  • to represent the number 2, if you have the four's place and the two's place

  • as the one place, you might say, well, if we had a 1 in the one's place,

  • and now we want to count up to 2, you might

  • do this and leave this to be a zero.

  • But of course this is not how the decimal system works either.

  • If you put a digit in both of those columns,

  • you've got to do the arithmetic.

  • So what number did I accidentally just represent?

  • >> So it's 3, because 2 times 1 plus 1 times 1, of course, gives us three.

  • So this would be two.

  • The bit sort of flips, so to speak, as 0 becomes a one, much like a 9 roles over

  • and becomes a 0 when you carry the 1.

  • This then would be three of course.

  • Four-- another interesting thing happens, where the ones roll over

  • and you carry the 1, so to speak.

  • So this, of course, is 4.

  • >> But if you fast forward now, what's the biggest number going

  • to be that a computer can represent?

  • So it's just seven in this case, right?

  • Because you have a one in the four, a one in the two, a one in the one.

  • So that's 4 plus 2 plus 1.

  • So that gives you seven.

  • And indeed, it would seem at first glance

  • that computers can count no higher than this.

  • >> But this of course is not true.

  • What do we humans do when we want to count higher than like 999?

  • Just carry the one and just add a fourth digit to the left.

  • And so indeed we could.

  • We could have an eight's place and a 16th's place,

  • and a 32's place, 64, 128-- and you can just keep going on up to infinity.

  • So these zeros and ones-- the so-called binary system--

  • are what a computer scientist would generally call a bit, or binary digit.

  • >> But now, how do we get from the concept or the graphics of these things

  • to an actual computer?

  • We seem to be skipping a step here.

  • Well, the only input at the end of the day, to my laptop here

  • is this flow of electricity.

  • Even if it's been a long time since you thought about

  • or never thought about how electricity works,

  • there's electrons flowing in or out, and that's my kind of input.

  • >> So if that's all that we're getting as input here,

  • what can we do with that information?

  • Well, we might think of a zero as just an absence of electricity.

  • Nothing is flowinw, nothing is moving, nothing is happening.

  • That's just the default state-- zero.

  • But if there is electricity flowing, why don't we just arbitrarily, but globally

  • consistently, call that a one.

  • >> So simply by having no power, we have a zero, yes power,

  • we have a one-- no power, yes power.

  • And in that way, using something more physical or electronic

  • we start to implement this notion of something either being one or a zero.

  • Indeed, we could just do it over here.

  • So here, I have not three but eight light bulbs, each of which

  • has its own switch.

  • >> And so if I wanted to represent the number seven here,

  • I might turn on these three light bulbs.

  • And indeed, inside of my computer is millions,

  • billions of things that are just smaller than that, called transistors,

  • switches, that you just turn on and off.

  • So these are big-- relatively big-- switches inside my laptop--

  • are many, many, many, many more switches.

  • But all they do is exactly that-- turn something on, turn something off.

  • And as such, a computer can represent, with those millions or billions

  • of transistors, lots and lots of zeros and ones.

  • And there's other hardware still that lets you store information long-term,

  • so that when you pull the plug, you don't lose it.

  • But that's a story for another day.

  • >> So what can we do with these bits?

  • Might we just to take the pressure off of me--

  • might someone want to come up here and offer up a demo?

  • I saw this hand first.

  • What's your name?

  • MADAY: Maday.

  • DAVID MALAN: Maday, come on up.

  • Nice to meet you.

  • MADAY: Nice to meet you.

  • >> DAVID MALAN: Come this way.

  • I won't have to lip you up.

  • All right.

  • So here, we have, notice-- one, two-- we'll edit that out-- one, two, four,

  • eight, 16, 32, 64, 128.

  • This is deliberate.

  • There's eight bits here-- binary digits-- zeros and ones.

  • And a bit is a useful unit of measure-- not as useful a unit of measure

  • onto itself.

  • Usually you want at least eight of these things, a.k.a.

  • a byte.

  • So we have a byte of bits here.

  • >> So if we wanted to challenge you with, for instance, spelling out, in binary,

  • this value here-- 42.

  • Want to take a stab at that?

  • >> MADAY: [INAUDIBLE].

  • DAVID MALAN: Yeah, just push the little white switches in front.

  • And you want to spell out 42, and up for grabs

  • is this CS50 stress ball if you get this.

  • All right.

  • So you have 32.

  • We're going to need 42.

  • So that's an eight, so that's 40.

  • And excellent-- very nicely done.

  • Thank you.

  • >> [APPLAUSE]

  • All right.

  • So we have one more stress ball.

  • Let's do this once more if we may.

  • One other volunteer?

  • Free stress ball, free stress ball.

  • OK.

  • Over here in the middle, do you want to come down?

  • All right.

  • I know.

  • There we go.

  • >> So the numbers here-- come on down.

  • What is your name?

  • >> DAVEY: Davey.

  • >> DAVID MALAN: Davey.

  • OK.

  • Come on up, Davey.

  • Nice to meet you.

  • And what we're going to have you spell-- if you could linger there

  • for just one moment-- is the number 50.

  • But, but, but but, but, these are grade school magnets for a reason.

  • Just got a little harder, all right?

  • There's still eight.

  • All right.

  • So what do we have on there?

  • We have 32.

  • Nice.

  • 32 plus 16 gives us 48-- so close.

  • And wonderful.

  • Congratulations to Davey as well.

  • >> [APPLAUSE]

  • >> All right.

  • So we can do this all day long, and it doesn't get all that much more

  • interesting and more challenging.

  • But that's really the point-- is how relatively simple

  • it is, at the end of the day, what a computer does to store information,

  • to store inputs and ultimately store or represent those outputs.

  • But numbers alone aren't all that interesting.

  • >> So humans, some years ago, decided, you know what?

  • It would be nice if computers were not just

  • calculators for arithmetic operations, but actually could

  • do things like word processing, or email, or more modern incarnations

  • of these kinds of technologies.

  • And so the world decided arbitrarily, but universally,

  • that if you want to store the capital letter A in a computer, you know what?

  • Let's just all agree to store some pattern of zeros and ones--

  • bits-- that ultimately represents the decimal number 65.

  • We'll just all agree on that.

  • >> 66 would represent B, 67 would represent C,

  • and there's bunches of other patterns of zeros and ones, or underlying numbers,

  • that would represent other letters still.

  • So if you kind of mentally absorb this for a moment,

  • I deliberately put up A through I, where H a 72 and I is 73.

  • If a computer then, in the context of a word processing program or an e-mail,

  • revealed underneath the hood to have these patterns of bits-- pattern

  • of bits representing 72, then 73, then 33--

  • what might this spell in that program?

  • >> So hi, and then something.

  • We don't necessarily know, but indeed 33-- not on the chart earlier--

  • was simply an exclamation point.

  • So 72 was H, 73 is I, 33 happens to be an exclamation point still.

  • But that's all fine and good, and in fact nowadays, rather than

  • just use seven or eight bits, thanks to something

  • called Unicode as opposed to Ascii back in the day,

  • we actually can represent even more interesting characters than just

  • these original English biased letters.

  • But we can also represent even neater things like colors.

  • >> If you've ever heard the acronym RGB, red, green, blue, that

  • just means that a computer typically uses three sets of bits--

  • some number of bits that represent a number for how much red you want,

  • another set of bits for how much green you want,

  • and another set number for how much blue you want.

  • So a big number means lots of red, small number means no red.

  • And so these are kind of middle values here.

  • >> So give me some red, give me some green, and give me a little bit of blue.

  • And if you mix those three shades of color together, in this case,

  • you get this murky shade of yellow or brown.

  • But that pattern of eight plus eight plus eight-- so 24 bits--

  • left to right, is how a computer would represent that particular color.

  • Now this is just a dot on a screen.

  • If you look really close at your TV your computer, you'll see dots or pixels.

  • And if you have a whole grid of pixels, horizontally and vertically,

  • you have images.

  • And then if you take an image and then wash

  • show yourself another image, another image, another image, another image,

  • really fast, you of course have movies.

  • >> And so notice where we started.

  • We started with these zeros and ones.

  • We worked from there to decimal numbers, how we represent them.

  • Now we have letters of the alphabet.

  • But in other contexts wait, we can use a few more bits and represent colors.

  • As soon as you have the ability to represent colors,

  • you have the ability to represent photographs and animated gifs

  • and other such characters on the screen.

  • And when you have a whole bunch of images flying by the human at once,

  • it looks like motion pictures, and so you get videos as well.

  • >> So using these very simple primitives do we

  • have the way of representing ultimately all of these forms of media.

  • And we've abstracted again and again and again, until we

  • get from the lowest level to this highest level.

  • So that gives us this general idea of abstraction.

  • But we started here.

  • >> Here now, we might represent in a computer

  • our inputs with zeros and ones, our outputs in zeros and ones,

  • but what goes inside the box?

  • That's where computer science gets interesting.

  • That's where you actually bring your own minds to bear to solve problems.

  • We can now stipulate, for the rest of the semester, yes.

  • I know how binary works.

  • I remember how Ascii or Unicode-- the mapping to letters-- works.

  • And it certainly stands to reason that we

  • could represent red and green and blue, and represent multimedia as well.

  • But this is the interesting stuff.

  • This is what makes someone capable of solving problems.

  • >> And one such problem we like to do, indeed,

  • is taking attendance, or doing this algorithmically.

  • And again, I might do this.

  • I might do one, two, three, four five, six, seven, eight nine.

  • And I could write it down to keep track of it.

  • But that's just how I would represent the information.

  • Or I could do this faster-- two, four, six, eight, ten, 12, 14, 16, 18, 20,

  • 22-- it feels like twice as fast but it's still

  • going to take a whole lot of time.

  • >> But it turns out, if we leverage yet another resource-- and indeed computers

  • these days have multiple CPUs or brains.

  • It turns out computers can do lots of things at once,

  • and indeed we, in this room, might represent exactly this.

  • >> So it's a little socially awkward, but if you would humor me

  • for just a three-step process, let me ask everyone in place there just

  • to stand up for a moment.

  • Stand up.

  • So think to yourself, number one-- so everyone in this room,

  • except the people who didn't oblige, are thinking number one.

  • So that is your number right now.

  • That is the first step, or as a computer scientist or a programmer

  • would typically do, we're going to start counting at zero.

  • If the smallest number we can represent with those light bulbs

  • is zero, by just leaving them all off, I might as well just

  • start counting from zero is instead of one.

  • And so that's what computer scientists do.

  • So step zero, stand up and think of the number one.

  • The next step is this-- pair off with someone standing

  • and add your numbers together.

  • Wonderful.

  • >> So at this moment in time, literally everyone participating

  • is thinking of the number 2, except for one odd person if we have

  • an odd number of people in the room.

  • And now the third step here is going to be this-- one of you should sit down.

  • One of you should sit down, and if you're still standing,

  • go back to step one.

  • All right.

  • All right.

  • So more and more people should be sitting down.

  • Notice that this has induced a loop-- some kind of cycle.

  • Some of you should be awkwardly stuck, going back and forth between step one

  • and two, one and two, one and two.

  • That's OK.

  • Our first bug.

  • We'll deal with that.

  • All right.

  • Let me try to spur things along.

  • >> In theory, only one person is standing as everyone continues to pair off.

  • But let me speed things up with the people still standing.

  • What number are you thinking of?

  • 46.

  • OK.

  • Go ahead and sit down.

  • You guys are still standing.

  • Who's still standing?

  • What number are you thinking of?

  • OK.

  • >> So we'll come back to you.

  • In the back?

  • What is that?

  • 22.

  • OK someone else up top-- yeah?

  • 34.

  • OK.

  • Over here on my right-- up here?

  • 132, very nice.

  • 22?

  • >> OK.

  • And who's still standing?

  • Over here?

  • 46, very nice.

  • 72.

  • I can't stall much longer.

  • Yeah?

  • 30, nice.

  • Over here?

  • 23?

  • 23.

  • >> And I think that's everyone except you guys, no pressure.

  • Oh, wait.

  • 28?

  • Just eight.

  • OK.

  • Just eight.

  • Down here?

  • 30.

  • 23.

  • 24.

  • 18.

  • This is the worst implementation of this algorithm ever.

  • OK.

  • So anyone else?

  • Anyone else?

  • OK.

  • One more.

  • 16?

  • OK.

  • 16.

  • All right.

  • So if I haven't missed anyone in the glare here, when I hit Enter,

  • we will see, algorithmically, the total number of people in Sanders.

  • Because again, it's as though everyone as you sat down, passed your number off

  • to someone else, to someone else, to someone else, so that in theory,

  • in the end, only one awkward person should be left standing.

  • But that's fine.

  • We sped things up manually.

  • It's especially hard to see in this particular space.

  • >> And the total number of people we think there are here is 546.

  • The total number I was handed by the teaching fellows,

  • who did it the old school slow way, was 820.

  • >> [LAUGHING]

  • >> [APPLAUSE]

  • >> That's OK.

  • So surely then, there are these bugs.

  • And that's fine.

  • And so think back on this the first time something

  • you write doesn't necessarily work.

  • This has happened to me here as well.

  • But let's now consider how we might apply this same idea to something

  • you might have seen before, which is this old school technology here--

  • a really big phone book.

  • And suppose that this phone book has 1,000 pages and 1,000 names

  • and numbers alphabetically inside of it.

  • >> Well, we could kind of apply a similar idea to this very physical problem,

  • just using me.

  • I just kind of cheated by leveraging all of you

  • with lots and lots of different CPUs or brains executing some algorithm.

  • But if it's just little old me, I can still

  • leverage that same essence of an idea of dividing and conquering that problem

  • again and again, whereby half of you, half of you, half of you, half of you,

  • theoretically kept sitting down, until we were left, theoretically,

  • with just one person.

  • >> So in this old school technology-- we don't

  • need this map-- this old school technology,

  • we might start looking for someone like Mike Smith, one page at a time.

  • And I see that no, Mike is not here.

  • I'm still in the A section.

  • Eventually, I find myself in the B section.

  • And this is an algorithm-- step-by-step instruction.

  • Start at the beginning and one page at a time, look for Mike Smith.

  • Is this correct-- this algorithm or approach?

  • >> Yeah, it's correct.

  • If Mike's here, eventually I'll get to him.

  • But it's not efficient.

  • It's obviously very slow.

  • So I can leverage the same twosies approach.

  • I can do sort of two, four, six, eight, 10, 12.

  • It's twice as fast.

  • I'm going to get to Mike faster if he's there.

  • Is it correct?

  • Yes, but I heard a little-- no.

  • Now I heard a no.

  • Yeah.

  • There's a bug potentially.

  • Maybe Mike just accidentally gets sandwiched between two pages,

  • because I'm flying through this two at a time.

  • So at least we need some kind of conditional fix.

  • I need to say, hey, if I hit someone whose

  • name starts with a T instead of an S, I better double back at least one page.

  • So buggy at first, but fixable.

  • But none of us are going to look for Mike Smith through a 1,000 page phone

  • book one page at a time.

  • What's a normal person going to do?

  • You're going to go to the S's, if you knew where the S's.

  • You might go roughly to the middle or slightly skewed towards the end.

  • And I look down here and I'm in the M section.

  • But what do you know about this problem now,

  • that we didn't necessarily know before with all of us just counting ourselves

  • equivalently?

  • Well, Mike is clearly going to be in this half of the book

  • if he's here at all because it's sorted.

  • >> And so you can very dramatically--

  • >> [GASPING]

  • >> I know.

  • >> [APPLAUSE]

  • >> It's actually really easy if you do it down the spine there.

  • But you can then throw half of the problem away.

  • Now, I'm left with the same problem-- find Mike Smith in a phone book--

  • but now the phone book starts at M and goes to Z, but it's half as big.

  • >> But this is what's impressive.

  • Just like in theory, you guys, when you all sat down only half at a time,

  • the problem got half as big, half as big, again and again.

  • So has this problem become the same problem but half as big.

  • Now it's a 250 page problem.

  • As soon as I realize, oh, I'm in the T section accidentally.

  • I've gone too far.

  • I can throw that half of the phone book away.

  • Now, I'm down to a quarter of the problem.

  • >> And you can repeat, repeat, repeat until, in theory, you're

  • left with just one page.

  • And if Mike is on that page, I can now solve this problem.

  • But how quickly did I solve it?

  • In the first case, it took me like maybe 1,000 steps to find Mike Smith.

  • It might have taken me-- I picked up the phone book

  • and I started looking one page at a time,

  • and Mike might be 1,000 pages later.

  • >> Second approach maybe takes me 500 steps,

  • because I'm flying through two at a time.

  • And the third approach though, it's especially powerful.

  • But let's consider what we actually did with this third approach.

  • I'll have what I'll call just these statements here, one at a time.

  • Pick up a phone book.

  • Open to the middle of the phone book.

  • Look at names.

  • And then things get a little more intellectually interesting,

  • if still simple.

  • If Smith is among the names on that current page,

  • then do something conditionally.

  • It's like a fork in the road.

  • Call Mike.

  • If Mike is among the names on that page, called Mike.

  • But only do line four if line tree, if you will, is true.

  • The answer to that question is yes.

  • >> Else if Smith is earlier in the book-- in other words, if I'm in the M section

  • and I'm looking for someone to the left, then what I should do

  • is something very similar.

  • Then I should open to the middle of the left half of the book.

  • So go left, and then go back to step two.

  • Look at the names there.

  • >> So in other words, do the same thing, but on a problem that's been halved.

  • You know what else?

  • If Smith is later in the book based on the page I'm looking at,

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

  • and then go back again to step two, else--

  • there's a fourth possibility here.

  • Mike's either here or to the left or to the right or not there.

  • And here we better consider this.

  • And in fact, if you've ever had your computer just crash on you,

  • that is sometimes, but not always, the result of just a human programmer not

  • realizing, oh shoot, there's actually this fourth scenario.

  • And if you don't write code to handle that scenario,

  • sometimes you don't know what the computer might do.

  • And indeed a program might crash.

  • >> But in this case, I thought about it, and I said, else quit,

  • because that's the fourth logical possible scenario.

  • Now, let's just add some vocabulary so we

  • can start to toss around terms that are otherwise pretty intuitive.

  • All of the things I've just highlighted in yellow here,

  • I'm just going to the functions or procedures.

  • They're just kind of actions.

  • So pick up, open to, look at, call, open, open,

  • quit-- these are just actions, or we'll call them more formally, functions.

  • >> Meanwhile, now in yellow, I've highlighted things

  • that-- let's just start calling them conditions or branches.

  • These are decision points where you might go this way, this way,

  • or some other direction still.

  • So those will be conditions.

  • And now this one's a little fancier.

  • Let's call these questions Boolean expressions,

  • after someone with a last name Bool.

  • >> And a Boolean expression is just something

  • that's either true or false, yes or no.

  • So it's the question whose answer you care about, so as to in a condition

  • make a decision-- get back an answer, and then go left or right, or something

  • else altogether.

  • >> And then lastly, these lines here-- go back

  • to step two, go back to step two-- we could

  • implement this idea in different ways.

  • And then those of you with programming experience might have done

  • or can imagine doing this differently.

  • But for today's purposes, it's just the idea that matters.

  • This is inducing what we'll generally call

  • a loop-- some kind of cycle, because it's making me do something again.

  • >> So now, let's just consider how good this algorithm is.

  • It's correct.

  • If Mike's in the book, it's one of those four scenarios-- again and again

  • and again, we'll find him.

  • But how good is it?

  • Well, we don't have to be too formal here.

  • But let's just plot something, x and y, to get

  • a sense of the shape of this problem.

  • >> On the x-axis here is the size of my problem.

  • And they a y-axis here will be the time to solve.

  • So maybe this is number of pages.

  • Maybe this is seconds or page turns-- whatever.

  • However you want to count is what this picture will represent.

  • And that first algorithm, I'm going to describe as just a straight line.

  • If there's n pages in the phone book, then it

  • might take me as many as n steps to find Mike.

  • If Verizon or the phone company adds one more page next year,

  • it might take me one more step-- one more unit of time to find Mike.

  • So there's just this one to one ratio.

  • It's a straight line slope.

  • >> Meanwhile, that second algorithm-- if I'm

  • going two at a time-- two, four, six, eight, or double--

  • going through the pages twice at a time, two at a time,

  • it's still straight line.

  • There's now a one to two ratio, but just a little lower.

  • So if there's this many pages on the chart here in yellow,

  • that might take me this many steps or seconds,

  • otherwise it's going to take me twice as many on the red line.

  • >> But the green line is the real takeaway.

  • This is what we generally call a logorithm-- log

  • of n, where n is the number of pages.

  • But it's the shape that matters today, because we don't have

  • to even think about plotting points.

  • >> Think about an extreme scenario.

  • Suppose Verizon tomorrow doubles the number of pages in that phone book,

  • from 1,000 to 2,000.

  • In the first algorithm, I might waste an extra 1,000

  • steps looking for Mike, just because Verizon doubled the size of the book.

  • The second algorithm-- it might take me an extra 500 steps.

  • 1,000 more pages, I go two at a time-- 500 more steps to find Mike.

  • >> But that third algorithm is kind of magical.

  • Verizon doubles the number of pages from 1,000 to 2,000,

  • but how many more steps does it take me to look for Mike?

  • It's just one, because I can just tear the phone book one more time

  • from a 2,000 page problem to a 1,000 page problem, and voila.

  • I've taken a massive bite out of it.

  • >> And if you go really extreme, suppose that the phone book

  • company had something crazy like a 4 billion page phone book.

  • Well how many steps might it take to find Mike Smith in a 4 billion

  • page phone book?

  • It's a big number, but just 4 billion to 2 billion to 1 billion to 500 million,

  • 250 million-- still sounds like big numbers,

  • but I'm very quickly getting to smaller values.

  • >> And in fact, if I do the math right, I can only divide 4 billion

  • by roughly 32 times before I get down to just one.

  • So if that phone book were 4 billion pages long, no big deal.

  • Within a few seconds, maybe 32 seconds, I could divide it in half

  • and eventually find Mike or conclude that he's not there.

  • And that's the essence of an algorithm-- a good algorithm.

  • And that's one of the goals of a class like this,

  • is trying to figure out how do I solve the problem not just correctly,

  • like I always knew how to do it one page at a time-- but correctly and well.

  • How do I design good solutions to problems?

  • So let's take a moment here and give you a sense now

  • of CS50 the course itself-- introduce a few course's staff members.

  • Just before 2:00, we'll take a short break

  • so that those of you who are shopping can

  • duck out and take a look at some other class

  • and watch the rest of this online.

  • But for now, let me introduce CS50, the class itself,

  • and particularly what is new.

  • >> So the past spring, we spent quite a bit of time--

  • the course's staff and I-- thinking about what it is we want CS50 to be,

  • and going back to first principles, so to speak,

  • to consider what it is we want this course to look like and be

  • like for its students.

  • And so you'll see in problem set zero as well, an invitation

  • to take a look at that URL which summarizes

  • some of the motivations behind the following characteristics of fall 2016.

  • >> So as you may have gleaned from the TL:DR handout,

  • the syllabus today as well as from the course catalog, this year in CS50,

  • you're only expected to attend today-- so job well done--

  • and the last lecture on November 21st.

  • And you're welcome but not expected to attend those lectures in the middle,

  • because what we're doing this year, is shooting

  • in real-time the course's material.

  • So everything will stay current and incorporated

  • as best we can-- current events and conversations that folks might

  • be having in industry in the world, but making that material

  • available, as a result, even earlier-- complete with full text transcripts

  • and searchability and links to other resources.

  • >> And indeed, we've been claiming for some time

  • and we do now believe this, that we can create, digitally,

  • a more immersive, a more compelling educational experience, as opposed

  • to gathering here some 23 times in person, hearing someone like me

  • simply talk about computer science, as opposed to engaging more actively.

  • So you'll see in the course's syllabus a sketch of the semester here,

  • along with when lectures will be filmed, to which you're

  • welcome but not expected, and when they will

  • be released on the course's website.

  • >> And what we'll do here on Wednesdays starting next week,

  • is a lot more intimately, with only those folks who want to participate,

  • is a so-called walk through, where I and the course's heads

  • will actually make things a little more intimate

  • down here in the orchestra section, still have some technology

  • and walk through the current week's problem set,

  • and offer you particularly-- if among those less comfortable-- all the more

  • guidance that you might want or need for the week's challenge.

  • And similarly, for those who can't attend those in person, no big deal.

  • There will be similarly led by one of the course's senior staff,

  • Zamalya, the same opportunity embedded in the problem sets themselves.

  • >> Problem sets this year will be released on Fridays

  • and no longer do seven days later, but 10 days later-- deliberately

  • overlapping with each problem set, so as to better accommodate,

  • we hope, ebb and flow in student schedules,

  • especially when midterms or athletics or academics or extracurriculars

  • tend to come and go especially mid-semester.

  • That should give you a little more discretion as to whether you front

  • load your week with CS50 or back load it on the following weekend instead.

  • So look to the course's syllabus here for the schedule thereof.

  • And you'll notice too among the changes this year,

  • for those more familiar with programming in the past,

  • we'll start the semester as we will today in Scratch,

  • focus especially on the language called C, and then transition not

  • to PHP, but to a language called Python towards the end of the semester

  • in the context of web programming, along with SQL and JavaScript,

  • HTML, CSS, and yet more.

  • >> And in answer to an FAQ, it's indeed the case

  • that CS is not as scary as I once thought it was, but it is as much work

  • as I had heard it might be.

  • But this is the say that here are some statistics from fall 2015 student body,

  • whereby the horizontal blue lines represent the average number of hours

  • reported.

  • And you'll see an average of six to 10 to 12-- maybe 16

  • or so and so forth, but with high variance to be clear.

  • And so realize that there is not only students more comfortable and less

  • comfortable in the course, but a corresponding support

  • structure to get those students through the semester successfully.

  • >> Indeed, in answer to an FAQ, should you take CS50 as a first year?

  • Absolutely.

  • And in fact, I do regret not having found my way

  • or found a new field that first year as well.

  • And should you take CS50 with other courses, certainly as well--

  • and the general advice we might give students, that CS50's probably

  • not the kind of class or intro class that you should take with three

  • other or four other p-set classes.

  • But if you're taking two other p-set classes, something else, and CS50,

  • absolutely manageable.

  • I've had many students in the past done so quite successfully.

  • >> And to get you toward that finish line successfully,

  • does the course have sections-- different tracks for students

  • less comfortable, more comfortable, and somewhere in between,

  • whereby in the course's first problem set,

  • you'll be asked to describe yourself.

  • And if you are among those less comfortable, it's the kind of thing

  • that you just rather know.

  • And indeed, that's been the growing demographic in CS50

  • for quite a few years.

  • >> As of last fall for instance, 58% of the class

  • described themselves as among those less comfortable,

  • with 9% among those more comfortable, and then

  • the other students there in red describing themselves

  • as somewhere in between.

  • And you'll see here the topics overall and schedule of sections, all of which

  • are offered in person, in real time, with the course's

  • amazing staff of teaching fellows and course assistants, some of whom

  • you'll meet in just a moment.

  • >> Sections themselves, as you'll see, will be Mondays and Tuesdays and Wednesdays,

  • so as to allow you to dive in after engaging, if you so

  • choose, in the course's lecture earlier that week.

  • And then office hours, which certainly, with each passing year,

  • have been no less of a challenge for the course.

  • And this year, we're planning not only to hold office hours-- one

  • on one opportunities for help for students on Wednesdays Thursdays

  • and Sundays, the last of those being in the afternoon by design

  • to reduce some of the stress that invariably arises with late night

  • p-settting with a deadline looming-- but office hours will also be offered

  • on Mondays and Tuesdays and Wednesdays, and Fridays and Saturdays,

  • thanks to our friends at HSA.

  • >> CS50 now has its own space for students and CS50 staff,

  • atop 67 Mount Auburn Street, right there in Harvard Square.

  • The vision for which is that CS50's TFs and CAs throughout the week,

  • pretty much throughout most days, will be there for support.

  • So if you've got some question on a p-set

  • or you're feeling a little blocked or a little confused,

  • and heck, you've got an hour or half an hour between classes,

  • especially in the square-- can you pop in and have that question answered

  • of have that confusion clarified-- very much in the spirit,

  • you're familiar, of the math department's own math questions center,

  • but pretty much around the clock per [? Gcal ?] that we will post online.

  • >> Tutoring is also available for those students, freely from the course's

  • own staff if you would like more intimate one on one,

  • or two or three classmates only, working with one of the course's staff members.

  • And indeed, these here are just some of the course's staff members,

  • a few of whom you'll meet in just a moment.

  • In fact, CS50's own head teaching fellow,

  • and head course assistant, and preceptor,

  • could come on up, allow them to say hello.

  • >> [APPLAUSE]

  • SPEAKER 1: [INAUDIBLE].

  • >> [APPLAUSE]

  • SPEAKER 2: [INAUDIBLE].

  • >> [APPLAUSE]

  • SPEAKER 3: [INAUDIBLE].

  • >> [APPLAUSE]

  • >> DAVID MALAN: And allow us to bring on board two of CS50's most

  • senior staff, Rob and Zamayla as well.

  • >> [APPLAUSE]

  • >> Indeed, both Rob and Zamayla have been with us

  • for so long, that I was able to go into CS50's archives

  • and find this very SD footage of them participating

  • on stage themselves some years ago.

  • ROB: [INAUDIBLE].

  • >> [APPLAUSE]

  • ZAMAYLA: [INAUDIBLE]

  • >> [APPLAUSE]

  • DAVID MALAN: Thank you.

  • So in addition to these team members here,

  • CS50 has a team of nearly 100 staff members, all of whom

  • will be available for sections and office hours and so much more.

  • And as Rob says too, this is the most significant overhaul

  • of CS50 in the 10 years that I've been in [INAUDIBLE].

  • [INAUDIBLE] focused especially in providing a support structure,

  • trimming away a lot of the bulk that's been

  • accumulated in 10 years of iterative developments

  • on the course's problem sets.

  • >> So this year, not only in class but also in the form of the course's problem

  • sets, should you find things to be more streamlined, trimmer, much

  • more manageable than in years past, as we

  • shed some of the baggage that's developed by nature of evolving year

  • after year and iterating.

  • So the new and improved begins today.

  • >> You'll meet some more of the course's staff out in the [INAUDIBLE]

  • at 2:30, where we serve, as a tradition, cake.

  • There's a bit more cake than that, but you'll

  • meet Erin and Tobias and others still.

  • And let me give you a tour before we hear

  • from some of the other staff members in the class, of what awaits as well.

  • In fact, we always start CS50's semester this coming Saturday,

  • with what's called CS50 Puzzle Day.

  • >> It has nothing to do with computer science per se,

  • but with about problem solving more generally.

  • And if you so choose to partake, per some of the invitations,

  • you might have seen door dropped or on the stage here,

  • it's an opportunity in teams of two or three or four,

  • to participate for puzzles and pizza and prizes and more-- this Saturday,

  • stay tuned for more.

  • >> You'll find too that every Friday, at Fire and Ice,

  • does CS50 bring a whole bunch of students

  • to lunch, to make a large class feel more intimate,

  • and generally bring together alumni and friends from industry

  • to talk about what they've been up to since graduating.

  • Similarly, this year, will we inaugurate the first ever CS50 50

  • coding contest-- a mid-semester opportunity to allow everyone

  • on an opt in basis, to have a challenge of wits against classmates,

  • again in teams of two or three or four, using only that programming

  • savvy that you then have under your belt after just six or seven

  • weeks of the class, and participating in this kind of competition

  • online-- if you'd like to hone your own skills all the more in that challenge.

  • At the end of the semester is the so-called CS50 Hackathon--

  • an opportunity that begins at 7:00 PM ends at 7:00 AM, and along the way

  • are 12 evening hours in which to dive into the course's final project--

  • an opportunity to design and implement most anything of interest

  • to you with your teaching fellow's guidance.

  • Around 9:00AM do we typically serve pizza, 1:00 AM,

  • Philippe's, and the few of us who are still awake at 5:00 AM,

  • are shuttle bussed down the road to IHOP for breakfast.

  • >> And then a few days later is the so-called CS50 fare--

  • an end of semester exhibition in celebration of just how far so many

  • of CS50 students have come from week zero all the way to week ,

  • and keeping in mind that 73% of those classmates and yours this year have

  • never taken a CS class before.

  • In fact, to reemphasize as much, here is a few more faces from CS50's staff.

  • SPEAKER 4: [INAUDIBLE].

  • SPEAKER 5: [INAUDIBLE].

  • SPEAKER 6: [INAUDIBLE].

  • SPEAKER 7: [INAUDIBLE].

  • SPEAKER 8: [INAUDIBLE]

  • SPEAKER 9: [INAUDIBLE].

  • >> SPEAKER 4: [INAUDIBLE].

  • >> SPEAKER 10: [INAUDIBLE].

  • SPEAKER 11: [INAUDIBLE].

  • SPEAKER 12: [INAUDIBLE].

  • SPEAKER 13: [INAUDIBLE]

  • >> SPEAKER 14: [INAUDIBLE].

  • >> SPEAKER 13: [INAUDIBLE].

  • SPEAKER 15: [INAUDIBLE]

  • SPEAKER 16: [INAUDIBLE].

  • >> SPEAKER 11: [INAUDIBLE]

  • SPEAKER 5: [INAUDIBLE].

  • DAVID MALAN: Some of the team are themselves shopping classes.

  • But if those members of CS50 staff are here,

  • could come on up for just a moment.

  • CS50's TFs and CAs and [? staff ?] members here-- these are just a few

  • of the faces-- one of whom you just saw, and a few other-- and a few others

  • still.

  • Why don't we go ahead and allow you guys a five minute break.

  • If you need to duck out to shop classes, that's fine.

  • And in five minutes, we'll resume, taking a look at Scratch-- the first

  • of our programming language, meet the course's staff here some more,

  • and focus ultimately on problem set zero.

  • So we'll be back in five minutes.

  • >> All right.

  • So we are back.

  • And in our remaining time today, the goal

  • is to level the playing field in terms of some terminology,

  • in terms of some ideas.

  • Because indeed, as per some of the charts earlier,

  • there is going to be a range of levels of experience in the class,

  • some of whose students have taken some programming before,

  • some of whom haven't.

  • And so with this first problem set and with this first language

  • do we have an opportunity to start to take for granted after today

  • some common vocabulary and idea.

  • >> And we'll do this by way of the course's first languages--

  • in addition to C and Python and JavaScript and SQL and HTML and CSS,

  • we'll be focusing initially and just for problem set zero

  • on this graphical language, called Scratch, developed by MIT'S Media Lab

  • down the road, to help students and kids especially

  • express themselves algorithmically-- in a way more consistent with what

  • we might call computational thinking.

  • >> And it's a useful language because very quickly next week in week one,

  • do we transition to a more traditional and arcane language called

  • C, which is purely textual.

  • You only use your keyboard in order to write instructions

  • like these on the screen.

  • But even if you've never seen a programming language before,

  • in just glancing at this, all be it cryptic,

  • you can probably guess that probably prints Hello World.

  • But there's a lot of syntactic overhead there.

  • There is the weird hash symbol or hash tag up top.

  • There's the angle brackets, some parentheses, curly braces, semi-colon--

  • there's just so much visual syntax that gets in the way.

  • We start the course with Scratch so as to get

  • past all of those intellectually uninteresting distractions,

  • and focus instead on the ideas.

  • >> In fact, this might be before.

  • This, for this, week shall be after.

  • This, in this graphical language Scratch,

  • is how you would implement that same program-- a program that when run,

  • simply says hello world.

  • And what's nice about Scratch is that it's this graphical programming

  • environment that uses puzzle pieces or blocks, that only interlock together

  • if it makes logical sense to do so.

  • And with Scratch can you develop animations and interactive games

  • and art, and any number of things that you might imagine in your own mind,

  • and implement them simply by dragging and dropping puzzle pieces.

  • >> And indeed, we'll have the ability to express some of the same ideas

  • that I just mentioned a moment ago in the context of Mike Smith

  • and searching a phone book-- things like functions, just actions,

  • things like loops that do things again and again,

  • variables, which is something we'll introduce,

  • but it's familiar perhaps from algebra-- just some kind of placeholder

  • to store some value you might need later-- Boolean expressions,

  • where those yes no or true false questions from before.

  • Conditions are those forks in the road-- those branches so to speak.

  • And then there are some fancier features we'll see even today,

  • called arrays and threads and events, that we'll then revisit over

  • time in different languages.

  • But Scratch allows us to explore all of these.

  • So here in Scratch, this purple block is what a function is typically

  • going to look like.

  • This purple puzzle piece that has some word like say, which is the action,

  • and then it might have an argument or a parameter-- some way

  • of kind of customizing what that block does

  • so that it's not pre-determined by MIT what this purple block says.

  • In fact, you'll see in a moment that I'm able to type

  • the words like hello world, or hello David, or hello Zamayla,

  • or whatever I want, in the argument to that puzzle piece-- the white box

  • there.

  • Meanwhile, if I want a loop, we'll see that there's puzzle pieces that

  • look a little orange like this.

  • And their shape kind of suggests that something happens again and again

  • in a cycle.

  • >> So if I wrap a say hello world block with a forever block in Scratch,

  • it's just going to keep saying hello world forever, quite literally.

  • Meanwhile, there's another type of loop in Scratch

  • that we'll see-- a repeat block-- where, if you

  • know in advance how many times you want the loop to execute

  • a finite number of times in fact-- you can specify that by typing in a number

  • or even plugging in a variable, like x or y as we'll see.

  • >> In fact, variables like i in this case, which

  • is a common name for an integer variable that

  • just stores a number-- an integer might be,

  • to use this orange block here to set a variable like i to zero.

  • Here's an example in green of a Boolean expression in Scratch.

  • Even though this looks like a math formula, math inequalities like this

  • really are Boolean expressions.

  • This is either true or false.

  • I is less than 50.

  • It's either a yes or no answer or true or false answer.

  • And we'll generally call those Boolean expressions.

  • And it doesn't have to be 50.

  • It can be x less than y, greater than y, equal to y--

  • any number of other questions might be asked.

  • >> Now, at first glance, this might look suddenly quite bold here, and it is.

  • But concept wise, it's pretty familiar from before.

  • If x is less than y, than say as much.

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

  • Else say x is equal to y.

  • So we have an example there of a third scenario--

  • the only third possibility-- x is either greater than, less than, or equal to.

  • So we have a three way fork in the road.

  • >> And notice what's cool here-- Scratch, it would seem, has just one puzzle

  • piece, in this case, in if else block.

  • And yet that would seem to imply you can only have a two way fork in the road.

  • You can go left or right, but what about that third scenario?

  • What if x equals y?

  • No big deal.

  • Take one puzzle piece, put another one inside of it

  • to create the semantic equivalent of if, else if, else-- and now you

  • have your three way fork in the road.

  • And as we'll see, the Scratch puzzle pieces

  • can be stretched and grow, so as to cram more stuff in them.

  • You don't have to fit everything in its default size.

  • >> This is something we'll soon see is called an array.

  • It's like a list-- some way of storing multiple pieces of information

  • in a variable, not just a number.

  • These we'll see a representative of something called multi-threading.

  • In fact, all of your Macs and PCs these days

  • support multi-threading, which means you can literally

  • do multiple things at a time.

  • You can have Microsoft Word up in the foreground, working on some essay.

  • You might have a browser in the background opening

  • G-mail or Facebook or the like.

  • Your computer can do multiple things today because it is multi-threaded,

  • and programs they're in in particular are also multi-threaded.

  • >> There's things called events as well in the world of Scratch,

  • and then there's a way too, to make our own custom puzzle pieces if things

  • don't actually exist in advance.

  • So let's motivate this as follows.

  • Some years ago, when I first discovered Scratch,

  • when I was actually a grad student at MIT, we

  • ourselves were tasked to make homework.

  • And I implemented-- which, in retrospect,

  • was a very poor decision because it's the most infuriating song in the world

  • to listen to for eight hours while working on your homework--

  • but something I had called Oscar Time, which is perhaps a familiar song.

  • >> CS50s own Jordan Hayashi, one of our more senior staff members,

  • has upgraded it for 2015 and now 2016, since back in the day,

  • I had everything just going into Oscar's trash can.

  • Now we support recycling and composting.

  • >> But to paint the picture of what we can do here

  • and to motivate some of the lower level examples,

  • could we get one other volunteer to just come on up

  • and play my first homework assignment ever?

  • Come on up.

  • What's your name?

  • >> HENRY: Henry.

  • >> DAVID MALAN: Henry, come on up.

  • Come on up.

  • Head either way, and you'll see in a moment,

  • I'm going to go ahead and hit the green flag in the top right hand

  • corner, which means go.

  • The little stop sign icon is going to say stop,

  • and that's when you start and stop the program.

  • Nice to meet you.

  • All right.

  • So we're going to see the instructions on the screen in just a moment.

  • And just by playing this game for a few seconds-- trust me,

  • we're not going to want to play all the way to the end-- you will

  • get a sense of what the program does.

  • And more than just focus on Henry being good or bad at this game, focus

  • and how was it implemented by me originally and then by Jordan.

  • In other words, where are the variables?

  • Where are the loops?

  • Where are the functions?

  • And we'll see if we don't see those underneath the hood.

  • >> Just click and drag trash to the appropriate bin.

  • >> [MUSIC PLAYING]

  • All right.

  • That's very good.

  • Why don't we stop it there.

  • Thank you.

  • Congratulations to Henry.

  • Thank you.

  • >> [APPLAUSE]

  • >> Just imagine debugging that program.

  • If there's a problem two minutes into the song-- but so

  • what's going on here really?

  • As complicated as it might start to seem to get over time,

  • indeed more and more stuff started falling,

  • what's interesting about this kind of example--

  • and we'll see a few others-- is that if you

  • look past the complexity or the sophistication of the game,

  • there's a very simple building blocks that play-- all of which,

  • if you distill them to those building blocks, are very accessible

  • and implementable unto themselves.

  • For instance, it's been some time, but I'm

  • pretty sure what I initially did when making this game for the first time

  • was I completely like procrastinated.

  • I didn't focus at all on the logic or the puzzle pieces,

  • I focused on the graphics and finding the street post and the trash can

  • and all of that.

  • But those were requisite ingredients at first.

  • And once I finished procrastinating and laying out the overarching framework,

  • I decided, let me just make one piece of trash fall from the sky.

  • And we'll see Scratch supports things called

  • sprites-- characters that can have different costumes on so they

  • look different.

  • >> And so I put a trash costume on one such sprite.

  • And I just needed it to fall from the sky.

  • And so it turns out, Scratch, like most programming languages,

  • supports random numbers or technically pseudocode random numbers,

  • so that by dragging and dropping certain puzzle pieces,

  • I was able to have the trash come from the left at first.

  • And then the next time it fell, from the right and then from the middle.

  • And all the game did was just have trash falling from the sky.

  • You couldn't point at it or click on it.

  • You couldn't open the trash can.

  • You couldn't do anything.

  • But it was a baby step toward my ultimate vision.

  • >> And after that, I actually implemented some kind

  • of sensing so that if you did click and drag on the piece of trash

  • over the trash can, Oscar's lid would open and close.

  • Nothing would happen to the trash, but at least the lid would open and close.

  • So then check, step two of two.

  • And this is what's going to be key in both problem set zero

  • and in programming more generally, is to take these very deliberate baby steps.

  • Because not only does it allow you to feel honestly accomplished much more

  • quickly-- it's the worst thing in the world

  • to try to implement all of Oscar Time, then hours later hit the green flag,

  • and nothing works as expected because where do you even

  • begin to debug or to troubleshoot that program?

  • It's just overwhelming.

  • >> And so truly embracing this idea of taking steps-- baby steps again

  • and again-- building up something that's, in the end,

  • really impressive and complex, but at first, is not nearly as much so.

  • In fact, let's do this.

  • Let me go ahead and-- Scratch itself exists on the web at Scratch.MIT.edu,

  • and you'll be told as much again in problem

  • set zero, the specification for which is already on CS50's website.

  • >> But this is what Scratch itself is.

  • And there's really just three primary areas.

  • At the top left there is the so-called stage.

  • This is Scratch.

  • The default costume is a cat.

  • And this is the rectangular world in which you can move-- up, down, left,

  • right and some other stuff.

  • In the middle here are our categories or our pallets of puzzle pieces,

  • and different colors mean different things.

  • And if you poke around, you'll see things like loops and conditions

  • and variables and other ingredients.

  • >> And then over here is the scripts area.

  • This is where I can drag and drop those puzzle pieces to do things.

  • So let's do one such thing.

  • Let me go ahead and-- and I know where it is.

  • So I'm going to immediately click on where I know things are ready to be,

  • but pointing and clicking and poking around are inevitable.

  • So when green flag clicked, what do I want to do?

  • I'm going to do this.

  • I'm going to drag this purple puzzle piece, say hello for two seconds,

  • and let me zoom in.

  • >> And I'm going to change this to be what I want it to be--

  • hello world for two seconds is fine.

  • Now, I'm going to click the green flag, or if I really want,

  • I can full screen it and then come back.

  • It will just keep everything in one window.

  • Green flag-- hello world.

  • All right.

  • Not all that interesting.

  • So let me go ahead and do this.

  • Let me try another one.

  • When green flag clicked-- let's do something like a sound.

  • And notice that out of the box for free you get

  • a cat sound, as is the default sprite.

  • So now let me go ahead and hit the green flag now.

  • >> [MEOWING]

  • >> Aw.

  • That's adorable.

  • I'm programming.

  • So what have I done?

  • This is the equivalent of a program.

  • It's obviously super simple.

  • It didn't really take all that much effort and MIT did most of the work,

  • but I have called a function.

  • I have used a function.

  • I've made some action, using just that one purple puzzle piece.

  • >> Well, if I want to do three meows in a row?

  • Let me go ahead and do two and three.

  • And notice that when you hover nearby a puzzle piece,

  • a little white line appears sort of magnetically,

  • and it will snap together when you let go.

  • Let's see what happens here.

  • >> [MEOWING]

  • >> There's a bug.

  • I only hear one meow.

  • Why might that be?

  • Yeah?

  • Yeah.

  • We don't really hear it, but that's good intuition.

  • They're all playing at the same time.

  • Why?

  • Well, the computer is just going to do what you tell it to do.

  • So if you say, play sound, play sound, play sound,

  • but you don't tell it to play until you're done, play until you're done,

  • it's going to blow through the program really fast

  • and do only what you tell it to do.

  • >> So I actually need to fix this in a couple of ways.

  • I could just do this, get rid of this.

  • Let me try this other puzzle piece-- play sound meow until done,

  • and then drag three of these and click Play.

  • >> [MEOWING]

  • >> It's not really very-- thank you-- very natural.

  • So why don't I-- let me go to control here.

  • Nice.

  • Wait one second, and now let me go back to sounds, and play sound until done,

  • and then let me get wait one second.

  • And then let me go and get one more sound, and here we go.

  • >> [MEOWING]

  • >> A little more natural, but this is not very efficient.

  • Like I was getting bored, all be it briefly, clicking back and forth

  • and really duplicating my work-- pretty much copying and pasting.

  • Indeed, if I Control clicked or right clicked,

  • I could have just copied and pasted.

  • What would be a better construct to use?

  • What idea from before?

  • >> Yeah, so a loop.

  • And in fact, if we poked around, we might find exactly that.

  • Let me go to Events or rather Control.

  • So repeat-- I don't want it to be 10 times.

  • That's going to get annoying quickly.

  • But I will repeat three times.

  • Let me go back to sound and play the sound until it's done.

  • Let me go back to Control and just wait one second.

  • And notice, you might think it doesn't fit,

  • but again if magnetically you let it snap in place, it will grow to fill.

  • What's it play now?

  • >> [MEOWING]

  • OK.

  • Nice.

  • And this is what would be called a program that's also correct.

  • It meowed three times fairly naturally, but it's better designed.

  • I'm using less redundancy.

  • I didn't copy and paste anything.

  • I just used a better idea.

  • >> Now, this is still not all that interesting with Scratch not doing

  • anything.

  • So let's do something else instead.

  • Let's do something forever.

  • And you know what?

  • Motion seems interesting.

  • Let's have him move 10 steps and hit play now.

  • >> OK.

  • Well we can kind of drag him back, and he's still

  • running because he's doing this forever.

  • So the loop is doing what it's saying to do,

  • but this isn't all that interesting.

  • Let's do this.

  • Let me add a control block, and use one of those conditions for the first time.

  • >> So it's going to move 10 steps-- 10 dots, 10 pixels on the screen--

  • then it's going to ask this question.

  • If something is true, then do something inside this block.

  • So it turns out sensing has a whole bunch of Boolean expressions--

  • questions of the yes no or true false form-- let me do this.

  • >> If touching-- and then there's this little drop down menu.

  • I can parameterize it.

  • If touching the edge-- let's do something like that.

  • So if touching edge-- let me go back to motion.

  • And why don't we just turn around 180 degrees?

  • All right.

  • So forever, move 10 steps.

  • If you're touching the edge, turn 180 degrees.

  • And that's not the end of the program because you're in a forever block,

  • so it's going to go again and again and again and again.

  • So let's see what happens.

  • OK.

  • A little buggy, but kind of cool.

  • >> And we can add to this some silly things that aren't all that intellectually

  • interesting.

  • But if we hit this little microphone button-- ouch.

  • Let me clean this up.

  • Let me enhance this as they would say on TV.

  • Clean that up, Save, and now go up to scripts.

  • >> And now, let me go to sound.

  • Let me give it a name.

  • I'll call this ouch.

  • And now play sound ouch.

  • Notice it appears in the little drop down menu.

  • Let's see.

  • >> [OUCH]

  • >> [LAUGHING]

  • But we can change t his on the fly.

  • We can be twice as annoying.

  • >> [OUCH]

  • >> Or if we make it like 1,000 steps at a time--

  • >> OK.

  • So we're going to leave that one alone.

  • So again, building blocks-- I started with something super simple,

  • and then I added a feature, added a feature, added a feature.

  • And I no longer need to worry about how the first of those features

  • was implemented as I continue to layer things on top.

  • So in fact, let me do one other here.

  • Let me go ahead and open a file that I brought in advance, called Sheep.

  • >> So it has a slightly different character that looks like this.

  • And let me see if I can't do something using a counter

  • in this case-- a so-called variable.

  • I'm going to go ahead and under Events-- let me get a green flag clicked.

  • Then let me go to Data, which I know from just playing around before,

  • is where variables are.

  • And I'm going to go ahead and drag this.

  • >> So a variable called counter, and I'm going to initialize it to zero.

  • I can call it anything-- x or y or z-- but in programming,

  • calling something in a semantically useful way, like counter,

  • that describes what it is, it's a lot easier to read your code later.

  • Let me go ahead and get a forever block here.

  • And let me go to the looks page and do a Say block.

  • But what's cool about variables is I don't have to just type in something

  • like hello world, which we've already done, I can instead go to Data

  • and drag my variable, and even though the shape doesn't quite

  • look like it should fit, it will grow to fill.

  • And I'll just say the counter for one second-- spoiler-- he's going to count.

  • We'll say it for one second.

  • Then I'm going to go and have him wait for one second,

  • so it doesn't count up too fast.

  • And then lastly, change counter by one-- in other words,

  • increment the counter by one additional value and do this forever.

  • >> So the sheep too, like a programmer, counts from 0.

  • And if we wait long enough, he will do this forever.

  • But that's not exactly true, because in fact, as we'll discover in week one,

  • integers and computers more generally, technically have only a finite-- well,

  • rather computers, when they represent integers,

  • only have a finite number of bits.

  • Those light bulbs there can only count so high

  • before you're out of light bulbs.

  • And a computer too, only has so much memory,

  • only has so many transistors, so it can only count so high.

  • >> So it turns out that the sheep, I think, can count to 2 billion

  • or something pretty big.

  • So we're not going to wait for this to happen.

  • But eventually some bug will happen that can have some very real world

  • ramifications.

  • But beyond the sheep, that just introduces a variable.

  • Let's go ahead and open up something I made in advance

  • here called Pet the Cat-- Pet the Cat over here.

  • And notice here it's few blocks, but when green flag

  • clicked, forever doing the following.

  • If you're touching the mouse pointer-- so the cursor on the screen,

  • the arrow-- play sound meow and then wait two seconds.

  • And just do this forever.

  • Just constantly wait to see if the pointer--

  • if the cat is touching the pointer.

  • >> So I hit play.

  • Nothing's happening.

  • But as I move the cursor over the cat,

  • >> [MEOWING]

  • >> And if I move it away, not petting the cat anymore.

  • So some conditional logic nested inside of a loop.

  • How about this example, deliberately called Don't Pet the Cat?

  • What's this going to do?

  • >> [MEOWING]

  • >> Why should you not pet the cat?

  • >> [MEOWING]

  • >> OK.

  • So this is an example of an if else.

  • It's a decision point and because it's sitting in the loop,

  • they're both getting checked.

  • Is this true?

  • Is this true?

  • Is this true?

  • Is this true?

  • And eventually, one of those is going to apply

  • and so you hear either the meow or the roar of the lion in that case.

  • >> Well, let's do a slightly more fancy one that I made in advance too-- threads.

  • So a thread is just one thing that a computer can do.

  • So a multi-threaded program is a program that can do multiple things at once.

  • And all of these examples thus far have had

  • just one script, so to speak-- one program like this up here.

  • But notice this program has two sprites, two characters.

  • One is a bird.

  • One is a cat.

  • >> And notice when I click on these down left, they each have their own scripts

  • or programs associated with them.

  • And both of those programs, notice, start

  • with when green flag clicked-- let's look at the cat--

  • when green flag clicked.

  • And so indeed, when I hit play now, two things are going to happen at once.

  • The cat and the bird are both going to operate simultaneously

  • to create this effect.

  • And you might imagine what's happening.

  • There's a loop and the bird and the cat are in a loop.

  • The bird is just bouncing like I was before when I said ouch.

  • But the cat clearly has an advantage.

  • There's another sensing block that points the cat deliberately

  • to the bird in this case here.

  • So we could tease apart, by looking through those blocks, what's happening.

  • But the key ingredient here is one.

  • The bird, so that this game isn't completely boring-- or this animation--

  • starts at a random direction.

  • And the computer is picking a number between 90 and 180

  • essentially, so that it's a slightly different animation each time.

  • >> And then notice here, if the cat is touching the bird, then

  • play the lion four sound-- the roar.

  • But meanwhile in the bird's palette, we have this.

  • Forever, if not touching the cat, just keep moving three steps.

  • And then here's another puzzle piece.

  • If you're on the edge, bounce.

  • So the bird is just kind of minding its own business,

  • just flying around and bouncing, and it's really

  • the cat that had the conditional logic to determine if it had caught the bird.

  • All right.

  • So let's do one other here, this one being called Hi Hi Hi.

  • And this one here just does this in a forever loop.

  • But notice-- how do we stop this very annoying program?

  • Hit the space bar.

  • Because if I do that, the left hand program--

  • notice it's constantly listening-- is the key space press.

  • If the space bar pressed, and if so, what does it do?

  • It does a very common technique.

  • It sets a variable equal to some value.

  • But it toggles that value.

  • [? So appearance ?] based on the shape-- I

  • have a variable that I wrote in advance called

  • Muted, which just says yes or no.

  • Is the sound muted or not?

  • True or false?

  • And notice, I'm saying this-- if muted is zero, then change to one,

  • else set mute it to zero.

  • So just flip the value from zero to one.

  • I could have done-- change it from two to three and three to two

  • or four to five or four to six.

  • But it doesn't matter what numbers I use,

  • so long as I keep changing it the opposite.

  • >> And most any programmer would just choose zero and one-- false and true,

  • off and on-- to represent this.

  • And this is still running.

  • If I hit the space bar again

  • >> [SEAL SOUNDS]

  • >> The program is still running.

  • Because there's this other script that says, forever do the following.

  • If the muted variable equals zero-- so if you're not muted

  • is the logic-- if it's false or no, then play the sound,

  • because you're not muted.

  • You should play the sound and then think hi hi hi for two seconds

  • and then wait, and do it again and again and again.

  • >> And so in this way do we have a way for people to-- for programs to interact.

  • And they don't have to be as dated as others.

  • In fact, poking around-- no pun intended--

  • someone spent a huge amount of time on the internet implementing

  • PokemonGo in Scratch.

  • It even geolocates you in Cambridge or Allston here.

  • So if you want to see too what people can do is this-- very fancy menu.

  • Click on here.

  • >> This is me with my arrow keys now.

  • I'm going to go after this.

  • Click.

  • And now you click the PokeBall.

  • I mean, I think you're supposed to click the PokeBall.

  • All right.

  • So I did that.

  • I can go over here.

  • And this person implemented some more PokeBalls over here-- three PokeBalls.

  • >> We'll post a link to this online so you can play.

  • But notice there's just some basic building blocks.

  • It looks a lot fancier, and it is.

  • This is impressive and more than we would typically

  • expect, certainly for problem set zero.

  • I have no idea how long this person spent online.

  • But it's all just a loop.

  • There's a sound playing.

  • There's some kind of loop listening for whether I'm

  • hitting the up arrow or the down arrow or the left and the right,

  • and then if so, it's moving it some number of pixels.

  • And then if I click on another sprite, there's

  • some kind of if condition there.

  • Yeah, this is getting too intense.

  • We're going to stop.

  • It's all those basic building blocks.

  • There are no other ingredients other than the ones we've looked at already.

  • >> And yet here, let me do one final set of examples

  • that paints a picture too of what you can do here.

  • Here's a very simple program that just does this-- cough, cough, cough.

  • And based only on what we've looked at thus far,

  • where is the obvious opportunity for improvement.

  • This program is correct.

  • It coughs three times, which is what I intended.

  • But it's poorly implemented.

  • It's badly designed.

  • Why?

  • Yeah.

  • It's not a loop.

  • And it's not so much that it's not a loop,

  • it's that there's a lot of redundancy.

  • There is copied and pasted code, so to speak.

  • And the solution probably is indeed a loop.

  • So let me go ahead and improve upon that.

  • And I'm going to drag these over here.

  • Let me go ahead and get a repeat block, change this to three.

  • I'm going to throw away some of those blocks.

  • >> And you'll notice it's pretty intuitive.

  • You drag and drop and things appear and disappear eventually.

  • And I can just drag this in here, and now I have a cleaner version still.

  • But you know what?

  • There's this opportunity now for abstraction--

  • to start to define new vocabulary that MIT didn't anticipate.

  • There's wait and repeat and forever and if,

  • but what if I want to introduce the word cough as a block?

  • What if I want a puzzle piece whose purpose in life is to cough?

  • >> Well, let's look at this version here, which I made as follows.

  • Magically, I have created this puzzle piece here,

  • which Scratch allows you to do.

  • And indeed C and Python and JavaScript are

  • going to allow you to do this as well.

  • You can create your own custom pieces that you call what you want.

  • In this case, cough feels like a reasonable definition.

  • And then with these pieces down here can you define what it means.

  • >> I dragged and dropped from this palette here-- more

  • blocks-- this big purple block, where I typed in cough

  • as the name of my new puzzle piece.

  • And then I'm saying any time a user calls this new cough puzzle piece,

  • do a say and a wait.

  • And so up here in my repeat block, I can just cough three times.

  • >> And I would argue, especially if now you hide this detail.

  • Who cares how cough is implemented?

  • All I care about as a programmer that I can cough.

  • I don't care how say is implemented.

  • I just care that the cat can say something.

  • I can abstract away that detail and only focus on what's on the screen here.

  • But I can take this one step further.

  • >> Notice that here, I have implemented the loop three times.

  • But what if instead I grab this version?

  • And what if instead in this version here,

  • I just change my puzzle piece to take an argument and input unto itself?

  • And that input can be a number like three.

  • So now, if I am writing a program and I want the cat to cough,

  • I can actually tell the puzzle piece how many times to cough,

  • because at the bottom here, a fancier version of these custom puzzle pieces

  • lets me specify that cough actually takes

  • an input-- takes an argument like this.

  • And you know what?

  • Maybe I realize, wait a minute.

  • Coughing is the same-- it's fundamentally

  • the same idea as sneezing.

  • It's just a different word on the screen.

  • I can abstract away further and implement

  • this final version of a cough, which at first glance

  • is way more complex looking.

  • But notice what I've done.

  • I have now generalized-- genericized really-- this puzzle piece

  • to be called say word n times.

  • >> And now I have two new puzzle pieces down here define cough n times.

  • And what does the cough function do?

  • What does my custom puzzle piece do?

  • It just calls the say block, passing in the word I want to say,

  • passing in the number of times I want to say.

  • Because now I can implement sneeze by simply saying achoo,

  • in this case, some number of times.

  • >> And so I'm layering and layering.

  • And again, the key here is not how I implemented it, but the fact

  • that if I just literally move these off the screen,

  • look how simple if not pretty my program now looks.

  • Because it does what it says, I've abstracted

  • away what is inside that black box. it happens to be a purple box here,

  • but I've obstructed away what's inside because I don't care how it works.

  • I just care now that it works.

  • >> And indeed, in problem set zero, this is exactly

  • the kind of layering of ideas you'll have the opportunity to explore.

  • It's exactly the opportunity to apply problem solving techniques,

  • to what's probably an unfamiliar environment.

  • And whether you've not programmed before or programmed before,

  • you'll find that there's a little something

  • in this environment for everyone.

  • And with problem set one in a week's time,

  • we'll be transitioned to focusing on a higher level language called

  • C-- or rather a lower level language called

  • C-- that's even more powerful, even though it's

  • a little more cryptic at first glance.

  • >> And you'll realize per today's TL:DR, that this problem set has a shorter

  • window of time than future ones, simply because you should find it fairly

  • accessible.

  • And not to worry if you add the class late.

  • We'll address that before long.

  • And before we adjourn for cake, let's finish with just a two-minute look

  • at what awaits you here in CS50.

  • [MUSIC PLAYING]

  • All right.

  • That's it for CS50.

  • We will see you soon.

  • Cake is now served.

  • [MUSIC PLAYING]

  • SPEAKER 17: Have you heard of a sabbatical, Chief?

  • SPEAKER 18: Perhaps there's more under the hood.

>> [MUSIC PLAYING]

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

A2 初級 美國腔

2016年CS50--第0周--刮痧 (CS50 2016 - Week 0 - Scratch)

  • 202 22
    zero2005x 發佈於 2021 年 01 月 14 日
影片單字