Live data from Hacker News

How I'm still not using GUIs in 2019: A guide to the terminal

lucasfcosta.com

221–230 of 248 posts

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#221
post #206
post #45

Earlier quoted context omitted.

Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.

> Navigation is rarely the limiting factor in development speed Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky thin…

> Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.

Isn't that a test coverage issue more than a navigation issue ?

Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#222

Earlier quoted context omitted.

Yes that's also key for network admins - ironically I found when doing my CCNA that my experience years ago on PDP's cli came in handy on ios (the Cisco os).

Yes. I wonder though, with proliferation of tools for automating server management, how much does this approach still matter?

Serious sysadmins /network admins only config kit via out of band terminal mode - that's what the AUX and Console ports are for on Cisco kit

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#223

Earlier quoted context omitted.

I would like to see data on this, any studies done?

You need studies for something you can trivially test for yourself with a stopwatch?

One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#224

Earlier quoted context omitted.

You need studies for something you can trivially test for yourself with a stopwatch?

One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.

Let me sketch you something of a theoretical proof here, then.

1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster.

2) The absolute upper bound on the simplest possible way of aiming at a single pixel of 4K UHD screen with just two keys is 23 key presses. 14 key presses if you're aiming at 16x16 squares (mouse rarely needs to aim better). 12 keypresses for arbitrary pixels with four keys (home row). 8 for 16x16 square with four keys. 5 presses with full set of English letters, for arbitrary pixels. That's an upper limit. It's slower than a mouse, but only by a little bit (within the same order of magnitude).

3) Generalizing this, the upper bound of keypresses you need to touch arbitrary element on the screen is given by log_n(number of elements), where n=how many keys you want to use. +1, if you need some sort of activation key before (to switch between typing and selecting). This quickly drops to 1-3 keys, and you can get even better if there's some structure to the expected workflow (see e.g. tab stops in any sane form in any UI that isn't suffering from acute JavaScriptitis yet).

4) 1-3 random keys are faster to press than clicking a random object on a screen. That you can time for yourself trivially.

Basically, unless you're dragging arbitrary pixels around, for almost[0] any task one could easily design a keyboard-driven UI that's faster. Those kinds of UIs are not omnipresent (with the exception of Windows-style "accelerators" and tab stops, which the web is doing its best to get rid of), but they show up. In fact, properly configured Vim and Emacs are full of these kinds of UIs for programming tasks (see e.g. [1]). Which is exactly why you keep seeing people telling you Vim/Emacs are more efficient to work in.

--

[0] - I'll make concession to visual arts here, but take a good look at Blender to see how far you can go with keyboard-driven efficiency improvements for 3D modeling.

[1] - https://github.com/easymotion/vim-easymotion; Emacs has stuff like this too, but this repo has better screenshots.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#225

Earlier quoted context omitted.

No no, the problem isn't reaching across the desktop. The problem is literally taking your fingers off of home row. It's fine if you're in a phase of your activity where you're moving slowly, contemplatively. But if there's a series of tasks that we want to accomplish and we already know what they are, lifting your fingers off of home row will slow us down! Wireless vs wired mice have nothing to do with this. As far…

I would like to see data on this, any studies done?

A healthy skeptic doesn't demand data for claims like "touch typing is faster than hunt-and-peck".

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#226

Earlier quoted context omitted.

You need studies for something you can trivially test for yourself with a stopwatch?

One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.

Of course this isn't true for everyone. For example, some people don't have any fingers.

I type about 105 per minute, 3% error rate.

If you can only type 10-15 words per minute, it's probable better to mouse most of the time.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#227

Earlier quoted context omitted.

One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.

Let me sketch you something of a theoretical proof here, then. 1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster. 2) The absolute upper bound on the simplest possible way of aiming at a single pixel of…

For your point in 1) that won't apply on any kind of navigation. I have to ls -l / dir multiple times to view whats in my folder and go back up with various key presses, versus just hitting the breadcrumb in windows explorer.

Not sure I fully understand 2-4 but the fundamentals still remain, i want to do a git pull i alt tab to my command line, already two presses, then i find my src directory, and pull. Or just right click on my IDE and click pull?

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#228

Earlier quoted context omitted.

One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.

Let me sketch you something of a theoretical proof here, then. 1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster. 2) The absolute upper bound on the simplest possible way of aiming at a single pixel of…

Blender is an amazing example. I was daunted by the thought of learning the rich set of hotkeys until I saw it compared to vim. Learning vim or emacs is well worth the effort, inspiring confidence that blender is as well.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#229

Earlier quoted context omitted.

Let me sketch you something of a theoretical proof here, then. 1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster. 2) The absolute upper bound on the simplest possible way of aiming at a single pixel of…

For your point in 1) that won't apply on any kind of navigation. I have to ls -l / dir multiple times to view whats in my folder and go back up with various key presses, versus just hitting the breadcrumb in windows explorer. Not sure I fully understand 2-4 but the fundamentals still remain, i want to do a git pull i alt tab to my command line, already two presses, then i find my src directory, and pull. Or just righ…

If I want a refreshed list of my homedir, the first time is simply

ls ~

Subsequent refreshes are simply

C-p

Dragging over to that breadcrumb is tedious and time consuming, by comparison

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#230

Earlier quoted context omitted.

Yes. I wonder though, with proliferation of tools for automating server management, how much does this approach still matter?

Serious sysadmins /network admins only config kit via out of band terminal mode - that's what the AUX and Console ports are for on Cisco kit

Eh, that doesn't scale beyond a few devices. There's out-of-band management, yes, but often it's in the form of an isolated management network, which allows automation quite conveniently. Even the serial console is often accessible over a network using terminal servers. You usually also want to be able to download and archive your device configuration automatically using eg. oxidized.

That said, being able to work with standard tools is extremely relevant for debugging problems, still.

Post reply on HN