My post about leaky abstractions generated some interesting discussion over at Joel‘s discussion board, and in the comments. I’d like to summarize it, from my viewpoint, of course.
Joel’s original article was probably not primarily intended for the kind of "formal" interpretation I attempted. That doesn’t necessarily matter in this case, but it confuses people when I’m arguing from that view, and other people are interpreting my arguments from the "other" view. And vice versa. But confusion is productive, that’s an old idea that I’ve always subscribed to!
Another thing that I realized was that I shouldn’t have said anything about "native" APIs in relation to leaky abstractions. That was simply wrong. Leaky abstractions has nothing to do with whether you have access to the abstraction layers below or not, as was kindly pointed out to me. On the contrary, this is necessary (another Joel classic!).
So, let me reformulate my points (some new stuff added, too).
First, there are many important things that aren’t specified when we construct software, such as real-time constraints, CPU consumption and similiar non-functional requirements. Then, specifying those wouldn’t necessary decrease the amount of abstraction leaks in practice, only in theory. For the practice, we’d need some kind of usability analysis of the APIs. Consistently performing usability tests on APIs would indeed reduce the amount of abstraction leaks, I think! Microsoft‘s already doing that.
Second, some abstractions are sloppy, in addition to being leaky, causing even more "leaks". C++ is a sloppy abstraction because it doesn’t properly abstract away the C language. ATL is a sloppy abstraction because it doesn’t abstract away COM completely. And so on. I don’t say these abstractions aren’t useful, indeed they are. But I think Microsoft has finally produced a reasonably strict (as opposed to "sloppy") abstraction with .NET.
Filed under: Software Development
