BFPG Meetup - March 2026 - algebraic structures + the monad tutorial fallacy
Join the BFPG Discord: https://discord.gg/yYz2d8w7FY
Agenda
18:00: Welcome and setup
Presentation #1: Algebraic Structures as Interfaces by Donovan Crichton
Presentation #2:
34 years of Monad tutorials - has anyone learned anything? An anthropological study. by Carlo Hamalainen20:00ish: Pack down, head to Criterion pub
Algebraic Structures as Interfaces
Why are our interfaces (typeclasses) in functional languages called things like 'Monoid', 'Functor' and 'Monad'? Where do these names come from? This talk explores the relationship between familiar interfaces in functional programming, and their equivalence in mathematics: the algebraic structure. We will explore the relationship in the Idris2 programming language. Specifically we will cover:
Underlying definitions of algebraic structures.
Monoids, Semigroups, Functors, Monads.
Free Algebra.
An Algebraic Introduction to Categories.
Monoids as Algebra vs Monoids as Categories.
Overloading of mathematical terms.
This talk is suitable for intermediate functional programmers who can read the ML family of languages (Haskell, SML, etc). The only mathematics required is to understand that (x, y) is a pair of x and y.
34 years of Monad tutorials - has anyone learned anything? An anthropological study.
Between 1992 and 2026, at least 187 monad tutorials were published. They employed space suits, burritos, elephants, cowboys, and monsters. They were written in Haskell, then Scala, then JavaScript, then Rust. They spawned a named cognitive bias (the monad tutorial fallacy), a counter-genre (the anti-tutorial), and a 25-year analogy arms race.
This talk examines the monad tutorial as a cultural artifact: what patterns emerged, what actually worked, and why — after 34 years — most people still find monads confusing. The answer has less to do with category theory than you'd expect, and everything to do with picking the wrong examples. Using Go's HTML libraries as a case study, we'll look at a pattern that every working programmer has felt: the moment a clean DSL starts sprouting workarounds for problems it can't quite express. What is that friction, exactly? It turns out it has a name. No prior Haskell knowledge required.