Leaky abstractions

From APIDesign

When creating an API one is creating a facade, an abstractions over the internals of the API's implementation. Often the characteristics of the implementations are visible through the API. There is some controversy on wikipedia whether this is good or bad and even whether the original Spolsky's article is properly understood. Let me add few comments to this debate from the perspective of selective cluelessness.

Joel Spolsky's article claims that it is inevitable that every abstraction is leaky. I can only support this statement. In the world of DCI, when the bindings between data and interactions are almost unpredictable, one can see such leakage effects quite easily. However the rest of Joel's article concludes that due to that he has to learn far more than he had to when dealing with old good char* years ago. This is where I have to, in the name of (selective) cluelessness, object! Good abstractions (and APIs) hide the implementation details in a way that 99% of usages do not require understanding of the underlying (and leaking) gory details. As a result majority of users of such systems can use them while staying clueless. For them the abstractions are quite beneficial. Indeed, some users, in some situations need the underlying details, but for them there is the selective adjective in the selective cluelessness. This ensures that the knowledge is build-able, that the source code, implementations, behind the abstractions are no oraculums, but can be inspected, read and understood (for those 1% which needs it).

Leaky abstractions are here and we need to learn to live with them. When accompanied with selective cluelessness, we can maximize their benefits while minimizing the negative effects of their leakages.

In other news

Leakages of this kind are not restricted just to the world of API. After writing TheAPIBook I also noticed that I made my own cultural context leak which created an unwanted confusion and led one of TheAPIBook's reviewers to reject to publish its review.