Welcome to Exploring Computing.
Today's video is about programming.
So unless you've programmed before,
this whole programming process can
seem quite mysterious and very strange and very unnatural.
But there's actually a bunch of different activities
that we do that are quite similar to programming
in many ways.
So I'm going to start off by talking about a couple
of these.
So one activity that's quite analogous to programming
is giving directions.
If somebody asked me how to get to San Francisco International
Airport from Stanford, I would say get on Sand Hill Road,
travel east until you hit the freeway, get onto 280 North,
switch to 380 East, switch to 101 South in the SFO lanes,
and you should hit the airport.
So I've given a series of instructions,
and if the person who I've given the instructions to
follows the instructions properly,
they should end up at SFO.
Another example is cooking.
So here are the instructions for making Kraft Macaroni
and Cheese.
You boil the water, you're stirring the macaroni and cook
for seven to eight minutes, you drain,
you add butter, milk, and cheese mix, and then you mix well.
So again, for both these tasks, we are giving--
by the way, that's [? Manny ?] sneezing if you wondering
what's going on over there--
for both these tasks, we've given a number of directions
that should be carried out step-by-step,
and they are to be carried out in the order in which they're
listed, that is important.
And they are not to skip any of the steps,
that actually turns out to be important as well.
So if our instructions are good and the user follows them
explicitly, they should successfully
fulfill the task that we've given instructions for.
So the good news here is, the computer will always follow
the instructions exactly.
It turns out that that's not always the case with humans.
And just to give a rather embarrassing example,
one of the first things I remember trying to cook
was Kraft Macaroni and Cheese, and I
skipped one of the steps, which was the drain step.
And I ended up with Kraft Macaroni and Cheese soup.
It was pretty disgusting, and this would be an amusing tale
if I were like five at the time, but I was actually in college,
so.
All right, well that's not going to happen on the computer.
If you tell the computer to drain the macaronis,
it will drain the macaronis.
So another thing to keep in mind here
is, so I've got my little program here,
so the computer, as I said, will carry out the instructions
in the order listed.
And it will execute them in the order in which they're listed,
and it actually turns out that last part is important.
And this is something that I have
found that many new programmers don't pay a lot of attention
to.
That is, the order in which you list
the instructions for the computer
is often very important.
So if we look at our little program here,
I asked the computer to ask the user
for the temperature in Celsius.
I carry out my little Celsius to Fahrenheit conversion,
and then I go ahead and print out
the temperature in Fahrenheit.
It has to happen in this order.
If I reverse the order of any one of these statements,
we have a problem.
So in the bottom example here, I have
asked the user what the temperature is in Celsius,
and I print what the temperature's in Fahrenheit,
and then I calculate the temperature of Fahrenheit.
That doesn't make sense.
So in this case, the ordering is very important.
If I reorder these, it's not going to work,
and I do often see students just randomly reordering
their statements because it's not working,
and they figure if they just reorder them,
maybe that'll fix things.
You need to think carefully about what the order is
and why the statements are in that order
and put them logically in the correct order.
So in this particular example, we
are converting a total number of minutes
to the number of hours and minutes.
And it actually, in this particular case,
the ordering of those first two statements is not important.
If I calculate the number of hours
first, followed by the minutes, or if I calculate the minutes
first, followed by the hours, that can actually
go in either order, whereas that last statement,
the print statement does have to happen after the first two
statements occur.
So ordering is often important, but not always important.
Again, the best way to work this out
is to think things through logically.
What [? does ?] each of these statements doing?
Is the order between this statement
and the next statement or this statement
and the previous statement, is that important
or is that not important?
OK, as I suggested in the last lecture,
there is this edit debug cycle where I write or edit my code.
I try it out, see if it works.
If it doesn't work, I go back to writing or editing the code,
and I try it out again, and I just
keep on repeating that process as long as necessary.
This is very similar to the process
we had for our HTML and CSS, and this
is this process we will use for Python
or for any other programming language.
The one area where I think--
it's not that this process falls apart,
it is still the same process, but the one area
where the process with programming
is harder than the process with HTML and CSS
is that in HTML and CSS, the results are always visible.
That's one of the reasons why I like
teaching HTML and CSS first, you load that up in the web page,
and you can see what went wrong.
Oh, I thought I was only making the title bold,
but I see the entire web page is bold.
I start thinking about what might
make the entire web page bold.
Maybe I forgot to end my bold tag.
So in HTML and CSS, the results are always visible.
With programming, sometimes the results are invisible.
And in particular, the intermediate results
are often invisible because you recall
from our previous discussion, we have these storage locations,
which are [? four ?] variables, and we
are storing our intermediate results in these variables.
We don't know what the variables are set to,
and in order to figure out, if we start a program
and it works, great, but if we start up our program
and it doesn't work, the question
is, why isn't it working?
And a lot of times, the reason why it's not working
is our intermediate results are wrong.
And so how am I going to figure out
what the intermediate results are, because they're invisible?
Well, as a professional programmer,
there are a variety of different tools
we can apply to make the invisible results visible,
but the easiest thing for someone just starting out
is to just use a print statement.
So you recall, if I use a print statement,
it is just going to print the value of whatever
is inside that press statement out onto the Python interpreter
or the Python shell.
And so here let's say I've got this variable x,
I don't know what x is doing.
It doesn't seem to be working.
I'm guessing that x is wrong, but I'm not really sure
because I can't actually see it, it's invisible.
What I do is I add this print x statement into my code,
and again, you can think about where to put in your code,
it's going to vary depending upon which part of your code
you're concerned about.
But wherever I put in print(x), what's going to happen
is the Python shell will print the value of x right there,
and I'll either be like, oh, that actually
looks like what I'm expecting it to be,
so maybe the problem is in another variable,
or it prints out the value of x, and I'm like, that's not right.
I think it should be this other value,
and then I start digging into the code trying to figure out
why the value of x is what the Python interpreter thinks
it is, as opposed to what I think it should be.
Yeah, and there's actually a fancier version of this.
Here's the fancier version, print("x",x).
OK, so what this is going to do is that first x which
is in quotes with a colon after it, remember, that's a string.
So remember, the computer is going
to distinguish between strings and variable names.
If there's quotes around it, and remember,
we need to use these standard straight quotes instead
of the angle quotes, which if they ever show up on my slides,
it's because PowerPoint loves turning them
into angled quotes.
There is a way to turn it off, but then when
you're typing actual English and then angle quotes look nice,
then you don't get those.
Anyway, so use the regular straight quotes.
If you're using Visual Studio code,
if you're using the Python built-in editor,
it should just give you the standard quotes,
should give you the angle quotes.
Anyway, those straight quotes, that identifies
a character sequence, a string of characters.
And so I'm saying print the following string of characters
as is, just literally as I've given it to you.
So it will print a x followed by a colon.
And then that second x after the comma says,
that's not inside of quotes, that's
actually a variable name.
So it will go ahead and retrieve the value of x.
So let's say the value of x is currently 3.
What this statement would print is x:3,
and this is going to be useful if you're pointing out
the value of a bunch of different variables,
and it's going to identify if I've got in another place I
have print("y:",y) I'll say in one place, x is 12, y is 15,
and so it's useful to go ahead and add in that extra label
that's going to get printed out when I'm trying to figure out
with the different variables are being set to.
OK, another thing to be aware of is
there's actually several different types
of errors that can occur when we're programming.
They are referred to syntax errors and semantic errors.
A syntax error occurs when there's
an error in the grammar.
So here, I'm trying to take Celsius,
and then you see I've got that multiply, divide by 5,
and that doesn't make sense because you can't multiply
something and then divide it without telling me
what you're multiplying by.
This is gibberish.
All right, so this would be the equivalent
of trying to take a sentence in a language, a human language,
and not following the correct grammar rules.
So with humans, the human can sometimes figure out what it is
you're trying to say, but with a computer,
if you don't follow the grammar rules,
if you don't follow the syntax rules-- remember,
syntax and grammar are basically synonymous when we're talking
about computer languages here--
if you're not following the grammar or syntax rules,
the computer is just going to be like,
Patrick, I have no idea what it is you're trying to tell me.
So I'm just going to ignore it.
So that's the first source of errors.
And generally, you're going to determine
if you have syntax errors when you edit
your program in the Python editor and you tell it to run,
it will immediately tell you, hey, I
looked through this program you're telling me to run,
and there's a bunch of stuff that are
completely illegal in Python.
These are not allowed, and those are your syntax errors.
The other source of errors is semantic errors.
Semantic errors occur when you have a perfectly legal program,
but it's not actually correct.
So in this case, I'm converting Fahrenheit to Celsius.
I'm multiplying by 9, I'm dividing by 5,
it turns out I'm also supposed to add 32 to it, and I didn't.
So this program will run, it is perfectly legal, grammatically
correct, syntactically correct Python,
but it's going to give me the wrong answer.
And so in contrast with the syntax errors, which
will be discovered by Python as soon as I tell it to run,
it will list, hey, here's a bunch of things you did wrong
and these are illegal, the semantically incorrect program
is legal, it will run, it's just not going to give you
the correct result. And so when that happens, if it's
a short program, you just have to look over the program
and try and figure out, why did I get this number when
I thought it was supposed to get this other number?
When you've got a slightly longer program,
then you have to go back to what I said a couple of minutes
ago about trying to figure out what
those invisible intermediate results are
and what's going wrong with those,
so add in some print statements to figure out
what's going wrong.
OK, the last thing I wanted to tell you
is that programming can be very frustrating,
and a lot of times when you're first starting out
as a programmer, you think that I
have all these errors in my program, this must be my fault.
I must not be very good at this.
And that's actually not true.
So it turns out that if you have bugs in your code,
you have bugs or errors in your code,
we call errors in code bugs--
there's actually a story about why they're called bugs.
It's not clear entirely.
This is apocryphal, although apparently this story
did happen, it's not clear that this
is why they're called bugs, but the story
is that back when we had electromechanical machines,
a program was not working.
And when they went to try and figure out why the program was
not working, there was a moth stuck
in one of the electromagnetic switches,
and therefore, they said it was a bug.
So that part of the story is actually true,
and the person who found the bug is Rear Admiral Grace Hopper.
If you've got computer science friends,
there's a big conference for women in computer science named
after her.
She created one of the most widely used programming
languages back in the day called COBOL,
and the Navy actually has a photograph
of the bug that she found.
What's less clear is that this is actually
the source of the name "bug," but it's an amazing story,
so I thought I'd pass it on to all of you.
Anyway, so bugs, you have bugs in your code.
You have bugs in your code because you are a human being
and human beings generally do not write code correctly
the first time.
That's a normal occurrence.
It means that you are not some sort of a robot,
so that's mostly all to the good.
The TAs and I have bugs in our code,
so if you have bugs in your code, congratulations,
we have bugs in our code.
There have been plenty of times where
I have sat there with my computer
and wanted to take the computer and throw it out the window,
because I was so sure I had written the code correctly,
and it was still wrong.
And it's just super frustrating to try and figure out
what you did wrong, you're really sure you screwed up.
In fact, one of the very rare occurences
is, about five or six years ago, I had just taken over 108,
and every year I would--
when I first took over CS 108, I would rewrite the homework
assignments on my own before the students did it just
to remind myself of what the students were
going to be struggling with.
And I remember one of the programs I wrote,
and it actually ran the first time, and it was shocking,
it was amazing.
It was the best feeling ever, and I mention this
because that's super unusual.
That never happens.
I still remember that it was five or six years ago.
Having bugs in your program is totally normal.
It is not because you are not up to programming,
it is because it is part of the programming experience.
And in fact, professionals have bugs in their code,
and they often have many bugs in their code,
and that's one of the reasons why programs are constantly
updated.
So you see the operating systems being updated,
Windows is constantly being updated,
your apps are constantly updated.
Sometimes it's to add in new features,
but more often than not, it's because they
had a bug in their code that they discovered or maybe it
was a security hole in their code
because they didn't think things through carefully.
And so having bugs in your code is a perfectly normal part
of the experience.
I think those of us that become programmers,
it's just that the joy of actually creating a running
program and seeing something that we thought of in our head,
we've actually created it and it's up
and running, that joy of finally getting it all running
is worth the frustration of having problems with our code
until we get them all debugged.
But don't feel that there's something wrong because you
have bugs in your code.
It is part of being a human being.
Again, it is something that every programmer experiences,
including the TAs and myself and all
the professional programmers.
All right, in the next video, we're
going to extend your programming capability
by adding in some new structures that will actually
greatly enhance what you're able to do with your programs.
I'll talk to you soon.