3 ms·

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 d

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.

eternityforest 5y ago
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.
xorcist 5y ago
> 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.
- cameronh90 5y ago
  > 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.
oneeyedpigeon 5y ago
> 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.
- onion2k 5y ago
  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.
  - oneeyedpigeon 5y ago
    > 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.
atoav 5y ago
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.
more_corn 5y ago
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.

eternityforest 5y ago

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.

xorcist 5y ago

> 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.

cameronh90 5y ago
> 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.

oneeyedpigeon 5y ago

> 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.

onion2k 5y ago
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.
- oneeyedpigeon 5y ago
  > 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.

atoav 5y ago

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.

more_corn 5y ago

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.