The real problem with Stevenson's account is that the command line is no more the True Reality Behind Appearances than the GUI is; it's just another shadow on the cave wall. (Especially on Unix, where the shell is just another user-space program.) Eben Moglen identified the problem with the GUI (as we know it) http://www.cabinetmagazine.org/issues/1/i_moglen_1.php more precisely:
> What I saw in the Xerox PARC technology was the caveman interface, you point and you grunt. A massive winding down, regressing away from language, in order to address the technological nervousness of the user. Users wanted to be infantilized, to return to a pre-linguistic condition in the using of computers, and the Xerox PARC technology`s primary advantage was that it allowed users to address computers in a pre-linguistic way. This was to my mind a terribly socially retrograde thing to do, and I have not changed my mind about that.
I disagree. True, command lines are another shadow on the cave wall, but they're a sharper shadow: they show more of what's actually happening, and they give you tools to get more information about, as Stephenson would put it, "the tangled nam-shubs beneath." This is arguably not inherent to the command line, but it's definitely inerent to how GUIs work: GUIs cannot compose, are harder to script, and cannot show the kind of info CLIs can, if they wish to remain accessible (there's a reason there's no graphical method to get the inode number of a file). I think Stephenson expressed this quite well.
Nothing stops you from putting the inode number in a copyable field in a "file properties" window. Now, of course there is basically nothing you can do with an inode number in a graphical environment, but then there is also very little you can do with it in a command line as well. Omitting this detail is not something "inerent" to graphical interfaces.
Fair enough: for that particular detail. The point is, when UX matters, you cannot add mode switch (like command line flags), and you can't give the user all the data: their eyes would pop out. The GUI is a higher level abstraction: lack of control is the tradeoff.
This is what I like about user interfaces in Emacs. They are richer than command line interfaces as you have programmatic access to values (this gives you composition and scripting), yet they also hide information in their graphical representation bringing them closer to GUIs.
(Compared to well-designed GUIs Emacs interfaces aren't very pretty, though.)
However, GUIs are implicitly more complex than text steams. Sure, they can be programmable, and conposable, but it's an uphill battle, and CLI just does it so effortlessly.
The CLI only does so effortlessly because of all the work done to make it effortless. Pipes, string formatting, argument parsing. If the same amount of work was put into a direct manipulation GUI as was put into unix, it would be just as effortless, if not more.
Why are terminals still based on the concept of a teletype? It is fully one dimensional. You have to fit all interactions through that one dimension. (Multiple terminal windows are a kind of hyperspace, I suppose.)
I have recently found myself pondering what would have happened if a micro computer back in the BBS days could have handled access to multiple BBSs at the same time. My suspicion is that we would be looking at something very similar to what a multi-tab web browser is giving us these days.
Mmm I don't know. Self looks like yet another overdesigned thing at 100k+ lines of code that doesn't compile. After 3 mins on the site, I can't figure out the main thing it does.
Sure, the adaptive compilation is nice, and message sends and type inference, but how well do the UIs work?
It's sort of cool to see Urs Hölzle and Craig Chambers in the papers section.
I mean, it is almost 30 years old, so you have to take that into consideration. A lot of stuff had to be built from scratch.
As for what it "does", what does the smalltalk environment do? It's a combination of a programming language with graphical programming tools. It does anything it is programmed to do.
Self is the language that invented prototypical inheritance and the Morphic UI framework, one of which (morphic) is now used in pretty much all modern Smalltalks, and the other of which (prototypical inheritance) got picked up by a little language called Javascript, which you may have heard of. In addition, Self provides provisions for multiuser networked UI, kind of like Google Docs does.
Given, it's not exactly usable for modern projects, but it's worth studying.
They can't: that's the price you pay for the abstraction. Smalltalk got the closest, but if you really want to dig into a GUI, at the end of the day, you have to read the code behind it.
The Unix command line is in many (though not all) parts a way of exposing primitives of the OS itself. In a strong sense, it is a direct interface to the Unix primitives, rather than an indirect one through a layer of GUI indirection.
There are some commands which get quite close to this -- stat(1) is a wrapper around the stat(2) call, ls(1) is a way of exposing the directory structure, printf(1) is a wrapper around printf(3), and cat(1) does little but stream a file's contents -- it's providing basic file IO.
All of these are working with basic C functions and Unix system calls. There's a minimal bit of indirection, mostly concerned with how the shell itself does its parsing, around this.
Similarly, device and other management in Linux can be done directly through device files, and there's generally a very high level of transparency in this.
If I'm trying to find out what's going on in my system, I can call up utilities. Unfortunately, those change sufficiently often that I frequently find it more satisfactory to dig into /proc and /sys to find what it is I'm after.
As to the question of whether or not C and system calls are "truly" the system, that's debatable, but as with elements and atoms, they are as low-level as you can go within the system and still be dealing with the operating system itself. Below this level, you're working with machine and binary code, raw devices, and hardware -- you're no longer at the level of abstraction of the OS.
Which makes the command line a far closer approximation of the OS than a GUI. Particularly if the same GUI applies across multiple operating systems. Again, you're working now at the desktop level of abstraction rather than the OS.
How is the command line more direct than a visual file manager showing a directory as a list of files ("ls"), displaying file metadata in a file properties window ("stat") and opening files in a graphical text editor/hex editor ("cat")? How is printf(1) an interface to the operating system? It's just a helper command for manipulating text, which in a graphical interface is unnecessary.
Also, remember that part of the reason the Unix command line matches the underlying operating system primitives so well is because many of them were in fact designed to provide better support for command-line interfaces. In a graphical environment, concepts like "the current directory of a process", or its "controlling terminal", or "session ID", or distinctions between SIGSTOP and SIGTSTP, are superfluous.
Your second paragraph largely answers your first. The command line and system calls are strongly aligned. GUIs are not, and present an entirely new metaphor.
Stephenson describes the problems of GUI interfaces in terms of "metaphor sheer", a beautiful phrase.
There's another essay on interfaces, which I cannot presently place, that describes the situation in another way -- that the GUI folder, and colour, and listing, and columns, aren't themselves representative of how the OS sees or organises its content, nor do the actions a user practices on the desktop correspond in large part to what's happening at the underlying level.
And it's not as if all GUIs are necessarily bad. Another reference I cannot place -- a conference presentation of programming concepts in which a simple game was developed and an algorithmic landscape with a tree, flowers, and moon designed, shows how GUIs can be tightly linked to the underlying code.
But the key again is that the metaphors at each layer must be aligned, in ways that most visual computer metaphors are not. I find myself, when using computers, constantly having to second-guess the system, and in particular, if I know how the plumbing is connected, think in terms of "well, I want X, and have Y, but it's wired through Z, so ..." Which actually makes my cognitive process more complicated. As well as removing much the power of textual tools to perform innate looping or mass operations.
Not really. The text-mode shell presents you with a hierarchical file system where "files" are organised in a tree of "directories" and can be opened in various programs --- and so does your typical GUI. The only new thing added by the GUI are interaction and composition paradigms; e.g. windows, letting you simultaneously operate several programs (directly), and the clipboard replacing pipes. The features mentioned in my previous post are mostly implementation details and could just as well be moved to userspace; they hardly demonstrate some inherent "directness" of the command line.
Quite simply, this concept stumps and frustrates me endlessly in GUIs, and I almost always resort to a commandline.
In a CLI, a filename is simply an argument to the command you offer, and your thinking is command-specific. "How do I process this data?"
In a GUI, the filename is front and center, and the logic is one of "I need to open file X", with the application being dictated by some attribute of the file -- and at worst, the file's extension, something which is highly subject to external manipulation.
There are cases where those bindings are fairly strict -- only a single program can meaningfully interact with a file's content. This is often the case in GUI contexts, examples being Microsoft Office file formats (see a related ongoing discussion on that topic), some project-related tools such as Autocad, Photoshop, project planning tools, or medical imaging systems. But that's a deliberate choice of tool designers.
In a workflow I'm familiar with, I edit text files in specific formats with various editors (GUI tools, vim, emacs), process those to produce desired conversion or end outputs (Pandoc, latex, etc.), and can view the finished results in any of numerous tools, or process those further.
The GUI doesn't entirely limit the user to a single application operating on a file, and it can make the process somewhat simpler in terms of "what do I use to open this file" (though there are CLI tools which achieve this as well, "open" on OSX and some equivalent commands, though I use them so infrequently I can't recall them at the moment, on Linux), through standard file associations. It is possible to override those defaults, but it's difficult and cumbersome, particularly when interacting with multiple files.
And what the GUI does not support except in the most tedious way is the concept of operating on many files with many programs in a systematic way.
You may not need this in your world. Most people may not. But for me, the construct of:
for file in $( list-generating command )
do
process1 | process2 | ... | process n > $file.out
done
is something that's very high on my list of tools. The more flexible in that I can supply arguments, filters, input and output files, and processing logic, on a single command line. That's a loop which might have a handful of arguments or millions, and I've used it across that spectrum (though generally with some form of parallelisation in the latter case, also fairly trivially supplied).
And I can develop (and test) the processing iteratively, in terms both of inputs (one or a small set of files at a time) and processing (adding to the set of manipulations) through my CLI editing capabilities (bash readline and command editing).
The process is powerful, adaptable, flexible, and quite literally allows me to do in seconds what would take hours on a GUI, or in a day or two of unattended operation what would take years of penny-ante error-prone interactive work.
That is where the GUI and CLI metaphors start departing rapidly, and it's why I find myself cursing and screaming at systems, such as my complete piece-of-shit Samsung Galaxy Tab A 9.1" Android tablet, for the multiple ways and means in which the UI and OS simply gets in my fucking way for doing the shit I want and need to do.
It's a capable piece of hardware. But for the entirely self-serving choices of Samsung and Google, it is crippled beyond any and all possible forgiveness. And cannot be adapted to those useful purposes due to further lock-down on the device itself (I've wasted days of my life trying).
Not all of those limitations are specific to the GUI, but the limitations of the GUI leave me looking for CLI alternatives which cannot be applied thanks to yet more limits on the system, making me all the more painfully aware of the original set of insults.
In a GUI, you can right-click on the file icon and select "Open with another application" from the menu. What's your point?
You criticise point-and-click GUIs for poor composability and programmability. Those are valid criticisms; nobody seems to have figured out how to implement these qualities well in a pure point-and-click interface, and this will perhaps never happen. But these criticisms have nothing to do with directly reflecting the abstractions offered by the operating system. The GUI offers access to the same abstractions; it's manipulating them that is different.
And the Unix command line is not particularly well-designed either. I can already spot a potential bug in the sample you gave: what happens if your list-generating command outputs a file name containing a space? (Don't answer "don't use spaces, then"; it's as valid character as any other.) You probably know how to fix this mistake, but have you thought why you made it in the first place? It is a consequence of one of the poorer choices in the design of Unix: basing IPC on text streams that each program has to parse and serialise on its own.
The real problem with Stevenson's account is that the command line is no more the True Reality Behind Appearances than the GUI is; it's just another shadow on the cave wall. (Especially on Unix, where the shell is just another user-space program.) Eben Moglen identified the problem with the GUI (as we know it) http://www.cabinetmagazine.org/issues/1/i_moglen_1.php more precisely:
> What I saw in the Xerox PARC technology was the caveman interface, you point and you grunt. A massive winding down, regressing away from language, in order to address the technological nervousness of the user. Users wanted to be infantilized, to return to a pre-linguistic condition in the using of computers, and the Xerox PARC technology`s primary advantage was that it allowed users to address computers in a pre-linguistic way. This was to my mind a terribly socially retrograde thing to do, and I have not changed my mind about that.
(Which seems a fairer comment on the Lisa or Macintosh than the [2016 edit: LRC work] at PARC, where they were trying to teach children to program http://portal.acm.org/citation.cfm?id=155364&dl=ACM&coll=por... .)
In Doug Engelbart's words http://www.technologyreview.com/read_article.aspx?ch=infotec... :
> Here's the language they're proposing: You point to something and grunt.