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: Hello, and welcome to 6.01.

I'm Denny Freeman.

I'm the lecturer.

One thing you should know about today is that there's a

single hand-out.

You should have picked it up on your way in.

It's available at either of the two doors.

What I want to do today in this first lecture is mostly

focus on content.

But before I do that, since 6.01 is a little bit of an

unusual course, I want to give you a little bit of an

overview and tell you a little bit about the administration

of the course.

6.01 is mostly about modes of reasoning.

What we would like you to get out of this course is ways to

think about engineering.

We want to talk about how do you design, how do you build,

how do you construct, how do you debug complicated systems?

That's what engineers do, and we're very good at it.

And we want to make you very good at it.

We're very good at it.

And you know that from your common, everyday experience.

Laptops are incredible.

As we go through the course, you're going to see that

laptops incorporate things from the tiniest, tiniest

level, things so small that you can't see them.

They're microscopic.

The individual transistors are not things that you can see.

We develop special tools for you even to be able to

visualize them.

And yet, we conglomerate billions of them into a system

that works relatively reliably.

Now, I realize I'm going out on a limb because when you say

things like that, then things always fail.

But I'll go out on a limb and say, for the most part, the

systems we construct are very reliable.

We'd like you to know how you think about making such a

complicated system and making it reliable.

We want to tell you about how you would model things.

How do you gain insight?

How do you get predictability?

How do you figure out how something will work before

you've built it?

If you're limited to trying out how things work by

actually constructing it, you spend a lot of time

constructing things that never make it.

We want to avoid that by -- where we can --

making a model, analyzing the model, making a prediction

from the model, and using that prediction to build a better

system on the first try.

We want to tell you about how to augment the physical

behavior of a system by putting computation in it.

That's a very powerful technique that is increasingly

common in anything from a microwave to a refrigerator.

We'd like you to know the principles

by which to do that.

And we'd like you to be able to build systems that are

robust to failure.

That's a newer idea.

It's something that people are very good at.

If we try to do something, and we make a mistake, we

know how to fix it.

And often, the fix works.

We're less good at doing that in constructing artificial

systems, in engineering systems.

And we'd like to talk about principles by

which we can do that.

So the goal of 6.01 is, then, really to convey a distinct

perspective about how we engineer systems.

Now, having said that, this is not a philosophy course.

We are not going to make lists of things to do if you want it

to be robust.

We're going to learn to do things by

actually making systems.

This is an introductory engineering course.

And so you're going to build things.

The idea is going to be that in constructing those things,

we've written the exercises so that some of those important

themes become transparent.

So the idea is -- this is introductory engineering.

You'll all make things.

You'll all get things to work, and in the process of doing

that, learn something about the bigger view of how quality

engineering happens.

So despite the fact that we're really about modes of

reasoning, that will be grounded in content.

We selected the content very broadly from across EECS.

EECS is an enormous endeavor.

We can't possibly introduce everything

about EECS in one subject.

That's ridiculous.

However, we wanted to give you a variety.

We wanted to give you a sense of the variety of tasks that

you can use, that you can apply the same techniques to.

So we want to introduce modes of reasoning, and then show

you explicitly how you can use those modes of reasoning in a

variety of contexts.

So we've chosen four, and we've organized the course

around four modules.

First module is software engineering, then signals and

systems, then circuits, then probability and planning.

Even so, even having chosen just four out of the vast

number of things we could have chosen, there's no way we can

tell you adequately--

we can't give you an adequate introduction to any of those

things either.

What we've chosen to do instead is focus on key

concepts represented by the asterisks.

The idea is going to be we choose one or two things and

really focus on those deeply so you get a thorough

understanding not only of how that fits within, for example,

the context of software engineering, but also how that

concept ramifies into other areas.

Notice that I tried to choose the stars so they

hit multiple circles.

That's what we're trying to do.

We're trying to not only introduce an idea to you, but

also show you how it connects to other ideas.

