4 ms·

Strongly disagree. GUIs are just a distraction. The same CLI knowledge can be used to write scripts for common tasks. GUIs don't add any value beyond visually

Strongly disagree. GUIs are just a distraction. The same CLI knowledge can be used to write scripts for common tasks. GUIs don't add any value beyond visually showing some structure, but CLIs can do just the same and often do. Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is?

massysett 4y ago
> Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Browsing photographs.
jerpint 4y ago
I used to be of this opinion. Now I think more “GUIs are great once you’ve mastered the CLI and know what underlying operations you want to execute”. A GUI I discovered recently that I really like is docker-desktop. I used to do everything from the CLI. The gui gives me a much better overview of everything. If I need to dive in to the CLI, I know exactly where to go.
- vaughan 4y ago
  The problem is that when you need to perform a task on some data being rendered by the GUI that is not supported by the GUI. Usually bulk tasks. Like, for all your docker containers, run a certain command. A compromise is that GUIs should print the commands that can be run to get the output they are rendering and to perform the actions they are doing. Like a little command palette at the bottom of the window. Then the user can always break out into terminal.
vaughan 4y ago
The other day I was doing some `make` stuff. I was passing in a bunch of env vars and flags. I wanted to tweak them between each run. I would have preferred to have check boxes to enable/disable certain flags. Rather than copying into Then in the output, I have a bunch of make tasks and child make files running. I care about the output for each makefile as it runs, but then would prefer it to collapse when its finished. Otherwise its too difficult to see each step of the build process. A terminal cannot do this. XCode does it kind of well. At the end of build too, when it reports errors, I'd like to jump up to the errors. Almost every command output I would prefer to view as a GUI table or as a webpage. The problem is that then, instead of just printing output, now I am dealing with a huge mess of frontend frameworks and build toolchains.
ovao 4y ago
One example that comes to mind is a GUI for interactive rebasing, which lets you re-order commits with a drag-and-drop interface. I’m thinking specifically of the one that (I think) is included with the Git ReFlow VS Code extension. True, a CLI tool could be made to mimic the same thing the GUI variant does in most respects, but at that point you’ve simply re-implemented a GUI, just with all the interface restrictions imposed by the shell. I’d agree that apps in general should promote some level of scriptability, and letting users drop down into the CLI is a great option for that. I’d just make an argument for giving CLI users an option to “rise up” to a GUI where it makes sense.
- suprfnk 4y ago
  > One example that comes to mind is a GUI for interactive rebasing, which lets you re-order commits with a drag-and-drop interface. With `git rebase -i <some_commit>` on the command line, you get a list of one commit per line which are trivial to re-order in a text editor. It's probably faster than a GUI too, if you're at least a bit efficient in a text editor. --- This is not to say that there aren't valid uses for a GUI, I think there are, but re-ordering commits is not one of them, I'd say.
yakubin 4y ago
Debuggers. A GUI debugger can show you a watch window with some variables and you can see it change in real time as you step through code, without you having to explicitly run the print command on each step for each variable, and without leaving a mess of historical values on your screen. Thanks to that, observing state as it changes costs less effort. Instead of manually asking all the time, you passively observe. It means greater productivity for the user of the debugger. And it goes beyond the watch window: source preview, disassembly, registers, hexdump of memory… And obviously: editors. Unless you’re using ed, everybody’s using GUI or TUI editors. And TUI is just a poor man’s GUI. All the benefits of CLIs are gone, while the things GUIs are good at are degraded. Not to mention anything related to graphics, photography, video…
- vaughan 4y ago
  I think what we need is unix/shell-like GUI. CLIs all have the same consistent user interface. Positional arguments, flags, and text output. On unix-like envs they also have pipes. This is why people like them. This is what makes people productive in them. Sure, modern GUIs have a few shared UX paradigms, but largely they are all different. I wonder how the unix philosophy applies to GUIs? Or what the early developers thought about it. How would piping work in a GUI.
  - thesuperbigfrog 4y ago
    You might find Rio interesting: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system)
  - ogogmad 4y ago
    There was a GUI at some point - in an old rarely used OS - that allowed you to use point and click to connect the output of one text box into a form field. Found it. Doesn't work quite how I expected it: https://en.wikipedia.org/wiki/Pipeline_(software)#Pipelines_in_GUIs https://en.wikipedia.org/wiki/Pipeline_(software)#Pipelines_...
- vaughan 4y ago
  Debugger is also an interesting example. In IntelliJ, when using the debugger I've often use the command line interface too. Sometimes I have been debugging something and I wished I could use a Node.js script to automate some stuff. Or I wished I could pipe the output through a Node script. The way the debugger is implemented in IntelliJ makes this a little difficult. Certainly not as easy as piping. I think this is because it uses the gdb machine-interface API which is different to the text command one. For source control, IntelliJ does actually print all the git commands it is running which is nice.
