5 ms·

It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. Yo

It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. You didn't have to read anything or search around in order to change all of those settings in the GUI. If I were just transferring files or editing files remotely I would use WinSCP which has a much better interface than PuTTY. I can't stand browsing files through the commandline on any OS... It's so tedious. Also, you can operate the entirety of Windows with just the keyboard. You don't even have to pick up the mouse at all. The Tab and Enter keys get you pretty far without even having to know anything special.

jjawssd 10y ago
Scriptability is just as important as discoverability. I don't feel like constantly clicking to accomplish the same task when I have a ton of scripts written down which accomplish a lot of repetitive tasks without clicking.
- ebiester 10y ago
  People get creative: https://forums.adobe.com/thread/1445540 https://forums.adobe.com/thread/1445540
mchristen 10y ago
What about the first time you are using the program? You certainly do need to read all the menu options and search around until you find the correct settings to tweak. No matter what interface you use there is always going to be an initial learning curve, some people prefer the CLI and others prefer the GUI, there's nothing wrong with that.
joatmon-snoo 10y ago
For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful. Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE. Granted, GUIs can offer a lot of advantages - if I'm moving data between two different computers, I will almost definitely use WinSCP, unless it's someone I need to script, simply because the interface is clean, straightforward, and I've never yet had to worry about side effects. And obviously, I use a browser like Chrome and an email client like Gmail. But there are some things where the GUI just adds way too much complexity that I don't ever want to deal with.
- gruez 10y ago
  >For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful. >Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE. Probably because the GUI tools you're using are CLI first, with GUI frontends being a second thought? On Visual Studio (which is GUI first), changing a compiler is as simple as going to project properties and clicking the toolchain dropdown menu.
Panino 10y ago
> It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. The command line gives you both a larger learning curve (base) and greater capabilities (peak). It's not possible to put all the options from the command line into a GUI, because piping allows you to stitch unrelated commands together to form, on the fly, entirely new "programs." for f in *.gz; do gunzip < "${f}" | tr '(' '\n' | awk -F "'" '{print $2}' | grep -v -e '\.foo$' -e '\.bar$' > "out_${f}.txt"; echo "${f}"; done The above command is pretty simple (and could possibly be improved, as many awk+grep combos can be), but I can't picture it in a GUI. Additionally, the above command will still work 10 years from now, whereas the GUI will have changed. So from that perspective, a CLI user who has already reached "base camp" will have a lower learning curve than a GUI user, who will continually have to re-learn new interfaces.
- zo1 10y ago
  That sounds like a really complicated command, requiring countless amounts of keystrokes and indepth knowledge of the CLI (piping, etc) and the commands (tr, awk) involved. Something that could easily be solved with a bit of copy-paste and regex usage in the right text IDE. I'd argue that you're comparing a seasoned professional at the CLI with an inexperienced IDE-user. It's always assumed that IDE and non-CLI users are basic and not at all adept at performing their tasks in efficient ways.
  - randallsquared 10y ago
    If you had to program by point-and-click, I think you'd find it very slow and cumbersome (in spite of valiant efforts to make this kind of thing work, like lighttable). Your immediate reaction in the face of a task to do something conceptually simple, but with an annoying number of little steps, is to reach for a programming language and build it in your IDE. It would be more convenient, really, if you had an IDE that was specifically designed to work with all the other applications on your system, rather than just with whatever language you're using and its libraries. And there is such a thing: the shell! With things like tab-completion, history, aliases, and man pages, the unix command line interface basically already is an IDE. While I don't yet have enough experience with it to say for sure, it seems like PowerShell is intended to be similar, even going so far as to have a literal IDE (PowerShell ISE). There's a reason why IDEs always seem to have a built-in terminal, and why those which didn't at first seem to grow terminal-like capabilities, like VS Code's command palette.

jjawssd 10y ago

Scriptability is just as important as discoverability. I don't feel like constantly clicking to accomplish the same task when I have a ton of scripts written down which accomplish a lot of repetitive tasks without clicking.

ebiester 10y ago
People get creative: https://forums.adobe.com/thread/1445540 https://forums.adobe.com/thread/1445540

mchristen 10y ago

What about the first time you are using the program? You certainly do need to read all the menu options and search around until you find the correct settings to tweak. No matter what interface you use there is always going to be an initial learning curve, some people prefer the CLI and others prefer the GUI, there's nothing wrong with that.

joatmon-snoo 10y ago

For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful. Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE. Granted, GUIs can offer a lot of advantages - if I'm moving data between two different computers, I will almost definitely use WinSCP, unless it's someone I need to script, simply because the interface is clean, straightforward, and I've never yet had to worry about side effects. And obviously, I use a browser like Chrome and an email client like Gmail. But there are some things where the GUI just adds way too much complexity that I don't ever want to deal with.

gruez 10y ago
>For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful. >Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE. Probably because the GUI tools you're using are CLI first, with GUI frontends being a second thought? On Visual Studio (which is GUI first), changing a compiler is as simple as going to project properties and clicking the toolchain dropdown menu.

Panino 10y ago

> It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. The command line gives you both a larger learning curve (base) and greater capabilities (peak). It's not possible to put all the options from the command line into a GUI, because piping allows you to stitch unrelated commands together to form, on the fly, entirely new "programs." for f in *.gz; do gunzip < "${f}" | tr '(' '\n' | awk -F "'" '{print $2}' | grep -v -e '\.foo$' -e '\.bar$' > "out_${f}.txt"; echo "${f}"; done The above command is pretty simple (and could possibly be improved, as many awk+grep combos can be), but I can't picture it in a GUI. Additionally, the above command will still work 10 years from now, whereas the GUI will have changed. So from that perspective, a CLI user who has already reached "base camp" will have a lower learning curve than a GUI user, who will continually have to re-learn new interfaces.

zo1 10y ago
That sounds like a really complicated command, requiring countless amounts of keystrokes and indepth knowledge of the CLI (piping, etc) and the commands (tr, awk) involved. Something that could easily be solved with a bit of copy-paste and regex usage in the right text IDE. I'd argue that you're comparing a seasoned professional at the CLI with an inexperienced IDE-user. It's always assumed that IDE and non-CLI users are basic and not at all adept at performing their tasks in efficient ways.
- randallsquared 10y ago
  If you had to program by point-and-click, I think you'd find it very slow and cumbersome (in spite of valiant efforts to make this kind of thing work, like lighttable). Your immediate reaction in the face of a task to do something conceptually simple, but with an annoying number of little steps, is to reach for a programming language and build it in your IDE. It would be more convenient, really, if you had an IDE that was specifically designed to work with all the other applications on your system, rather than just with whatever language you're using and its libraries. And there is such a thing: the shell! With things like tab-completion, history, aliases, and man pages, the unix command line interface basically already is an IDE. While I don't yet have enough experience with it to say for sure, it seems like PowerShell is intended to be similar, even going so far as to have a literal IDE (PowerShell ISE). There's a reason why IDEs always seem to have a built-in terminal, and why those which didn't at first seem to grow terminal-like capabilities, like VS Code's command palette.