Hacker News Reader

Comment by lone_haxx0r | Hacker News Reader

> Alt-N goes to the next "window", Alt-P to the previous and so forth

Thanks to this sentence, it dawned on me that even if you're a l33t hax0r, GUI and mouse-based interfaces have the advantage of not requiring you to remember how to use a program. How many program interfaces can you keep in your long term memory? Is it even worth it to waste your precious (human) memory space in such a thing?

Sure, TUIs and UNIX commands can be really useful and efficient once you learn them, but GUIs are useful even if you've never used the program. They give you an acceptable level of productivity right off the bat, and most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.

View on HN

> They give you an acceptable level of productivity right off the bat, and most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.

The problem is, GUIs usually give you ridiculously low ceiling for productivity. So you're forever stuck with the level of productivity you get right off the bat. It used to be that GUI software had keyboard shortcuts for most operations (in particular, Windows made it really easy to do, and expected you to do it) - but then the web came and it all flew out of the window.

So part of the reason to use TUIs and Unix commands is because modern GUI philosophy makes my mind throw exceptions from boredom in the middle of doing something.

> How many program interfaces can you keep in your long term memory? Is it even worth it to waste your precious (human) memory space in such a thing?

Quite many. Human memory has natural garbage collection, so don't worry, you're not wasting anything. In this day and age, you're not really using your memory to its full natural capacity anyway.

And before someone says that learning a tool takes time, try this experiment: pick a tool with shortcuts you don't like, and spend one Pomodoro trying to operate in it. 25 minutes. There's a good chance you'll be past the mental block in that time, and the new navigation will already start to feel natural.

