Comment by asdff | Hacker News Reader

Comment by asdff | Hacker News Reader

Honestly the command line seems less conceptually challenging than having to learn a gui and all its abstractions first. Think of copying and pasting a file in mac os and explaining it to someone for the first time:

"ok, now open finder. its in the dock. you have to move the mouse to the bottom of the screen. its the man with the face. ok now we need to get to the file. ok where did you put it? ok lets click to it. is that it? ok right click. lets find copy. great where is it going, click back, its the button up there, click back again, click it one more time, lets go forward again, ok in that folder, click on the name, no thats a triple click click somewhere else and lets try again, ok double click, ok now we are in, ok right click, paste."

versus

"type cp filefromyada toyada and press enter"

A lot of people are so used to the GUI that they get scared of having to learn to walk again practically and diving into the cli. But if you never learned all the hoops and crap we have to deal with finagling stuff around a modern gui, I think you'd be able to do a lot more powerful things a lot faster starting with the cli from the beginning. I really wish I grew up learning the cli vs the gui, personally. guis also frequently change whereas the cli feels like its etched in stone (or you can use a container with whatever version of the stone you like)

Learning anything is easy if you only focus on the happy path where everything works as expected. The challenge of a command line, or a badly designed GUI, is discovering what to do next if what you tried first doesn't work. Your 'cp' example is good - how do you fix it if your current user doesn't have write permission to the location you're trying to copy to, or if the disk is full, or if it's a volume that worked last time but it's not mounted now, or any one of many hundreds of reasons why a file can't be copied. The process of copying a file is suddenly a blackbox of other commands, processes, and concepts that the system doesn't immediately tell you about. You're dropped into the fun world of learning about users, groups, permissions, volumes, etc. That's probably OK if your goal is to learn how to use the OS, but if you're just trying to copy a file it's incredibly frustrating.

The benefit of a well designed GUI is that it can give you high quality feedback, or block you even trying to do something in the first place, because it's contextually aware. Command line commands can only give you an error after trying something.

Good software makes recovering from a problem as painless as possible. In general command line apps are quite bad at that.

The other benefit of a GUI is that you don't have to spend time learning things you'll use once a year, and then relearning them every time.

I don't remember any of the syntax for commands I haven't used in the last month or so. GUIs are very fast for one off tasks like "Sort this CSV and only take these 3 columns".

LibreOffice loads faster than I can read 3 different man pages and figure out commands I haven't had a reason to use in months.

Plus, commands tend to be less integrated, and there are some things that GUIs automate very well, that would require writing your own automation in the CLI, and I like workflows with an absolute minimum of ad hoc software.

> The benefit of a well designed GUI is that it can give you high quality feedback,

In theory, yes. In practice, what happens is the progress bar would seem to freeze.

What do you do now? Some computers still have a blinking HDD LED, maybe you can glance there.

Otherwise you have to know a great deal of the mechanics behind the curtain to find where the relevant log is, and how to inspect the running process. Is it a stale mount? A shared library that wasn't found? Or perhaps an automatic operation triggered on a magic filename?

A CLI has the benefit on being conceptually simple. There's going to be a result, and it's going to the console. It may be cryptic, and you may have to look up the meaning it it's something unusual (notorious ones like "lp0 on fire" are the joke of the Internet, hilariously cryptic GUI messages are a dime a dozen), but it's seldom going to surprise you. It's not going to freeze the terminal, or suddenly boil your coffee.

It's certainly not the silver bullet that fits all, but things that are conceptually simple are often a good default.

> There's going to be a result, and it's going to the console.

If you're lucky. The kind of things that make a UI freeze often make a CLI freeze too. If you're unlucky, you end up with an unkillable process. Or, more confusingly, a process that garbles up your shell until you reset it.

> Your 'cp' example is good - how do you fix it if your current user doesn't have write permission to the location you're trying to copy to, or if the disk is full, or if it's a volume that worked last time but it's not mounted now, or any one of many hundreds of reasons why a file can't be copied.

All of those problems could also occur with the GUI approach, and I'm not sure the error messages would allow a novice to fix the problem any better than on the command line.

They don't. In a GUI a directory you don't have permission to write to is greyed out, or shows a "no entry" cursor when you drag something to it. An unmounted volume just isn't shown in the first place. A full disk shows an error saying how much space is needed, or asks you to free up space.

> In a GUI a directory you don't have permission to write to is greyed out, or shows a "no entry" cursor when you drag something to it.

Neither happens on macOS. Instead, I can drag the file as usual, but then I'm shown a dialog which asks me to login. It doesn't do a brilliant job of explaining the problem, but it's probably better on balance than the command line's "Permission denied".

