第0周 (Week 0) - VoiceTube 看影片學英語

字幕列表影片播放

>> [MUSIC PLAYING]
[MUSIC - ROSSINI, "RANZ DES VACHES" FROM WILLIAM TELL]
>> [MUSIC - THE ENGLISH BEAT, "MARCH OF THE SWIVEL HEADS"]
>> [APPLAUSE AND CHEERING]
>> DAVID MALAN: So this is CS50.
My name is David Malan.
And 73% of you have no prior experience with computer science,
contrary to what you might think.
So today we thought we would chip away at that lack of familiarity, but also
give you a sense of, for those of you with more comfort, which directions
you can go this semester.
>> So let's start with this.
I really have no idea what's inside of a computer, even though, like you, I
use it every day.
But it's some kind of box, and there's not many inputs into it.
Minimally, there's, what?
Probably a power cord.
>> And indeed with this one ingredient, electricity, we seem to be capable of
doing quite a bit these days.
But at the end of the day, we have to represent the things
that we care about.
We have to represent information in some form.
And you're probably at least vaguely familiar with the idea by binary or
bits somehow or other, computers reduced to zeros and ones.
But can we embrace that and at least put a bit of light to that?
>> So I have these little desk lamps here.
I have an electrical outlet here.
And I'm going to propose that inside of my computer is at least one of
these things, something capable of being switched on or off.
In this case, it's indeed a desk lamp, but at the lower level, it's something
called a transistor.
>> But in our world, it's a desk lamp, so I'm going to go ahead and plug this
into my electricity here.
And I claim that using this simple, simple device, this simple switch, I
can represent information.
For instance, right now, I am representing nothing, right?
I'm representing what I'll call 0 or false, the opposite of something
actually being present.
But if I simply turn this switch, now I've represented a 1.
So using this very simple piece of memory, if you will, I can represent
information.
>> Now unfortunately, my computer can't do all that much.
It can only represent two values in the whole world--
0 or 1.
But what's an obvious solution, now, if we want to expand our computer's
memory and represent more than just 0 and 1?
>> Well, let's grab another such bit.
Let's grab another switch, another transistor, however you'd like to
think about it.
Let me go ahead and plug this into my computer as well.
And I'm going to claim, now, that by using a bit more electricity and
turning more of these switches on and off, I can represent more such
information.
>> So right now, this is 1.
If I want to now represent 2, I could do this.
But typically, convention, as we'll eventually see, will have me do this.
So this is 0, this is 1.
This would be 2.
And not surprisingly, this would be 3.
>> So in this way, still, can we count up even further?
If I get a third bit, a third switch, what's the highest number I can now
count up to from 0?
So 7 if I'm starting at 0, right?
Because if I turn this light on and actually plug this third and final
light into my electrical socket here, then I have the ability to represent
any of two values here, two values here, two values here--
and so I can represent 2 times 2 times 2, or eight possible values.
And if I start accounting at 0, so that's 0, 1, 2, 3, 4, 5, 6, 7.
>> So this binary.
It really is as simple as that.
And I'd argue that this is actually quite familiar to most
everyone in this room.
Let me go ahead and open a little text editor here.
>> And you might recall from grade school that we had things like the hundreds
place, the tens place, and the ones place.
And recall that if you had some decimal number, like something random
like 123, you would essentially write that out in the form
of these three columns.
And why is 1, 2, 3 what we know as 123?
Well, in the leftmost column, we have one 100 plus two 10s, so that's 120,
plus three 1s, so that's 123.
>> Now this world that we just illuminated is exactly the same as
you've been familiar with for years, except now, our columns
aren't powers of 10.
They're just powers of 2.
So whereas that's the ones place, this is going to be the twos place, this is
going to be the fours place.
>> And because I am only using the simplest of mechanisms to turn things
on and off-- electricity is flowing or electricity is not flowing--
I don't quite have the same expressive range as 0 through nine.
We're going to keep it super simple in this world of computers.
I only have 0 or 1--
off or on, false or true.
>> And so what I'm representing right now is 1, 1, 1, because each of these
lights is illuminated.
Well, that gives me one 4 plus one 2, so that's 6, plus one 1, and that's 7.
And ergo does this sequence of three bits represent the number 7.
>> So all this time, inside of your computer, have been any number of
transistors, any number of bits.
But at the end of the day, we can represent information
as simply as that.
Now unfortunately, we've only counted up to 7 in CS50 thus far, but
hopefully we can do a bit better than that.
And indeed we can.
>> Suppose that we as humans just arbitrarily decided that we are going
to associate numbers like 1 and 2, 3, 4, 5, 6, 7, with specific letters of
the alphabet.
And for historical reasons, I'm going to start somewhat arbitrarily, but I'm
going to say, humans, we are going to decide as a standard, globally, that
65 represents the number the letter A. 66 will represent B. Dot, dot, dot.
90 will represent the letter Z.
>> And let's suppose, if we really put some thought into it, we could come up
with numbers for exclamation points and lowercase letters, and indeed,
other people have done that for us.
So now we had bits with which we can represent numbers, numbers with which
we can represent letters, and with letters can we now start composing
emails and printing characters on the screen.
>> So let me invite, if I could, eight brave volunteers--
who don't mind appearing not only on camera but on the internet--
to come up here and represent eight such bits, rather than these three.
So how about one, two?
How about three?
How about four in light blue, five on the end?
About someone over here?
Six in front, seven in front, and eight in front, as well.
>> So I just so happened to come prepared with a whole bunch of slips of paper.
And on these pieces of paper are numbers that represent what columns
you guys are going to represent.
So you will be-- what's your name?
>> STUDENT: Anna Leah.
>> DAVID MALAN: Anna Leah, you will be the 128s column.
You are?
>> STUDENT: Chris.
>> DAVID MALAN: Chris will be the 64s column.
You are?
>> STUDENT: Dan.
>> DAVID MALAN: Dan will be the 32s column.
>> STUDENT: Pramit.
>> DAVID MALAN: Pramit will be the 16s column.
>> STUDENT: Lillian.
>> DAVID MALAN: Lillian will be the 8s.
>> STUDENT: Jill.
>> DAVID MALAN: Jill will be the 4s column.
>> STUDENT: Mary.
>> DAVID MALAN: Mary will be the 2s, and?
>> STUDENT: David.
>> DAVID MALAN: David will be the 1s column.
So if you guys could step a little forward so that everyone can see.
What you guys don't see is that on the back of these slips of paper is a
little cheat sheet that's about to instruct these eight bits to either
raise their hand or not raise their hand.
If their hand goes up, they're representing a 1.
If their hand stays down, they're representing a 0.
>> Meanwhile, we the audience should be able to figure out, based on this
mapping, what three-letter word these folks are about to spell out.
So in just a moment, you're going to read the first line off the back of
your cheat sheet, and you're either going to raise or not raise your hand.
If you're a 1, you raise, if you're a 0, you stand there
awkwardly, just like that.
Go.
What number, first and foremost, are these guys representing?
>> 66.
66, right?
We have a 1 in the 64s column, a 1 in the 2s column.
That gives me 66, so that appears to be representing B. So
you guys have spelled--
OK, that's enough.
B.
>> So now let's move onto our second letter.
Go.
Who's quickest at math here?
So 79.
Again, if we add up all of the columns in which there's a 1, currently, just
like we did before with the simplest of examples of 7, we now
get the number 79.
Which according to our mapping is the letter O. So we're almost there.
B, O. And lastly, go.
>> What are they representing now?
Less consensus.
That's just an absolute murmur.
Yes, it's in fact 87.
Good.
>> So if we now map that back up to-- let's start calling our ASCII chart,
American Standard Code for Information Interchange.
That gives us the letter--
not "bo" but "bow." And that's a perfect cue for you guys to take a bow
and head on back.
Thank you very much.
>> [APPLAUSE]
>> DAVID MALAN: You can keep them.
Though actually, would anyone like a desk lamp, also?
>> [HOOT FROM AUDIENCE]
>> DAVID MALAN: Desk lamp?
>> [LAUGHTER]
>> DAVID MALAN: Really?
Desk lamps for everyone?
All right.
So starting with the very simplest of principles, we've now not only counted
up from 0 all the way up to 7, we've assumed that just by throwing more
bits or more lights or more transistors at this problem, we can
represent bigger and bigger numbers, and ergo, bigger and bigger ranges of
alphabets, like English.
And just let's take on faith for today that similarly could we start to
represent graphics and video and any number of other media with which we're
familiar today.
>> So this is CS50, and in this class alongside of you are, again, very many
classmates who have as little experience as you.
And I mention this only because quite often, including as recently as one of
the freshman advising events and at last spring's sophomore advising
event, we often hear students disclaim when coming up to the CS table, well,
I've been thinking about taking this intro class, but I'm not really a
computer person.
Or, but everyone surely knows more than me.
And I put this in the biggest font possible, to convey this message that
that's not in fact the case.
>> And if you're wondering, should I, in fact, be here?
Realize that not only is this course's title Introduction to Computer
Science, it is Introduction to Computer Science I. So there is indeed
a second such introduction.
So you're not, in fact, in the wrong place.
And among the goals I have for today are to assuage any such concerns you
might have, but also to paint a picture of what's in store for
students less and more comfortable alike in this course.
>> But first, a word on one of the handouts you have today, among which
are a number of FAQs.
It's been a vision of ours for some time now to introduce a new grading
option into this course-- namely, SAT/UNSAT.
Philosophically for me, it is much much, much more important that the
students in this class engage with the material, be challenged by the
material, and worry far, far less about the mechanics of actual scores
and letter grades at semester's end, but truly embrace the
course and its material.
And really this feels, more generally, for what's interesting to them, to
feel challenged and rewarded but without fear of failure.
>> And indeed, this too is a recurring theme in this and other introductory
courses in other fields, that you have this trepidation when it comes to
putting one's toes in unfamiliar waters.
I myself, back in 1995, was a freshman.
I was very much focused on being a Gov concentrator here.
And yet I'd always grown up with a bit of an interest in computer science.
I was always curious.
>> But back then, even, I had this fear of even stepping foot in CS50, so much
so that I didn't even shop it freshman year.
And the only reason I put a foot in the door sophomore year was because I
was allowed to take it pass/fail.
But even pass/fail required that I get up the nerve to make an appointment
with Professor Kernehan at the time, bring this big sheet of paper, and ask
him for his signature and his permission to explore
these unfamiliar waters.
>> And it hasn't helped in recent years that when doing this in CS50, when we
used to be pass/fail, similarly would dozens or hundreds of your classmates
have to come up, God forbid, at the front of Sanders with this form, that
in some minds represents an inability, I dare say, to perform
are your peers' level.
Which is ridiculous, but I do think there's that mentality.
And there's never been in this culture of SAT/UNSAT, or pass/fail more
generally, in this course, or really on this campus.
>> So this year we changed that.
I would be ecstatic half of this class or more ended
up taking CS50 SAT/UNSAT.
In a year's time, it would be wonderful if almost everyone is.
Thereafter perhaps we'll work on letter grades at Harvard
College more generally.
But for now, we'll do this within our own sphere, and I would heartily
encourage you to review those FAQs and ask questions as you see fit, so that
hopefully you, unlike me, won't quite have that same fear factor when
exploring what's probably an unfamiliar place.
>> So what is CS50?
It is an introduction to the intellectual enterprises of computer
science and the art of programming.
But what does that really mean?
>> Well, thus far, we talked very briefly about representing information.
But suppose that we actually want to do something with it.
We need to introduce the notion of what we'll call an algorithm.
An algorithm is a procedure, a process, a set of instructions for
doing something.
>> And an algorithm can be something super simple.
For instance, an example with which some of you might be familiar is this
thing here.
So this book here is increasingly dated, but once upon a time, it
contained a whole lot of names and phone numbers.
And indeed, if I wanted to find someone in this phone book--
say, someone named Mike Smith--
I could find Mike Smith in any number of fairly straightforward ways.
I could start at the beginning and move on to page 1, not there.
Page 2, not there.
Page 3.
Is that algorithm, is that process, correct?
>> So it is correct, right?
I'm kind of an idiot for doing it in that manner, but eventually I will
find the surname S, and hopefully Mike is in that section, and I will become
done with my algorithm.
But surely it's not intuitive.
Most every reasonable human in this room would not have done that.
What would you have done?
>> You'd have gone straight to the middle, right?
Roughly to the middle.
And you realize, oh, these are the Ms. So Mike Smith, last name being Smith,
is not, clearly, then in the left half of the book.
He must be toward the S's in the right.
And at this point, though most of us don't do this in reality, we can
literally tear this problem in half.
>> [CHEERING AND APPLAUSE]
>> DAVID MALAN: Thank you.
>> [CHEERING AND APPLAUSE]
>> DAVID MALAN: You can literally tear this problem in half, leaving me with,
literally, a problem half as big.
So if this phone book was-- and it probably was-- about 1,000 pages, now
it's only 500.
If I do this again and I realize, oh, damn, I went too far, I'm in the Ts
section, I can similarly--
figuratively or literally--
rip the phone book-- it was actually much easier that time.
I can literally rip the phone book in half, leaving me now with
not 1,000, not 500--
250 pages.
And I can go 125, and half of that, and half of that, and half of that,
until finally I'll be left with just one single page.
>> [LAUGHTER]
>> DAVID MALAN: That's the part I fail on.
One single page on which Mike hopefully is.
Now those different algorithms can be sort of assessed or evaluated in
different ways.
The first one was very linear, right?
Turn page, look for Mike.
Turn page, look for Mike.
It's very linear.
If there's one more page in the phone book, it's probably going to take me
one more second, one more unit of time, however we're computing time.
>> So I might draw like this this line here, whereby as the size of the
problem increases from left to right--
phone book gets smaller to bigger--
and time is going to increase on the vertical axis, the bigger
the phone book is.
So n is just a general variable that computer scientists use to represent
some value, some number.
So n is going to increase linearly.
Double the size of the phone book, it's going to take me twice as much
time, most likely, to find Mike.
>> Now I could have been smart about this, right?
I was getting bored quickly.
Could have done this by twos.
So two pages, then four, then six, then eight.
And I could start flying through it a little faster, albeit at minor risk of
overshooting Mike, but that curve isn't going to be all that different.
It's still going to be a straight line, but slightly faster.
>> But what did I do?
I actually did something fundamentally better.
I achieved what we'll call logarithmic time, log of n, whereby this green
line has a much, much, much less straight edge to it.
And rather, it suggests, as it sort of approaches infinity ever so gradually,
that I could actually take a 1,000-page phone book, double its size
next year-- because suppose a lot more people move into town.
>> So now I've got 2,000 pages, but how many more steps is that smarter
algorithm going to take?
Just one.
I mean, that's a powerful thing.
If we go to 4,000 pages next year, that's going to take me
only two more steps.
So you can throw bigger and bigger problems at me, not unlike the web is
throwing bigger and bigger problems every day at Googles and Facebooks of
the world, and it's not such a big deal.
Because I put more thought and care into my algorithm with which to solve
problems efficiently.
>> And indeed, that will be one of the goals of this course.
You will, along the way, learn how to program.
You'll learn how to program in any number of languages.
But at the end of the day, the course is about solving problems and getting
better at solving problems-- and, as in cases like this, solving problems
more efficiently.
>> Now thus far, we've done this fairly intuitively.
Let's introduce something fairly generic called pseudocode.
So we'll eventually get, in this course, to
various programming languages.
But today we'll do it in English-like syntax, where you just kind of say
what you mean, but you're ever so succinct and you don't worry about
grammar and complete sentences.
You just express yourself as concisely as possible.
>> So pseudocode is English-like syntax that represents
a programming language.
And toward that end, let me propose that we now model the process we just
described of counting something a little differently, this time taking a
look at this five-minute video produced by our friends at TED that
defines what pseudocode is, defines what algorithmic thinking is, and even
though the example you're about to see is, in of itself, super simple, it's
going to start to give us the mental model, the vocabulary, with which to
do much, much more complex algorithms quite quickly.
>> [BEGIN VIDEO PLAYBACK]
>> [MUSIC PLAYING]
>> NARRATOR: What's an algorithm?
In computer science, an algorithm is a set of instructions for solving some
problem step by step.
Typically, algorithms are executed by computers, but we humans have
algorithms, as well.
For instance, how would you go about counting the number
of people in a room?
Well, if you're like me, you'd probably point at each person, one at
a time, and count up from 0.
1, 2, 3, 4, and so forth.
>> Well, that's an algorithm.
In fact, let's try to express it a bit more formally in pseudocode--
English-like syntax that resembles a programming language.
Let N equal 0.
For each person in room, set N equal to N plus 1.
>> How to interpret this pseudocode?
Well, line one declares, so to speak, a variable called N and initializes
its value to 0.
This just means that at the beginning of our algorithm, the thing with which
we're counting has a value of 0.
After all, before we start counting, we haven't counted anything yet.
Calling this variable N is just a convention.
I could have called it most anything.
>> Now line two demarks the start of a loop, a sequence of steps that will
repeat some number of times.
So in our example, the step we're taking is counting people in the room.
Beneath line two is line three, which describes exactly how
we'll go about counting.
The indentation implies that it's line three that will repeat.
>> So what the pseudocode is saying is that after starting at 0, for each
person in the room, we'll increase N by 1.
Now is this algorithm correct?
Well, let's bang on it a bit.
Does it work if there are two people in the room?
Let's see.
>> In line one, we initialize N to 0.
For each of these two people, we then increment N by 1.
So on the first trip through the loop, we update N from 0 to 1.
On the second trip through that same loop, we update N from 1 to 2.
And so by this algorithm's end, n is 2, which indeed matches the number of
people in the room.
>> So far, so good.
How about a corner case, though?
Suppose there are 0 people in the room-- besides me,
who's doing the counting.
In line one, we initialize N to 0.
This time, though, line three doesn't execute at all since there isn't a
person in the room.
And so N remains 0, which matches the number of people in the room.
Pretty simple, right?
>> But counting people one at a time is pretty inefficient, too, no?
Surely we can do better.
Why not count two people at a time?
Instead of counting 1, 2, 3, 4, 5, 6, 7, 8, and so forth, why not count, 2,
4, 6, 8, and so on?
It even sounds faster, and it surely is.
>> Let's express this optimization in pseudocode.
Let N equal 0.
For each pair of people in room, set N equal to N plus 2.
Pretty simple change, right?
Rather than count people one at a time, we instead count
them two at a time.
This algorithm's thus twice as fast as the last.
>> But is it correct?
Let's see.
Does it work if there are two people in the room?
In line one, we initialize N to 0.
For that one pair of people, we then increment N by two.
And so by this algorithm's end, N is 2, which indeed matches the number of
people in the room.
>> Suppose next that there are 0 people in the room.
In line one, we initialize N to 0.
As before, line three doesn't execute at all, since there aren't any pairs
of people in the room.
And so N remains 0, which indeed matches the number of
people in the room.
>> But what if there are three people in the room?
How does this algorithm fare?
Let's see.
In line one, we initialize N to 0.
For a pair of those people, we then increment N by 2.
But then what?
There isn't another full pair of people in the room, so line two no
longer applies.
And so by this algorithm's end, N is still 2, which isn't correct.
>> Indeed, this algorithm's said to be buggy, because it has a mistake.
Lets redress with some new pseudocode.
Let n equal 0 for each pair of people in room.
Set N equal to N plus 2.
If one person remains unpaired, set N equal to N plus 1.
To solve this particular problem, we've introduced, in line four, a
condition, otherwise known as a branch that only executes if there's one
person that we could not pair with another.
And so now, whether there's one or three or any odd number of people in
the room, this algorithm will now count them.
>> Can we do even better?
Well, we could count in 3s or 4s or even 5s and 10s, but beyond that, it's
going to get a little bit difficult to point.
At the end of the day, whether executed by computers or humans,
algorithms are just a set of instructions with
which to solve problems.
These were just three.
What problem would you solve with an algorithm?
>> [END VIDEO PLAYBACK]
>> DAVID MALAN: That is the only time I will appear in cartoon form.
But where that story leaves off, now, is how can we do better?
Threes and fours, we claim, we can count people much faster, but can we
do fundamentally better than that?
And I wager we can.
>> If we introduce a bit of our own pseudocode here, I'm going to propose
that we can achieve a line like this.
We're not going to count people one, two, three, four.
We're not going to go two, four, six, eight.
We're going to do fundamentally better by rethinking the problem, and in this
case, leveraging an otherwise underutilized resource.
>> In just a moment, I hope you'll forgive and humor us by standing up in
place, at which point we're going to ask each of you to take on in your
minds the number 1.
You're then going to increasingly awkwardly, as time passes, find
someone else who is standing, combine your numbers together
by adding them up.
One of you is then going to race to sit down first, and the other person
is going to repeat.
>> So in other words, by seeding all of you with the number 1, and then
combining those 1s into 2s and those 2s into 4s, with everyone increasingly
sitting down, we should, at the end of this algorithm, have just one loan
soul who didn't sit down fast enough but who has the entire audiences count
in his or her mind.
>> So if you would, let's go ahead and-- step one-- stand up in place.
And execute.
>> [CROWD MURMURING]
>> DAVID MALAN: Do you know where Lauren is?
729?
>> [CROWD MURMURING]
>> DAVID MALAN: All right?
>> [CROWD MURMURING]
>> DAVID MALAN: All right, we should be nearing the end.
We see one fellow standing here still.
Who else needs to be paired?
If you guys want to pair off.
Someone up top.
Why don't I lend a hand here.
For the very few people who are still standing, what numbers do you
have in your mind?
>> STUDENT: 78.
>> DAVID MALAN: 78 plus--
who's standing down here?
>> STUDENT: 39.
>> DAVID MALAN: Plus 39.
Plus who else is still standing?
81?
OK, who else?
Another 81?
Wow.
And then what's in back?
>> STUDENT: 49.
>> DAVID MALAN: 49, plus?
>> STUDENT: 98.
>> DAVID MALAN: 98 plus?
Is that someone else?
12?
Good job.
>> [LAUGHTER]
>> DAVID MALAN: Oh, 112--
oh.
Good job!
>> [LAUGHTER]
>> [APPLAUSE]
>> DAVID MALAN: Anyone else still standing?
Sorry?
>> STUDENT: 99.
>> DAVID MALAN: 99.
Anyone else still standing?
And the total number of students here is actually, according to--
do you have a number?
Oh, the actual number of people in the room, according to the account that
the teaching fellows were doing on everyone's way in, was 729.
So out of a roomful of Harvard students who counted themselves, the
answer is 637.
>> [LAUGHTER]
>> DAVID MALAN: So close.
But still.
OK, so that's a teaching moment, right?
This now is what we describe as a bug.
Somewhere along the way, we did some arithmetic wrong, or someone sat down,
or left, or something went wrong.
But that's fine.
Because even still, we got pretty close.
And I'd argue that we got to the wrong answer a lot faster than I would have
using my more linear approach.
>> So let's assume we did in fact get that correct, but think now about what
was happening each time, versus my own naive pointing algorithm.
One, two, three.
If there are indeed 729 or 637 people here, that would have taken me
literally 637 or 729 pointings of the finger and
incrementing my total count.
And I could do a little better by going two, four, six, eight, and
double that speed, maybe even triple or quadruple, depending how well I can
do that counting in my head.
>> But this approach that you guys took was fundamentally different.
Because at the beginning, all of you stood up.
So all 729.
And then literally half of you sat down.
And after that, another half of you sat down.
And after that, another half of you sat down.
>> And the total number of times that you guys could have sat down is roughly
eight or nine or ten total times, depending on what our total count is.
And we can sort of do this the other way.
If we had 1,024 people in the room, the total number of times you could
halve 1,024 people is 10.
>> Now think about it in the other direction.
Suppose, ridiculously, that we had, say four billion people in this room,
or a slightly larger room.
How many times would we have gone through this algorithm, such that half
of that class sits down?
It's only going to take 32 such operations, even in a class of size
four billion.
Why?
Because four billion goes to two billion, goes to one million, goes to
500 million, goes to 250 million, dot, dot, dot.
I can only do that division some 32 times, at which point, everyone except
one person would be left standing.
>> And that, too, is sort of a powerful idea that increasingly we'll try to
leverage in this course, and in programming and computer science more
generally, these germs of an idea with which we can then solve problems much,
much more powerfully.
So we started quite simple with that pseudocode and a guy in a room, but
now with a whole room full of people have we done fundamentally better.
>> Well, let's now transition from pseudocode to some actual code.
This language you're about to see happen to be called JavaScript, and
we'll return to this toward semester's end.
It's a programming language that you use to make websites and other such
software these days.
And we have used it, thanks to a friend of ours at Stanford, to encode
some hidden information here.
This is the art of steganography, so to speak, where you can hide
information in what otherwise appears to be noise or a completely different
image altogether.
But embedded in this particular image is indeed a secret message of sorts.
>> So let me go ahead and pull up the same image here, this
time in a web browser.
And I'm going to wave my hand at some of the details for today, particularly
for those of you who this looks like not only JavaScript but Greek, as a
completely unfamiliar language.
But this is an example of a programming language.
>> And for now, take on faith that this first line of code--
and by code, I just mean text.
Text that I could have literally typed into Microsoft Word, if I had the
right software to then do something with it.
Programming source code, programming code, is really just text, and it
looks different based on what language you're using, not unlike English and
Spanish and Russian all look different when you type them at your keyboard.
>> So this first line, for now take on faith, simply opens a graphic from the
internet, that noisy graphic we just saw.
This next line here is an example of a loop, and we actually saw that same
jargon in the TED video.
A loop is something that happens again and again, and even though this
absolutely looks cryptic, with the keyword for, and some parentheses, and
some semicolons.
We'll come back to that before long, but that loop there essentially is
telling the program, iterate over all of those noisy dots, from left to
right, top to bottom.
>> Because at the end of the day, an image like this-- and you can actually
kind of see it on this projector--
is really just a grid of dots.
So we can identify each of those dots by a coordinate, x, y, and with this
program, now can we begin to do something to those dots.
>> So what I'm going to go ahead here and do is I'm going to make some changes.
First I'm going to go ahead and get rid of all of that greenish and bluish
noise, and I'm going to go ahead and type the following
admittedly cryptic syntax.
im for image.
set blue at location x, comma, location y, to 0.
In other words, I want to just turn off all of the blue
dots in that picture.
>> I'm going to go ahead now and click this Run/Save button, and you'll
notice on the right-hand side, the resulting image appears.
Now its super green, but that's not surprising, because I literally turned
off, by making a 1 a 0, all of the blue in that picture.
>> Well, now let's do it a bit more.
im for image, dot setGreen, x, y.
And that just means iterate from left to right and then top to bottom.
Turn that off with a value of 0, as well.
Save.
And on the projector, you can't actually really see anything at all.
>> On my laptop screen, if I peer in just the right way, I can see a bit of an
image, because they're still some red in there.
If you've ever heard the acronym RGB--
red, green, blue--
it's referring to this composition of an image using
just those three colors.
And right now, we've thrown away all green, all blue, but
there's not much red.
>> So let me crank up the red.
How can I do that?
Well, first, I'm going to ask this program a question.
I'm going to go ahead and let's call it a variable, just like in algebra.
You can have x or y or z.
I'm going to declare a variable and say, put in this variable,
temporarily, the value of the images getRed value at x, y.
>> And again, we'll come back to all of this detail in the future.
But for now, just take on faith that this line is asking the program, what
is the red value at x, y?
At that particular dot?
>> Then I'm going to do something to it.
Then I'm going to do image dot set red at x, y, y but this time I'm going to
boost it by doing red times, let's say, 10.
So increase it by a factor of 10.
Let me zoom out now and click could Run/Save.
And voila, that was there the entire time, even though our human eyes
couldn't quite see it.
>> So again, this now is real code, an example of a language that we'll come
back to before long.
But realize, particularly those of you with no such experience, it's quite
soon that we ourselves will be writing code like that there.
In fact, a tool with which you're all somewhat familiar, perhaps, is CS50's
own course-shopping tool, which was actually rebooted this summer by some
of CS50's own former students, now turn TFs.
>> So this happens to be a website built in a language called PHP.
It uses a database called MySQL, things with which we'll get our hands
dirty later in the semester.
But believe it or not, even something like this ultimately reduces to the
simplest of loops and conditions and branches, like those we saw just a
moment ago in the TED video.
>> What I thought I'd do now is share not just something we the staff have made
for the campus, but rather something a former student-- three
students, in fact--
made this past year, Sierra, Daniel, and Sam, the last of whom had no prior
programing experience when he took CS50.
And for their final project, they exhibited, at the CS50 Fair, an
application called wrdly, which is a web-based program for which they made
this video that I thought I'd share to give you a sense of just what is
possible by term's end.
>> [MUSIC PLAYING]
>> DAVID MALAN: That's from Week Zero to Week 12 this past year.
>> [APPLAUSE]
>> DAVID MALAN: As a teaser, too, really to whet your appetite is to what's
possible, you may have seen already, or may soon see, market.cs50.net, a
new tool that the course's team has been working on, this time in
collaboration with Harvard Student Agencies, such that starting this year
and continuing hopefully into this coming summer you'll have a standard
opportunity on campus to buy and sell things of interest to you.
And with partnership through HSA, you'll also be able to drop items off
in one of HSA's physical stores at some point in the future, so as to
proxy things, particularly as you graduate and don't necessarily want to
discard things, but actually pay it forward to folks who might follow you
here on campus.
So more on that to come.
>> But a little more concretely, a tool that's come out of CS50 in recent
years, with which some of you might be familiar and others of you might be
googling now, at CS50.net/2x, you'll find a link to a Chrome extension
which is demonstrative of how you can use JavaScript, that same language we
used with the Eiffel tower a moment ago, to implement 2x playback speed
for all Harvard iSites videos.
This is something that's built into CS50's own video player.
But this, too, if you begin to dig into the source code, which we'll
happily make available, you'll see how you can even solve problems like that,
accelerating widgets in websites with which you're already well familiar.
>> So a word now on the course and expectations and what lies ahead.
In general, we'll indeed gather here on Mondays and Wednesdays-- though
this Friday, we'll gather because of Shopping Week--
1:00 to 2:00 PM, though sometimes until 2:30.
Given that you might therefore want or have to take some class at 2:00 PM
onward, or even before, do realize the course is supportive of what's called
simultaneous enrollment, whereby we'll support a petition to the Ad Board and
your resident deans on your behalf if you have a conflict somewhere in this
1:00 to 2:30 range.
Head to that URL online for additional details.
>> But in terms of the support structure that characterizes CS50, for students
more and less comfortable alike, we offer distinct tracks of sections.
And this is a couple of weeks off, but before long, you'll be asked as to
your comfort level.
Are you among those less comfortable, more comfortable, or
somewhere in between?
>> And we'll have three distinct tracks that cater to
precisely those audiences.
So at no point in the term should you even feel like you're competing
against any student with more or less background than you.
Indeed, the course is meant to be much more collaborative and much
more open than that.
>> In terms of the problem sets, you'll find, too, that in addition to the
standard edition of each week's problem set, there's often a "hacker
edition" that's meant to be targeted at the 5% to 10% or so of the
demographic who's indeed among those more comfortable and would like more
of a challenge than the standard edition of that pset expects.
More details on those to be found in the syllabus.
>> But also in there can be found details on the courses late days.
Typically problem sets are due on Thursdays.
However, you can extend many of your deadlines this fall from Thursdays to
Fridays simply by meeting us halfway, so to speak, answering a few warm-up
questions in some of the week's problem sets, that will automatically
then give you an extra 24 hours.
We will also drop your lowest score, as per the syllabus.
>> To give you a sense of what the problem sets are-- because it's indeed
the course's problem sets that ultimately define almost every
student's experience, more so than lectures, more so than sections, more
so than most any other aspect of the course.
Last year, for instance, we began, as we'll begin this year, with Scratch.
Particularly this Friday, we'll use, for just one day's time, a graphical
programming language, with which we'll start programming by dragging and
dropping puzzle pieces that only assemble physically if it makes sense
to do so logically.
>> Next week, we'll quickly transition to C, a fairly old but very small and
simple language that will allow us to really go from 0 to 60 over the course
of just a few weeks, and then parlay those same skills and knowledge of
basic programming constructs into higher-level languages like PHP,
JavaScript, and yet others still.
>> Last year, the third pset in the course was that of cryptography, a
domain-specific application whereby we challenged students to implement any
number of ciphers, programs with which to scramble or unscramble information,
to encrypt it.
For the hacker edition, by contrast, we gave the hacker students a file
from a standard Unix computer containing user names and passwords,
the latter of which were encrypted, and we challenged those hacker
students to decrypt, as best they could, those passwords, still on that
same domain.
>> Scramble, a game with which some of you are perhaps familiar.
A forensics piece, where we ask students to recover data that had been
otherwise deleted from my own digital camera's compact flash card, by
actually writing software to figure out, where were the zeroes and ones in
that digital camera that previously composed a JPEG graphic?
>> A challenge of sorts last year involving writing the fastest
spell-checker possible, competing against friends and classmates if
they'd like.
Implementing Huff 'n Puff, a compression program.
And then ending the semester with CS50 Finance, a web-based application with
which you create an eTrade-like website to buy and sell stocks, so to
speak, by actually pulling nearly real-time quotes Yahoo!
Finance.
>> What we didn't do last year was one problem set that remains
nonetheless a favorite.
If you've never gone to shuttle.cs50.net, you'll see a user
interface a little like this.
But two years ago, the class implemented, using Google Maps and the
Google Earth plug-in and a little bit of savvy with driving around campus,
so that the objective of this game was, as you can see some of the faces,
is to drive around campus looking for staff, teaching fellows and CAs, and
when you do, putting them onto your shuttle bus.
None of them actually seem to be here, so we're going to enter a cheat code.
>> [LAUGHTER]
>> DAVID MALAN: There we go.
All right.
And here now is the staff laced throughout campus.
And as you can see, on the right-hand side of the screen, the shuttle bus
has empty seats.
And the objective was to write the code with which to simulate this
driving and picking up and dropping off of passengers.
That one, too, using a language called JavaScript.
So realize that programs like that will be on our same trajectory this
year, as well.
>> In terms, now, of additional support, we have office hours.
As you might have seen in your own house dining hall or in Annenberg,
we'll be in the house dining halls four nights a week--
Leverett, Pfoho, Eliot and Annenberg this year, 8:00 PM to 11:00 PM.
And what we thought we'd do this year is something a little different.
>> If you heard rumblings last year that it was a bit too stressful, this
year's office hours, as we'll describe next week, will be more organic,
whereby upon arrival, you'll be dispatched to one particular table
where multiple staff members await, and we'll do things much more
organically.
No more queue, no more iPad, but rather have more intimate
conversations around a table of just eight or so students, so that we
approximate the feel of what otherwise would be a much smaller class.
>> We offer, as well, these things we called walkthroughs, videos filmed in
advance by one of the course's teaching fellows, Zamyla, in which she
walks you through the week's problem sets, offering tips and tricks for the
challenges that lay ahead.
And conversely, after problem sets are due, this year, we'll also release
little clips call post-mortems that actually walk you through
representative solutions, both good and bad, via which you can infer how
you could have or should have implemented your own solution.
>> And what we'll offer for the first time this year as well, particularly
for those students who avail themselves of the course's other
resources but nonetheless are struggling all too much, the course
itself will pair those students, as resources permit, with tutors so that
you have a much more intimate opportunity than house dining halls
allow for one-on-one assistance.
>> Now a final glimpse at some of the end games in sight.
You might be familiar with the CS50 Hackathon.
Well, coming this December, from 8:00 PM to 7:00 AM, at the beginning of
Reading Period, will be an opportunity to gather with classmates--
this would be around 9:00 PM--
during which you dive into your final project's implementation alongside
classmates, friends, and food.
This would be around 1:00 AM, when the first batch of food arrived.
And this is about 4:00 AM that particular year at the CS50 Hackathon.
>> But the true climax of the course is meant to the CS50 Fair, a campus-wide
exhibition of your own final projects, to which family and friends are all
invited, as our recruiters and our friends from industry.
This, for instance, is a glimpse of the 2,000-plus people who've attended
past years.
Expressions like this are not uncommon, and similarly do your
classmates delight in things you've accomplished.
>> And actually, toward that end, we have a start-of-term event, as well.
If things like this appeal to you, or you're at least curious as to what
this, know that a new tradition of the course is called CS50 Puzzle Day.
And this was instituted a couple of years back to really signal to campus
that computer science is not about programming, and it's certainly not
about embracing only those students who have prior experience.
It's really about problem-solving more generally.
>> And so Puzzle Day, over the past few years now, has evolved into a nice
partnership with our friends at Facebook, whereby there'll be fabulous
prizes and pizza across the river at the i-lab this coming Saturday.
Head to that URL with two or three friends if you would like to partake
in this new tradition.
>> So I'd like to ask that you keep one thing in mind, and we've got just a
two minute clip on which to close today.
73% is the number to remember.
Cake, too, will await you outside this transept as we adjourn in just a
couple of moments, which is a tradition of the course, as well.
But this is the key quote from the course's syllabus to keep in mind.
What ultimately matters in this course is not so much where you end up
relative to your classmates but where you, in Week 12, end up relative to
yourself in Week 0.
>> But the glimpse that we will leave you with here today is this last one here
by our same Daniel, who did the wrdly video just a moment ago.
I leave you with this glimpse of what lies ahead.
And as we do this, if we could have CS50 staff from the front of the room
to come on up to the stage to paint all the more of a visual picture as to
what awaits you this year--
getting awkward.
We'll conclude with this here on the screen.
>> [MUSIC PLAYING]
>> DAVID MALAN: This is CS50.
>> [MUSIC - MATT & KIM, "IT'S ALRIGHT"]
>> SPEAKER 1: I love CS50 more than cats.
>> SPEAKER 2: Whoaaaa!
>> [LAUGHTER]
>> DAVID MALAN: This, then, is CS50.
We will see you on Friday.
>> [APPLAUSE AND CHEERING]
>> NARRATOR: At the next CS50, an onstage demo doesn't go as planned.
>> DAVID MALAN: We want to find Mike Smith in this phone book.
Well, what are your instincts?
I might jump roughly to the middle of the phone book, glance down, see that
I'm at M, and I know now that Mike Smith isn't to the left.
He must be to the right.
And so at this point, we can literally tear--
at this point, we can literally tear--
at this point, we can figuratively tear the phone book in half.
>> [UKELELE STRUMMING]