Functional Programming is Terrible
summary
Argues that Scala forces workarounds for pure FP: no general tail-call elimination in Scala, so composing many functions needs trampolines with memory and CPU overhead that hurt performance; higher-kinded types require manual kind annotations or ugly Lambda/unapply hacks (State[A,S] can’t be partially applied); lack of kind/type inference, boxed function objects, and missing existential/universal types force boilerplate. Recommends tail-call bytecode, kind inference and better type inference; nevertheless modularity, compositionality and reduced cognitive load make FP worth it.
AI-written summary · about
chapters (18)
- 0:00Intro
- 2:53Tail recursion
- 3:45Inter-method tail calls
- 4:23Tail calls in FP
- 5:34Trampolines
- 10:03Kinds
- 12:34Applicative functors
- 13:15Code reuse?
- 14:29Currying?
- 15:07Unapply
- 17:27FP made less terrible
- 19:44is FP just a hair shirt?
- 20:59Modularity
- 22:07Functions are modular
- 23:10Compositionality
- 24:11Functions are compositional
- 26:10FP = Happiness
- 30:02Summary
related talks
49mFunctional Programming Essentials
48mObject Functional Programming
19mScala for the Rest of Us
59mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 3 of 6
37mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 6 of 6
01h 00mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 1 of 6
38mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 5 of 6
42mPolymorphic Function Types in Scala 3
