150 was one of my favorite courses at CMU; each homework really made me feel like I unlocked a new level of reasoning with code.
Content aside, what gorgeous slides. I wish any of my lecturers had the same eye for presentation.
Does this include exercises? I didn't see any and I always find that the most useful part of learning.
Of note, CMU produces a bunch of functional programming research, including a whole homotopy type theory department, so this is a quality source.
God send!! The FP learning resource is quite sparse on the internet. I’ve been looking for structured material like this for a while.
No word on where the concept originally comes from? (in the text/description)
Should have at least differentiated between "functional programming" and "pure functional programming" IMHO.
This looks valuable. And it is from the summer of 2023, so quite current.
Great resource! Forgive my ignorance but why do so many modern functional programming courses use Standard ML instead of a Lisp dialect? Is it because of its built-in type-checking, or is it just how it's always been taught?
The lecture on CPS made things "click" for me in a way that they hadn't before. Thank you.
Use to be called 15-212. TA-ed it for 1 semester. That's when I really understood programming.
Pretty good for a new grad!
This looks cool! Just a note, it looks like the youtube playlist is in reverse order: https://www.youtube.com/watch?v=DSGXB9G5dxk&list=PLsydD1kw8j...
Standard ML (sml / smlnj)
The instructor is clear, energetic, has a decent flow in the first lecture e.g. emphasizes the important points with vigor and repetition, switches media every 10 or 15 minutes, has a conversation with students. Slides are relatively noise-free and are informative; terms to know are highlighted.
I haven't watched a full functional programming lecture series yet, but I'd gladly audit this one.
As a "new" instructor (as in, not a TA anymore) he's got a bit of teaching talent. I hope he keeps a tight feedback loop and improves every year and continues publishing material.
on the choice of language to teach the course why sml
i think there are a lot of nicer choice
OCaml , its basically sml only more popular and used more in real life
Haskell , again more popular , and used more in real life
Idris , newer and said to be more progressive
F# , a more practical choice and similar to sml
a lisp , well if you want to focus on the functional part and less on the types partSlightly off-topic but what's a good forum to seek help on FP practices outside of the courses like this online?
Every winter break I get back into trying to learn more FP (in Haskell) and in the past several years I have been practicing algo problems (codeforces, advent of code, leetcode).
I always get stuck on more advanced graph algorithms where you traverse a and modify a graph, not a tree structure - it gets particularly tricky to work on circular data structures (I learned about "tying the knot" but it's incredibly challenging for me) and usually the runtime perf is sub-par both asymptotically and empirically.
Wow, he went from taking his bachelor to lecturing.
I always dreamt of that when going through my degree and encountering courses that needed a thorough rework.
I do wish functional programming were more taught. we're getting to a point where I almost think OOP should be taught briefly and the rest of the focus on C/C++ for low level stuff (OS, data structures, some algorithms), and something functional or pseudo-functional for high level stuff. Most of the newer codebases in startups now require functional concepts to understand what's happening. For example, try writing modern JS without understanding .map, .reduce, et al, and function passing, etc.
Regardless I think it's important that students get exposed to more than just Python, which seems to increasingly be the only thing students come out knowing.
My complaint with FP: Sometimes I just want to do something silly, like adding a log somewhere. If I choose to add said side effect, now all my functions are marked with an io signature (so there might be _other_, nastier side effects hiding there as well - mainly an issue if you have multiple people contributing to the same project). If I don't add the side effect, and choose to refactor multiple layers of code, I will need to make all my functions return multiple values and later fold over all the accumulated strings and... life is too short for that. The principles really resonate with me, but maybe we are limited by the current tooling, because the development experience is quite clunky in its current stage.
Hey Brandon, thanks for posting this. Off-topic but maybe consider serving up thumbnails on that page instead of the full-size pngs https://brandonspark.github.io/prologue/lecture01.png
It seems that the fundamental problem with the functional paradigm (in its pure form) is that the real world - including the architecture of the computer that is used to run the programs on - is full of side effects, i.e. is essentially "imperative," and with this impedance between them the idea creates more problems than it solves.
Watching it now
just in time for nobody to really care about programming because LLMs are so good at translation and all computer code and programing are a subfield of linguistics...
I loved 150 when I took it, and program in SML from time to time to this day.
Bob Harper (a CMU professor with a focus on PL theory) also has a really good SML reference that is closer to a textbook than lecture notes.
http://www.cs.cmu.edu/~rwh/isml/book.pdf