dtgriscom 4y ago
> GUIs are just a distraction. That's an unnecessarily polarizing statement. No one paradigm serves all needs. I use GUIs if the tool needed is complex, and I'm not familiar with it; a well-done GUI is much more discoverable than a CLI. I also use GUIs if the output is more than one-dimensional. Image editors is an obvious case, but how about spreadsheets? And, I love SmartGit because it shows the log and diffs in a much more intuitive and interactive way than even tig. Note that I'm a bash-boy from way back, and spend time every day using it, interactively and in scripts. CLIs are great when they match my tasks. But they aren't the be-all and end-all. Beyond the differences in task, I'm sure there are people whose needs are consistently best-served with CLIs (you sound like one). Just like there are people who consistently go to GUIs for their tools. So: just because you view the world of tools in a certain way doesn't mean everyone else should as well.
- vaughan 4y ago
  Git is a good example because most tools will have a command-palette that prints out the git commands they are running to retrieve data to render. Otherwise they are using libgit2. It's interesting to think about the difference between an API as a library vs CLI / REPL. Often when I am building a library, for testing I usually would like almost every function to be runnable as a CLI. Anytime someone is doing some piping (joining commands) or shell-scripting, it usually could also be its own script with a CLI. Many applications could also just be shell scripts piping stuff together which I think is actually what the unix people envisaged. Starts making you ask: why are some things CLIs and not everything. Lots to think about...
- ngcc_hk 4y ago
  Yes. Once again And not Or. even playing game you use keyboard a lot. Not just the graphic input, even you live in a graphic world. So is editing etc. both.
anthk 4y ago
Diffs.
ogogmad 4y ago
Advantages: - Drag and drop - Discoverability of features - Higher density of information - Changes can be seen instantly - The use of a mouse or stylus when it's natural How are you going to use Photoshop or Illustrator from the CLI? (Or Gimp and Inkscape.)
- mellavora 4y ago
  cp is faster than drag-and-drop, especially when operating on multiple files (i.e. cp myphotos/2022-11-* someplace/)... vs drag and drop, where you need to open both locations in windows, select the files in one, and drag it to the other. Then probably close one of the windows. Command-line is also discoverable, just not by the 'click on this' mentality, you have to be more curious. Which might be the better way to learn. You might be right about higher density of information, but do you get to choose the information? vs i.e. ls, ls --color, ls -lht, ... How quickly can you change between different representations? i.e. find big directories by du -h | sort -h Changes can be seen instantly in the CLI, I don't understand what you meant by this. The use of a keyboard when it is natural. imagemagick With the added advantage that all of the above, because it is text-based, is: recordable, repeatable, searchable, scriptable. GUI, not so much.
dahart 4y ago
> Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Dunno if you’re just having some Thanksgiving fun, since the question of GUI vs CLI is mostly settled and moot, and this debate is irrelevant, but I’ll take your comment literally and respond as though you are serious. So are you taking about shells, or any programs at all? Are you talking about programmers or all software users? What makes a GUI, exactly? (Are text menus CLI or GUI? Is CLI defined by REPL? Is Logo a CLI or GUI? What about vi, nano, or ddd?) Speaking as someone with a lot of love for the shell, and few decades of experience with it, it seems to me like your question assumes a rather extreme position that doesn’t seem to be well supported by most people’s usage, even if we’re talking only about programmers. If the CLI is strictly better then why do people tend to prefer GUIs? That question needs a serious answer, ala Chesterton’s Fence, before dismissing GUIs. Make sure to thoughtfully consider learning curve, effort, discoverability, prior knowledge requirement, overall task and workflow efficiency, etc. Web browsing, such as visiting HN and commenting, is much much better in a GUI browser than via manually typed curl or wget commands. What if you had to send POST requests to get your comment up? What if people had to send GET requests to know your comment existed, and then another one to retrieve it? We wouldn’t even be chatting if this was a CLI, right? More or less all artist tools are better as GUIs, from Photoshop to video editing to 3d modeling to animation. If the output is graphical, then there’s no way around a graphical interface. Using the CLI for this isn’t just tedious and expensive, it’s far less efficient and effective. Text editors are not CLI REPLs, even vi and nano. Spreadsheets are all GUI. Desktop OSes are GUIs. Smartphones are GUIs. (Imagine making calls via CLI!) Programming GUI IDEs can be extremely effective, especially when refactoring and debugging. There’s also a gray area of text based GUIs in the console window, like nano and GBD’s TUI mode, just for two examples. Even in CLI-land these things are easier to use and more efficient for some tasks than a pure REPL with text commands. Could you maybe explain why you claimed a GUI has no value? Are you aware of the history of debate on this topic, and of academic research on this topic?

