Since our parallel programming course is no longer available and soon to be removed from the curriculum, we need something to replace it.
Possible candidates:
I couldn't find anything on edX. From the above three, the first two are on Coursera and, though I haven't tried them out yet, they look like those annoying courses that lock you out of some assignments if you don't pay. The third one is on a platform I've never heard of and I have no idea if it's any good.
In the future I want parallelism to be much more strongly emphasized in the curriculum. Back in 2011, Carnegie Mellon (basically the top CS school in the US, particularly for undergraduate education) initiated a comprehensive reform of their curriculum, the reasons for which can be read in this report.
They moved to emphasizing parallelism (and functional programming) almost from the very beginning in freshman CS courses. They basically did this to "future-proof" their students against the deterioration of Moore's law. In other words, CPUs aren't getting much faster, so instead manufacturers are just adding more CPU cores. To take advantage of all those cores you need to think differently about how you program. Their belief is that highly imperative, sequential code is brittle and will be a thing of the past some day.
All of which makes sense to me and I want to future-proof our curriculum as well, but unfortunately free resources on the topic are still sparse. There is a free textbook that looks interesting. So this kind of reform to our curriculum is still very much a work in progress and I don't know how long it will be before we get there.
@hanjiexi
What are your thoughts on requirements to learn new languages?
Intro to Parallel Programming uses Scala and Intro to Parallel Programming in Java uses... python. (No, really, it's java.)
Scala is certainly a useful language, but it seems to me that we should bias the curriculum towards standard languages when we can.
it seems to me that we should bias the curriculum towards standard languages when we can.
I personally like the non standard languages like Racket. Sure enough I will not use them anytime soon in a production environment. But they teach me how to program a computer without training wheels (to use a phrase from David Malan). They make me think more like a language designer than a language user. Or another analogy: like an aircraft designer instead of a pilot. This comment is of course highly personal. I know how to program, been doing that for ug-teen years. But being auto dicdact I missed the theoretical background that comes from programming in a non mainstream language.
The languages used in the curriculum have for a long time been a sore point for me. I'm not at all happy with the current state of affairs, neither in our curriculum nor in the world as a whole...
If I'm being asked whether the curriculum should favor non-mainstream or mainstream languages, I would simply shrug my shoulders and say that's not what matters. A well-educated graduate of a CS program should be armed with the ability to pick up any new language (in and of itself) fairly easily. (The tooling, documentation, and library ecosystem might be another story, of course.)
I would re-frame the question: which languages are the friendliest to learners? Which languages are most appropriate to teach the concepts students need to learn? Is there some pragmatic value in using a non-mainstream language?
The subsets of Racket used in HtDP / "How to Code" (Beginner Student Language, Intermediate Student Language, and Advanced Student Language) are relatively excellent examples of teaching languages. The syntax can be described in a few sentences and every function you can use can be found on one single webpage. And it all runs in Dr. Racket, which installs quickly and easily on all computers, so you spend you time thinking about concepts, not "ramping up on the language" or fussing with tools.
Advanced Student Language is statically unityped (commonly called "dynamically typed"); a logical next step for a teaching language in the vein of HtDP would be to take ASL and gradually add more static types until the type comments and manual type-checking (via, e.g., (cond [(integer? ...) can be completely removed from a student's existing programs. Then it would be a natural transition to (Typed) Racket, where students could explore the relationship between types and sets.
I'm not saying it's strictly necessary that students use a teaching language. We could get basically the same result by taking an easy, industrial-strength programming language, make it painless to install (perhaps no install at all -- run it from a webpage), and have a single webpage that explains everything about the language (including all library functions) that the student needs to know at that point in time for whatever lesson they're learning.
If you're running it in a custom environment, you could even have a checker running that complains if the student tries to use a function or language feature they're not allowed to know about yet. Then you could gradually arrive at the full language and library ecosystem. And what I've just described probably already exists in some form or another; the problem is choosing what language to use for teaching CS concepts.
But choice of language is dangerous. Software companies have a commercial incentive to encourage organizations like OSSU to teach Java or C++ (or whatever language they happen to be using these days), because they don't want to spend money on training new employees. They want organizations like OSSU to basically just be free job training.
My attitude: OSSU CS should teach real computer science, which is not the same thing as spending the years it takes to learn all the quirks of Java, .NET, or the Python ecosystem. There are other places where students can learn these things. At the same time I do think that's preferable for us to use languages with non-trivial library ecosystems, because we are a project-focused community; students would have greater freedom to implement real world projects.
My problem with Scala is that, it has many of the right features to make it look like a modern programming language, but it's just so complicated. I haven't tried taking that Parallel Programming with Scala course; I don't know how much of Scala a student would need to know to complete it. It may not be worth it.
To be frank, if I were trying to select one programming language to use for the entire curriculum, there is none I'm aware of that meets all of the practical, pedagogical, and theoretical requirements I would want to impose.
@hanjiexi You're preaching to the choir. Yesterday I spent 2 hours dicking around installing Emacs. Contrast that with 'download and run' Racket. Not complaining, because I still learned a lot. 馃憤
As an employer I would rather have my employees learn proper Computer Science before the toolset they will use in their day to day practice. Both are important, but there is an order: First CS then tools.
It might be an idea to keep a separate page in the extras for these courses (e.g. Git/GitGub and Linux CLI from Udacity)?
"if I were trying to select one programming language to use for the entire curriculum, there is none I'm aware of that meets all of the practical, pedagogical, and theoretical requirements I would want to impose."
I don't see anyone suggesting using one language for all courses. Adopting the rule of thumb to "bias the curriculum towards standard languages when we can" is not an argument to conduct all classes in one language. When there are pedagogical reasons to use a non-standard languages, that rule of thumb would say, "use the non-standard language".
We should be aware that OSS asks students to use 7 different languages in the first 10 courses. This surely meets any standard of expecting students to be flexible in their use of languages. That pedagogical goal has been met.
A different pedagogical goal is to help students move fluidly through the curriculum. This goal is displayed in the way calculus is split up between Core Math and Advanced Math. Using languages with which students are already familiar also meets the goal of fluid movement.
If there are pedagogical reasons that the Scala course is better than the Java course, that would favor the Scala course. But if all else is equal, OSS bias towards a course in a language with which students are familiar.
I don't see anyone suggesting using one language for all courses.
My statements about that were hypothetical. What I'm saying is that we are accomplishing the goals of the curriculum in a painfully indirect way: instead of using 1-3 very flexible and powerful languages to illustrate every concept from the ground up, the curriculum is littered with wildly different languages, some of which have unnecessarily steep learning curves and switching costs, that various instructors have chosen because they believe they are commonly used in their domain. One example would be requiring C++ to learn computer graphics.
But if all else is equal, OSS bias towards a course in a language with which students are familiar.
I agree, and by this logic the "Parallel Programming in Java" course would make the most sense as a replacement, assuming it is of sufficiently high quality. I see there are also "Concurrent Programming in Java" and "Distributed Programming in Java" courses; we are in dire need of more resources on concurrency and distributed computing so these could be useful. I wince at the idea of inflicting even more of Java's type system on students (especially its bizarre Stream library), but so far I'm not seeing any other pragmatic options.
Stanford has a course with lecture notes, assignments, readings, labs/projects.
Just going to leave another course I found here. I'm unsure as to its applicability (what with it being Intel-specific), but more choices can't hurt.
@t-miller this course has some gabs between weeks.. and you can find from it's review some gaps.. overall I don't like Coursera as I finished Swift specialization and it's worthless (although I've paid the course).
It looks like UBC has an ongoing course with everything except lectures as well.
CPSC 418 Parallel Computation
Google Site version
I just noticed there is already an issue on this. The YouTube videos are actually still there despite the course being taken down. I found a playlist containing all videos and have submitted a PR where the playlist is listed as an alternative link. Could be a quick patch before a decision is made on the replacement course.
Intro to Parallel Programming is currently available on Udacity. Closing this issue.
Most helpful comment
The languages used in the curriculum have for a long time been a sore point for me. I'm not at all happy with the current state of affairs, neither in our curriculum nor in the world as a whole...
If I'm being asked whether the curriculum should favor non-mainstream or mainstream languages, I would simply shrug my shoulders and say that's not what matters. A well-educated graduate of a CS program should be armed with the ability to pick up any new language (in and of itself) fairly easily. (The tooling, documentation, and library ecosystem might be another story, of course.)
I would re-frame the question: which languages are the friendliest to learners? Which languages are most appropriate to teach the concepts students need to learn? Is there some pragmatic value in using a non-mainstream language?
The subsets of Racket used in HtDP / "How to Code" (Beginner Student Language, Intermediate Student Language, and Advanced Student Language) are relatively excellent examples of teaching languages. The syntax can be described in a few sentences and every function you can use can be found on one single webpage. And it all runs in Dr. Racket, which installs quickly and easily on all computers, so you spend you time thinking about concepts, not "ramping up on the language" or fussing with tools.
Advanced Student Language is statically unityped (commonly called "dynamically typed"); a logical next step for a teaching language in the vein of HtDP would be to take ASL and gradually add more static types until the type comments and manual type-checking (via, e.g.,
(cond [(integer? ...) can be completely removed from a student's existing programs. Then it would be a natural transition to (Typed) Racket, where students could explore the relationship between types and sets.I'm not saying it's strictly necessary that students use a teaching language. We could get basically the same result by taking an easy, industrial-strength programming language, make it painless to install (perhaps no install at all -- run it from a webpage), and have a single webpage that explains everything about the language (including all library functions) that the student needs to know at that point in time for whatever lesson they're learning.
If you're running it in a custom environment, you could even have a checker running that complains if the student tries to use a function or language feature they're not allowed to know about yet. Then you could gradually arrive at the full language and library ecosystem. And what I've just described probably already exists in some form or another; the problem is choosing what language to use for teaching CS concepts.
But choice of language is dangerous. Software companies have a commercial incentive to encourage organizations like OSSU to teach Java or C++ (or whatever language they happen to be using these days), because they don't want to spend money on training new employees. They want organizations like OSSU to basically just be free job training.
My attitude: OSSU CS should teach real computer science, which is not the same thing as spending the years it takes to learn all the quirks of Java, .NET, or the Python ecosystem. There are other places where students can learn these things. At the same time I do think that's preferable for us to use languages with non-trivial library ecosystems, because we are a project-focused community; students would have greater freedom to implement real world projects.
My problem with Scala is that, it has many of the right features to make it look like a modern programming language, but it's just so complicated. I haven't tried taking that Parallel Programming with Scala course; I don't know how much of Scala a student would need to know to complete it. It may not be worth it.
To be frank, if I were trying to select one programming language to use for the entire curriculum, there is none I'm aware of that meets all of the practical, pedagogical, and theoretical requirements I would want to impose.