> An unmounted volume just isn't shown in the first place.

Is this significantly different from the volume not being listed under /Volumes (again, this is where it turns up on macOS)? I think I almost always use tab-completion with that directory anyway because volumes rarely have reasonable names.

> A full disk shows an error saying how much space is needed, or asks you to free up space.

I'd be surprised if the command-line error wasn't similar, tbh.

The CLI is conceptually aimple to grasp for most things: you type something, the computer does something. If you type the wrong thing it will tell you.

Piping commands etc is conceptually more intricate, but the good thing is, that even without it you can get quite far already.

The permissions problem depends on the ls -l knowledge. The disk full problem is another good example of fundamental knowledge that supports error recovery.

There’s a minimum level of knowledge required to solve problems on your own at the command line. Another 5 sessions would do it.

I imagine the GUI is similar but harder to quantify since spatial knowledge is more innate. I remember being 10 and fiddling with a computer UI without knowing anything. I figured out selecting and dragging on my own but not double clicking to open.

I've helped some older people and found the same. The command line gives some users more confidence. Hearing that "the computer does exactly what you tell it to", but "it's dumb, so you have to tell it very precisely" is more empowering than being expected to click around and figure out how things work.

The computer does exactly what you tell it to do, but never what you mean.

I feel like the point you’re making has never been less true. Dialog boxes with “not yet” rather that “no” are ever more popular. I don’t think that the modern UX designer has much respect for me or my intentions.

That reminds me of the speech the head of the computer science department gave at the start of my course.

“The best thing about computers is they do exactly what you tell them to do. The worst thing about computers is they do exactly what you tell them to do.”

GUIs give you a clear venue for exploration (click around), which is how kids dive into them.

CLI requires reading and writing, and usually in English — at the very least, Latin script.

I don't know how I would feel if I didn't grow on the CLI (back in the DOS days), but I'd say CLI is a faster way to do most things other than selecting by visual data (eg. find all images with mountains in this folder of 1000 files) — at some point, ML will help that bridge get crossed too.

Well true, but playing Police Quest somehow also just worked when it has a command line.

>"type cp filefromyada toyada and press enter"

so hit the 't' key, followed by the 'y' key ,,, followed by the enter key to copy this file. While this is a trite example, how many linux how-do-I-do-this's get resolved with copy this command with half a dozen flags[0] into your terminal?

The underlying problem with CLI is they lack information about the underlying structural logic and discoverability about the interaction. This makes it hard to impossible to extend 'copy this file' to 'open this file', or 'make this file read only'. In a (decent) GUI once 'left-click select' 'double-click open' and 'right-click options' is understood the rest is spelled out. Unlike with a CLI, where one needs to remember 'ls'[1] there are only two buttons on a mouse.

I absolutely agree GUI changes - especially paradigm changes - are a plague though.

[0]Which invariably seem to have a different obtuse formatting from the last command I had to copy.

[1]Which stands for what anyway?

> Which stands for what anyway?

I'd always figured it stood for something like "listing" but if it doesn't, who cares, no one's gonna have a problem remembering it.

> there are only two buttons on a mouse

There are 3 buttons on the mouse, plus 3-4 modifier keys (shift, alt, control, logo) on the keyboard, which are sometimes used in combination. Usually not more than 2 modifier keys are used at a time, so that gives us four (single mod) plus four choose two (two mods) modifier combinations, times three for each mouse button, equals 30 different actions, which are usually not well discoverable.

@[1]: 'list', I assume.

With half a dozen flags you're talking about an operation like "hard link all the files older than a week, preserving metadata", which honestly would not be easy for the average user independently of the user interface used.

> 1]Which stands for what anyway?

Ahhah. My favourite question when some fanboy starts to evangelize the ease of use.

It's 'list segments', from Multics, AFAIK.

You could say the same thing about double-clicking — what does that 'stand for'? Thankfully, in either case, it really doesn't matter. Both have their advantages and disadvantages, of course. Maybe 'double click a file to open it' is easier to remember than 'ls means show files' but 'when do i double-click and when do I single-click' is notoriously difficult for novice users to remember.

You skipped the part about learning what a directly path is, and how to find the names of all the subdirs in the paths.

You could explain the file system hierarchy and how to built a path string with a sheet of paper and a pen and a minute or two. That part isn't the hard part of the cli IMO. When you want to find the names of the subdirs, then you introduce ls. Now you know two powerful command line tools, cp and ls, in a few minutes of explanation.

Reply on news.ycombinator.com