Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the lack of context and safety kind of is baked into CLI.

GUIs can be a guided experience, the documentation is in the UI itself. There's nothing external to look up, which greatly lowers your productivity unless you have an excellent memory and can do it once and still remember it months later.

CLIs in theory can be, but most things these days assume that you know exactly what you want to happen and the computer is a passive tool that does exactly what you say.

Technically rm could ask for confirmation and then trash, but the confirmation step would get in the way of scripting. You could add a -y flag as some commands do, but if simplicity, scriptability, and maximum efficiency for power users are the goal, you probably won't.

On the GUI you can assume it's interactive, and the generally accepted way of design is to aim for the lowest common denominator, not power users.

GUIs can present unrelated information and make changes to the UI, some users will be annoyed but nothing will break, and those of us without a good sense of space will hardly notice if stuff is moved...

On the CLI as it currently ls and cd are separate actions and combining them would make lots of useless output in scripts. On the GUI, LS and CD are the same thing, double clicking a folder takes you to a new page and there's no such thing as "being in a folder" without the contents displayed.

Making a CLI as safe and discoverable as a GUI would involve reinventing half the entire ecosystem. Possible in theory, but then you'd be maintaining a bunch of stuff on your own, because CLI users seem to like the idea of computers as passive tools for computing, and there might not be much interest.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: