Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There’s a certain kind of dev that just gets a superiority complex about using CLI stuff.
Which means a person doesn’t need to become that good with the command line, they just need to learn the commands long enough to write the script and then never think about those commands again.
I’ve written a lot of scripts, but if someone asked me to do what the script does at the CLI with no man pages or anything, nope. Can’t do it, and I think that’s probably a good thing.
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
I’d argue the GUI has the lowest barrier to entry as it eliminates the need to learn any syntax or look up which switches to use.
If someone use a particular CLI tool often it can be quick and easy to do something, but for the occasional use, a GUI is much easier, assuming it has the required features a person needs. Can I use sed to replace a bunch of text in a file, sure, but it’s probably be faster and easier to use a text editor since I’m not using sed everyday.
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
I agree, for a power user there is some value there.
I’ve used the git CLI, but find it a bit tedious. I also find a lot of value in the GUI providing an easy diff reference before a commit, at least in the app I use most of the time. There are some things the GUI can’t do, or it’s too weird to do, so the CLI is still handy.
I agree only when your job function is specifically geared around those tools… Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn’t mean 99% of most debugging tasks isn’t easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI… But for most software devs… CLI gdb isn’t valuable.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
The terminal can remember everything you ever did. Forgotten the command you wrote 2 months ago? You can do a search for it with a tool like fzfand run the exact same command again.
Communicating with others. GUI programs require step by step instructions, often accompanied by screenshots while CLI may be copy/pasted.
Combining programs together. There are a few different techniques for combining CLI programs to search/format output, use secrets without ever having them in the clipboard or on disk, monitor something frequently/constantly etc etc
So while I agree with you that there’s plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It’s not a superiority complex, it’s a fact. I’m not a minimal wage worker pushing buttons I don’t understand. I’m not a technician who learnt your shitty software to do the most basic tasks.
That’s the gold standard as far as I’m concerned. Haven’t used the ytdlp-gui yet, but it’s simple stupid… I might want a few more switches (more exactly the extract audio/subtitles) to turn
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. “Sync” comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don’t permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I’ve seen people end up using the git GUI like a “save” button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I’ve definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I’m trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!
Tools that use a GUI are just as good (if not better) than their CLI equivalents in most cases. There’s a certain kind of dev that just gets a superiority complex about using CLI stuff.
The big thing you can do from the command line is script it.
My file explorer has a GUI and is scriptable ;)
Which means a person doesn’t need to become that good with the command line, they just need to learn the commands long enough to write the script and then never think about those commands again.
I’ve written a lot of scripts, but if someone asked me to do what the script does at the CLI with no man pages or anything, nope. Can’t do it, and I think that’s probably a good thing.
Indeed, the problem with gui apps is when you can’t script them!
I always loved alfred on osx, then loved scripting rofi on linux, only to come back to osx years later and find alfred can’t be invoked with stdin options. It’s damn shame….
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
That said, jetbrains git integration is awesome.
I’d argue the GUI has the lowest barrier to entry as it eliminates the need to learn any syntax or look up which switches to use.
If someone use a particular CLI tool often it can be quick and easy to do something, but for the occasional use, a GUI is much easier, assuming it has the required features a person needs. Can I use sed to replace a bunch of text in a file, sure, but it’s probably be faster and easier to use a text editor since I’m not using sed everyday.
It also depends on the specifics — in many cases when a GUI is just a wrapper over the CLI tool, it is instructive to learn the CLI, similarly how you are a better programmer if you know about at least a layer beneath the one you are programming at (e.g. you can reason about this usage of hashmap because you roughly know what it does).
It is probably the most visible in git, but if you can only do commit and push from a GUI, just please learn the CLI as well. You don’t have to use it, but understanding it is important and the GUI may abstract away too much from you.
I agree, for a power user there is some value there.
I’ve used the git CLI, but find it a bit tedious. I also find a lot of value in the GUI providing an easy diff reference before a commit, at least in the app I use most of the time. There are some things the GUI can’t do, or it’s too weird to do, so the CLI is still handy.
I agree only when your job function is specifically geared around those tools… Otherwise high quality guis are more valuable.
Just because I can do everything in gdb that I can do in visual studio doesn’t mean 99% of most debugging tasks isn’t easier and faster in visual studio. Now if my job was specifically aimed at debugging/reverse engineering there are certain things that gdb does better on the CLI… But for most software devs… CLI gdb isn’t valuable.
There are some massive intrinsic advantages of the CLI though, that apply for everyone, not just leetcoders:
fzfand run the exact same command again.So while I agree with you that there’s plently of elitism around the CLI, you do yourself a disservice if you try to avoid it.
Just no. CLI can be automated, which makes it superior. It’s not a superiority complex, it’s a fact. I’m not a minimal wage worker pushing buttons I don’t understand. I’m not a technician who learnt your shitty software to do the most basic tasks.
My gold standard app is a CLI where I have the option to visually add the flags. I’m thinking of the ytdlp-gui type programs.
Which yt-dlp GUI do you use?
On windows I was using youtube-dl-wpf
That’s the gold standard as far as I’m concerned. Haven’t used the ytdlp-gui yet, but it’s simple stupid… I might want a few more switches (more exactly the extract audio/subtitles) to turn
Aside from automation, CLI can support significantly more complicated apps reliably. It can also be tested more reliably.
GUIs are better for anything simple, and good UX designers can make a moderately complex one, but anything like server administration/git/configs are 100x better on CLI
I don’t know, a tool we use at my work has a git GUI integrated, and it breaks all the time, lol.
This depends a lot on the GUI and the tool. Some cli tools are great alone or for scripting, others benefit from the extra attention to ux and exposure of options that a GUI can offer
For git in particular, I encourage juniors to learn and use the CLI. I find that GUI git clients often do some or all of the following:
Use non-git terminology that ends up being confusing. “Sync” comes to mind as a frequent offender, I can think of several incompatible things that could refer to.
Ignore the useful ability to stage your changes
Don’t permit or encourage a review of the changes
Implement only the basics and make remediation of branching issues difficult
In the worst case, I’ve seen people end up using the git GUI like a “save” button, blindly commiting and pushing the current state of their code, including to-be-removed print statements and other cruft. Yeah, git cli is a bit complex compared to that, but you gain a lot for that added complexity.
That said, I’ve definitely jumped into a git GUI from time to time just for a visualization of whenever branching snafu I’m trying to untangle. None of the above invalidates GUIs if you take care to still understand the underlying tool properly!