Some Context for Pure FP Concepts and Style: A Retrospective
summary
Builds a multi‑page site with PureScript and a server and actually shares types between front end and server, starts with Pux for the UI and discovers Pux fails to scale so the app ends up as a big single‑state SPA, ports a JavaScript Pong to PureScript to test ideas, prefers concrete domain types for maintainability but argues for algebra‑first design (define laws and interpreters, then refactor), and flags the coarse Effect row versus extensible effects as a practical pain point.
AI-written summary · about
chapters (13)
- 0:00Pure FP introduction
- 3:03PureScript for large apps
- 6:14Scaling PureScript challenges
- 10:27Algebraic laws in code
- 18:58Domain-specific algebras
- 21:55Imperative to pure FP
- 23:05PureScript learning curve
- 26:43FP vs OO architecture
- 30:41FP architecture necessity
- 37:27Type-driven design in FP
- 46:47Principled FP programming
- 51:30Effect systems in PureScript
- 57:01Closing thoughts
related talks
51mPragmatism, Puritanism and Functional Programming
45mFP: The Good, the Bad and the Ugly
43mEverything You Always Wanted to Know About Functional Programming...
44mFunctional Programming: Failed Successfully
46m"Melange: The Next Frontier in Type-Safe Web Development"
27mEffectful
52mBake Real-life Apps with a Handful of Free, Coproducts & Types
21mFP for Data Science For Loops Considered Harmful