Entering text in the terminal is complicated

what would be ideal from my point of view for check boxes, dropdowns, and labels would be if they were a simultaneous alternative view of a command line, or rather a configuration line. an additional simultaneous view would provide a live preview of the result of that line. but you could still type and copy and paste the text

interestingly this is not too far from my usual experience with the command line. i want to compile a target, so i type `make ` and hit tab twice. i see a list of targets and pick one by typing a letter or three and tab, and hit enter. the compiler errors out right away with a c99 construct, so i add `-k` to the command line (^p spc - k ret) to see how widespread the carnage is. it's everywhere, so i add a compiler flag to the options and try again. and in 30 seconds i have a working build. or maybe i need to use a different compiler, or something, but it's easy to return to the fresh unpacked tarball or git checkout

this is close to the opposite extreme from what you describe in

> You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging.

i very rarely do anything in text mode that is in any way hard to undo. shell commands are mostly purely ephemeral: their only effect is some text on your screen, an entry in your history file, and maybe an output file. if i want to change one, i hit ^p and change it before hitting enter. as for configuration changes, i would say that change management is actually the major strength of the text approach: you can copy configuration lines into your notes, comment out old versions in case you want to go back to them, check the whole configuration into git, diff it to see what all has changed, etc. everything can be undone in exactly the same way. everything is a controlled experiment, with the computer itself recording the configuration of each trial automatically and implicitly

admittedly there are occasional exceptions, like when you're reconfiguring the firewall or upgrading debian to a new release. though current configuration-as-code systems like docker and ansible go a long way to making all that stuff just as recoverable. the server went catatonic? too bad, revert the firewall rule change and reinstall it, and 45 seconds later the problem is fixed

by contrast, it's almost never obvious how to undo clicking on a command button or a menu item. even a dropdown selection is hard to undo: you have to remember what was previously selected

but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it

the cli is just as much of a fiction, just fiction with a different focus

i agree that reading the manual is helpful, but doing stuff you don't understand is necessary to come to understand it, so i don't think it's good advice to avoid it. using the cli for simple things builds the skills you can use for more complex things. the same is true of a gui

(of course there are clis and guis incapable of doing complex things, and those are kind of a dead end)

I have to agree with the other commenter (drewg123). Been a Vim user for decades but don't use Vi-mode in the terminal.

> the problem she describes is a non-issue. And I am not a pro.

Not sure what you're saying here. Julia didn't describe a problem but a preference ("I didn’t really like using it"). I'm not sure how you can you call someone's preference a non-issue. It's a preference and we're allowed to have those last I checked! :p

Whenever someone brings up this subject, I'm reminded of this classic article from Linus which has appeared many times on HN: http://www.linusakesson.net/programming/tty/index.php

> but doing stuff you don't understand is necessary to come to understand it

Only if you're doing an experiment and can constrain accidents. Any other type of activities would require to read the manual first. They're terse because they're supposed to be a reference, but you can usually find books that ease the way in. And then there's the domain expertise that is required. You need networking knowledge to interact with software like ip, operating system knowledge to understand what top is showing to you, etc. You can't get around that.

The GUI is a fixed canvas already painted by someone else, the CLI let you write your own poetry.