Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't do that because I hate you

bvisness.me

Post reply on HN
Print view View original

21–30 of 216 posts

Re: You can't do that because I hate you

#21

Post by fifticon »

As a software developer, I am in wonder at the shape some software ships in. The last couple of days, I have toyed with Raspian bookworm together with my father.

Its menu contains an 'Add-Remove Software' GUI tool, which seems to be a thin and ill-conceived wrapper around apt-get (?). It combines several horrible choices, which conflict and clash perfectly. (1) it appears to insist on retrieving and building its entire list of apt packages, EVERY TIME YOU TRY TO OPEN OR OPERATE IT. (2) it doesn't give you any choice to CACHE this data, or any choice to skip this "refresh". (3) it takes five minutes or more to refresh this list, on our raspberry 3. (4) on any excuse you give it, it will refresh the list again. (5) once it succeeds in retrieving this insane 5-minute list, it presents it to you in an unnavigable manner - no sorting, no searching, no filtering, just a scrolling list with something like 10.000 apt packages.. page up/page down doesn't seem to work. For example, I naively pressed the cursor keys, wrongly assuming it would move my selection point in the 10.000+ list.. WRONG: Instead, it navigated a category-word-list, causing it to redo the 5-minute re-init. In effect, it because a 'trial and error game from hell', where you can attempt 10 wrong ways to navigate the list, each time being punished with a 5-minute "no you can no longer view the list you just waited 5 minutes to retrieve, you must now wait 5 minutes again for your next wrong attempt!" (6) oh yeah, and you are not allowed to view the partial list during load. I really really wonder who decided to implement that window in that maddening way??

In the end, I resorted to using apt search in the command line, which of course works perfectly, but not before having wasted about an hour together with my less-tech-savvy dad, trying to make the raspian package install UI "work" in the naive idea it would be easier for him to use :-/.

Re: You can't do that because I hate you

#22

Post by Arnavion »

0cf8612b2e1e wrote: post #16

Do what I mean, not what I said can be problematic for tools. That being said, the example where the devs left a link to file an issue to beg to restore functionality was maddening.

"Beg", and "passive aggressive" from TFA, is an unnecessarily emotional interpretation of that sentence. It's perfectly neutral. When they imported `cargo-vendor` into cargo they removed a feature that was not trivial to reimplement, so they asked for an issue to be opened so that they can see if people want it and so that someone can decide to implement it.

That message *could* be updated to point to https://github.com/rust-lang/cargo/issues/10310 instead of asking for new issues to be created or suggesting the old `cargo-vendor`. (The author of TFA already knows about that issue, since they commented on it before they published their article.)

