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. 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.
Why Study General PL Concepts?
Loading...
Del curso dictado por University of Washington
Programming Languages, Part A
817 calificaciones
De la lección
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.
Conoce a los instructores
Dan GrossmanProfessor
Computer Science & Engineering
[MUSIC] So now let's give some indication of why it's valuable to study general
programming language concepts outside the context of any particular detail or
programming language. This is the most abstract question in
terms of motivation so it will have the most abstract, probably least precise
answer. And I'd like to start basically with an
analogy. So, I get asked a lot of times what's my
favorite programming language. And my favorite answer is, well what's
your favorite kind of car? Or, what's your favorite pair of shoes? So go ahead
and take a second and imagine in your head the best kind of car.
What do you think the best car ever made anywhere in the world is? And, and think,
you know, that's the best car, it's better than all the other cars.
And whatever you think of is actually probably a really good car, and it's
probably better than a lot of other cars, but it can possibly be the best car for
all purposes. Right? You know, cars are used for a lot
of different things. I seriously doubt that whatever car you
picked is good at winning a race, you know, one of these things where people
drive around at 300 kilometers an hour, and good for taking a group of children
to go play soccer or football. Right? Cars just can't do both of those
really, really well and yet any car can participate in a race, and can take
people to where they need to go. So it's not that you can't do it with
these other cars, it's just that they focused on certain aspects of the design
at the expense of other aspects of the design.
Right? there's a bunch of other things you might do with a car.
You might want to go off of the highway onto dirt and rocky roads.
You might want to haul big items around like a mattress.
You might want to just have fun and roll down the top of a convertible car.
It might be raining, in which case that's a bad idea.
A lot of these things are in conflict with each other, even though the basic
idea of what a car can do and how a car can participate in these activities is
fairly universal. And of course it's the same with shoes.
A lot of people imagine i'ts their favorite shoes.
Something that they would wear with a very fancy dress or a suit or something
like this. Other people like to play sports.
I probably could play basketball with my fanciest pair of shoes on but it would be
painful. It would not be pleasant.
And I hope the analogy is clear here that programming languages in some sense are a
kind of shoe or a kind of car. And once you learn how to drive in
general it's not that hard to switch cars.
It get easier after you've done it a few times, but you still want to pick the
best thing for what you're trying to accomplish that day.
Let me push this analogy a little bit further one more slide on cars and then
we'll move on I promise. It's perfectly reasonable for a mechanic,
someone who fixes cars, to have a specialty.
They work on cars from a certain company or they are a certain age or what not,
and programmers can be better at certain languages.
But I think mechanics do have a general understanding of how cars work.
And they can participate and help even with cars that aren't right in their core
specialty. They also have a very good idea of what's
important and what's not. I've never gone to a mechanic and said my
engine, is making a funny noise, can you help me? And have the engine say, have
the mechanic say, well, your seats are blue and I only really
like cars where the seats are brown, right? And the analogy there is that sort
of unessential detail is syntax. Now syntax does matter to people.
people when they purchase cars really like certain colors, really like certain
mirrors, and things like this, but it's not essential to how the car actually
runs, and accomplishes its goals. Okay? So that's kind of from the
mechanic's perspective. What about someone actually designing
cars, whether it's a mechanical engineer, or someone else? Someone really trying to
make changes or understand what it is to be a car,
to be an automobile, really has to know how to get the most out of the different
design constraints. That if you try to make something better
over here it might be harder to make this other feature as good over there that
certain things are in conflict. And that's why I simply don't have a
favorite programming language, and I don't have a favorite kind of car either.
I find the question a little bit silly, it really does depend on what I'm trying
to do. Now, if you're trying to learn more about
cars, how they run, how to fix them, how to design better ones, one approach would
be to take a number of really good, really fancy, really expensive cars, and
study why they're so good and what they do and why people spend so much money to
buy them. But I would argue that that's often
counterproductive that those cars are very complicated and they're the result
of over 100 years of engineering and improvement and sometimes the best way to
learn is to go back to a simpler model. An older model.
Something like say the ML language, which is I would say over 25 years old.
Because it's simpler it doesn't deal with every modern feature and advance and
computer controlled gizmo. And it's much easier to understand an
older car. You can actually open the hood and see
the pieces. And then after you've learned those
basics, the modern state of the art, the more current things actually can be
easier to understand, and in some ways you can understand is actually less
elegant in some ways because things have become more complicated over time, due to
historical Improvements okay? Finally we also know that sometimes cars are very
popular even if they're not the best cars.
you know popularity is a very hard thing to understand why it happens or how it
happens. That doesn't mean that popular things are
bad, but we also know that popular things are not necessarily good.
You know popularity in and of itself is not evidence of being the the best.
So, in this course, we don't just study programming languages, we focus on two
key parts of them: the semantics, what do programming language concerts mean and
the idioms, what are ways to use those language constructs to perform common
tasks in elegant ways. The reason I focus on this,
it's really first of all the semantics. That, if you want to reason correctly
about what your program does, is the implementation of the language correct?
You wrote a library, someone's complaining that it's not working
properly. Are you wrong or are they wrong? You have
to understand language semantics. There's simply no room in software
development for well, I don't feel that's the way conditional expressions actually
work, or that's the way they should work. No, there's a way conditional expressions
work in a programming language, and either you're using them correctly or
they're not. This is not a matter of do you like curly
braces or parenthesis, or using the word and also versus the and character two
times in a row. This is really about what the concepts
mean. And so much of software development is
designing a precise interface and then using it.
And programming languages are probably the best example of this where the
definition has to be so precise that people all over the world can use the
language and agree on what's supposed to to happen.
So that's semantics. In terms of idioms, I just think they
make you a better programmer. That if you see something in multiple
settings, including languages where it's very convenient, then you can use it
anywhere. Then once you've seen data type bindings
and case expressions, it teaches you to think in terms of one-of types and all
the different possibilities, and even if your language does not provide direct
support for writing down your algorithm that way, it's still a great way to
think, and you find your code suddenly being much more nicely laid out and in
terms of exactly the cases you need to cover.
And that's why I often like to say that a lot of students taking this class have
seen Java in the past. We do almost no Java in this course and
yet I truly believe this course will make you a better Java programmer.
Okay, last one. as long as I'm really talking about the
beauty and generality of programming languages and why it's, useful to learn,
let me tell you about the play Hamlet by William Shakespeare.
The play Hamlet, if you've never seen it or watched it, I highly encourage it.
It is a beautiful work of art. It teaches deep eternal truths about the
human condition. It teaches about family relationships and
revenge and jealousy and murder and letting our emotions get the best of us.
It's also, even in modern day, the source of a number of expressions and sayings
that we actually use to understand life. if you've ever heard someone say, the
most important thing in life is to be true to yourself, in Hamlet, the line is
actually, This" above all, to thine own self be true" if I recall correctly.
And we study this stuff because it makes us a better person.
okay. Programming language concepts are like
that. There really are deep eternal truths
going on here. The fact that the booleans and
conditional expressions are nothing more than syntatic sugar for a data type
binding with two constructors called true and false.
Is a deep truth about logic and how things fit together and how we can
express there being two possibilities, yes and no, true and false.
And it's worth studying those things in sort of the purest settings that we can
and to see them in multiple settings. The same way the lessons of Hamlet Come
up in movies and plays and, and novels over and over and over again.
And we should learn these things even if the syntax is really annoying.
I don't particularly like reading Shakespeare because it's very hard to
understand and English is my first language.
But if I can get past the syntax and understand the deep truths that are going
on it makes me a better person. And I don't have to worry so much about
will learning this thing. This thing that will increase my
understanding. either the human condition for
Shakespeare or software for programming languages.
I don't need three weeks later to be able to apply for a new job.
That will come. I'll be able to pick up the skills later,
but in the meantime I can get the right foundation, the right perspective, of how
to look at the entire field.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
