5 ms·

Reproducing an ooold comment from elsewhere https://www.reddit.com/r/programming/comments/hwnm/unix_the_hole_hawg/ci4x8 https://www.reddit.com/r/programming/com

by leoc 10y ago

Reproducing an ooold comment from elsewhere https://www.reddit.com/r/programming/comments/hwnm/unix_the_hole_hawg/ci4x8 https://www.reddit.com/r/programming/comments/hwnm/unix_the_... : 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 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=portal 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=infotech&sc=&id=11992&pg=4 http://www.technologyreview.com/read_article.aspx?ch=infotec... : > Here's the language they're proposing: You point to something and grunt.

qwertyuiop924 10y ago
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.
- pwdisswordfish 10y ago
  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.
  - qwertyuiop924 10y ago
    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.
    - rer 10y ago
      What if the data where there but not in front of their eyes. I want there to be data there.
- rer 10y ago
  How would you do GUIs to make them compose, script, and show the kind of info CLIs can?
  - qwertyuiop924 10y ago
    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.
    - rer 10y ago
      Maybe I should read the code behind Smalltalk. I'm glad the day isn't over.
    - colejohnson66 10y ago
dredmorbius 10y ago
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.
- pwdisswordfish 10y ago
  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.

by leoc 10y ago

qwertyuiop924 10y ago

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.

pwdisswordfish 10y ago
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.
- qwertyuiop924 10y ago
  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.
  - rer 10y ago
    What if the data where there but not in front of their eyes. I want there to be data there.
rer 10y ago
How would you do GUIs to make them compose, script, and show the kind of info CLIs can?
- qwertyuiop924 10y ago
  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.
  - rer 10y ago
    Maybe I should read the code behind Smalltalk. I'm glad the day isn't over.
  - colejohnson66 10y ago

dredmorbius 10y ago

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.

pwdisswordfish 10y ago
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.