Live data from Hacker News

You can't do that because I hate you

bvisness.me

181–190 of 216 posts

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

#181
post #127

Earlier quoted context omitted.

Except they didn't -- the result of a statement is turned into a string, and the string is printed. There are standard ways of turning objects into strings, and the `__repr__` function on the `exit` object returns that string. If you call that object then it raises an exception that triggers a REPL to cleanly quit. The code is here: https://github.com/python/cpython/blob/3.12/Lib/_sitebuiltin...

How about making `exit.__repr__` raise a CleanExit exception that gets caught in the outer REPL and then exits?

I'm fairly sure that having any object's `__repr__` throw an exception and exit would lead to even more confusion. Especially if it exits cleanly.

The object shouldn't be in scope anywhere other than the REPL, but that doesn't mean that something, somewhere, isn't stringifying everything because $REASONS and changing the behaviour won't cause an obscure "crash" somewhere unexpected and hard to debug.

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

#182
post #145
post #132

Earlier quoted context omitted.

> then became universally relied upon but somehow never enabled by default. Often it's not that universal; especially for older software there's a lot of variety in how people use it, and changing defaults can be hugely confusing for existing users. A lot of these (alleged) "don't suck" buttons are probably more subjective than you might think. The HDMI thing may be a security-related, or maybe there are is another r…

This is the chesterton's fence. Don't remove the barrier until you understood why the barrier was there first.

Thank you ! I for some reason tried googling this word last week and had "gate" stuck in my mind.

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

#183

Earlier quoted context omitted.

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...

Anything a user tries to do to ask for help is correct behavior that you need to support. It is a crime to tell the user “you asked for help incorrectly”. I suggest supporting at least all of the following: -h, -help, --help, -?, /h, /?, help, (if possible). Other flags don’t have to follow these rules, but I think help can be an exception. And maybe you should print the help any time the user enters a bad command.

Just to be clear, I'm not saying programs shouldn't provide help in response to "`-?`". It sounds like a good idea to me, because that would be an obvious guess for what a user would mean by putting a question mark there. And, as you say, some help is a good response to any unrecognized option.

I'm just saying that I hadn't realized programs did that. And I've been around a long, long time. I guess I'm just blind.

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

#184
post #98

Earlier quoted context omitted.

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...

> ... but don't get me started on people who think it's ok to use a single hyphen to start a multicharacter option There are quite a few older programs that do that, including ImageMagick and FFmpeg.

I'm pretty sure slavery was also going on when those programs started doing that. Doing it now is kind of different...

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

#185
post #70

> But it does neither. It acknowledges your intent and refuses it. It’s saying “I know exactly what you want to do, but you’re doing it wrong. Do it right next time.” Programming languages follow rules and programmers should follow the rules. Just because mistake is common doesn’t mean the language should incorporate it into its functioning. That makes inconsistent behavior and is a pain in the long run because inste…

> “Just because mistake is common” A good example of why having a language that is squishy to common errors is valuable. I still understood your point even though it’s grammar wouldn’t compile.

Postel's law (https://en.m.wikipedia.org/wiki/Robustness_principle) would seem relevant here:

"Be liberal in what you accept, and conservative in what you send"

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

#186

Earlier quoted context omitted.

But really it should just exit. There's really no reason why it shouldn't. I think telnet does something stupid along the same lines "I know you want to quit but please ask address me as Sir first".

There would be two ways to implement that, neither of which are particularly good. You could either have the exit function call itself from its __repr__ method, which an abstraction violation so egregious it introduces security vulnerabilities (imagine a logger printing repr(thing) to stderr, and someone sneaking the exit function in there for it to print), or you could special case it by making exit a reserved word,…

You're trying to think of problems, not solutions.

It's pretty easy to think of a good solution with few enough downsides that overall the design is much better:

In the REPL only, if you type "exit" and press enter, it quits.

No changes to Python semantics required. All code still works. Much friendlier UX.

I wonder what dubious justification the Python Devs would come up with to avoid implementing that (and therefore admitting they've been wrong for 20 years). They'd probably try and claim it is more confusing to beginners or some nonsense like that.

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

#187
post #51

Earlier quoted context omitted.

> you can continue to write about how much free software sucks. I think that's unfair. He wasn't writing about how much free software sucks, he was writing about how some of the rust tooling sucks. Even in the larger context, everything he wrote applies just as readily to proprietary software. These sorts of issues are everywhere.

The post itself isn't very generous; its title is “You can’t do that because I hate you.” You're right that "frustrating to use software" applies to proprietary software as well, but the author only gives very specific examples all of which involve open source.

> The post itself isn't very generous; its title is “You can’t do that because I hate you.”

Well, sure, the post is a good old-fashioned rant to vent his frustrations. The title is part of that. A well-written one, but nothing more than a rant.

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

#188

Earlier quoted context omitted.

The correct behavior is to print: Are you sure you want to exit? [y] and then you press enter again to exit.

The correct behavior from `repr()` isn't to do anything, including reading from stdin. That would break documentation generators, along with anything else that expects to be able to call `repr()` without side effects.

Nobody said anything about repr()? It's the REPL's job to handle this case and provide a good UX.

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

#189
post #100
post #89

Earlier quoted context omitted.

Humans aren’t programming languages. So programming languages don’t need to do everything humans do. It’s ok for things to be different. It’s cool that I understood what you meant when you said “it’s grammar wouldn’t compile” but I would definitely expect a compiler to barf unless you entered “its grammar.”

Programmers just haven't been able to make computers as good at language as humans are at language because they're not good enough at their jobs. There's no inherent reason that programming language statements need to perfectly follow regular grammars and have exactly defined vocabularies (functions) that compile to ASTs, etc. that's just the highest level of language technology we've invented. It has essentially no…

[deleted]

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

#190

Earlier quoted context omitted.

>It absolutely was No, there is no such absolute requirement that "newly added" functions cannot be stabilized. Off the top of my head: https://github.com/rust-lang/rust/issues/111544 `OsStr::as_encoded_bytes` was proposed in 2023-05, finished being implemented in 2023-07, stabilized in 2023-09, and released in 2023-11. > https://news.ycombinator.com/item?id=38801228 The reason attr of "newly added" is the reason to…

> No, there is no such absolute requirement that "newly added" functions cannot be stabilized. I never said so.

You did, and it was already covered in https://news.ycombinator.com/item?id=38801686 so I'm not going to repeat it.
Post reply on HN