Commons license.

Your support will help MIT OpenCourseware continue to

offer high-quality educational resources for free.

To make a donation, or view additional materials from

hundreds of MIT courses, visit MIT OpenCourseware,

at ocw.mit.edu.

PROFESSOR: OK, to work.

A word of warning: fasten your seat belts.

Or, another way of saying it is, I'm going to open up the

fire hose a little bit today.

Last lecture, you might have thought this was a SHASS class,

it's not like a philosophy class, and it was important to

set the stage for what we're going to talk about, but

we talked about very high level things.

The notion of recipes, the notion of computation, why

you want to do this, what you're going to learn.

Today we're going to dive into the nitty-gritty, the nuts and

bolts of the basics of computation, and in particular,

what I'm going to do today is, I'm going to talk about

operators and operands, which we did a little bit real last

time, in particular how to create expressions, I'm going

to talk about statements as the key building blocks for writing

code, and I'm going to introduce simple sets of

programs, in particular I'm going to talk about branching,

conditionals, and iteration.

So, a lot to do.

OK?

So, let me jump straight to it.

At the end of last lecture, we started introducing some of

the pieces you want to do.

And I want to remind you of our goal.

We're trying to describe processes.

We want to have things that deduce new kinds

of information.

So we want to write programs to do that.

If we're going to write programs, we need at least

two things: we need some representation for

fundamental data.

And we saw last time two examples of that.

And the second thing we're going to need, is we're going

to need a way to give instructions to the computer

to manipulate that data.

We need to give it a description of the recipe.

In terms of primitive data, what we saw were

two kinds: Right?

Numbers and strings.

A little later on in the lecture we're going to

introduce a third kind of value, but what we're going to

see throughout the term is, no matter how complex a data

structure we create, and we're going to create a variety of

data structures, fundamentally all of them have their basis,

their atomic level if you like, are going to be some

combinations of numbers, of strings, and the third type,

which are booleans, which I'm going to introduce a little

later on in this lecture.

And that kind of makes sense right?

Numbers are there to do numeric things, strings are our

fundamental way of representing textual information.

And so we're going to see how to combine those

things as we go along.

Second thing we saw was, we saw that associated with every

primitive value was a type.

And these are kind of obvious, right?

Strings are strings.

For numbers, we had some variations; we had

integers, we had floats.

We'll introduce a few more as we go along.

But those types are important, because they tell us something

about what we want to do when we want to put them together.

OK, but nonetheless, I want to stress we have both a

value, yeah, and a type.

All right.

Once we have them, we want to start making combinations

out of them.

We want to put pieces together.

And for that, we combine things in expressions.

And what we saw as expressions are formed of operands

and operators.

And the simple things we did were the sort of things you'd

expect from numerical things.

Now I want to stress one other nuance here.

Which is, and we're going to do some examples of this,

initially we just typed in expressions into the

interpreter; that is, directly into Python.

And as I suggested last time, the interpreter is actually a

program inside of the machine that is basically following the

rules we're describing here to deduce the value

and print it up.

And if we type directly into the interpreter, it essentially

does an eval and a print.

It evaluates, and it prints.

Most of the time, we're going to be doing expressions inside

of some piece of code, inside of a script, which is the

Python word for program.

In there, I want to make this distinction, this nuance: the

evaluator is still going to be taking those expressions and

using its rules to get a value, but it's not going to

print them back out.

Why?

Because typically, you're doing that to use it somewhere

else in the program.

It's going to be stored away in a variable.

It's going to be stuck in a data structure.

It's going to be used for a side effect.

So, inside of code, or inside of a script, there's no print,

unless we make it explicit.

And that's a little bit down in the weeds, it's a detail,

but one I want to stress.

You need to, if you want something to be printed out

inside your code, you need to tell the machine to do that.

OK.

So let's do some simple examples.

We've already seen somebody's.

I just want to remind you, if I wanted to, for example, type in

an expression like that, notice the syntactical form, it's an

expression, a number, followed by an operand, followed

by another expression.

And of course I get out the value I'd like there.

Yes sir.

Oh, you don't like leaning that far to the left?

OK, if you're a Republican I'll be happy to shift

this over a little bit.

Wow, John, I got a laugh for a political joke,

I'm in big trouble.

That better?

