Hacker News Reader

Comment by lquist | Hacker News Reader

CLI tools also have the advantage that their developers don't have to waste their time building and maintaining a useless GUI, but can instead use the time to improve the tool itself

Maybe it's just me, but I stopped reading here b/c this language struck me as unnecessarily antagonistic. Just some feedback.

View on HN

Well, it's also non-sensical. A CLI "interface" needs a lot of thought and work behind it, too, unless you want to end up loathed by your users as something like git is.

I don't think it is fair to say that git users loathe it overall. I enjoy using git, is this not a common experience?

I think it would be fair to say that a lot of people have a love/hate relationship with git.

Nope, I enjoy using it too. It might have a learning curve but afaic for a tool I use every day in my full time job productivity == good ux.

I regard the command line as a last resort if I can't do something in SourceTree. After spending time with a quality source control client, any command line interface feels like wading through quicksand.

This is likely an insult to git but it’s really similar to vim in that regard. After using ST2 or TextMate for so long, many people aren’t interested in learning (remembering?) how to use vim’s modals/commands.

A lot of people probably did start with SourceTree or a git plug-in in Visual Studio etc

My git workflow is very much tied to aliases. Customization is a hot thing for many people

(but really you should probably read the fugitive.vim docs in their entirety)

I go the other way. After twenty years of unix, the first few without X11, I have become very clear on what is cruft and history and what is actually making my life better.

SourceTree didn't exist when I started using git, but it makes the day to day operations of source control much easier and more precise than the command line. I spent enough years in a command line debugger that I am thrilled to have good debugger integration in my IDE.

It's easy to get into a machismo thing where you regard the shell and a teletype emulator as the "natural" interface to the computer, but it's really an incredibly abstracted interface already, and if you spend some time thinking about what you're actually doing, there's usually a GUI or library for an actual language that is what you really want. It just may not exist.

> It's easy to get into a machismo thing where you regard the shell

Unspoken presumptions about how the CLI is harder to use and GUIs somehow more natural (because graphics) is usually a sign of not understanding neither.

I spend most of my time in my editor and at the command line because it's easier to use. I don't have to learn thousands of little clickable widgets just to get the job done (which tend to change with every version of the tool).

That said, there are good and bad user interfaces with CLI tools, just like with GUI tools.

What's more interesting however, is how tools shape the way you think. CLI tools tend to feel like processing data, whereas with GUI tools you feel like maneouvering a large machine. The former tends to lead to fewer mistakes at scale.

Maybe I should learn how to use SourceTree, but using an abstraction over git kind of makes me nervous because I don't know what it's doing in the background. I suppose it would be pretty simple to learn what it's doing, but I just prefer knowing exactly what git commands I'm running.

I use the IntelliJ IDE family's visual conflict resolution tool so I guess it wouldn't be a big step to start using SourceTree. Realistically the only git commands I use are add, commit, rebase, push and pull.

I tried using GUI tools with Git when I started but after I took the time to learn the core operations, using the CLI became a lot faster and less scary.

After using other Atlassian products and being very disappointed, I can't even imagine using a GUI built by them.

Yup, it's much easier in many ways to use the git CLI than it is to use a UI.

emacs magit is the exception that proves your rule.

I've found a lot of people seem to hate it. I like using it in the command line personally, I find that 99% of the time I am using the same commands day in day out so I don't have to do anything particularly hard using the git CLI.

my absolute favorite command is: git add -p {insert some path here}.

personally, I don't know why people claim that mercurial is so much more intuitive, but I also don't think that something that is clearly a personal preference based on previous experience warrants an ideologic war.

If you like that just wait until you've tried

    git -c interactive.singleKey=true commit --verbose --patch

I think pijul is a counterexample to this claim. Category theory was used to find the mathematically optimal semantic (i.e. interface) for the category of files and patches (i.e. version control) and so the need to plan the command line interface has been minimized. A GUI would still require a substantial amount of work. I wouldn't go so far as to defend the somewhat exaggerated claim in the original article but I still think CLIs are easier than GUIs.

That doesn't really change the equation. You've just front-loaded the work into the categorical analysis of version control (and the implied "learn category theory" phase).

PS: I'm cheering for Pijul from the sidelines. :)

It is hardly a controversial statement, particularly in the context of something entirely text oriented like accounting.

It would be different if they were expressing the same sentiment for something like a 3D graphics editor...

Stopped here also. Bad sign. Different tools for different jobs, no need to get emotional.

Reply on news.ycombinator.com