That natural garbage collection happens during sleep, you need to sleep on it a couple of times. So make that a staged 25 minutes, i.e. 10 mins one day, 10 mins the next, then 5 mins on the third day. Only then will the mental block be gone -- as long as there's only about 7 shortcuts you don't like (and that's plus or minus 2, probably minus).

Oh, and that's a good night's sleep, not a programmer's every-other-night sleep, so better stage that 25 mins over four days, not two.

While I agree that a GUI can be a bit more discoverable in general, I don't think CLIs (and more generally, terminal-based programs) are necessarily for the l33t crowd. We've just been conditioned that way by the fact that most user-facing applications these days are GUI based.

But think of the DOS-based programs of yore, like WordPerfect 5, and the Turbo C/Pascal IDEs... they had menus on screen, easy-to-access help screens, etc. to guide the novice. (What's the Web-app equivalent to the F1 key?) History shows that WordPerfect was fine to use as a non-technical person. (I wish our modern word processors were so simple to use as WP 5, actually -- modern app-design trends have bloated the word processor into a confusing mess, IMO, and I think the average office worker who has worked in both generations might agree.)

I really like the approach taken by the 'which-key' extension for Emacs, which is particularly well used in the Spacemacs distribution. Pressing the space bar pulls up a very nicely organized menu of actions, including access to help. It's extremely helpful both as a memory aid, and also for discovering new features.

Obviously a nice menu doesn't get the user fully past the initial Emacs learning curve, which supports your argument. But for the next level of user -- from novice to initiate -- it's a tremendous productivity boost.

- https://github.com/justbur/emacs-which-key - http://spacemacs.org/

Also, natural language can be quite discoverable if designed properly. Jef Raskin and his son Aza did quite a bit of work in this area. Things like Alfred on the Mac, and a bunch of different IDEs nibble around the edges of this concept with EMACS Meta-X taking it the farther than the others.

- https://en.wikipedia.org/wiki/Canon_Cat - https://en.wikipedia.org/wiki/Archy - https://en.wikipedia.org/wiki/Ubiquity_(Firefox) - https://www.youtube.com/watch?v=BVVXNlOFqXA

> I really like the approach taken by the 'which-key' extension for Emacs, which is particularly well used in the Spacemacs distribution. Pressing the space bar pulls up a very nicely organized menu of actions, including access to help. It's extremely helpful both as a memory aid, and also for discovering new features.

It's even nicer than that (in particular, when you're not using Spacemacs): Emacs has a lot of multi-key commands (just like Vim). Whenever you pause in the middle of such command for a brief while (0.5 second by default), it'll pop up a sidebar listing you keys you can press to continue along with the command they execute. So e.g. there's a command you want to invoke, you remember it was under C-c something, but don't remember the exact combination. With which-key enabled, you just press C-c and wait until a list of available continuations shows itself. It's also useful for command discovery (what's there under C-c? what's under C-c C-v?).

Speaking of similar techniques, I like the way Magit works even better. Most commands involve several key presses, like "d d" for diffing against the thing you're pointing at, or "l l" to show current log. So whenever you press "d", a popup like this appears (bottom 2/3 of the screenshot):

https://magit.vc/screenshots/popup-diff.png

It immediately shows you all the different keys related to [d]iffing, including some sequences that set flags (like e.g. -f). It disappears as soon as you press the key. The principle here is that you'll quickly memorize most frequently used commands and type them so fast you won't even notice the popup, but whenever you don't remember something or want to explore, there's always something showing you the next steps.

Totally agreed. Magit's interface feels like the "curated" approach -- they laid out all the options precisely to optimize your use of the tool. This is great to have in small, task-dedicated parts of Emacs. But then we also get complete, "uncurated" discoverability such as in your C-c example.

I think that Spacemacs is a decent compromise between the two, covering a large swath of functions with a loosely organized menu structure. Although they occasionally clobber some key bindings in an annoying way (org-mode and magit come to mind), it's nice to be able to find "text" things under the text menu, even when you don't remember the key-binding at all. It's surprising how well the three modalities (curated magit, general which-key, and semi-curated Spacemacs) work together, and stay out of each other's way (for the most part!).

We acquired language so that we could express ourselves better than we could pointing and grunting. Learning a new word was always tricky- we could sometimes model it with existing words we already knew, but sometimes we would only learn it by practicing its use in different ways to see what works. When we might meet another person with another language, we may resort (at some point) to pointing and grunting again, but knowing language we feel the pains trying to convey anything beyond the most basic wants and wishes when resorting to such a crude tool.

So it is with text-based interfaces like unix. I learned unix over thirty years ago, and thirty years of practice with a language gives me a great deal of comfort learning the occasional new word in unix. Conversely, every time I point and grunt, I don't feel like it's an even remotely "acceptable level of productivity".

I do however think these TUI things are abominations combining the worst of both worlds.

Surely TUIs for editing text (nano, vi, emacs) are better than using something like `ed`. There's something to be said for having two dimensions to navigate in!

Not the parent but I took his comment to be a response to a comment above that mentioned DOS apps that had menus, used standard function keys, had "form controls" (e.g. buttons, lists), etc.

I think of a TUI not so much as a 2D text interface but more like text interfaces that work with a mouse, use similar constructs as GUI's like menus and form controls and standardize on conventions for displaying information in a uniform way across different applications.

Like I said, not the parent, so I may be wrong but there's my two cents...

Vim still qualifies as a TUI under that definition (since it supports using the mouse to select text, change or resize windows, etc), though I think Vi would not.

Agreed, although I'm glad Bram, et el. have not tried to add a text based "toolbar" or menu to Vim like in GVim.

But yeah, to this day after using Vim for years and years I still get a little surprised when I absent mindedly click on a Vim session in a terminal window and it moves the focus to whatever buffer I happened to click on.

I'm so used to ^W-^W that I forget this is even possible. Same with moving the cursor, selecting text, scrolling up and down, etc...

Ah, that might be what he meant. Still not sure I agree, but it makes more sense than the "real men use ed" alternative! :)

There is le editor. F10 brings up a menu. Shortcuts all around. It's nearly like an old turbo c/ pascal app, but it's available with a simple apt install le.

I've read many comments like yours over the years, but I've never understood how a GUI precludes using a language, whereas a text based interface means giving up the features of a GUI.

I wonder if there are many people that are as young or younger than the personal computer, who are stuck on the idea that a GUI is somehow inferior. Because I was about 7 when the first ones were available, so anything before that seemed like an obsolete relic.

I think you're trying to read me too narrowly and make a strawman out of what I said: My finding incredible value in text doesn't mean that I see no value in pointing and grunting. Besides the example I gave (having no common language), another good use is when precision isn't desired: I can freehand draw with a greater approximate precision than I can write a program to draw what I have in-mind. There are others as well.

