Hacker News new | ask | show | jobs
by noobermin 2806 days ago
CLI is like speech. Therefore, I don't get for why people think it isn't a friendly human computer interface since it is so close to the original human-human interface. And just like with speech, things can be ambiguous and easily mistook. The way we've dealt with speaking is just learning to speak clearer, not by turning everything we say into a movie.
4 comments

> CLI is like speech.

You must be kidding here. CLI is like speech only if imagine you are in a completely dark room full of people, and you can't talk to anyone unless you know their name and their job description, and although you can get a list of names, you need to figure out the job descriptions yourself.

On top of all that, everyone speaks a slightly different dialects, the adjectives and verbs are slightly out of order. And although that's not hard to memorize, you have to speak flawlessly in order to be understood.

Hmm? Apart from the "dark room" bit, how is it not analogous? "Get the bag of chips." Who? Which bag of chips? What is the context?

If there is a special context say, there is only one person and one bag of chips, which is similar to there being one file and one program to open it with certain options say, and you do it often enough, an apt shell user would bake that into either an alias or a short shell script. It's rare that I use more than 4 options on a command before baking it into a script. That's very analogous to language: things like slang, contractions, and sayings that make sense in certain contexts form naturally between people or even in some situations, are decided explicitly.

Of course, come times of ambiguity, then you have to explain yourself, just like when a script you usually use as a shortcut doesn't match a certain need, and you crack open the original call, which man helps with, and may be you write another script if need be.

That's entirely not true, the shell remembers a lot for you, the current state and the execution of commands can depend in any measure on environment variables and set them, also current directory and time of day, calling script, current history, the name used to call the script (if it has many links), your current line of input (in autocompletion handler).

The shell can also indicate it's state however you want - synchronously, asynchronously, before every input (PS1, PS2, etc.)

Mostly because when you forget to put a ./ in a conversation with me I don't burn your house down.
Alright, so I want to be careful here, because what I'm going to say will come off as elitist, and it is in a way, but it's helpful because it demonstrates why some of us don't feel the way many of you do, and how you can feel more comfortable if not productive in the shell.

Many of us who work extensively in the shell simply use best practices and hacks in order to not worry or deal with the problems that many of the people in the replies to my comment are expressing. One is "too many options" another, like yours, is "foo" will write zeroes to my drive, if I don't properly include the path. Another is "humans are more understanding of ambiguity" which ignores the myriad times humans do not understand ambiguity. (that said, of course humans understand ambiguity more than computers).

For the too many options, learn to use alias or scripts. The reason for 90 options in commands is not for humans, who can't process more than 5 items simultaneously in the mind's working memory. It's for being able to craft scripts that you can use can use for cases that suit you. Of course, it helps to memorize a couple, but I don't think anyone expects any normal user to remember all of mplayer's options. That's what man is for.

For the ./ bit, there's a reason that . is not in your path. There's a reason there's a path in the first place and it's to avoid doing things you'd rather not. If you worry about being having scripts you write being mistaken based on the path, there is a very smart fix for that, don't name your scripts things like delete,rm,dd,unlink,mount, etc that can be mistaken for commands elsewhere. If you use scripts, best to append an ending to them (.py for python scripts, even .sh for shell scripts although I admit I don't do this) so you can distinguish them. That way, when you try to run doit.py, it won't accidentally doit, at worse, it will complain about not knowing what doit is.

A lot of these bits I learned just by using the terminal. May be there are classes out there, which is great too. Regardless, understand that CLI's have existed for decades and people are extremely proficient in them, and it has nothing to do with people being smarter or more elite than others, they just have practice. The same can be said for any profession, be it carpentering, repairing cars, or selling and presenting. Of course, CLIs can always be improved, but don't discount them completely. There is a reason they have persisted, it's not merely tradition and intertia.

I love the command line for some things and would never trade it, but like anything, I believe it's about using the right tool for the job, and frequently, humans work well with shiny gadgets over memorizing spells.
We've also dealt with it by being extremely flexible, error-tolerant, and context-aware on the parsing end.
> I don't get for why people think it isn't a friendly human computer interface

Because the human is not friendly and has near 0 margin for error.

> The way we've dealt with speaking is just learning to speak clearer,

No, the way we've dealt with that is also to understand less clear speech.

Doo u undrstnd mi? None of those words were even actually correct yet I imagine most people had a good guess at what I said.

An unfriendly human interface that acts like many CLIs:

Hello I'd like a burger

NOT UNDERSTOOD I'D

Hello, can I have a burger?

NOT UNDERSTOOD CAN

Hello, burger?

ERROR ITEM BURGER NOT FOUND

Hello, cheese burger please

Good evening sir, thank you for placing your order.

How about

man 6 mcrestaurant

mcrestaurant offers... cheese burgers