Live data from Hacker News

You can't do that because I hate you

bvisness.me

31–40 of 216 posts

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

#31

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 enti…

Certain Linux UI stuff can be an opinionated death by a thousand papercuts. Probably because most Linux devs don't dogfood their own stuff as they just stick to the command line anyway, so there's less incentive to fix the UI issues, if nobody in the dev chain is actually using it.

I remeber when Linux GUI users were asking for a "Right click -> run/open as root" feature just like in Windows, and the devs basically said something along the lines of "we're not gonna do it just because the way Windows does it means it must be wrong; if you need to run stuff as root it means you're a poweruser so you should use the comand line anyway; you're welcome". Linux Mint was the first and only to have this feature in the GUI early on, then came the other DEs who ceded defeat to sanity.

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

#32

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.

Agreed, but in that case the tool shouldn't be trying to detect what I mean. Why look for 'exit' only so you can print 'no actually, it's exit() dummy'. If you're parsing for it then just bloody do it! Otherwise I'll get a syntax error and realise that 'exit' isn't the right way to exit. And I'll do a quick search myself. But explicitly looking for and detecting my intention and then ignoring it is just dumb.

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

#33
post #18
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…

i agree about the help flags, but not about `exit`, given that `exit()` is implemented as a function and not a repl builtin. python functions do not get run unless called with `()` and it's not worth introducing that inconsistency in there.

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

#34
This assumes 100% competent and knowledgeable users. Nobody is in every field, and so the question is "do we freely hand out footguns, or should we put a safety in place"

In some fields, the decision is easy. We're by now culturally aligned that shipping encryption libs with bad APIs or a default-on footgun option is a bad idea.

Clearly, with less impactful tools, we still have more debate ahead of us. I'm hoping that we'll realize at some point that proper engineering is always fail-closed[1] if there are destructive consequences. Yes, it might temporarily inconvenience some, but it prevents harm to more.

Ultimately, the question is "Who is more important, you, or the rest of the world".

[1] fail-open if you're EE. We're so bad, we can't even decide on terminology.

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

#35
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…

I'd have done both the hint and the actual result. Like this: >>> print >>> exit Hint: Use exit() or Ctrl-D (i.e. EOF) to exit >>> This way, it does do the thing you literally asked for, but also does help a newbie out.

It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.

The regular Python REPL doesn't distinguish between stdout and stderr (perhaps it should!), but you can embed it in things like Jupyter notebooks that do.

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

#36

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 enti…

[deleted]

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

#37
post #35

Earlier quoted context omitted.

I'd have done both the hint and the actual result. Like this: >>> print >>> exit Hint: Use exit() or Ctrl-D (i.e. EOF) to exit >>> This way, it does do the thing you literally asked for, but also does help a newbie out.

It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used. The regular Python REPL doesn't distinguish between stdout and stderr (perhaps it should!), but you can embed it in things like Jupyter notebooks that do.

> It should print the first to stdout and the second to stderr. That's completely consistent with how stdout and stderr are usually used.

That makes sense from a unix tool perspective, but not from a python repl perspective. The repl's behavior is to print the result from the last executed statement. For the exit function, the __repr__ method was overwriten to print the message. That way when you type in "exit", the last value would be exit (the function), and the overwritten __repr__ method causes the help message to be printed. There's no way to have it print to both without adding in some repl specific hacks.

    >>> exit
    Use exit() or Ctrl-Z plus Return to exit
    >>> exit.__repr__()
    'Use exit() or Ctrl-Z plus Return to exit'

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

#38

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 enti…

> I really really wonder who decided to implement that window in that maddening way??

They implemented it in a test environment with either an emulated device pulling packages from the host, or pulling packages over a gigabit network from a local cache on their LAN, or on a high-speed fiber connection where it took far less than 5 minutes to retrieve the list.

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

#39
post #5
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.

> A world where that's the standard would be chaos.

We saw this play it with web browsers in the late 90s early ‘aughts where they’d do their best to render what they thought you meant if your html was wrong, and it was indeed chaos.

Strict systems with strict inputs makes for a better overall ecosystem.

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

#40
post #28
post #5

Earlier quoted context omitted.

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.

How do you feel about java/c++ compiler that give hints like "missing semicolon"? Clearly it knows what's wrong. Why not automagically fix that for you[1]?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Post reply on HN