The word reify/reified/reification is used 19 times in this article (which to me suggests the meaning of this particular word is quite important), and I’m not sure I agree with the author’s usage of it. My understanding of the word reify is to make a concrete implementation of an abstract idea or data model. I’m finding it hard to stretch this definition to fit the ideas the author is describing.
I tried to learn if this word might be interpreted differently in a design or human-computer-interaction context, but if this word just means to “thingify” something abstract like a work practice, then I don’t understand the distinction the author is making between CLIs and GUIs. In fact, the author seems to almost immediately totally contradict themselves in the conclusion with these two pull-quotes; emphasis my own:
A unique advantage that CLIs typically offer over GUIs is that the interaction between user and computer is reified
The reification of interaction is, however, not fundamentally limited to CLIs, and the concept may just as well be applied to GUIs.
The word “reify” is used broadly enough that I don’t think the author’s use is too much of a stretch.
Also, I think the author was mistaken in using “unique advantage”, because the rest of the article makes it pretty specific that they really mean “the default behaviour.” GUIs interactions can be reified, but shell commands are reified by default, because the shell itself takes care of it.
I agree. I think I get what the author is trying to express, and I think persistent is a much closer word. Previous interactions remain on the “screen” (sometimes you have to scroll up), .bash_history and all that.
To me, for a CLI to reify the UI, it would have to do something like create ~/.interactions/ and save each interaction as a file (or a directory of files) so I can look at ~/.interactions/last/command much like !!. You know when the CLI doesn’t reify? when output scrolls off the screen, and your output buffer is too small, and the command you want is in another bash terminal, when you accidentally paste hexcode and you need to reset the window. And the bit about copy/paste is extremely limited on the command line without GUI niceties like mouse selection.
CLIs are documented UIs, sure maybe. CLIs are persistent UIs, sure. But not reified.
UI discoverability is orthogonal to {G,C}UI IME. I’ve seen great documentation come out of --help and man pages, and I’ve seen baroque and opaque GUIs.
I don’t think this is true. The default for GUI is a bunch of buttons you can click to see what happens. The default for CLI is a blank screen. Using a manual (–help) as a counter example isn’t arguing for CLI, but arguing for good manuals.
When you are in a french bakery, pointing at a croissant is using a GUI, and trying to say things randomly hoping to make sense is using a CLI. Clearly one is superior to another, both in immediate usability, and discoverability.
The default for GUI is a bunch of buttons you can click to see what happens.
Not necessarily for three reasons:
Menus. GUIs tend to have menus, and menus are not discoverable unless you and the developers spontaneously develop the same ontology and, therefore, classification scheme for the program’s functionality. Conventions help, but conventions apply to CLI programs, too.
Buttons need to be labeled somehow, and iconic labels tend to verge on the pictographic. Even textual labels can be hard to decipher, but the trend is towards images, which are smaller and (supposedly) don’t need to be translated for different audiences.
The increase of mobile UIs as being the new default for GUIs means fewer buttons and more gestures, and gestures aren’t signposted. Can I pinch something here? Do I need to swipe? Is this operable now? Do I need to long-touch it or caress it in some other fashion? It might be good for you, but it’s remarkably inscrutable as opposed to discoverable.
I disagree here. Going through the menus to see what options you have is a pretty common thing to do.
The increase of mobile UIs as being the new default for GUIs
But the mobiles GUIs are not discoverable the same way CLIs are not discoverable. There are no buttons and you are supposed to know what to do (the right incantation or the right gesture). But even then swipe and pinch are more intuitive than shlib -m -t 500
I disagree here. Going through the menus to see what options you have is a pretty common thing to do.
Every user I have had an interaction with never looks through the menus; I can for certain tell you nine out of every ten people I work with are unaware the menu bar exists for the majority of executables they use and if they are aware of its existence its only to click something they have been shown how to use; they will rarely venture far from that well trodden path and its frustrating as a little bit of curiosity would have solved their question before they asked it.
#3 is the big one for me. I have no idea how to use most mobile apps. Whereas with a well-designed CLI I can mash TAB and get completion at its repl or through its shell completion support, and work out what the thing can do.
A GUI is immediately useable in that you can see buttons and other widgets, and with the mouse you can point and click. However for GUI’s, as they are mostly implemented in todays world, the advantage stops there. There is no next step in that you can improve your mastery, possibly except for your mastery of mouse precision and keyboard shortcuts. However in CLIs, as they are today, there is a steep curve to getting started, however because of certain properties of the CLI, as the article mentions, when you have interned those key principles, the sky is the limit.
GUIs are excellent for basic usage, but doesn’t allow any kind of mastery. CLIs are tough to get started with, but allows all kinds of mastery. That’s a key distinction. However I don’t think those properties are inherent to “GUIs” and “CLIs”, it’s just inherent in the way they have been implemented in our current software landscape.
In CLIs the user interacts with the computer by sequentially typing various textual commands, to which the computer replies, also in text. Graphical interfaces base the interaction with the computer on graphical icons and widgets and navigation typically depends on a pointing device such as the mouse.
This is a bit arbitrary. Does reading my email with mutt really consist of “sequentially typing various textual commands, to which the computer replies, also in text”?
I think most of the “command line” apps nowadays are really GUI apps rendered on a text grid…
How about:
CLI: true “sequential typing of various commands” eg bash, ed, core unix utils, nmh
TUI: 2D text grid based UIs, eg vim, emacs, mutt, links
GUI: 2D bitmaps, mouse input, Xerox Parc heritage widgets like menus, eg Classic Mac OS, Windows95
Pen: pen based input on 2D bitmap, eg Newton
Touch: finger based gestures on 2D bitmap, eg Android, iOS
I think a main distinguishing feature for GUIs vs CLIs is who uses which. If the same crowd that uses Emacs or Vim would use (and contribute to) more GUI software, it would quickly grow to support pervasive scripting and history.
Many parts of at least GUI emacs is very GUI-like - it has buttons, advanced interfaces like magit, and so on. Obviously it’s not all “GUI-like”, but I do think that Emacs is a good example of what happens if the people that use CLI creates GUI software. The only limiting feature is that Emacs was made a long time ago, and its scars reveals that.
I’m not sure about that, it would require the right design to begin with for a certain mentality to want to contribute without losing the legacy they already are proficient in. I’m not sure how a GUI awk would look like in our GTK/Qt/Electron world, if anything because you’ve always got those who have to go out of their way to create a “innovative” look and feel. HTML is probably the closes we’ve gotten to anything like this in real world applications, when considering user scripts, though I don’t think it was worth it.
Reading this, it occurs to me that one of the secret strengths of Emacs is that it too reifies user interaction: every single thing you see happen on-screen is a Lisp command which the user can look up, read documentation on, read source of, edit and override (there are some low-level parts of Elisp written on C, but even those can be read, edited and changed, albeit with more difficulty).
The advantages are all those indicated by the article. And, as the article notes, one is not limited to using a command line to enjoy them (although a Lisp REPL can be a powerful way to do so).
The word reify/reified/reification is used 19 times in this article (which to me suggests the meaning of this particular word is quite important), and I’m not sure I agree with the author’s usage of it. My understanding of the word reify is to make a concrete implementation of an abstract idea or data model. I’m finding it hard to stretch this definition to fit the ideas the author is describing.
I tried to learn if this word might be interpreted differently in a design or human-computer-interaction context, but if this word just means to “thingify” something abstract like a work practice, then I don’t understand the distinction the author is making between CLIs and GUIs. In fact, the author seems to almost immediately totally contradict themselves in the conclusion with these two pull-quotes; emphasis my own:
The word “reify” is used broadly enough that I don’t think the author’s use is too much of a stretch.
Also, I think the author was mistaken in using “unique advantage”, because the rest of the article makes it pretty specific that they really mean “the default behaviour.” GUIs interactions can be reified, but shell commands are reified by default, because the shell itself takes care of it.
I agree. I think I get what the author is trying to express, and I think persistent is a much closer word. Previous interactions remain on the “screen” (sometimes you have to scroll up), .bash_history and all that.
To me, for a CLI to reify the UI, it would have to do something like create ~/.interactions/ and save each interaction as a file (or a directory of files) so I can look at ~/.interactions/last/command much like
!!. You know when the CLI doesn’t reify? when output scrolls off the screen, and your output buffer is too small, and the command you want is in another bash terminal, when you accidentally paste hexcode and you need to reset the window. And the bit about copy/paste is extremely limited on the command line without GUI niceties like mouse selection.CLIs are documented UIs, sure maybe. CLIs are persistent UIs, sure. But not reified.
GUI are superior sometimes. One aspect - better feature discovery and less learning how changing one thing affects the others.
UI discoverability is orthogonal to {G,C}UI IME. I’ve seen great documentation come out of
--helpand man pages, and I’ve seen baroque and opaque GUIs.I don’t think this is true. The default for GUI is a bunch of buttons you can click to see what happens. The default for CLI is a blank screen. Using a manual (–help) as a counter example isn’t arguing for CLI, but arguing for good manuals.
When you are in a french bakery, pointing at a croissant is using a GUI, and trying to say things randomly hoping to make sense is using a CLI. Clearly one is superior to another, both in immediate usability, and discoverability.
Not necessarily for three reasons:
I disagree here. Going through the menus to see what options you have is a pretty common thing to do.
But the mobiles GUIs are not discoverable the same way CLIs are not discoverable. There are no buttons and you are supposed to know what to do (the right incantation or the right gesture). But even then swipe and pinch are more intuitive than shlib -m -t 500
Every user I have had an interaction with never looks through the menus; I can for certain tell you nine out of every ten people I work with are unaware the menu bar exists for the majority of executables they use and if they are aware of its existence its only to click something they have been shown how to use; they will rarely venture far from that well trodden path and its frustrating as a little bit of curiosity would have solved their question before they asked it.
#3 is the big one for me. I have no idea how to use most mobile apps. Whereas with a well-designed CLI I can mash
TABand get completion at its repl or through its shell completion support, and work out what the thing can do.Leave out “well-designed” and you’re back in pinch-bash-swipe land on your CLI as well.
A GUI is immediately useable in that you can see buttons and other widgets, and with the mouse you can point and click. However for GUI’s, as they are mostly implemented in todays world, the advantage stops there. There is no next step in that you can improve your mastery, possibly except for your mastery of mouse precision and keyboard shortcuts. However in CLIs, as they are today, there is a steep curve to getting started, however because of certain properties of the CLI, as the article mentions, when you have interned those key principles, the sky is the limit.
GUIs are excellent for basic usage, but doesn’t allow any kind of mastery. CLIs are tough to get started with, but allows all kinds of mastery. That’s a key distinction. However I don’t think those properties are inherent to “GUIs” and “CLIs”, it’s just inherent in the way they have been implemented in our current software landscape.
This is a bit arbitrary. Does reading my email with mutt really consist of “sequentially typing various textual commands, to which the computer replies, also in text”?
I think most of the “command line” apps nowadays are really GUI apps rendered on a text grid…
How about:
Then the various 3D UIs.
I wouldn’t consider Mutt (or Pine, or top, or Vim) command-line applications. You can start them from a command line, but so can you with Firefox.
I think a main distinguishing feature for GUIs vs CLIs is who uses which. If the same crowd that uses Emacs or Vim would use (and contribute to) more GUI software, it would quickly grow to support pervasive scripting and history.
Many parts of at least GUI emacs is very GUI-like - it has buttons, advanced interfaces like magit, and so on. Obviously it’s not all “GUI-like”, but I do think that Emacs is a good example of what happens if the people that use CLI creates GUI software. The only limiting feature is that Emacs was made a long time ago, and its scars reveals that.
Emacs is GUI software! It can be profitably used using just the menus and toolbar. I turn them off, but I imagine many people never do.
I’m not sure about that, it would require the right design to begin with for a certain mentality to want to contribute without losing the legacy they already are proficient in. I’m not sure how a GUI awk would look like in our GTK/Qt/Electron world, if anything because you’ve always got those who have to go out of their way to create a “innovative” look and feel. HTML is probably the closes we’ve gotten to anything like this in real world applications, when considering user scripts, though I don’t think it was worth it.
I think Applescript (on Mac) or ARexx (on AmigaOS) are better real-world applications. HTML with user scripts is basically screen scraping.
Reading this, it occurs to me that one of the secret strengths of Emacs is that it too reifies user interaction: every single thing you see happen on-screen is a Lisp command which the user can look up, read documentation on, read source of, edit and override (there are some low-level parts of Elisp written on C, but even those can be read, edited and changed, albeit with more difficulty).
The advantages are all those indicated by the article. And, as the article notes, one is not limited to using a command line to enjoy them (although a Lisp REPL can be a powerful way to do so).
@monokrome made a comment but it was posted to another thread: https://lobste.rs/s/1qmlfh/today_s_javascript_from_outsider_s#c_wfzqmo