GUIs are better for poring through data as a whole, like Google docs, but CLIs are better when I want to do an operation or filter through things without looking at the thing itself, ie git or grep.
i think one difference between guis and clis that people don’t think about is composability. you cant do something like “pipe the contents of a folder into vscode and do a regex find and replace” but that’s what pipes let you do on the command line. with gui programs, you always have to do these things manually… which is nice the first time but then time consuming each subsequent time.
Pipes and repeatability are the big advantages of CLI for me.
Someone asks me how to do something, I can give them one or more commands and they can parse that and understand it.
On a GUI I have to trying and navigate them either in person or through chat somehow. Plus, if they forget how, they might need to ask again instead of just finding the command in their chat history.
yes, great example. also: when the creators of that program decide the want to redesign the ui, all of your tutorials on how to do things break.
my theory is that its not something inherent about using text instead of graphics: a maintainer of a cli program could also decide that they want to redesign the command line options. but its more that users of guis don’t demand stability or repeatability. they are impressed by a ui redesign and so that’s what they get.
It’s also inherently something that has to happen to add new features on a GUI. There’s only so much real estate, you add more menu options, then the menu gets too big and you need to reorganize it.
that could be it… I’ve just thought about it a lot and came up with a new theory.
it seems to me that the limitations of screen real estate seem surmountable. eg: a settings menu could have a search bar like in android, meaning your options can be accessible even though they’re buried in the gui.
then, your settings could be “stable” and repeatable by adding flags like in google chrome (another gui program).
you can actually use chrome from a cli with selenium or the headless command (–headless) and I’ve used this to scrape websites locked behind Javascript. but average chrome users don’t demand the further development of these features.
You can hide things in submenus, tabs, side bars etc. so you can get get to lots of things in a few clicks, think BTrees for indexing data, but you can search through a screen more more easily by taking in multiple things at once compared to a vector of data.
The issue is that you can rebalance BTrees and no one notices, you “rebalance” a GUI and people’s pre-remembered paths are invalidated.
GUIs are better for poring through data as a whole, like Google docs, but CLIs are better when I want to do an operation or filter through things without looking at the thing itself, ie git or grep.
i think one difference between guis and clis that people don’t think about is composability. you cant do something like “pipe the contents of a folder into vscode and do a regex find and replace” but that’s what pipes let you do on the command line. with gui programs, you always have to do these things manually… which is nice the first time but then time consuming each subsequent time.
Pipes and repeatability are the big advantages of CLI for me.
Someone asks me how to do something, I can give them one or more commands and they can parse that and understand it.
On a GUI I have to trying and navigate them either in person or through chat somehow. Plus, if they forget how, they might need to ask again instead of just finding the command in their chat history.
yes, great example. also: when the creators of that program decide the want to redesign the ui, all of your tutorials on how to do things break.
my theory is that its not something inherent about using text instead of graphics: a maintainer of a cli program could also decide that they want to redesign the command line options. but its more that users of guis don’t demand stability or repeatability. they are impressed by a ui redesign and so that’s what they get.
It’s also inherently something that has to happen to add new features on a GUI. There’s only so much real estate, you add more menu options, then the menu gets too big and you need to reorganize it.
that could be it… I’ve just thought about it a lot and came up with a new theory.
it seems to me that the limitations of screen real estate seem surmountable. eg: a settings menu could have a search bar like in android, meaning your options can be accessible even though they’re buried in the gui. then, your settings could be “stable” and repeatable by adding flags like in google chrome (another gui program).
you can actually use chrome from a cli with selenium or the headless command (–headless) and I’ve used this to scrape websites locked behind Javascript. but average chrome users don’t demand the further development of these features.
You can hide things in submenus, tabs, side bars etc. so you can get get to lots of things in a few clicks, think BTrees for indexing data, but you can search through a screen more more easily by taking in multiple things at once compared to a vector of data.
The issue is that you can rebalance BTrees and no one notices, you “rebalance” a GUI and people’s pre-remembered paths are invalidated.