Lecture 1 | Programming Paradigms (Stanford)

[music playing] >> This presentation is delivered by the
Stanford Center for Professional Development.
Jerry Cain: Okay. Here is, uh, in a nutshell, a reduced
version of what's presented in handout two.
This is the syllabus.
I have, umm, several languages I'm gonna put on the board
and, uh, one concept: C, Assembly, C++, Concurrent
Programming-- that's not a language, that's just a paradigm-
- umm, Scheme, and then, it is official, I'm actually gonna
cover Python from now on in 107.
People look at this and they go, "Wow. I'm gonna be able to
legitimately put all these languages on my resume." Okay.
And it's on a separate list on the bottom and it feels real
good.
It isn't so much about that.
Certainly what-- We wanna give you some mileage in some
relevant languages that are very good, umm, for both
research and for industry, but the real intellectual value
in learning all these languages is to really study the
paradigms that they represent.
And I'll explain with that means in a second.
But to program in C or C++, it's almost a different thought-
- you're following a different thought process that you are
when you program in Scheme or in Python.
Okay?
You all know enough C++, and believe it or not you know
enough C already, just take out the object orientation from
C++ and you're more or less left with C.
Umm, when you program in C, pure C and you have no classes,
you're very procedure-- procedure-oriented, you think of the
main function as being a high-level out line of maybe five
top-level functions to call and those five functions each
have sub functions and those sub functions have sub sub
functions, etc.
Does that make sense?
It's like a bit like-- it's like outline for history--
outline to notes for history class where you have Roman
numeral one in main and Roman numeral two in main, and Roman
numeral three in main, and then you have small A and B, and
maybe little I's and things like that. You understand what
I'm getting at?
Okay?
Your origin to run the procedures, okay.
You program with side effects, you pass around references
and pointers with the idea of updating shared data.
Okay?
You do that both in C and C++.
But as far as C is concerned, this represents, uh, what's
called the procedural paradigm.
You also hear it called the imperative paradigm.
It is verb-oriented in the sense that the first thing you
ever see-- or you typically see with a statement is the
function call, okay, where the function name is usually has
some strong verb in it so it gives you some idea as to what
the function's supposed to accomplish.
Okay?
Does that make sense to people?
When you study C++ and all of a sudden rather than calling
do this and passing the address of some object, you do my
object arrow do this.
Does that make sense?
Okay.
Then all of a sudden the first thing you see on that line is
the data or the object that's being manipulated and because
the first thing you see is the object, that's why it's
object-oriented as opposed to procedure-- procedurally-
oriented.
Okay?
Does that make sense to people?
Okay.
I think a lot of C++ programmers really program in C and
just incidentally use the objects in classes that are
available to them.
Okay?
Which is a perfectly reason way to program.
Most people learned how to program in C.
Most people I know in industry know C very, very well and in
spite of the fact that there's many newer languages that are
better in most regards, they still stick with what they know
and that's why C and C++ are still such popular languages.
There's nothing wrong at all with programming in C if you
really know it very well, and you write clean, readable
code.
It's just more difficult-- I'm sorry. Let's say it this way:
It's much easier to make memory errors in C because
everything is exposed and there's very little error checking
going on.
C++ is a little bit better about it.
In between here I have this thing called assembly.
I haven't decided whether I'm gonna go with what I've gone
with for the past seven or eight years, which is this mock
assembly language, or I'm really going to take a step and
teach you a real-- I don't wanna say-- It's a real assembly
language although you don't see it's if use very much.
But there's an assembly language called MIPS and it's very
easy, as far as assembly languages go to learn.
Uh, I don't want really care so much about teaching you how
to program in assembly.
I use it as a vehicle for showing you how C and C++ programs
compile to .o and object files into binaries and eventually
become executables, and show you how a line like I equals
seven or J plus plus, or, umm, foo of X and Y as a function
call, how that all translates to assembly code. Okay?
Does that make sense?
I mean, you know that when you write C++ code that you--
When you execute the program it's not C++ anymore.
It's assembly code.
It's all zero's and one's eventually.
I wanna give you some insight as to how C is translated to
assembly code, how all your variables, and your functions,
and your objects, and all of that eventually get boiled down
and hashed down to a collection of zero's and one's.
And I wanna do a little bit of the same thing for C++.
It turns out that while C++ and C represent different
paradigms that they really also compile to zero's and one's
and after you get enough experience with this assembly and
the manual compilation process that we're gonna learn about
as in how to look at C code and figure out what the assembly
code would look like, you're really gonna see that C++ and C
almost look like the same language as far as the zero's and
one's are concerned.
Okay?
We're really just gonna extend the compilation model we use
for going from C to assembly to accommodate C++ references,
and classes, and templates, and things like that are new to
the language compared C.
And you have, I think, have a very, very good understanding
of how C and C++ work after the first five weeks of the
course.
Okay?
And it makes you so much better of a C and C++ programmer.
We're gonna demystify this whole pointer thing, I'm gonna do
something, like, asterisk, asterisk, ampersand, asterisk,
asterisk, P, arrow, asterisk, asterisk, asterisk equals
seven and you're gonna know exactly what it means.
Okay?
>>
[laughing] Jerry Cain: And so it takes a little bit of work
and it's almost laughable how arbitrary you can be with all
your casts, and your ampersands, and with your asterisks.
But if it compiles it means something so when it runs it
actually does something.
It's probably not good if you have a lot of asterisks and
ampersands but nonetheless you can have some idea as to why
it's crashing not just that it is crashing.
Okay?
I spend a good amount of energy talking about concurrent
programming.
We actually at the moment do that type of programming in C
but all the programs you've written in the past two quarters
if you've just taken the 106A and 106B courses here or 106X,
all the programs you've written at Stanford prior to 107
have been sequential programs.
Which means that there is-- whether it's object oriented or
imperative-- procedurally oriented-- you have this outline
of steps that happen one after another.
Okay?
Nothing's done in parallel, or pipeline, or done side by
side.
Everything happens in one clean stream of instructions.
Okay?
Well, what concurrent programming is about is within a
single program, trying to get two functions to seemingly run
simultaneously.
Okay?
And if you can get two functions to seemfully run
simultaneously then you can extend that and get ten
functions to run simultaneously, or 20 functions to run
simultaneously, or seemingly simultaneously.
I say it that way because technically they don't run at the
same time.
When I go over assembly code-- and I think get into it
enough to know what assembly code is like, but if you have
this one function, okay, my hand is a function.
This hand is another function.
Okay?
And you concern yourself with the execution of one of them,
then when I do this you can just think about it reading the
code and executing it for side effects.
Does that make sense to people?
When you deal with concurrent programming you have two or
more functions-- just two right here because I only have two
hands-- to do this and they both seemingly run at the same
time.
Okay?
But what really happens is it's like watching two movies at
the same time where, because there's only one processor on
most machines, it doesn't really run like this.
It runs like this and switches back and forth between the
two functions.
But it's happened so fast that you can't see the difference.
Okay?
It's more than 24 frames per second.
It is like a million.
Okay?
And you're watching two movies at the same time, okay?
And that extends just fine to three, to five, to ten, to 100
in theory.
Okay?
There are a lot of situations where concurrent programming
is really not very useful but there are several situations,
particularly networking whenever that's involved, umm, where
concurrent programming is actually very useful.
There are some problems that come up when you deal with
concurrent programming that you might not think about.
Umm, the example I always go over the first day of class is
just it uses two Wells Fargo ATM machines.
Okay?
Think about you have a Wells Fargo checking account-- you
may not have to think about it because you do-- so just
imagine your Wells Fargo checking account is in danger
because two computers in ATM machines, and you have a
hundred dollars in it.
Okay?
And you share your pin with your best friend and you go up
to neighboring ATM machines and you make as much progress as
possible to withdraw that $100, okay, and then you both on
the count of three press okay to try to get $200
collectively.
Does that make sense?
That is not a nonsensical example because both of those
machines are basically very simple computers, okay, that
ultimately need access the same master account balance to
confirm that $100 is available and in this transactional
way-- transactional makes sense both in terms of money and
also in a sense of concurrent programming.
You have to make sure that the $100 being identified as the
account ambulance, umm, is maintained with some-- some
atomic flavor so that if you have two people trying to
withdraw $100 at the same time that only one person gets
away with it.
That $100 account balance is the shared resource that two
different processes have access to.
Does that make sense to people?
Okay.
So, there have to be directives that are put in place to
make sure that the account balance check and the withdrawal
are basically done not at all or in full so that it really
does function truly as a transaction, both in the finance
and in the programming sense.
Okay?
If you're sloppily about it-- I don't mean sloppily.
That's not a very nice thing to say on the first day.
If you're not careful about how you actually program using--
program concurrently, you can actually come up with problems
and have these data integrity issues which banks are
actually very, very, umm, worried about obviously.
They don't wanna give out $10 million with they only have $1
million.
Okay?
Same thing with, like, airlines.
If they have one seat remaining on a flight and two people
call and try to get that seat they only wanna give it to one
person.
Now, it would seem that they don't care about concurrent
programming 'cause they're more than happy to give you a
seat that doesn't exist on the plane.
Okay?
But the airline's problems are probably not related to
concurrent programming.
Okay?
Umm, as far as the Scheme and Python thing are concerned,
once we get through concurrent programming, uh, we really
switch gears and we start looking at this language called
Scheme.
You may not have heard of this.
If you haven't heard of this you may have heard of a
language called Lisp, which, uh, it's certainly related to.
This is a representative of, umm, what is called the
functional paradigm.
Okay?
There's two things about Scheme and functional languages--
purely functional languages-- that are interesting in
contrast to C and C++.
When you program using the functional paradigm you always
rely on the return value of a function to move forward.
Okay?
And you program without side effects.
Now, that's a very weird thing to hear as an expression when
you've only coded for a year.
But when you code in C and C++, it's very often all about
side effects.
The return value doesn't always tell you very much.
It's a number or it's a bullion.
But when you pass in a data structure by reference to a
function and you update it so that when the function returns
the original data structure's been changed.
Right?
Does that make sense?
That's programming by side effect.
Well, the idea with Scheme and particularly the functional
paradigm is that you don't program with side effects.
You don't have that at all.
That you always synthesize with results or partial results
that become larger partial results that eventually become
the result that you're interested in and only then are you
allowed to print it to the screen to see what the answer to
the problem was.
Okay?
Umm, it's very difficult to explain Scheme if you've never
seen it before in a five-minute segment of a full
introduction.
But when you get there, umm, we have tons of examples of the
paradigm.
It's a very fun, neat little language to work in. I think
it's the-- I think it's the easiest function of all four up
there because it's such a small language.
Once you get the paradigm down and you understand how to
program functionally, Scheme is not that bad at all.
It's actually very fun.
Okay?
Not that all programming isn't fun but Scheme is
particularly fun.
Okay?
Now, I used to teach either some advanced C++ or recently
some Java toward the end of the course.
Last quarter I decided literally in the eighth week that I
was gonna not do Java because 108 is all about Java and I
felt like I was stealing the thunder, umm, from 108.
So, I just decided, you know what?
I'm just gonna teach Python and see how that works out.
And it worked out well certainly considering I'd never
really taught it before.
But this language called Python-- I'm suspecting most people
have heard of it even if they haven't seen it.
It seems to be the rage language at a lot of significant
companies in the Bay Areas.
They're very smart people at these companies so when they
use a language and they like it, there's usually a very good
reason for them liking it.
You've probably heard of a language called Pearl.
Okay?
It's not a very pretty language.
Uh, you can just think about, in a sense, Python being a
more modern object-oriented version of Pearl.
Okay?
And I know if you don't know Pearl and you don't know Python
it doesn't mean anything to you but just understand that
this is the sexy little language has been around for
probably 16, 17 years that's really established itself as a
popular language since year 2000, 2001.
I know a lot of people who work at Google that program in
Python on a daily basis.
There are a subset of us at Facebook that program in Python
every day doing a lot of distributing systems work and
Python just seems to be the way to go for that right there.
Uh, it actually has, uh, a lot of good libraries for dealing
with web programming.
Umm, web programming can seem really boring for a lot of
people because it seems that it's just html and web pages
and a lot of things like that.
Real web programming is more sophisticated than that.
You dynamically generate web page s based on content in data
bases and things like that.
And Python, being an encrypting language, meaning it's
interpreted and you can type in a language and stuff as you
go and it recognizes, and reads, and executes the things as
you type, it's very good for that type of thing.
And if all goes well, meaning I have type to develop this
new assignment I have an idea-- this new assignment idea I
have, umm, you're gonna write a little-- a miniature web
server in Python for your final project.
It won't be that sophisticated.
You're not gonna write all of Apache.
But you are probably gonna write some little thing where you
really do have a web server behind the scenes making
decisions about how to construct an html page and serve that
over to a client.
So it'll be an opportunity to learn Python, learn its
libraries, to see, as a language, because it's fairly young
it has the advantage of not bothering to include the C and
C++'s and Java's mistakes.
So, I'll leave all that stuff out and go with this more
interesting, well-formed core.
It has great libraries, umm, it has object orientation.
You can program procedurally if you want to and just program
as if you're in C but using Python syntax.
There are even functional programming aspects in the
language.
So, even though the syntax is different than Scheme,
conceptually you can use Scheme-like ideas in Python code if
you want to.
Okay?
I'll be able to illustrate the client/server paradigm and
how it's different from traditional programming.
Uh, that's not so much a Python thing, but Python's a good
vehicle for learning that stuff.
I'll show you the library so that you can parse XML and you
can parse ht-- and you can understand http protocol, umm,
and all of this stuff-- and just to actually read blogs, to
download rss files, all of these things that are very, very
gracefully handled by Python programs.
Okay?
And so that's where I'm hoping to take people by week ten of
the course.
Okay?
Does that make sense?
Okay.
There are a few other paradigms that aren't represented here
but I think I really cover all the ones that you're likely
to see for the next 15 years if you go out and you're a
coder.
Okay?
There are a couple of languages that I may briefly mention
in the last day that are just fun but they all have some
overlap with some language that's represented right here.
Okay?
You guys are good?
Okay.
So, I don't like starting in on any real material when I
only have ten minutes left so I'm actually going to let you
go.
But recognize that Friday I'm gonna have tons of handouts
for you, I'm gonna have an assignment.
Okay?
We're gonna dive right into the the low-level pointer stuff of C and C++. Okay? So have a good week.