When is an ADT not an ADT?
summary
Compares two Scala encodings of a tiny expression DSL (ints, +, -, , equality) and shows concrete tradeoffs: an OOP/subtyping encoding uses classes, a common num type parameter for the expression normal form, and builds a pretty-printer, while the algebraic (case class + pattern match) encoding builds eval and an optimizer*. Demonstrates that OOP makes adding new terms easy but adding interpreters hard, ADTs make adding interpreters easy but adding terms hard, and mentions object algebras / tagless final as hybrid solutions.
AI-written summary · about
chapters (11)
- 0:00Introduction and context
- 2:02Defining software quality
- 6:12The problem setup
- 9:32Object-oriented approach
- 12:44Extending with new types
- 15:08Adding interpreters
- 19:02Evaluating OO extensibility
- 22:40Functional approach
- 25:57Functional extensibility
- 30:01The expression problem
- 34:35Conclusion and takeaways
related talks
40mADTs For The Win!
31mGADTs in Dotty
45mDesign and Effectiveness of Internal DSLs in Scala
49mAcademese to English: Scala's Type System, Dependent Types and What It Means To You
37mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 6 of 6
44mIn Types We Trust
39mA few tips on modelling things in Scala
52mConstraints Liberate, Liberties Constrain