Ask HN: Good examples of interactive command-line user experience?

Post by Sir_Cmpwn » Tue, May 23, 2017, 2:40 PM UTC

exDM69 wrote: post #34

Sir_Cmpwn wrote: post #24

Earlier quoted context omitted.

Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.

All of what you say is correct. git is great in many ways and not too difficult to use once you grok the internals. But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things. Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command…

Post by git-pull » Tue, May 23, 2017, 2:41 PM UTC

d0mine wrote: post #36

zie wrote: post #32

There was a talk at Pycon 2017 about this [0] that's pretty good. He(amjith) goes through several examples with his favorite being bpython [1] and even covers writing such a thing in python live on stage. [0] https://www.youtube.com/watch?v=hJhZhLg3obk [1] https://bpython-interpreter.org/

Python prompt toolkit is worth a look https://github.com/jonathanslenders/python-prompt-toolkit/bl...

Post by neovintage » Tue, May 23, 2017, 2:44 PM UTC

pricechild wrote: post #26

neovintage wrote: post #15

I would recommend that you check out the Heroku CLI Style Guide: https://devcenter.heroku.com/articles/cli-style-guide There are many different teams within Heroku that need to provide interactions for developers via CLI whether its for dynos or data services. The guide was a way to codify building a consistent interaction that all product managers and engineers could follow. Disclaimer: I work for heroku.

One thing not mentioned there is exit statuses. I think they're just as important a thing to think about, up there with what arguments to accept.

Post by open_bear » Tue, May 23, 2017, 2:49 PM UTC

Sir_Cmpwn wrote: post #24

souenzzo wrote: post #6

git

Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.

Post by Sir_Cmpwn » Tue, May 23, 2017, 2:59 PM UTC

open_bear wrote: post #47

Sir_Cmpwn wrote: post #24

Earlier quoted context omitted.

Sad to see this in the grey. Git is unintuitive to those who don't understand it. If you read about its internals and learn how it works, the command line gets much better. It's well documented and it gives you a whole lot of power and insight into the inner workings of the VCS. Things like launching your editor to do more complex commands, plugging a script into git bisect, these are all great design choices.

There is even a science paper showing that "for most people Git is a magic black box they whisper obscure spells into": http://www.ppig.org/sites/default/files/2014-PPIG-25th-Churc...