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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|selective cluelessness]].

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|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 [[DCIAndLeakyAbstractions|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 [[API]]s) 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.

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 [[DCIAndLeakyAbstractions|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 Technology|Good]] abstractions (and [[API]]s) 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 [[cluelessness|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).

Indeed, some users, in some situations need the underlying details, but for them there is the ''selective'' adjective in the [[cluelessness|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).

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|selective cluelessness]].

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|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 [[DCIAndLeakyAbstractions|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 [[API]]s) 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 [[cluelessness|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).

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 [[DCIAndLeakyAbstractions|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 [[API]]s) 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 [[cluelessness|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 [[cluelessness|selective cluelessness]], we can maximize their benefits while minimizing the negative effects of their leakages.

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

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|selective cluelessness]].

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|selective cluelessness]].

 

 

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

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

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]]. This is common source of [[wikipedia::Leaky abstraction|software bugs]].

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::Leaky abstraction|wikipedia]] whether this is good or bad and even whether the original [http://www.joelonsoftware.com/articles/LeakyAbstractions.html Spolsky's article] is properly understood. Let me add few comments to this debate from the perspective of [[cluelessness|selective cluelessness]].

Leakages of this kind are not restricted just to the world of [[API]]. After writing [[TheAPIBook]] I also noticed that I made my own [[LeakingCulturalContext|cultural context leak]] which created an unwanted confusion.

 

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

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]]. This is common source of [[wikipedia::Leaky abstractions|software bugs]].

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]]. This is common source of [[wikipedia::Leaky abstraction|software bugs]].

Leakages of this kind are not restricted just to the world of [[API]]. After writing [[TheAPIBook]] I also noticed that I made my own [[LeakingCulturalContext|cultural context leak]] which created an unwanted confusion.

Leakages of this kind are not restricted just to the world of [[API]]. After writing [[TheAPIBook]] I also noticed that I made my own [[LeakingCulturalContext|cultural context leak]] which created an unwanted confusion.