Oh damn, all right, I'll have to do it even more.

OK, here we go, here we go, you see, I'm doing it down here, I

can't see it, does that-- ah, I hear his sighs of

relief, OK, good.

There we go.

Better.

All right.

One of the other things we showed last time is that

operators are overloaded.

And this is where you heard John and I disagree.

I don't happen to like this, but he thinks it's an ok thing.

In a particular-- if we, whoa, we don't do that, we do this--

that is, give a combination of a number multiplication in a

string, this will in fact give us back a new string with that

many replicas, if you like, of the string concatenated

together.

All right?

And if you want to do other things, for example, we can

take two strings and add-- whoops, sorry-- and add them

together, we will get out, again, a concatenation

of that string.

And these will, we'll let you work through the variations,

but these are the simple expressions we can use.

Now, sometimes things get a little interesting.

All right?

What's the value of that expression?

What do you think should happen if I evaluate that expression?

Somebody with a hand up, so I can see it.

What's going to happen?

STUDENT: [UNINTELLIGIBLE]

PROFESSOR JIM ERICSON: An error?

Why?

STUDENT: [UNINTELLIGIBLE]

PROFESSOR JIM ERICSON: Great.

OK.

That means, let's check it.

It certainly is.

We bribe people.

So I, ah, by the way, John's a Yankees fan, he throws like

Johnny Damon, I'm a Red Sox fan, so we'll see if

I, how about that?

And I almost hit John along the way, great.

My third right, exactly, what can I say?

All right, so we're into bribing you as we go along

here, and all right?

You'll be badly overweight by the end of the term.

Right, it's a syntactic error, because it doesn't know

how to deal with this.

But there's an important thing going on here, if I in fact

wanted to combine those into a string, I should have told the

machine to do that, and I can do that, by explicitly saying,

take that, which is a number, and convert it into a string,

and then-- bleah, I keep doing that-- then add it

to that string.

OK, so there's an important point here.

We've got what's called type conversion.

That is, if I want to combine two things together in a

particular way, I need to make sure that I give it the

kind of operand it expects.

So STR, which I just typed up there, takes in parens, some

input, and it converts it into a string, so that now I can

use that where I was expecting a string.

John.

PROFESSOR JOHN GUTTAG: You've got a static semantic

error in your syntax.

PROFESSOR JIM ERICSON: Thank you.

And I was going to come to that in a second, but thank you,

John, for pointing it out.

All right.

Why is it a static semantic error?

The syntax is OK in the sense of, it is an operand, an

operator, an operand, so syntactically it's OK.

The semantics was what caused the problem, because the

operator was expecting a particular kind of

structure there.

There's a second thing going on here that I want to highlight,

because it's really important.

Yes indeed.

OK, there we go.

The second thing I want to highlight is, that what's

going on, is that Python is doing some type checking.

It caught the error, because it checked the types of the

operands before it applied things, and it says,

I'm going to stop.

Now, you might have said, gee, why didn't it just assume that

I wanted to in fact treat these as strings, and

combine them together?

Sounds like a reasonable thing to do.

But it's a dangerous thing.

Because in doing that, Python would then have a value that it

could pass on into some other part of a computation, and if

it wasn't what I wanted, I might be a long ways downstream

in the computation before I actually hit some result

that makes no sense.

And tracing back where it came from can be really hard.

So I actually want to have type checking as much

as I can early on.

And in fact, under type checking, different languages

sometimes fall on a spectrum from weak to strong typing.

Which basically says, how much type checking do they do?

Now, you're going to hear John and I go back and forth a lot,

as I said I'm an old time-- well I'm certainly old

time, but I'm also an old time Lisp programmer.

I love Lisp, but Lisp is certainly in the category of a

very weakly typed language.

It does not check the types of its arguments at all.

Python is, I wouldn't say completely strong, but it's

much closer to the strong end of the spectrum.

It's going to do a lot of type checking for you before it

actually passes things back.

Nonetheless, I'm also going to argue that it's probably not as

strongly typed as we might like.

So, for example, there's an expression.

Now, less than is just, if you haven't used it before, it's

just the operator you'd expect, it's comparing two things and

it's going to return either true or false depending on

whether the first argument is less than the second argument.

What's going to happen here?

Again, I need a hand so I can know where to throw candy.