Ya. My brain is all thumbs when trying to handle the philosophy parts of software.
Both this OC and the wiki article on 'abstraction', wrt to software design (eg OOAD) make me think of generalization and specialization.
--
My own working definition of 'abstraction' vs 'mental models', because I lack more proper terms:
- abstractions hide details, aka black box
- mental models explain how something works, even if over simplified
An example of a good (quite useful) abstraction is the initial Java Virtual Machine. Its 'interface' (per this OC) is quite good, meaning comparatively small impedance mismatch, and acceptable 'leakiness'. As we've seen over time, driven by optimization, that abstraction is necessarily bypassed or mitigated with JMM, FFI, unsafe stuff, intrinsics, direct memory, etc.
Using an example of a mental model from my prior works, because I'm precaffeinated, and I can't think of a better example than Newtonian mechanics, already mentioned.
I used to work in print production, like books and magazines. For bookwork, I created an algorithm for the folding of big sheets of paper into 'signatures' containing printed pages. My app accounted for folds, binding, and cutting. It revealed the manufacturing process, so there could be no mistake. It reduced an Illustrator-like application (ScenicSoft' Preps imposition app) to a simple form. This simplification was possible because I had invented a better mental model.
I think of things in terms of abstractions and models. Abstractions generalize commonalities into a vocabulary that can be used on any entity that is covered by the abstraction. A sequence is an abstraction, but data structures themselves aren't as far as software is concerned. Data structures can be sequences, but you can't create a sequence.
A (logical) model is a simplified representation of the real thing that is still complete enough that it can be used to successfully reason about and accomplish goals with a system. A linked list datastructure is a real thing with a number of possible implementation details, but it still has a straightforward, concrete model of what it is. It's not an abstraction.
A model does not have to be abstract at all; it can be very concrete, even if it in practice hides some underlying details.
It seems common in software to either get lost in abstraction so that you forget the model, or consider the model so rigid that you miss useful, simplifying abstractions.
Both this OC and the wiki article on 'abstraction', wrt to software design (eg OOAD) make me think of generalization and specialization.
--
My own working definition of 'abstraction' vs 'mental models', because I lack more proper terms:
- abstractions hide details, aka black box
- mental models explain how something works, even if over simplified
An example of a good (quite useful) abstraction is the initial Java Virtual Machine. Its 'interface' (per this OC) is quite good, meaning comparatively small impedance mismatch, and acceptable 'leakiness'. As we've seen over time, driven by optimization, that abstraction is necessarily bypassed or mitigated with JMM, FFI, unsafe stuff, intrinsics, direct memory, etc.
Using an example of a mental model from my prior works, because I'm precaffeinated, and I can't think of a better example than Newtonian mechanics, already mentioned.
I used to work in print production, like books and magazines. For bookwork, I created an algorithm for the folding of big sheets of paper into 'signatures' containing printed pages. My app accounted for folds, binding, and cutting. It revealed the manufacturing process, so there could be no mistake. It reduced an Illustrator-like application (ScenicSoft' Preps imposition app) to a simple form. This simplification was possible because I had invented a better mental model.
--
My working definition of abstraction doesn't jive with anyone else's. I'm open to alternate suggestions. https://en.wikipedia.org/wiki/Abstraction