Leaky abstractions - Revision history

JaroslavTulach at 09:22, 31 October 2009

JaroslavTulach — Sat, 31 Oct 2009 09:22:10 GMT

←Older revision		Revision as of 09:22, 31 October 2009
Line 1:		Line 1:
	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).

JaroslavTulach at 09:21, 31 October 2009

JaroslavTulach — Sat, 31 Oct 2009 09:21:37 GMT

←Older revision		Revision as of 09:21, 31 October 2009
Line 1:		Line 1:
	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.

JaroslavTulach at 09:11, 31 October 2009

JaroslavTulach — Sat, 31 Oct 2009 09:11:05 GMT

←Older revision		Revision as of 09:11, 31 October 2009
Line 1:		Line 1:
	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]].

-	~~TBD~~	+	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.
		+
		+	==== 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 [[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.

JaroslavTulach at 08:32, 31 October 2009

JaroslavTulach — Sat, 31 Oct 2009 08:32:01 GMT

←Older revision		Revision as of 08:32, 31 October 2009
Line 1:		Line 1:
-	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.	+	TBD
		+
		+	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.

JaroslavTulach at 07:18, 31 October 2009

JaroslavTulach — Sat, 31 Oct 2009 07:18:04 GMT

←Older revision		Revision as of 07:18, 31 October 2009
Line 1:		Line 1:
-	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.

JaroslavTulach: New page: 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 ...

JaroslavTulach — Sat, 31 Oct 2009 06:39:26 GMT

New page: 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 ...

New page

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]].

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.

←Older revision		Revision as of 09:22, 31 October 2009
Line 1:		Line 1:
	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).

←Older revision		Revision as of 09:21, 31 October 2009
Line 1:		Line 1:
	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.