massysett 4y ago

> Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Browsing photographs.

jerpint 4y ago

I used to be of this opinion. Now I think more “GUIs are great once you’ve mastered the CLI and know what underlying operations you want to execute”. A GUI I discovered recently that I really like is docker-desktop. I used to do everything from the CLI. The gui gives me a much better overview of everything. If I need to dive in to the CLI, I know exactly where to go.

vaughan 4y ago
The problem is that when you need to perform a task on some data being rendered by the GUI that is not supported by the GUI. Usually bulk tasks. Like, for all your docker containers, run a certain command. A compromise is that GUIs should print the commands that can be run to get the output they are rendering and to perform the actions they are doing. Like a little command palette at the bottom of the window. Then the user can always break out into terminal.

vaughan 4y ago

The other day I was doing some `make` stuff. I was passing in a bunch of env vars and flags. I wanted to tweak them between each run. I would have preferred to have check boxes to enable/disable certain flags. Rather than copying into Then in the output, I have a bunch of make tasks and child make files running. I care about the output for each makefile as it runs, but then would prefer it to collapse when its finished. Otherwise its too difficult to see each step of the build process. A terminal cannot do this. XCode does it kind of well. At the end of build too, when it reports errors, I'd like to jump up to the errors. Almost every command output I would prefer to view as a GUI table or as a webpage. The problem is that then, instead of just printing output, now I am dealing with a huge mess of frontend frameworks and build toolchains.

ovao 4y ago

One example that comes to mind is a GUI for interactive rebasing, which lets you re-order commits with a drag-and-drop interface. I’m thinking specifically of the one that (I think) is included with the Git ReFlow VS Code extension. True, a CLI tool could be made to mimic the same thing the GUI variant does in most respects, but at that point you’ve simply re-implemented a GUI, just with all the interface restrictions imposed by the shell. I’d agree that apps in general should promote some level of scriptability, and letting users drop down into the CLI is a great option for that. I’d just make an argument for giving CLI users an option to “rise up” to a GUI where it makes sense.

suprfnk 4y ago
> One example that comes to mind is a GUI for interactive rebasing, which lets you re-order commits with a drag-and-drop interface. With `git rebase -i <some_commit>` on the command line, you get a list of one commit per line which are trivial to re-order in a text editor. It's probably faster than a GUI too, if you're at least a bit efficient in a text editor. --- This is not to say that there aren't valid uses for a GUI, I think there are, but re-ordering commits is not one of them, I'd say.

yakubin 4y ago

Debuggers. A GUI debugger can show you a watch window with some variables and you can see it change in real time as you step through code, without you having to explicitly run the print command on each step for each variable, and without leaving a mess of historical values on your screen. Thanks to that, observing state as it changes costs less effort. Instead of manually asking all the time, you passively observe. It means greater productivity for the user of the debugger. And it goes beyond the watch window: source preview, disassembly, registers, hexdump of memory… And obviously: editors. Unless you’re using ed, everybody’s using GUI or TUI editors. And TUI is just a poor man’s GUI. All the benefits of CLIs are gone, while the things GUIs are good at are degraded. Not to mention anything related to graphics, photography, video…

vaughan 4y ago
I think what we need is unix/shell-like GUI. CLIs all have the same consistent user interface. Positional arguments, flags, and text output. On unix-like envs they also have pipes. This is why people like them. This is what makes people productive in them. Sure, modern GUIs have a few shared UX paradigms, but largely they are all different. I wonder how the unix philosophy applies to GUIs? Or what the early developers thought about it. How would piping work in a GUI.
- thesuperbigfrog 4y ago
  You might find Rio interesting: https://en.wikipedia.org/wiki/Rio_(windowing_system) https://en.wikipedia.org/wiki/Rio_(windowing_system)
- ogogmad 4y ago
  There was a GUI at some point - in an old rarely used OS - that allowed you to use point and click to connect the output of one text box into a form field. Found it. Doesn't work quite how I expected it: https://en.wikipedia.org/wiki/Pipeline_(software)#Pipelines_in_GUIs https://en.wikipedia.org/wiki/Pipeline_(software)#Pipelines_...
vaughan 4y ago
Debugger is also an interesting example. In IntelliJ, when using the debugger I've often use the command line interface too. Sometimes I have been debugging something and I wished I could use a Node.js script to automate some stuff. Or I wished I could pipe the output through a Node script. The way the debugger is implemented in IntelliJ makes this a little difficult. Certainly not as easy as piping. I think this is because it uses the gdb machine-interface API which is different to the text command one. For source control, IntelliJ does actually print all the git commands it is running which is nice.

dtgriscom 4y ago

