Abstractions Too Near

This is the situation where one wraps or abstracts a concept with another concept that is too similar to what it is wrapping such that it provides no net benefit. This is because each layer has maintainence cost and interface management overhead associated with it. If the abstraction does not offer something signifantly higher up the abstraction scale or significantly different, it is just adding red-tape to the mix. --top

Possible Examples:

Wrappers to HTML - HTML is already an abstraction, it is not "machine GUI code". See FuzzyDistinctionBetweenInterfaceAndImplementation. (App-specific shortcuts such as a "cell()" function are not the issue, but rather general-purpose UI wrappers in place of HTML.)
Class wrappers around database schemas - The classes and database fight over which gets to be the application or business "domain noun model".

HTML is not particularly abstract, though it is somewhat less concrete than postscript. HTML carries both low-level (string/text) based content plus presentation information just as much as any physical carving; it only leaves a little budge-room for interpretation. I believe HTML is a horrible mix of content and presentation. The momentum HTML has built is among the great impediments to machine processing content in a meaningful manner (e.g. for more intelligent search-engines and intelligent agents). True abstraction for document presentation (or a 3D-model presentation, for that matter) requires the use of stylistic presentation of structured content... and a fine (but still primitive) example is provided in CSS over XML. Even better, and more abstract, would be structured content that carries high-level 'meaning' and can be translated from this structured language into the reader's language. As is, calling 'HTML' an 'abstraction' is sort of like calling C a 'high level language'; i.e. you'd certainly be dating yourself.

WRGT 'Wrappers to HTML', just how close a wrapper are you thinking, Top? Certainly if a wrapper separated content from presentation information and recombined them to HTML or High-Level Content + CSS or whatnot at will, it wouldn't be an 'AbstractionsTooNear'. Or are you thinking more a helper-class for reading and writing XML? And would such a class even be trying to be abstract, or just to relieve the user (programmer) of string manipulations? I've never really used a class where the AbstractionsTooNear, mostly because I tend to build abstractions top-down from a 'top' that is as sky-high as I can manage (up to the point that code-proof becomes possible, at least).

My "top most" abstractions tend to be app-specific. I do not strive for a generic wrapper over HTML because those usually fail in my experience. --top

Hmmm... my experience is quite different. My top abstractions are usually abstractions of domain components, with app-specific implementations. These, for me, usually result in a much easier time for both code-integration and proving correctness (which is something I take seriously.) However, it does come at the cost of it taking me much -longer- to code certain pieces than it would for someone pumping out code at the lowest abstraction possible.

Each department or application tends to have a different view of the domain such that a domain-level is often too high a target in my experience. Marketing versus production are natorious for this. It also requires more inter-department coordination and cooperation, which is difficult to come by. They each have different goals, priorities, and time-lines. One can barrow abstractions across such, but it is risky to marry them.

I wouldn't go for a generic wrapper over HTML, but rather an abstraction of all content-presentation mechanisms. I'm not sure it's correct to call it a 'wrapper'... I'd probably tear apart the HTML and re-create it later. However, I'm thinking of this in the context of editing HTML or displaying it alongside other sorts of content-presentation objects, and possibly running it through a stylistic artist for final presentation (i.e. allowing meta-css), not displaying it as fast as darn possible. It sure is slow coding the first time, but then you can prove it is correct on multiple levels. I have some fondness for BigDesignUpFront accompanied by rigorous proof of design.

You seem to suggest that a generic "content-presentation mechanism" is possible. I am highly skeptical. But, there is already a discussion about that somewhere around on this wiki, and I'll link to it when I find it. I've been jaded by one-size-fits-all generacy attempts in the past and feel it is an impossible goal, almost like getting a Soviet-style economy to be more efficient than Capitalism. Ideally, it is better OnceAndOnlyOnce. In practice such large-scale coordination is very very difficult for humans.

Many have observed and agreed that re-use and abstraction on a "local" basis (intra-app and intra-shop) is much easier than general abstractions. PresentationIsDifficult, there are no trivial fixes.

CategoryAbstraction