Pragmatism, Puritanism and Functional Programming
summary
Argues that using Haskell and GHC in an industrial codebase of hundreds of thousands of lines yields measurably simpler, more readable programs: purity plus a static type system reduces where bugs can hide, lets refactoring and reasoning scale, and enabled a working commercial system after five years of exclusive pure FP. Describes concrete tools: monadic effect encoding for controlled side effects, unique identifiers for fast pointer-equality in caches, and type-indexed file/path distinctions; warns about the learning curve and that pure by default + static types as sliding scale is the pragmatic compromise.
AI-written summary · about
chapters (20)
- 0:00Start
- 0:19Pragmatism Puritanism and Functional Programming
- 2:31An Industrial Functional Programming System
- 2:59Haskell Makes Our Programs Simpler To Read and Simpler To Write
- 4:44' S Important about Functional Programming
- 14:49The Pitfalls behind Purity
- 17:26Syntactic Sugar
- 21:42Objects Which Change To Do with Identity
- 23:54Learning Curve
- 24:52Type Systems
- 25:44How Haskell Works in Haskell
- 27:02File Paths
- 29:37Distinguish between File Paths and Directory Paths
- 31:45Benefits of Static Type Systems
- 34:56Locating Bugs
- 37:26Type Signatures
- 40:53Type Signature
- 42:00How Types Help Us with Side Effects
- 44:13Changing Your Mind
- 45:43Summary
related talks
44mFunctional Programming: Failed Successfully
45mFP: The Good, the Bad and the Ugly
57mSome Context for Pure FP Concepts and Style: A Retrospective
49mType Theory Behind the Glasgow Haskell Compiler Internals (Part 2)
01h 01mType Theory Behind the Glasgow Haskell Compiler Internals (Part 6)
58mType Theory Behind the Glasgow Haskell Compiler Internals (Part 4)
57mType Theory Behind Glasgow Haskell Compiler Internals (Part 1)
59mIntroduction to FP Using Haskell (Part 1)