The Extensibility Problem
summary
Elm code stays concrete which makes reasoning trivial but blocks practical optimizations. An escape room hint search is implemented by word-splitting then moved to a Dict word → list of hints after ~100 games because naive search becomes very slow on decade-old hardware; Dict speeds lookup but worst‑case searches still take about a second and cannot be optimized further because Dict is opaque types in the stdlib. A seating app exposes the array→list rendering cost and shows why ad hoc polymorphism like type classes or a generic Dict API is tempting but would require language or library changes.
AI-written summary · about
chapters (8)
- 0:00Welcome and introduction
- 1:32What is the extensibility problem
- 3:40Case study escape room hints
- 6:12Opaque types trade-offs
- 8:43Pricing with opaque types
- 9:46Board game tracker struggle
- 11:32Clojure’s extensibility pitfalls
- 12:56Trade-offs and unanswered questions
related talks
53mAdventures in Elm: Events, Reproducibility, and Kindness
10mFunctional Data Structures
26mDeveloping with Elm in a large application
02h 38mLazy Evaluation
41mWriting Reliable Web Apps With Elm
47mElm or how I learned to love front end development
26mInfinite Possibilities
43mThe Tyranny of Structurelessness