Writing that on my wall.
Over the past year, I have revisited the SICP [0] and the audio recording of a one-week short course that Hal Abelson and Gerry Sussman taught for HP [1]. You nailed it.
[0]: "The Structure and Interpretation of Computer Programs", https://en.m.wikipedia.org/wiki/Structure_and_Interpretation...
(see also https://github.com/sarabander/sicp )
The fundamental abstraction/metaphor of the CLI is the file (especially in unix), where for a graphical system it is the "window". But the window has always been a weak metaphor. Windows are nothing like the thing outside the computer. Nobody understands them to be metaphors to physical windows. They are much closer to the computational object they represent (an area of i/o) than they are to a real window. Files on the other hand, are like their physical non computer counterparts. They are in fact much closer to real files than they are to a filesystem that's divided up into sectors or whatnot and distributed in the disk.
Does that mean from this definition, cli's are the metaphors and window systems are the abstraction?
But yes, it is also an abstraction of a set of related functions that manipulate or show data. It is even necessarily an abstraction of the computational objects it represents. But the sign(s) of the window points to physical/metaphorical objects.
Now the name "file" is also a metaphor. It represents (abstracts) a block of physical memory. But "file" is (or was) a sign for a physical thing made out of paper.
The metaphor of a file is on one hand useful, as it helps to understand physical memory as a set of objects we relate to in the outside world.
However it is also misleading: A real world file is typically immutable, to a high practical degree at least. We usually don't change files outside of correcting mistakes. We just add them and put a date. The file is first in "working" mode, then it is "done" quasi forever. To achieve the same with the computational object we need to impose constraints and/or discipline.
A pipe in the Linux kernel is a real thing. The name is metaphorical because it’s supposed to evoke the image of things flowing through it but that’s where it ends. A Linux pipe makes no effort to pretend that it behaves like a physical pipe. But it does abstract the implementation details about how data is sent to and retrieved from it.
An email program where the user is shown sheets of paper and envelopes is an illusion. The underlying implementation now has to modify its behavior to fit the physical properties of paper and envelopes to some degree. Letters only have one destination, CCing and BCCing now means copying and sending bundles.
It's all abstract, it's all metaphors.
You should be able to, though. The pipe has a (OS) memory location, which, after a bunch of redirections, is an absolute location in memory, which is a bunch of capacitors and transistors. Now, you could argue that those redirections are akin to metaphors, though.
Except if they're just transistors because the representation of the pipe is sitting in static RAM for some reason, or in the fluctuation of a magnetic field. Or all of the above at the same time (caches, page files). Which one is the "real", non-metaphorical representation of the pipe? The one in the cache because it's being worked on by the CPU? The one in memory because its lifetime is longer?
This may be true of our perception of “real life” too, of course, in which case computer interfaces are not something different, just an extra couple of layers
If you open up your computer and get out your microscope, you're not going to find the pipe.
Computers are metaphors on top of metaphors. There's nothing wrong with that but you have to go way way down the abstraction tree before you are dealing with anything "physical"
> The CLI is not a metaphor - it's an abstraction.
I'm unconvinced there is a difference (other than abstractions being hardcore)