Abstraction Development

Push as far as you want into other worlds, death is the only real escape from this one
Contents
Framing the issue

It is difficult to discuss these concepts when the meaning of each word is also abstracted. The nature of describing and solving a problem resembles the problem itself. Of course MeaningDependsOnContext. The difficulty in software development is design, not implementation. Developing good abstractions is more difficult than implementing them as code.

The author assumes that any defined words rely on definitions using words that are themselves abstract. It is up to the reader's to draw meaning correctly.

The reader is assumed to be a terran human fluent in the English language.

Reality is assumed to mean the physical substrate humans live in. It is where the corporeal bodies of your loved ones exist.

A solid foundation for abstractions
The nature of abstractions

All abstractions: Good abstractions: Bad abstractions: Developing abstractions See:

Forces working against us Possible parallels with MetaDevelopment?
Forces that help us It is possible that humans simply cannot reason about abstractions that are not related to the real world. The source of creativity is elusive, but truly original thoughts are generally considered impossible. A thought is always based on previously knowledge. Abstractions created in software are still tied to consensual reality. Attempts to reach beyond that limit are futile, as any implementation or mental thought about the abstraction will always be tied to our consensual reality context. In essence, our physical reality is the FundamentalContext?.
Abstraction Prejudice

Let us consider the following software development metaphor:

Software Development as Shamanistic principles Some would reject the metaphor due to their own opinions of shamanism - as they have experienced in the real world. Real-world opinions affect our abstractions that they would easily trump the correctness of the solution.

Software Development as Hardcore Drug use In the context of anti-patterns, this is a suitable metaphor. It is societally acceptable as most drug use is considered by the mainstream as counter-productive. The social aspects weigh so heavily they almost obscure the point of the metaphor in the first place - to describe bad software practices.

Software Development as Psychedelic Drug use In the context of design & brainstorming, this is a suitable metaphor. However is runs into social implications immediately. Do I appear to be advocating psychadelics? Are the effects too debatable? the metaphor attempts to describe a software development technique, but the social implications again obscure the issue.

It appears that the real-world counterpart to a development metaphor should not be a hotly debated topic. This is due to technical considerations like clarity. It is also due to social considerations - specifically the desire not to offend, and the desire not to get dragged into endless debate on the wrong side of the metaphor.

Imagine the obscuring issues that would arise from using the following metaphors: All other factores excluded, unrelated real world constraints affect what can be practically used as a metaphor or abstraction.
A Unified Abstraction Map / Pattern Taxonomy

Many would like to have a hierarchical taxonomy of patterns, but there are problems in the way: What are the non-orthogonal aspects to patterns that prevent creating a hierarchical taxonomy? Prototype pattern taxonomy for software development(ignoring the non-orthogonal problem): Possible taxonomy conventions(where is data included): See:
Implications for SoftwareEngineering

SoftwareEngineering is any subset of the art/craft/science of using any management style to map anything to anything in any possibly way in any language to run on any machine over any network that is usable by any level of user at any level of quality at any level of cost at any level of abstraction, using any number of workers to solve a problem that is constantly changing.

SoftwareEngineering needs a way to resolve choices efficiently. It is no wonder there is DisciplineEnvy when the BenefitsAreSubjective for most choices when even the BestPractices cannot be agreed upon. SoftwarePlatonism seems interesting

Too many choices is no choice at all
Questions that remain
The awful truth

A good approach to MetaDevelopment? is unlikely to come from extrapolation by architects who do not solve practical problems. The experiences of developers is far more likely to bear pearls of knowledge. The techniques used to solve problems in computer science are not applicable in the subjective abstract space of software development. Currently, experience seems to be the primary indicative factor of the correctness of an abstraction, and then only as a difficult-to-teach, informal, possibly illogical approach.

Developers must accept that standards have won for many reasons other than technical superiority. A mediocre solution implemented is still superior to an optimal solution unimplemented. Social considerations are usually more important than the technical. To avoid AnalysisParalysis, compromises must be made. A developer must have the will to take action. Hopefully that will is forged from wisdom in the fires of experience.

In the real world, will power is as powerful as thought.

Shamanism is not measured by the distance traveled, but by what is brought back

From AbstractionDevelopment: As the level of abstraction increases, meta-abstractions are needed to convey meaning. A pattern is a meta-abstraction used to convey meaning about a lower level abstraction. Therefore patterns always exist at a higher abstraction level than any abstraction it references. For any loa(n), a loa(n+1) exists that can convey meaning about loa(n)

Not always so, I think. For example it is possible to design a type system in which the types are themselves types. Compare with awareness of awareness. Want to take this shamanism meets software abstraction discussion into email? JamesCrook (crookjATindigoDOTie)

Oh...actually another mathematical principle holds here; intuitively it seems as if any space of dimension N requires a space of dimension N+1, causing an infinite sequence of dimensions. However it was proven long ago that such embedding spaces are not inherently required. This proof was very important in differential geometry (an underpinning of General Relativity) in allowing direct treatment of the curvature of space via intrinsic curvature, without reference to any embedding space.

Similarly here; if you treat a LevelOfAbstraction as a space, it does not necessarily require a higher dimensional space to contain it.

I suppose this is less directly helpful than my earlier point about the Liar Paradox, but I think it helps to keep in mind these areas where mathematics has discovered that intuition yields incorrect results.
CategoryDesignIssues CategoryAbstraction

EditText of this page (last edited June 2, 2008) or FindPage with title or text search