This inspired some of our design principles in the CLI Guidelines: https://clig.dev/
The CLI is the opposite of the Mac in a lot of ways -- reality instead of metaphors, remember and type instead of see and point, make it a conversation, and so on.
The CLI is the opposite of the Mac in a lot of ways -- reality instead of metaphors, remember and type instead of see and point, make it a conversation, and so on.
For me, this was the signal that this as a "if only people used computers like I personally think they should" pieces. I know lots of people who play guitar hero, lots of people who play real guitars, and some who play both (me for one, mediocrely in both cases). I have met zero people who think guitar hero = guitar. They are different things that serve different needs.
I use a cli to compute all day, every day. Can't imagine using computers without one. I have no empirical proof of this, but I would be willing to wager the deed to my house that the vast majority of users, having been explained what a cli is, the benefits of it, and how to use it, would chose to never use a CLI again. It's not what they want, it's what other people want and it's a myopic view of what computing is.
If people could understand what computing was about, the iPhone would not be a bad thing. But because people don’t understand what computing is about, they think they have it in the iPhone, and that illusion is as bad as the illusion that Guitar Hero is the same as a real guitar. That’s the simple long and the short of it.
What’s interesting is, the computational ability of an iPhone is far beyond what we need to do good computing. What you wind up with is something that has enough stuff on it and is connected to enough stuff, so it seems like the entire thing.
"A combination of this 'carry anywhere' device and a global information utility such as the ARPA network or two-way cable TV, will bring the libraries and schools (not to mention stores and billboards) of the world to the home. One can imagine one of the first programs an owner will write is a filter to eliminate advertising!"
[Kay72] "A Personal Computer for Children of All Ages"
As stated, I agree.
But "ugliness" and unfamiliarity are big confounds here.
The fairer experiment would be something like: For tasks where a CLI app is a better fit than a GUI, would a person trained in the CLI and forced to use it for, say, a day (however long it took to become comfortable and see productivity benefits) then decide to keep using it, or go back to a GUI?
Imagine an office worker and some cumbersome workflow with excel, microsoft word, and GUI folders.
I think that if one could take a sufficiently aggregated superset of that from everyone on HN, one might very well come up with a philosophy of computing that actually is quite powerful.
In general I think the idea is that the computer is supposed to be a tool, in addition to a toy; with the awareness that playing with tools is often just as much fun as any toy could be, and conversely that a toy is a powerful way to learn.
> "Because people don’t understand what computing is about, they think they have it in the iPhone"
I agree this is myopic. I can use my iPhone to do a great many computing-related tasks; and when it is insufficient, it is certainly sufficient to reach out to a bigger, more powerful machine where I can do such things. As long as we retain the powerful (and not yet enshrined) freedom to connect things together over the Internet, your "computer" is not just whatever device you hold in your hands.
Its not like shell pipelines are really pipes between two processes or a filesystem is the same as a physical system of files.
A filesystem is fundamentally a way toorganize blocks of data on a storage medium. It consists of an actual physical medium with various attributes, which is used by a rule-driven system ("the filesystem") to decide where to put data (and conversely where to find it). It doesn't actually work in the same way as a paper filing cabinet, but in most operational senses, the two things are far closer together than they are different.
The CLI is not a metaphor - it's an abstraction. It removes details that you don't need to know about (mostly), but provides you with a way to operate directly upon the objects (concepts) known to the operating system that you are interacting with.
The classic Mac desktop described in TFA does consist of a lot of metaphors. Technically one can see this clearly in the way that the kernel of macOS isn't responsible for most of the way that desktop functions today: this is left to user-space services that create higher level objects for the user to interact with, leaving the kernel to deal with the same sorts of objects you'd describe with the CLI.
Or something like that.
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)
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?
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.
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
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.
By that argument, there really is a physical object corresponding to the desktop. That, too, is made up of pieces of memory.
> It consists of an actual physical medium with various attributes
Not necessarily. I mean, yes, ultimately it does because we live in a physical reality. But ultimately even I start think about a filesystem in my head it exists on a physical medium, my brain.
Are the trees that modern filesystem usually consist of nowadays actual trees growing in my computer, or are they metaphors? Named after their biological counterpart because they roughly look and act like them in very specific aspects? Like a desktop, or a window?
Are the "folders" or "directories" that you interact with in your shell actually those pieces of objects, or are they a metaphor?
> The CLI is not a metaphor - it's an abstraction. It removes details that you don't need to know about (mostly), but provides you with a way to operate directly upon the objects (concepts)
I don't see the distinction. The desktop provides you with a way to operate directly upon the objects/concepts of the OS. In both cases, there is usually a multitude of abstractions before you reach any actual physical object.
> the way that the kernel of macOS isn't responsible for most of the way that desktop functions today [...] leaving the kernel to deal with the same sorts of objects you'd describe with the CLI
You mean the same way the kernel is not responsible for the way the CLI functions?
Why is an open() system call (which can refer to numerous virtual, abstract, immaterial things) more "real" when the piece of memory it has been passed has been collected through a multitude of abstractions and maybe originated from a sequence of keystrokes on a keyboard via USB, than if it had been collected through a multitude of abstractions and maybe originated from a sequence of mouse movements via USB?
We touch on metaphors in this section: https://clig.dev/#conversation-as-the-norm
If you’re talking about how to design a command line for usability, you really need to become familiar with them, as usability and extensibility were explicit design points and they both work very differently than (and much better than) even modern UNIX.
They should have come up in whatever literature search you did prior to writing your piece. At least you can easily investigate both of them via preserved documentation and emulators, if you don’t have access to hardware on which to run them: There’s an x86-64 build of OpenGenera floating around you can run on Linux, and you can run VMS in SIMH. And Kalman Reti did a great demo of Genera on YouTube.