I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.
- you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object.
- you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y.
Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.
It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used.
Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.
You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again
There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.
The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.
I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can.