Earlier quoted context omitted.
> Having to do things indirectly is not a good state of affairs. One key point to note here is that "Indirection" is often the mechanism used to design and express an "Abstraction". Given that Abstraction is the key to taming complexity and building large Systems they often go together i.e. Indirection becomes a key element in the design of Abstractions. It is only the non-designer of the Abstraction/Indirection who…
Yes and no. Yes, indirection in the source "abstraction" is the way to get to a new abstraction. However, the result has to be an actual abstraction for that to work, and it often isn't. Often it's just indirection. And once you have the new abstraction, you have to be able to express yourself using that abstraction with little or no leakage. For example, the "procedure" abstraction works that way, we really and trul…
Not quite true. "Abstraction" is what you imagine/design according to your needs and treat as a "Single Concept" (eg. a Design Pattern). The fact that it is made out of more granular elements i.e. machine instructions/language statements/procedures for a state machine does not change your ability to reason and work with abstractions at a higher level. While there maybe some "leakage" (mainly when things fail/need for performance) it is by no means total.
Also many people often equate Abstraction with Indirection since the latter is so prevalent in defining the former. But they are different concepts and have to be treated as such.