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.
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.
Reagan wasn't the only one doing this; this is how radio broadcasting worked (essentially they functioned as human repeaters, and decompressors of lossy compression).
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)
IBWCL is dated, true, but it's still an excellent essay, and I would argue required reading for anyone learning about programming, computing, and/or UX/UI. If nothing else, it provides an excellent understanding of what abstractions are, and what sort of tradeoffs you make by using one, while still being more or less comprenhensible to the layman, unlike Steve Yegge, who covers more programming-specific topics, although often of the same nature.
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.
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.
The description of emacs never fails to make me smile: "emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish"
This essay set me off on an Odyssey of discovery and exploration. I learned emacs, Bash, gained an appreciation for abstractions in a mindset strongly influenced by this philosophy.
If you enjoyed his essay, it is well worth reading Neal Stephenson's novels. I would start with Cryptonomicon or Snowcrash.
From a Slashdot interview with Neal Stephenson in 2004:
"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."
Many people since 2004 have "embraced" the whole Apple ecosystem of tools, hardware and software.
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.
What? Did Sierra stop being Unix and nobody's mentioned it before now? Or is there something about owning a MacBook Pro that makes it impossible ever to buy a Thinkpad again? Something about owning an iPhone that makes Android unimaginable?
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.
The key part of my comment was the "embracing the _whole_ ecosystem" (whole) In other words, if you are with Apple 100% it is actually much harder to buy a Thinkpad again, because it hurts your investment in the brand.
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.
In other words, writing portable software is harder than writing non-portable software. Fair, but I don't see what it has to do with the matter at hand.
What I think in the beginning was a stack of cardboard with holes in it. I remember talking with old programmers in my first job who started out programming with switches, who by that point in the early 80's were using terminals to write batch programs with one compile-run cycle per day (they usually worked on multiple apps at a time this way). You won't catch me lamenting progress.
Dang. What great writing! Descriptive, interesting, inspiring. It just makes me smile and I'm glad this was shared. It seems like a classic that lots of people are familiar with, but I've never read it before.
I first read this essay as an ebook on my Newton (what was the 3rd party tool? Paperback?), and the title mislead me to believe I was reading Cryponomicon, so I was highly surprised when I read the actual Cryptonomicon.
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:
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.