Comment by pak | Hacker News Reader

Comment by pak | Hacker News Reader

As somebody continually interested in new and successful user interface ideas, the GUI one has me tickled pink:

http://catb.org/esr/writings/unix-koans/gui-programmer.html

because it is true that point and click will always suffer from a loss of expressivity in the way that this story so perfectly captures.

In a way, though, the koan also illustrates the flip side: if the expressive solution to something is a new language, how do you empower somebody who doesn't know or can't learn the language? The same way a person who goes to a foreign land tries to communicate basic ideas--by sign language, or symbols, or pictures. Sure, sometimes you will be misinterpreted and get peed on. And you can only handle the basics, like asking for food or directions; discussing philosophy or politics is probably out of the question. But it's better than not being able to communicate at all, and for many problems, people are happy with buying the pictographic toolkit that lets them do their job.

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.

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