Evolving Functional Programming Languages
summary
Argues that evolving functional languages splits into compiler plugins and macros (opaque, global, can speed code — machinist claims up to ~5x for numeric type-class calls) versus encodings vs extensions (type-level encodings like type classes or HLists keep composability and pedagogy). Shows tools: kind-projector, simulacrum, machinist, Shapeless and circe derive (automatic JSON encoders generated), notes many extensions start as encodings then gain macros, and warns about incompatible, hard-to-google sublanguages.
AI-written summary · about
chapters (19)
- 0:00Intro
- 1:52methodology
- 3:31referential transparency?
- 5:45why is substitution so important?
- 8:03what was that about types?
- 8:40types make this more difficult?
- 11:11strategies against boilerplate
- 13:12type lambdas
- 14:25natural transformations
- 20:16what does simulacrum do?
- 21:44even more about type classes
- 25:01so extensions are great? Extensions are a clear way to evolve the language
- 25:33the other side
- 28:07in the eye of the beholder
- 28:55encodings as pedagogy Encodings have pedagogical value
- 30:39trade-offs
- 33:46cast back your mind
- 34:47magic dogs How does this work?
- 35:21encoding or extension?
related talks
58mKeynote: Why Functional Programming Matters
44mFunctional Programming You Already Know
14mFundamentalist Functional Programming
36mConcrete Functional Programming
57mThe Fun of Functional Programming Panel
46mFunctional Programming with Go
42mProgramming with Math
41mChoosing Your Next Programming Language