> It's a stunningly difficult and surprisingly low-value proposition to create abstractions that don't leak.
Maybe for you. For me, non-leaky abstractions have enormous value. And, while designing non-leaky abstractions requires more effort upfront, in the long run, it requires less effort than plugging leaks in carelessly designed (non)abstractions.
> That's not the goal anyway: The goal is to leverage abstractions to build things.
The goal is to do it efficiently, and creating as few problems as possible for the future.
> The implementation details frequently do matter.
Of course they do matter - for the implementor.
> When possible, it's preferable to design abstractions that have a clear implementation in terms of the lower level's abstractions.
No disagreement here.
> This way, when something goes wrong - and it will - you can understand and fix it.
That's the job of the abstraction's implementor. If that happens to be me, I will fix it. Otherwise I'll just submit a bug report. If that doesn't work, then I'll reimplement the abstraction myself, but by no means will I work around an existing broken implementation.
