Fundamentalist Functional Programming
summary
Argues that mixing effects into imperative or “functional” languages breaks expectations: lazy LINQ queries in C# interleave console output and delay exceptions, closure capture yields different results (examples print 7 7 7 vs 4 5 6 vs 6 6 6), and resource disposal in using-blocks causes late failures. Proposes modeling effects as explicit types—monads as types for effects—points to Haskell (and unsafePerformIO risks), notes F# eager comprehension tradeoffs, and claims purity lets compilers freely reorder for parallelism.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:55What is a XXX Language?
- 1:14What is a Functional Language
- 3:12Doing IO is a side-effect
- 3:58Lazy evaluation and side-effects
- 5:40Exceptions
- 6:40Disposing resources
- 7:57Variable Instantiation
- 8:17Concurrency
- 9:10Forget about effects? Forget it!
- 9:53Values vs Computation
- 11:46Haskell 2
related talks
43mFunctional Programming with Effects
56mFunctional Programming on .NET - The Best of Both Worlds
50mFunctional Programming with Effects
41mFunctional Programming for Pragmatists
01h 00mLogic vs. side effects: functional goodness you don't hear about
58mFunctional Programming with C#
46mFunctional effects in perspective
31mA Primer on Functional Programming