[thethimble]

It seems to me that a lot of popular Unix-originated software seems to have really high learning curves (Vim comes to mind).

I wish projects like git spent more efforts on things like GUIs.

Does anybody know of any Linux alternatives?

[p3ll0n]

My feeling is that people's strong preference for one interface and stern rejection to the other (GUI vs. CLI) are sometimes more psychological than technical.

The truth, I think, lies somewhere in the middle. CLI and GUI are essentially complementary modes of interacting with the computer. CLI is generally easier if you can remember the commands and the options, which is the case if you use them a lot. If you don't use certain functions a lot, a nice GUI (like Gitbox) can help you find them quickly. Of course whenever you have to repeat a command many times you should automate the process by writing a script, but in theory you could link that script to a button or menu item in a GUI. It doesn't have to stay at the command line.

[koenigdavidmj]

Apple's A/UX had a nifty interface feature: but if you double-clicked a UNIX command-line executable and a `Commando script' existed for that program, then a little window would pop up with the common options. It would show you the command line that it was putting together, and when you click OK, it would bring up a terminal and run the command in it.

Here's a screenshot of how it worked for ls(1): http://applefritter.com/ui/aux/images/cmdo-ls.gif

[piramida]

Then again, git is not a consumer software. Developer should spend some time and learn 5 commands to be productive.

But I find this interface interesting, even knowing all command line git this makes browsing history for reviews easy, nice tool.

[bruceboughton]

The command line is very efficient for input of commands, far more so than GUIs (though keyboard shortcuts mitigate this). GUIs are far more efficient for output of infomation though, especially verbose info like history, log files, etc. It surprises me that die-hard CLIers often fail to recognise this.

[mechanical_fish]

And, in fact, my git setup has evolved to rely on magit (an emacs-based git GUI of sorts) for some operations, and the command line for others, and GitX for others.

In this case the best tool, even for experts, is a hybrid tool.

[nailer]

>> a lot of popular Unix-originated software seems to have really high learning curves

>git is not a consumer software

I don't understand. What does being consumer software or not have to do with learning curves? Do you think developers don't appreciate simplicity or discoverability?

[piramida]

The more time is spent learning something, the better you can use it later. For consumer software, getting stuff done right now without any prior education is important. For developer tools, learning your tools is a necessity to perform the task better.

If you hide complexity behind a pretty UI, you end up with broken projects when something unexpected happens during push to production and nobody on your team spent time reading the manuals. So what I'm saying, I guess, is that steep learning curve for real tools is a good practice which should not be avoided. You don't want to be operating a chainsaw without reading the manual first.

[nailer]

Why do you think a command line interface helps learning more than a GUI one?

In your own language, isn't a CLI simply hiding an API in much the same way a GUI one is?

I used to teach people Linux Volume Management. Far more people understood what they were doing with a visual aid - either in, or outside the app - than those who ran the commands without any context to what was actually happening.