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.

Avis

SK

An excellent course! Make sure you really have enough time to take this course. There are a lot of videos, but they worth watching. I'd recommend this course to everyone involved in programming.

MK

Jun 17, 2017

Filled StarFilled StarFilled StarFilled StarFilled Star

Good fundaments for learning new programming languages. Well prepared and challenging homeworks. I learned a lot of functional programming concepts fom this course and I am sure I will use them.

À partir de la leçon

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.

Enseigné par

Dan Grossman

Transcription

[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.