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.
Why Functional Languages?
Loading...
来自 University of Washington 的课程
程序设计语言
869 个评分
从本节课中
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] This is the segment where I want to justify why it makes sense to spend
most of the course on programming languages using functional languages and
the ideas of functional programming. So, depending how you count, we're
probably spending 60-80% of the course using these languages where mutation is
discouraged, where higher-order functions like we study in the section on that,
very convenient, and where one-of types, like use things
like datatypes and the sort of thing. So why do this? Well, the first reason is
that these language features and this approach to software is invaluable for
correct, elegant, efficient software. It's a great way to think about your
computations, but that's what I've been emphasizing in all the other [LAUGH]
contents parts of the course, right? That's kind of what half of the
course is about. So in this sort of more course motivation
background segment, let me try to make two other arguments
that are actually quite different. The first is that functional languages
have, for many decades, been ahead of their time.
And so studying them is a great way to see where the future of software may be
going. And, in particular, some current trends
suggest that functional languages are very well suited to the more near future
as opposed to something further out. So, it turns out that there's a long
history of decades of people learning things in programming languages classes
using functional languages that were dismissed as, well, that's a pretty idea,
but that's not how real languages work. It's too slow, it's not what people are
used to, it looks too weird, I just don't like it, etcetera.
So I've put a list here, I'm not a historian, you might be able to quibble
on the details, but garbage collection, just the idea
that you can create all the data you want and the language implementation will take
care of reusing the memory when you're done with things, is something that is
recently as 20 years ago was considered impractical for a lot of real software.
There are still systems where it's probably impractical, but there's a lot
of software where it is not, and most of our modern popular languages happily
embrace garbage collection. Generics, the type variables, the quote
As and alphas we've seen in ML. This is something that was more recent
than garbage collection to really catch on mainstream.
I would say it was the last ten or 15 years, and yet SML, the ML-like languages
we've been studying, have had these ideas since the 1980s.
In XML, this is a universal data representation.
All the HTML on the Internet, all the XML tools that you see everywhere, the basic
idea of XML is that we can write down in text something that is trivial to
transform to a tree. There's never any ambiguity.
If I write 1+2*3, did I mean 1+2*3 or did I mean 1+2*3? When you have the full
structure of XML, there's never any such ambiguity, you always have all your open
tags and all your closed tags. And yet, this is exactly the syntax we're
going to see in Racket and before it's Scheme and before it LISP which goes back
to 1958. The idea that if we put enough
parentheses in XML case, XML's case, angle brackets into our code then there's
no ambuiguity and it's easy to process that text in a structured recursive way.
High-order functions of course, a huge emphasis in the course.
We now see them in most languages, we see them in Ruby and Javascript and C#.
They're slated to be added to Java soon. it took us a long time to get there, I
would say this is something that's more like the last 5 or 10 years that people
understand they should really be in your general purpose programming languages.
Type inference, the idea that you can have a statically typed language without
having to suffer the burden of writing down all the types is something that's
now limited support in C# for, more support in Scala.
It's something that, again, in functional languages, goes back for 30 years.
And my favorite one may be or at least the one I learned about most recently, is
even the idea of supporting recursion of letting a function call itself, most
languages have supported this for a long, long time, but back in the 1960s, it was
a very controversial idea, of whether your language should have to support
this, and of course, even more recently people
love to pick on old versions before trend, it was not something that could be
conveniently done in certain languages. So, this slide is a bit speculative. I
can't, I can't give you a proof of this, but it does seem to me that functional
languages and the people who design them are often right.
The world comes to see that the language [UNKNOWN] and approach being advocated
are useful, whether it's garbage collection or higher-order functions, it
just often takes a couple decades. So the way I like to think of it is
functional languages have never succeeded in conquering the world, in taking over
the world and replacing what came before them but the ideas get assimilated.
They get incorporated into other languages and that's what I mean by
functional languages being ahead of their time,
being the leaders that then things get adapted elsewhere.
I think that's fine. I think societal progress often takes
time. It can be frustrating to people sometimes
how long change takes. When something like this takes so long,
you can't give credit. I'm not saying that C# has type N friends
because ML friends, it's a much more complicated story.
I'm not saying that one person is to blame and another single person is to
take credit, but there is influence and there is a
reasonable historical path from one place to another place.
And being speculative, perhaps the next thing will be something you'll learn in
this class, whether it's pattern-matching, currying, or we'll
study macros a bit when we study Racket. All of these things are good ideas, are
elegant constructs that I would like to see be more popular, and I'm not going to
predict which one or something not on the list might be next, but that's some of
the benefit of learning languages that have a history of being ahead of their
time. Now, that's really about the past. What
about what's been happening recently? I think it's quite clear to me, although,
I may be biased that in the last few years, there's been a real surge of
interest and popularity in using functional languages for real.
Real companies, real projects, real systems, and I've made a list here, I
apologize if I left a language off, but these are all languages that have active
user communities that are still growing. They're all absolutely functional
languages, no one would deny that. Perhaps with Scala or F#, you would say
they are also object-oriented languages, but the new thing they bring to the
table, in my opinion, is really the functional aspects and people really like
these languages. I'll talk, in the next segment about why
we're not using those in this course and there are reasons for and against that.
for a couple of these, I happen to know of URLs that list a number of companies,
not one or two but more like ten or 20 or 50 that use these languages for real
projects. if you know of some for the other
languages, I encourage you to post them on the discussion board.
I didn't mean to leave anyone out. and in general, you might be interested
in this last URL cufp.org, that's the Commercial Users of Functional
Programming soft of group and website. They have an annual meeting, that sort of
thing. I just don't want to leave the impression
that functional languages have no real world use.
they do, and, and, and of course, it's on something I focus on a lot in this
course. I would point out that even if none of
these languages existed, you could still very much argue that functional language
ideas are more popular and more important than ever.
Never, okay? So we see other languages adopting ideas, C# and its LINQ support
on the NET. framework, this is stuff from Microsoft, is
fundamentally about starting with an object or any language and then adding
things, like function closures, and type N friends and they feel this adds a lot
of benefit and, and good things to their language.
As I've already mentioned, JAVA have plans to add closure in the near future,
perhaps even they have by the time you're watching this video.
and then another example is if you've heard of MapReduce or the open source
variant Hadoop. This is this idea of doing large scale
data computations on fault-tolerance distributed clusters where there's a
complicated implementation of the infrastructure. But on top of that, you
just write functions that are essentially map and fold,
reduce and fold and essentially synonyms, and then, many things are taken care of
for you. If you actually go back to the original
paper introduce research paper introducing the idea of MapReduce,
it says right in the first few sentences that we take the ideas of the functions
map and reduce that have been used for a long time in functional programming
languages. so why this sort of recent-ish surge to
the extent that there is one? Here, I really am guessing, but I, but I thought
it would be nice to kind of give some ideas on why I think this might be
happening. Of course, the first one is these
functional language ideas are concise and elegant and make people.
People productive, but that's always been the case,
so it doesn't really explain sort of more recent phenomena, unless you just say,
well, people have finally gotten the message or, or wish to pursue these
ideas. I, I think some credit actually goes to
languages like JavaScript or Python or Ruby or whatever that people now
understand that real systems and real things you want to write and do, don't
have to be written in C or C++ or Java or C# or whatever, that, that it's helpful
to have a diverse heterogeneous programming language landscape rather
than trying to find one program or one system that everyone will use.
I also think that avoiding mutation in particular which is one of the key things
that functional languages offer is the easiest way to making current and
parallel programming easier. That with a world with, so much parallel
processing, multi-cores in your phone or your laptop or your desktop, as well as
in data centers. We need to make parallel programming
easier and it is hard to share data that can be updated by other threats.
and so this is something where functional languages should shine.
I think, in general, our software has gotten so complex that it's very hard to
keep track of all the places in your system that someone might have access to
a particular piece of data. And if that data cannot be updated, then
you often have to worry much much less about who else might have an alias to it.
We talked about that earlier in the course with the benefits of no mutation,
although, only with a small example. And then finally, it might well be that
functional programming remains a very small niche in the overall landscape.
I don't know how to measure how much software industry there is, how much
software is being written. Other people probably try to do that sort
of thing, but there's so much software in the world
today that there's room for everybody. There's room for ML programmers and
MATLAB programmers, and Java script programmers, and C programmers, and
Assembly programmers, and Java programmers.
And so there's plenty of software to be written and we need to bring the best
tools to bear that we can on every problem that we need to.
