In the Beginning Was the Command Line (1999)
cristal.inria.fr
cristal.inria.fr
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.
For example, the work on tangible UIs eg- Self: http://www.selflanguage.org/
This is a good demo of what could be done in the Self environment: https://www.youtube.com/watch?v=Ox5P7QyL774
GUI and non-programmability are tangential things. I don't think they're implicitly bound together.
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.)
If only if you could easily pipe from one terminal to another.
[1] http://www.linuxjournal.com/content/using-named-pipes-fifos-...
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.
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.
Given, it's not exactly usable for modern projects, but it's worth studying.
(Compared to well-designed GUIs Emacs interfaces aren't very pretty, though.)
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.
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.
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.
In a CLI?
In a GUI?
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
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.
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.
When Ronald Reagan was a radio announcer, he used to call baseball games by reading the terse descriptions that trickled in over the telegraph wire and were printed out on a paper tape. He would sit there, all by himself in a padded room with a microphone, and the paper tape would eke out of the machine and crawl over the palm of his hand printed with cryptic abbreviations. If the count went to three and two, Reagan would describe the scene as he saw it in his mind's eye: "The brawny left-hander steps out of the batter's box to wipe the sweat from his brow. The umpire steps forward to sweep the dirt from home plate." and so on. When the cryptogram on the paper tape announced a base hit, he would whack the edge of the table with a pencil, creating a little sound effect, and describe the arc of the ball as if he could actually see it. His listeners, many of whom presumably thought that Reagan was actually at the ballpark watching the game, would reconstruct the scene in their minds according to his descriptions.
I'll be damned if Ronald Reagan wouldn't have made an amazing Dungeon Master.
I always think of this when I hear about programs that generate news stories from game statistics or financial reports (companies like Narrative Science or Automated Insights)
Knowing this stuff is important, because in computing, abstractions are pretty much what we do. We build them, manipulate them, argue about them, consider them harmful, and continue to travel up and down the endless stack of turtles. Knowing why the endless stack of turtles exists is important and useful, and that's part of what this essay provides.
http://garote.bdmonkeys.net/commandline/index.html
The 2004 comments are now of course 12 years old, so they're not much newer than the original text, but it's interesting to have two datapoints to draw a line between (1999 and 2004) and see where the trajectory of the future seemed to be headed over that period, versus where it actually landed.
If you enjoyed his essay, it is well worth reading Neal Stephenson's novels. I would start with Cryptonomicon or Snowcrash.
"I embraced OS X as soon as it was available and have never looked back. So a lot of 'In the beginning was the command line' is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."
https://slashdot.org/story/04/10/20/1518217/neal-stephenson-...
They actually cannot look back now. It's literally almost impossible for Stephenson and many other of our contemporaries to look back and choose another way. To do so is literally more pain than is worth. To even contemplate an alternative means negating the investment in Apple. To turn your back on the investment of time, money, effort would mean the benefits of change would need to be greater (or the pain of staying would be worse). It's not going to happen: those who embrace Apple remain within Apple's bosom.
Perhaps you'd argue that there is. In order to do so, you'd need to explain why there is a distinction to be made here between Apple and literally every other software and hardware manufacturer on the planet. That such a distinction exists constitutes an implicit prior in what you've said above. I don't agree even that that is true, let alone that it's self-evident. You have the opportunity to convince me otherwise.
Yes the core is BSD derived unix, but OSX is also a massive layer of libs on top that is proprietary to OSX.
So unless the developer takes outmost care to not touch anything that makes OSX, well, OSX, its damn hard to transfer anything over to a _nix from OSX.
Man, this Android phone I'm carrying around now is such a step down from that Newton.
I think that the message is very clear here: somewhere outside of and beyond our universe is an operating system, coded up over incalculable spans of time by some kind of hacker-demiurge. The cosmic operating system uses a command-line interface. It runs on something like a teletype, with lots of noise and heat; punched-out bits flutter down into its hopper like drifting stars. The demiurge sits at his teletype, pounding out one command line after another, specifying the values of fundamental constants of physics:
universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 1.673e-27....
But no major thread in a long time, it looks like: https://hn.algolia.com/?query=In%20the%20Beginning%20Was%20t....
So by HN's standards this isn't a dupe: https://news.ycombinator.com/newsfaq.html.