> GUIs are just a distraction. That's an unnecessarily polarizing statement. No one paradigm serves all needs. I use GUIs if the tool needed is complex, and I'm not familiar with it; a well-done GUI is much more discoverable than a CLI. I also use GUIs if the output is more than one-dimensional. Image editors is an obvious case, but how about spreadsheets? And, I love SmartGit because it shows the log and diffs in a much more intuitive and interactive way than even tig. Note that I'm a bash-boy from way back, and spend time every day using it, interactively and in scripts. CLIs are great when they match my tasks. But they aren't the be-all and end-all. Beyond the differences in task, I'm sure there are people whose needs are consistently best-served with CLIs (you sound like one). Just like there are people who consistently go to GUIs for their tools. So: just because you view the world of tools in a certain way doesn't mean everyone else should as well.

vaughan 4y ago
Git is a good example because most tools will have a command-palette that prints out the git commands they are running to retrieve data to render. Otherwise they are using libgit2. It's interesting to think about the difference between an API as a library vs CLI / REPL. Often when I am building a library, for testing I usually would like almost every function to be runnable as a CLI. Anytime someone is doing some piping (joining commands) or shell-scripting, it usually could also be its own script with a CLI. Many applications could also just be shell scripts piping stuff together which I think is actually what the unix people envisaged. Starts making you ask: why are some things CLIs and not everything. Lots to think about...
ngcc_hk 4y ago
Yes. Once again And not Or. even playing game you use keyboard a lot. Not just the graphic input, even you live in a graphic world. So is editing etc. both.

anthk 4y ago

Diffs.

ogogmad 4y ago

Advantages: - Drag and drop - Discoverability of features - Higher density of information - Changes can be seen instantly - The use of a mouse or stylus when it's natural How are you going to use Photoshop or Illustrator from the CLI? (Or Gimp and Inkscape.)

mellavora 4y ago
cp is faster than drag-and-drop, especially when operating on multiple files (i.e. cp myphotos/2022-11-* someplace/)... vs drag and drop, where you need to open both locations in windows, select the files in one, and drag it to the other. Then probably close one of the windows. Command-line is also discoverable, just not by the 'click on this' mentality, you have to be more curious. Which might be the better way to learn. You might be right about higher density of information, but do you get to choose the information? vs i.e. ls, ls --color, ls -lht, ... How quickly can you change between different representations? i.e. find big directories by du -h | sort -h Changes can be seen instantly in the CLI, I don't understand what you meant by this. The use of a keyboard when it is natural. imagemagick With the added advantage that all of the above, because it is text-based, is: recordable, repeatable, searchable, scriptable. GUI, not so much.

dahart 4y ago

> Do you have any examples of tools where the GUI is more useful than the CLI, and could you explain why that is? Dunno if you’re just having some Thanksgiving fun, since the question of GUI vs CLI is mostly settled and moot, and this debate is irrelevant, but I’ll take your comment literally and respond as though you are serious. So are you taking about shells, or any programs at all? Are you talking about programmers or all software users? What makes a GUI, exactly? (Are text menus CLI or GUI? Is CLI defined by REPL? Is Logo a CLI or GUI? What about vi, nano, or ddd?) Speaking as someone with a lot of love for the shell, and few decades of experience with it, it seems to me like your question assumes a rather extreme position that doesn’t seem to be well supported by most people’s usage, even if we’re talking only about programmers. If the CLI is strictly better then why do people tend to prefer GUIs? That question needs a serious answer, ala Chesterton’s Fence, before dismissing GUIs. Make sure to thoughtfully consider learning curve, effort, discoverability, prior knowledge requirement, overall task and workflow efficiency, etc. Web browsing, such as visiting HN and commenting, is much much better in a GUI browser than via manually typed curl or wget commands. What if you had to send POST requests to get your comment up? What if people had to send GET requests to know your comment existed, and then another one to retrieve it? We wouldn’t even be chatting if this was a CLI, right? More or less all artist tools are better as GUIs, from Photoshop to video editing to 3d modeling to animation. If the output is graphical, then there’s no way around a graphical interface. Using the CLI for this isn’t just tedious and expensive, it’s far less efficient and effective. Text editors are not CLI REPLs, even vi and nano. Spreadsheets are all GUI. Desktop OSes are GUIs. Smartphones are GUIs. (Imagine making calls via CLI!) Programming GUI IDEs can be extremely effective, especially when refactoring and debugging. There’s also a gray area of text based GUIs in the console window, like nano and GBD’s TUI mode, just for two examples. Even in CLI-land these things are easier to use and more efficient for some tasks than a pure REPL with text commands. Could you maybe explain why you claimed a GUI has no value? Are you aware of the history of debate on this topic, and of academic research on this topic?