• Not all abstractions are good: Abstraction-heavy codebases can lead to sluggish performance, debugging nightmares, and more time spent on abstractions than solving problems. Many so-called "abstractions" are actually just layers of indirection that add complexity without value.
• Characteristics of a good abstraction: A great abstraction hides the complexity beneath, like TCP which takes on error correction and retransmission. It allows us to operate as if the underlying complexity doesn't exist.
• Bad abstractions as layers of indirection: These "abstractions" add complexity without hiding it. They add a layer with no added behavior and make the system more difficult to trace and understand.
• Real costs of abstractions: Abstractions add complexity and performance penalties. They are the enemy of performance as more layers mean further from the underlying code. They also add to the complexity of systems, making them harder to understand and maintain.
• All abstractions leak: Eventually, one needs to understand the underlying implementation details. A good abstraction minimizes this need; a bad one makes every small bug a major issue.
• Asymmetry of abstraction costs: The author benefits immediately from an abstraction, but the cost of maintaining it falls on others who have to deal with the complexity.
• Conclusion: Abstractions are powerful but not free. Use them wisely, ensuring they truly simplify the system and hide complexity rather than adding layers of indirection.