(You might say it would've been better to let cargo-vendor remain separate instead of merging it into cargo, but the reason that was done was to ensure it would continue to work with changes to cargo. Indeed that is why the original cargo-vendor does *not* work properly any more.)

Re: You can't do that because I hate you

#23

Post by breischl »

burnte wrote: post #18
zem wrote: post #6

the trouble with "do what I mean" is that if the software guesses, and guesses wrong, the results are far worse than just not doing it. an "if you really meant to do this here is the correct incantation" error message seems like the best possible thing to do.

The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to…

The problem is that all the "do what I mean" examples become part of the spec, and then have to be supported forever. Whereas "prints an extra-informative error" is much easier to change.

Even for low hanging fruit. eg, `exit` in Python can be redefined as a variable - so if I do that and then type `exit`, should it print that value for me or quit the REPL? Is it better to guess, or just not encourage the user to do the wrong thing?

If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file?

You can probably come up with ever-fancier ways to work around this, but that takes effort, and more testing, and more code...

Re: You can't do that because I hate you

#24

Post by Hizonner »

burnte wrote: post #18
zem wrote: post #6

the trouble with "do what I mean" is that if the software guesses, and guesses wrong, the results are far worse than just not doing it. an "if you really meant to do this here is the correct incantation" error message seems like the best possible thing to do.

The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to…

Wait what? It would never occur to me to try to use a question mark as a command option at all. That's what "--help" is for. I'm actually surprised any program at all recognizes either form of the question mark.

... but don't get me started on people who think it's ok to use a single hyphen to start a multicharacter option, or don't let you put multiple single character options after the single hyphen...

Re: You can't do that because I hate you

#25

Post by nneonneo »

mrblampo wrote: post #3

First example seems odd? The author acknowledges that the two proposed alternatives (printing " " or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do…

Yeah, and it’s also useful to teach newbies about the usual syntax for doing things rather than introducing special-case magic. It would be _weird_ to just quit after writing a bare “exit”.

Re: You can't do that because I hate you

#26

Post by nneonneo »

Hizonner wrote: post #24
burnte wrote: post #18

Earlier quoted context omitted.

The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to…

Wait what? It would never occur to me to try to use a question mark as a command option at all. That's what "--help" is for. I'm actually surprised any program at all recognizes either form of the question mark. ... but don't get me started on people who think it's ok to use a single hyphen to start a multicharacter option, or don't let you put multiple single character options after the single hyphen...

Windows uses /? as the standard help flag, so maybe there are tools that are ported from that convention?

-h/--help are all I ever see in macOS CLI tools, in any case.

Re: You can't do that because I hate you

#27

Post by Hizonner »

breischl wrote: post #23
burnte wrote: post #18

Earlier quoted context omitted.

The problem with this argument is the low hanging fruit. EXIT is pretty unambiguous. I HATE that some tools the help argument is -? and others use --? when everyone COULD just print help on both is maddening, especially when you use the "wrong" one and it just says "do the other for help". You KNEW what I wanted, and didn't do it, just like the article says. Yes, mindreading is tricky, but sometimes you don't need to…

The problem is that all the "do what I mean" examples become part of the spec, and then have to be supported forever. Whereas "prints an extra-informative error" is much easier to change. Even for low hanging fruit. eg, `exit` in Python can be redefined as a variable - so if I do that and then type `exit`, should it print that value for me or quit the REPL? Is it better to guess, or just not encourage the user to do…

> If I make `-?` print help, what happens when I want to define `-` as "read the following text as input" and then users start getting bizarre behavior instead of the help file?

I'm not sure what that means, but if you're saying that you would want your program to interpret "-?" as though somebody had run it with no option at all and then provided a question mark on the standard input, that's really obnoxious and grounds for torches and pitchforks from all users.

Look, on a command line, a bare hyphen, given as an argument where there might otherwise be a filename, can reasonably mean "read from the standard input" or "write to the standard output", but only because it's been so common for so long. As an alternative to it, you can just use standard input/output by default, or you can just punt and make the user give you something like "/dev/stdin".

In any other context, a hyphen introduces an option that modifies normal program behavior. If it's a single hyphen, then the option name is a single character. If it's a double hyphen, the option name is the rest of the argument up to any equal sign. It should consist of complete words and be in `kebab-case`, not `snake_case`. But even if you violate those rules, it's a far more basic rule that an argument starting with a hyphen is an OPTION NAME, not arbitrary data.

And the options "-h", "--help", and I guess maybe "-?" and "--?" are pretty much universally used to mean "print help about how to use your program". Changing that is insane.

I know that code on on Windows does horrific stuff (including pretending it's freaking RSX-11 and using slashes of all things). I know that some really old UNIX stuff written in the bad old days also breaks the rules. But even those don't just arbitrarily redefine what the hyphen means. Redefining absolutely everything under the user, to the point where they can't even guess how to ask for help, is just crazy.

Re: You can't do that because I hate you

#28

Post by phs318u »

pluc wrote: post #5
mrblampo wrote: post #3

First example seems odd? The author acknowledges that the two proposed alternatives (printing " " or actually exiting) aren't great. The fact that the Python REPL provides a helpful hint seems like extra effort to make your life easier. This is especially notable given that in the next example, the author's complaint is about a command _not_ providing special guidance about the thing the user is probably trying to do…

Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos. When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.

Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.

Re: You can't do that because I hate you

#30

Post by froh »

interaction design for API and CLI, text based interfaces, is both hard and underdeveloped.

for example argparse and similar cli argument parsers _know_ the basic structure of the command line, but they don't provide it in machine table form, to interactive shells, so these could ask CLI tools: "hey, what do you expect at this point?"

Post reply on HN