Hacker News Reader

Comment by loewenskind | Hacker News Reader

It's funny, but nonsensical. A counter would be to tell a story about one student explaining every last detail of some device and the other student still not understanding, while the GUI student just shows a picture and everything is instantly clear.

IMO command line "interfaces" are only suitable to programs. A command line interface is basically a language for communicating with the program. I'd rather not spend the time learning a substantial amount of the language just to be able to use the program for common tasks.

An example of this is revision control systems. I always personally liked darcs but was limited to the command line interface. When I tried out GitX I made the switch instantly after being loyal to darcs for years. Sadly there are still things you have to use the command line for in GitX but there is no reason it has to stay that way.

View on HN

Ah yes, the old "one true way" argument. It is sad to such great foolishness in someone who has used git and darcs.

Perhaps you should re-read the koan without the assumption that it is saying "GUI is bad". It is really about the "only one way and that way is GUI" attitude.

I think you're engaging in a logical fallacy. Using a "GUI" isn't "one true way" as there are a near infinite amount of ways to structure a GUI.

Command line tools often use graphics to display their results and GUI tools often show their results in textual form so the main difference between a command line interface and a GUI interface is how to provide input. With a GUI I have to click in the right place to make actions happen. This puts more onus on the developer to make sure everything is where it is expected. With a command line tool I have to read a document or help output about how to use it and memorize this information if I wish to be efficient.

I'm not saying there should be no command line. It's simply my view that the command line should be treated like XML: not for human consumption. I think this would also potentially make command line tools even better at providing an interface for scripting tools if this was the only expectation placed on them.

gitref.org makes it really easy to understand and use git, at least it did for me. No graphical tools required.

>gitref.org makes it really easy to understand and use git, at least it did for me.

I don't avoid the git command line as much as I can because I don't know it or am afraid to learn it. I have to use it since GitX can't do everything I need yet (and the picture seems even worse on windows). I use the GUI as much as I can because it's a much more efficient work flow. In a GUI like GitX it is much less effort to do patch commits because I can just view the changes and select the lines I want. It takes several different commands to accomplish this same functionality (a git status to see what's changed, git add -i on the file, e on the hunk I want, edit the hunk via vi, write the file).

>No graphical tools required.

Except there is. When you do "git -p file" (which I do a lot and would not have switched without this capability) you are put into a graphical editor to pick which parts of the hunk to commit.

"Except there is. When you do "git -p file" (which I do a lot and would not have switched without this capability) you are put into a graphical editor to pick which parts of the hunk to commit."

Not if $DISPLAY is cleared ;P

Reply on news.ycombinator.com