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. 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. The three parts are not quite equal in length: Part A is almost as substantial as Part B and Part C combined.
Are All PLs the Same?
Loading...
來自 University of Washington 的課程
程序设计语言
880 個評分
從本節課中
Section 3 and Homework 3 -- and Course Motivation
This section is all about higher-order functions -- the feature that gives functional programming much of its expressiveness and elegance -- and its name! As usual, the first reading below introduces you to the section, but it will make more sense once you dive in to the lectures.
Also be sure not to miss the material on course motivation that we have put in a "lesson" between the other videos for this week and the homework assignment. The material is "optional" in the sense that it is not needed for the homeworks or next week's exam, but it is still very highly encouraged to better understand why the course (including Parts B and C) covers what it does and, hopefully, will change the way you look at software forever.
與講師見面
Dan GrossmanProfessor
Computer Science & Engineering
[MUSIC] In this segment, I want to talk about the question, are all programming
languages the same? Afterall, if the general concepts come up in every
programming language, then wouldn't it be enough to learn just one.
and there are arguments in both ways here.
You don't need to learn every programming language that's ever been to understand
what's going on in programming languages, but I also think there's value in
learning more than one. So let me return to the car analogy I
started in the previous segment for a second and then we'll get more technical.
when you go to rent an automobile or get in a friend's car that you've never
driven before, you can actually kind of drive it, if you
know how to drive. It's actually a great thing that there's
kind of worldwide standardization on what the steering wheel does, where the brakes
are, how to open the windows, the fact that there are headlights in front of the
car. This sort of standardization is helpful.
It makes it easier to read code in another language even if you're not
familiar with all the details, but it can also get you into a lot of trouble.
Some things not their, quite in their right place, you don't really understand
how a particular language construct or car feature works it can be very
uncomfortable. And your comfort level increases as you
learn the standard general concepts, as well as get experience with different
cars or different programming languages. So programming languages are probably
more different from each other than cars are different from each other.
maybe they're more like cars or trucks or boats, I'm not really sure how to
measure, but nonetheless, I feel that the analogy is fairly decent there.
You could also argue that for all the benefits of standardization, it actually
impedes progress, that if someone had a much better way to design a car, but for
it to work the gas pedal and the brake pedal had to be in different positions
than people are used to. It would be very hard to get that idea
adapted, because people would have a lot of
trouble using that car and would find it very dangerous.
So, that's the analogy. Now, let me get to something much more
computer science and technical that you really should know if you're going to
study programming languages. And that is, that on a very technical level, all
programming languages actually are the same in the following way.
Anything that you can write in language X, you can write in language Y.
If, what I mean by a program is given some arguments, what does it return as a
result? If it takes in some input and returns an output and there's someway to
implement it in Java, there's a way to implement it in ML,
there's a way to implement in Python, there's a way to implement it in PHP.
In fact, there's a way to implement it in a programming language where all you have
is one while loop and three numbers, that can, three variables that can hold
numbers of infinitely large size. Okay? That's a truth, it's something
essentially known as the Church Turing thesis, and it's something that we have
found to be true, that for every programming language we can think of with
sufficient power, and you have to take another course to study exactly what that
power is. I'm not going to get into it here.
There is a translation from any program in one language to a program in the other
language. So in that sense, all programming
languages are equally powerful. In another sense, in practice, all the
languages that we actually use around the world to develop software have the same
fundamentals. There's some notion of variables,
there's some way to hide things from other parts of the code,
there's some notion of one of types. Later in the course, we'll see how
object-oriented programming does one of types,
there's some support for recursive definitions.
So all languages are the same, they're just combining these same features in
different ways. But now, let me argue it the other way
and say, just because all languages share these similarities, they have the same
expressive power, they're built from many of the same concepts, that doesn't mean
they're exactly the same. Okay.
The analogy I like to make here is that I actually believe on a lot of levels
people are people. It doesn't matter what country you live
in, what language you speak, what society you're in.
there are certain things that make us happy, make us sad,
certain things that are hard for us in terms of intelligence, certain things
that are easy. There's a lot of similarities and yet, no
one would deny the large cultural differences we have around the world.
It's why I love to travel. It's why I love to have friends who grew
up from all around the world. It's because those differences are
exciting too. And in fact, one of the best reasons to
travel to another part of the world or to learn another language is because you
appreciate more about where you come from.
And how your language works and programming languages work the same way
and that why, as I've said before, I think this course makes you a better
programmer in any programming language. More on the software side, what often
happens in programming languages is the primitive or default in one language can
be done in another, but it's very awkward.
That there is a way to program like case expressions in another language, but
without the support for case expressions, it's a lot more wordy, you have to go
through extra hoops, you have to add extra variables.
And conversely, if you want to do something like objects in ML,
it's frankly not particularly pleasant, it's a lot of extra work, you have to get
a lot of detail, right? You don't get convienent error messages,
because the compiler doesn't understand the idiom you're using, and that's okay.
And often, the best way to understand a language construct is to understand how
you would code it up in terms of other language constraints in another language
and we will see examples of that in this course.
So the last line here on the slide, beware the Turing tarpit. This is exactly
getting back, this is a famous expression the Turing
tarpit. And what it refers to is, we know that
your programming language can't implement everything that needs to be implemented.
The Church Turing thesis gives us that that is going to be the case.
The tarpit is you are not using convenient features.
You're saying, well, I have a way to do it, and it's beautiful to me, it's good
enough to me. I can get this done, but you end up using awkward error prone
features that are complicated or less efficient or less straightforward to get
the job done. And so part of a programming languages
course is to draw out the elegant way of thinking of the ideas rather than always
just finding a way to code it up in terms of some other ideas.
And so, that's our summary of how programming languages have universal
similarities, but it would be an exaggeration and a
counterproductive exaggeration to dismiss the diversity of programming languages by
saying oh, they're all the same.
