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 6 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].
Tidak ada komentar:
Posting Komentar