[As described below, this is Part B of a 3-part course. Participants should complete Part A first -- Part B "dives right in" and refers often to material from Part A.] This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module of Part A. Part B assumes successful completion of Part A. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.
Static Versus Dynamic Typing, Part One
Loading...
来自 University of Washington 的课程
Programming Languages, Part B
366 个评分
从本节课中
Section 7 Including a Quiz
In the last module of Part B we will use our experience programming in ML and Racket to
compare and contrast static typing and dynamic typing. This is not only the most important difference between these two languages, but it is a fundamental topic in the study of programming languages. Learning it can help you program more effectively in both kinds of languages. After completing this week's quiz, don't forget to watch the Part B Wrap-Up and Part C Preview video.
与讲师见面
Dan GrossmanProfessor
Computer Science & Engineering
[MUSIC]
In this segment I'm finally going to start the discussion of which is better,
static versus dynamic typing?
And sorry to disappoint you, but I'm not going to reach a firm conclusion.
Instead, the way we're going to do this is we're going to consider arguments,
reasons, why static checking may be superior or
why dynamic checking may be superior.
And we will give corresponding similar arguments for
both sides on similar topics.
We'll start in this segment and then we'll continue in the next one.
Remember, of course,
that most languages do check some things statically and other things dynamically.
So it's not a matter of should you check everything statically or
everything dynamically.
But for anything you're going to check, there are advantages and
disadvantages about when you do the checking.
So let's start.
Probably one of the most common arguments people make in
favor of dynamic type systems, that languages that check things dynamically,
is that they're more convenient.
That if you want to build a list that holds data of different types, or
you want to write a function that returns things of different types,
you can just do that.
And you don't have a type system getting in your way.
So you see the Racket code here at the top.
And I have this function f that sometimes returns a number by adding y and y.
And sometimes returns the string hi.
And if you want to do that, you can just do that.
The corresponding ML code at the bottom makes you go and
create some data type definition.
Introduce your own tags for int and string,
rather than the language just doing that for you.
And then in the definition of f,
you have to remember to put the right constructor in the right place.
So it's just clumsier code, it was more work for the programmer.
The people in favor of Racket would also point out
that when some user of this function f needs to use the result.
It has nice built in primitives like number?,
that just can therefore know whether the function returned a number or a string.
And this is exactly the natural thing to do,
knowing that f sometimes returns a number and sometimes returns a string.
Whereas over at ML, the program has to use this data type binding we define and
then use pattern matching to get the pieces out, okay?
So dynamic typing seems more convenient for this sort of program.
But the static type system people say, now wait a minute, wait a minute.
If you want to talk about convenience, what could be more convenient
than have a type system that enforces that the arguments and
the data you receive from somebody already has the right type.
Suppose I want to write some simple function that just cubes its argument.
Well, in ML if I write fun cube = x * x * x, I know absolutely that
anyone in the program that every calls cube in anyway, will pass an integer.
So I don't have to worry about any error checking,
I can just do the multiplication and return the result.
Whereas in Racket,
we know that you can call a function with any argument you want.
So maybe if I want to be more careful,
if this is something the outside world might use.
I need to put some sort of check here that I was actually passed a number.
Racket actually has an entire contract system.
I didn't show you here for a more uniform,
easy to document, more standard way of doing this sort of error checking.
But how it can be convenient, not only that I have to do these checks, but
I have to wait until runtime for
these checks to fail if someone does actually misuse my function.
So that's the argument on that side.
Let's give another argument for dynamic typing now.
And that's that all that static type checking always prevents useful programs.
There's always some program someone wants to write that's been rejected,
even though it makes perfect sense.
So I have a short example here that I kind of like,
just because you might think that ML would allow this, but it doesn't.
All right, so let me show you this in ML real quick, not there, just at the here.
Suppose I want to write a function that takes in, it's called f, but
it takes in another function g,
and then it makes a pair of calling g with an int, and g with a bool.
It just doesn't type check.
Type inference doesn't work that way.
The type system doesn't work that way.
Even though it would make perfect sense, as long as g was itself some function,
maybe just an anonymous function.
If I could pass in something that, say,
makes a pair of its arguments, this would work perfectly fine.
And ML just rejects it.
So that's what I have down here at the bottom.
You would think this code makes perfect sense and it will not type check.
Type system is just not powerful enough for it.
The Racket code works just fine.
You can define a function f, takes in g.
It calls, it makes a pair out of calling g with 7 and g with true.
It's exactly the same as the ML code here.
And then I can call it.
I can call f with a function like (lambda (x) (cons x x) ))).
And if I do that, I will get a perfectly good result.
I'll get back the pair of 7 and 7, cons together with the pair of true and true.
There's nothing wrong with that and so
static type checking is just getting in my way.
Now, the static checking people would say, now, wait a minute.
The only way Racket was able to do that was by tagging all the data in your
language and always checking before every operation that you have a pair,
for every addition that you have a number, and so on.
We can do this in ML.
It you want to pass things of different types around,
then you just have to use your own data type bindings.
And you can now have the control, as the programmer,
in tagging exactly where you want to tag, and not tagging where you don't need to.
And in the extreme, as I showed already once earlier,
you can program in entirely Racket-like way in ML, if you want to.
By creating TheOneRacketType with a constructor for every kind of data and do
all your own tagging and pattern matching every time you need to use a value.
Now, this may be less convenient than in Racket but Racket,
in some sense, forces all programs to always have in check tags.
Whereas in a statically typed language like ML,
the programmer is in control of where things are tagged,
where things can fail, where things are checked dynamically.
So one more argument in this segment.
Probably the best argument people usually make in terms of static checking,
is that it catches bugs earlier.
What could be better than catching bugs before you ever write test programs,
before someone misuses your function?
As soon as you try to use the file, you get an error.
So let me show that by actually flipping over here to SML again.
You see I have here this function pow1.
We'll get to pow2 in just a minute.
And if I go to try to use this,
I get an error message.
And the reason is that pow1 want to actually expects to curried arguments,
the recursive call tries to pass them in terms of a pair.
And it's good that I have an automatic system to catch that sort of bug.
Whereas if I'm over here in Racket, I have the corresponding code here,
pow1, it takes in one argument and returns a function, so this really is carrying.
But then here in the recursive call,
I guess I'm passing two arguments instead of passing them in a curried way.
And that compiled just fine, and it's not til I try to go and
use pow1 with say, 3 and 4, that I get an error.
Or even if I get it right here, at the initial call,
I'll get an error at the recursive call side.
So I have to test it to catch these errors, and figure it out that way.
So that is basically the argument in favor of static checking.
That it catches these simple bugs for
you, that are actually quite hard to find just by staring at the code.
But the dynamic type people say, now, wait a minute, wait a minute.
Yes, it catches lots of those simple bugs for you.
But it tends to catch the easy bugs, right?
It catches the same bugs, the dynamic typing people would say,
as you were going to catch later when you test your function.
And don't even try to tell me that static typing is so
good you don't have to test your function.
Because that's just not the case.
The dynamic typing people would say, okay, ML,
I appreciate that your pow1 didn't type check.
So let's comment that out, you caught that bug nice and easily.
But now, let's look at pow2.
So let's go back over here, To SML, and let's use the file now.
And look at that, everything compiled.
I have a wonderful pow2, takes two curried arguments.
And if I call with 3 and 4,
I get 13 which is not 3 to the 4th power which is what I was trying to write.
And the reason is, pardon me.
The reason is that right here I wrote + instead of times.
And no type system is ever going to catch that because plus and
times take arguments of the same type.
And if you're going to have to test your functions anyway, then what's so
bad about the Racket code, where testing the code caught my error for me?
And I do have here the version of pow2 that is wrong in the same way as the ML
version, + instead of times.
And I can just test it in the same way, and
if I call pow2 in curried form with 3 and 4,
I will also get 13, which I should realize is the wrong answer.
So those are the first three arguments for and against static and dynamic typing.
I believe they're all valid, it's a matter of which is more important to you.
And we'll continue with some more reasons in the next segment.
