alt Hacker NewsKeyboards are higher bandwidth man-machine interfaces than mouse + GUI unless what you're exchanging is spatial information, which is typically not the case for writing software.
There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.
Replies
This 100%. For me, the philosophy is not so much a terminal-centric design but a keyboard-centric design. Sure, this could be done in a GUI, but even GUIs with a keyboard-centric design are not as fluid as a TUI.
I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.
I didn't understand much of you said but it sounded mathy so I'm going to reply with a counterexample, just look up on youtube Russ Cox solving AoC with Acme and tell me that's not impressive!
By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.
I use IDEA for most things and barely touch the mouse. It has its problems (like terrible performance), but it's a good example of a GUI done right.
Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).
Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.
And so on, and so forth.