Abstraction Considered Harmful (and other opinions about writing maintainable code)
summary
Argues that abstraction hides failure modes with concrete failures: line-numbered stack traces in r15 turn a polite library into a bottleneck and create 40,000 stack traces/sec that slow the system; generated DSL modules produce doubled try‑caches and hit a runtime limit signalled as no free slots (sadface) until run_erl and an OTP fix arrive; shared terms trigger a 256 GB memory spike by expanding sharing; naive permutation code explodes combinatorially, so upgrades, gdb inspection and simpler explicit code fix these problems.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 2:54Transaction system performance collapse
- 13:55System crash after code reload
- 21:16Memory spike from XML parser
- 28:54Set comparison complexity disaster
- 32:18Domain-specific language dangers
- 36:15Avoiding callbacks macros
- 41:18Readable code saves debugging
- 42:31Questions and final discussion
related talks
36mOn the Spectrum of Abstraction
40mLessons from two decades of writing bad code
01h 03mIt's Abstractions All the Way Down...
27mScala bad practices or how to keep your job for life
01h 01mProgram Obesity: A Code Health Epidemic
20mGood Code is a Balancing Act
35mMind Over Error
48mAnti-Patterns in the Wild