So the idea, then, is to focus on a few, we hope, very

well-chosen applications that will demonstrate a variety of

powerful techniques.

Our mantra, the way we intend to go about teaching this

stuff, is practice, theory, practice.

There's an enormous educational

literature that says--

whether you like it or not--

people learn better when they're doing things.

You have a lot of experience with that.

You have a lot of experience on the other side, too.

I'll try to forget the other side, or at least try to wipe

it from your brain momentarily to focus on your more

fundamental modes of learning.

When you were a kid and you were learning your first

language, you didn't learn all the rules of grammar first.

You didn't learn all the letters of the alphabet first.

You didn't learn about conjugating verbs first.

You learned a little bit about language.

You started to use it.

You ran into problems.

You learned a little more about language.

You learned to go from words like "feed me" to higher level

concepts, like "Hey, what's for dinner?"

So the idea is that you learned it in an iterative

process where you learned some stuff, tried it out, learned

some more stuff, tried it out.

And it built up.

There's an enormous literature in education that says that's

exactly how we always learn everything.

And so that's the way this course is focused.

What we will do is, for example, for today, we'll

learn a little bit about software engineering.

Then, we'll do two lab sessions where you actually

try to use the things we talk about.

Then, we'll come back to lecture and we'll have some

more theory about how you would do programming.

And then, you go back to the lab and do some more stuff.

And the hope is that by this tangible context, you'll have

a deeper appreciation of the ideas that

we're trying to convey.

So let me tell you a little bit about the four modules

that we've chosen.

The course is going to be organized on four modules.

Each module will take about one fourth of the course.

First thing we'll look at is software engineering.

As I said, we don't have time to focus on, or even survey,

all of the big ideas in software engineering.

It's far too big.

So we're going to focus narrowly on one or two things.

We'd like you to know about abstraction and modularity

because that's such an important idea in the

construction of big systems.

So that's going to be our focus.

In today's lecture, we'll begin talking about modularity

and abstraction at the small scale.

How does it affect the things you type as

instructions to a computer?

But by next week, we're going to be talking about a whole

bigger scale.

By next week, we're going to talk about constructing

software modules at a much higher level.

In particular, we'll talk about something that we'll

call a state machine.

A state machine is a thing that works in steps.

On every step, the state machine gets a new input.

Then, based on that input and its memory of what's come

before, the state machine decides to do something.

It generates an output.

And then, the process repeats.

We will see that that kind of an abstraction --

state machines --

there's a way to think about state machines that is

compositional that you can think of as a hierarchy, just

as you can think of low-level hierarchies within a language.

I'll say a lot more about that today.

So the idea will be that once you've composed a state

machine, you'll be able to join two state machines and

have its behavior look just like one state machine.

That's a way to get a more complicated behavior by

constructing two simpler behaviors.

That's what we want.

We want to learn tools that let us compose complex

behaviors out of simple behaviors.

And the tangible model of that will be the robot.

We will see how to write a program that controls a robot

as a state machine.

That's certainly not the only way you could control a robot.

And it's probably not the way you would first think of it if

you took one course in programming and somebody said

to you, go program the robot to do something.

What we will see is that it's a very powerful way to think

about it for exactly this reason of modularity.

The bigger point that we will make in thinking about this

first module is the idea of, how do you

make systems modular?

How do you use abstraction to simplify the design task?

And in particular, we will focus on something

that we'll call PCAP.

When you think about a system, we will always think about it

in terms of, what are the primitives?

How do you combine them?

How do you abstract a bigger behavior from

those smaller behaviors?

And what are the patterns that are important to capture?

So the bigger point is this idea of PCAP, which we will

then revisit in every subsequent module.

OK, second module is on signals and systems.

That's also an enormous area.

So we only have time to do one thing.

The thing that we will do is we will think about discrete

time feedback.

How do you make a system that's cognizant of what it's

done so that it, in the future, can do things with

awareness of how it got there?