Chris - Impressive amount of work! Since this is "cafe" ... allow me to put my standard rant here: Browsing your table of contents, I certainly agree that lambda calculus is a first principle. But when I teach (beginners or not) I put algebraic data types and pattern matching even before functions. Because I want to first describe data, then transformation of data. (Yes, I know, we can simulate data with functions. We can also simulate lambda calculus with term rewriting. No winner there..) And testing really should go as early as possible (lecture 1 or 2, ideally). I don't really know how to do this from first principles and early, because we need some type-classes here (deriving Eq and Show, and also Serial, for automated test case generation. Which should be a strong selling point.) And I do avoid numbers, lists and strings. Really. Functional programming tragically over-uses lists, and by extension, strings. (Of course, other languages also tragically over-use strings.) When I need a list, I have the students write down the data declaration. When I need numbers (mostly I don't), it's Peano numbers. Yes, lazy lists have a purpose in Haskell (expressing control) but this only works if they're being fused away. Later, when we have modules and type classes (for abstract data types), students can learn to use different representations for sequences. But if you start feeding them lists/strings, they'll think it's natural, and have a hard time switching to Data.Sequence, Data.Vector, Data.Text ... I know I did. Well. I'm sure you've given this a lot of thought. I see that you refer to Brent Yorgey's course https://github.com/bitemyapp/learnhaskell#yorgeys-cis194-course and there we have "data"/"case" in lecture 2. Oh, and I do have to read up on how he sells Applicative/Monad. For me, Monad feels more natural, but that's just because I learned it earlier, and now I have to unlearn it. And that illustrates the point I'm making about lists and strings. Best - Johannes.