15-150: Principles of Functional Programming
A Carnegie Mellon course on functional programming in Standard ML is drawing praise as a rare, well-structured resource for learning modern FP concepts such as strong typing, immutability, and higher-order functions. Commenters debate the choice of SML over more popular languages like Haskell, OCaml, or Lisp, arguing that a small, stable, strongly typed language helps students focus on core ideas rather than tooling and advanced features. The thread also surfaces broader themes: the scarcity of good FP teaching materials, tensions between pure functional ideals and practical concerns like logging and side effects, and the value of exposing CS students to multiple paradigms beyond Python and OOP.
Emphasis on Functional Programming in CS Education
- Many welcome a university-level FP course and wish FP were taught more widely and earlier than OOP.
- Several describe curricula where students learn multiple paradigms and languages (C, C++, assembly, Haskell/Scala/Racket, Java, Python, etc.) and praise this breadth.
- Some recommend prospective students explicitly look for programs that teach FP and low-level systems, not just Python.
Choice of Standard ML vs Other Languages
- Standard ML is defended as small, stable, and well-suited for teaching core FP concepts without tooling or language “bloat.”
- Historical reasons at CMU also matter; SML is a research language with roots there.
- Critics argue SML is verbose, less practical than OCaml/F#/Haskell, and hard to install; proponents say its simplicity outweighs lack of industry use.
- Static typing, algebraic data types, pattern matching, and strong type checking are cited as key teaching advantages over Lisps.
- Debate occurs over “pure” vs “impure” FP and whether Lisps lack referential transparency; others note RT is about how you use the language, not the language itself.
Course Materials, Exercises, and Slides
- The lectures are praised for clarity, energy, and high-quality slides.
- Official homeworks/labs are not public due to shared authorship and academic-integrity concerns; some older assignments and a supporting SML “book” exist.
- There is interest in new, publicly available exercise sets, but this is noted as time-consuming.
Practical FP Issues: Side Effects, Logging, IO
- A recurring complaint: in pure FP (especially Haskell), small side effects like logging “infect” types with IO and complicate refactoring.
- Responses suggest:
- Using more pragmatic FP languages (OCaml, F#, Erlang).
- Embracing impurity where helpful (“functional core, imperative shell”).
- Using monads/type classes (MonadIO, logging type classes, ST) or debugging helpers (e.g., trace) to manage effects.
- Some see the IO-monad discipline as powerful; others find it clunky.
Learning FP and Graph Algorithms
- Learners struggle with graph algorithms and circular structures in Haskell; they find purely functional graph code slower and more complex.
- Suggestions include:
- Translating imperative algorithms more directly at first.
- Studying functional data structures (e.g., Okasaki-style), algebraic graph libraries, and store-passing style.
- Using FP communities (e.g., language-specific Discords) for help.
FP, Theory vs Practice, and LLMs
- Some worry FP teaching leans too theoretical and not enough toward practical/industrial languages; others prioritize conceptual clarity over immediate applicability.
- Views differ on whether FP enthusiasts lack real-world perspective; others counter that FP is valuable in production and in pairing with AI-generated code due to strong type systems.
- One commenter suggests LLMs make programming less relevant; others argue programming/FP remains valuable, akin to foundational math.