The cli has one other benefit which I think is rarely recognised: it's pretty easy to tell someone you need to run "xyz -a -b -c" (bringing the safety risk with it to be fair), but it gets a lot harder to be like "so in the top left there is a cog button that opens a panel on the right where you're looking for the 2nd tab and there'll be a checkbox".

The things I appreciate even more than a good gui are programs with a good gui and a cli.

Tbh a lot of things are just easier to show/explain with images and icons in addition to text.

And in many cases mouse control is just super handy and fast

And while a terminal can show all these things… its just not comparable, IMO.

I wouldt want to write my job application in the terminal, or design a product, or whatever else requires just a smidge of graphics

"I am the commander of the CLI! The CLI Commander!"

So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.

I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.

But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.

Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:

‘tool read_cfg’ reads from the device and prints the config to stout

‘tool write_cfg’ reads a config from stdin and sends to the device.

Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.

The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.