But our grandparent poster said:

> > > GUI and mouse-based interfaces have the advantage of not requiring you to remember how to use a program. ... Is it even worth it to waste your precious (human) memory space in such a thing?

And my point is, if I spend my time learning a graphical workflow, I will undoubtedly have wasted it, for learning a textual workflow isn't much more work and the knowledge will pay dividends. I believe I am not unique in these regards, so yes, I don't think it's just worth it to me, but to lone_haxx0r (and you) as well.

Here's an example: I watched a graphic designer once doing a lot of work manipulating assets. He had spent the last hour translating all these artefacts for the web, so over the next 5 minutes or so, I learned some new unix words and wrote a little shell script to do that translation. The script ran quickly taking maybe another minute or so to do what would've been at least another hour of work the other way.

> stuck on the idea that a GUI is somehow inferior.

A GUI (and these TUI) will always require a coding of every workflow, and that workflow is undoubtedly written in text: Despite many efforts over many decades to tell the computer what to do purely graphically, we haven't begun to approach within an order of magnitude, the precision and productivity of textual interface. It's not turtles all-the-way-down!

So yes, it's definitely inferior in this way.

This is probably part of why people like programs that follow a set of conventions. If all of my programs use vi keybindings, there's not much left for me to remember. This also covers GUIs to an extent; if every program had its own ideas about how scroll bars should be placed or work, or what each mouse button meant, then we'd struggle.

Most CLI/TUI programs have integrated help.

Anyway, I have to remember most of CSS, HTML, JS builtins, all kinds of syntax, posix API, std. C library, so bunch of shortcuts or commands in some weird ass MUA like mutt (I probably use 10-15 commands/shortcuts regularly), really doesn't add much.

The problem is that GUI/web programs are typically not easily extensible or composable. Though thanks to popularity SPAs, at least some web programs can be integrated with via internal REST APIs.

CLI tools don't usually have this problem.

Even if GUI tools have some scripting, it usually is ad-hoc and may not integrate that well with the rest of the system.

On the CLI side, you have a scripting system (shell) in which you're able to run and combinine all your tools.

Discoverability is discoverability, no matter whether you're operating in a text interface or a graphical one.

Look at nano for instance: all the essential commands are there, always displayed at the bottom of the screen. Nothing to remember.

This morning, it took me a solid 20 minutes to find the page on Amazon.com where I could tell them that my book marked as delivered wasn't, and that I needed them to send me a new one. This is something I've done many times before, within a GUI, but the feature is hidden away because the company wants it to be - the graphical nature of the interface is irrelevant here.

There's a tradeoff to be made between efficiency and ease of learning. For my environment that I use every single day, I'll go for efficiency all the way.

Of course, we humans like short term returns and so most people don't make the investment to use a more efficient system.

> How many program interfaces can you keep in your long term memory?

Infinity. A practical one. You can keep as much as you like.

> Is it even worth it to waste your precious (human) memory space in such a thing?

We do not know what is waste of memory and what is not. Really no one knows exactly how human mind works and how diversity of your motor skills influence your mind in general. It even could be that it have no impact at all!

> most of the time it's not worth it to waste your time learning the superior UNIX/terminal version.

You never know. The more commands you have learnt, the easier learning become. The learning is a recursive thing, you can learn to learn. So if you didn't learn to use TUI, you couldn't measure the difficulties of learning one more utility.

There's some level of GUI compitency or fimilarity - we have an understanding and expection of where menus should be and how they should work. I'd argue this is also the case with ncurses like software too - in fact a lot of programs support emacs style keyboard shortcuts.

You're also missing the distinction between keyboard shortcuts for a TUI and a CLI. Given a level of terminal compitency I'd argue that a CLI isn't any harder or is often easier to become compitent thanks to the UNIX philosophy.

Just be an old man about it and keep a stickynote of all your shortcuts you need to remember. Eventually they will click.

There is no greater tool for getting things to stick than than a sticky note clung to the end of a stick.

Having a good shell (like zsh) that shows available flags with descriptions when hitting tab goes a long way toward not having to remember tools' flags.

Reply on news.ycombinator.com