Live data from Hacker News

You can't do that because I hate you

bvisness.me

161–170 of 216 posts

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

#161
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 worst is a few tools where when you type: the_command -foo ...and the tool responds with: -foo: No such option. You probably meant --foo Well shit! Thank you for that burst of empathy. If you, developer, are that confident that's what I meant why couldn't you just make both inputs do the same thing? You went out of your way to make the code handle -foo, but only to have the program fire off that snide remark inst…

Given the number of times I run

    git psuh
To be told "you probably mean push"... yeah it'd be easier for me if they went ahead and accepted the typo :D

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

#162
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 worst is a few tools where when you type: the_command -foo ...and the tool responds with: -foo: No such option. You probably meant --foo Well shit! Thank you for that burst of empathy. If you, developer, are that confident that's what I meant why couldn't you just make both inputs do the same thing? You went out of your way to make the code handle -foo, but only to have the program fire off that snide remark inst…

Because you may have meant --f=oo or -f -o -o, both of which are standard unix interpretations of single-dash multi-character flags (e.g. ls, ssh). Or maybe the newest version added the -foo flag.

And if you've got something like 'sed' overwriting the input file (-i), it'd better make sure the flags are exactly as documented.

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

#163
post #149

Earlier quoted context omitted.

At In-n-Out, you have to say a magic chant to have them make the food taste better (and even then it still tastes bad).

What’s the magic chant?

Wild fries or something, and a triple burger, there's a hidden menu that is double the calories.

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

#164
The example with experimental features is soo weird. It is like the author knows why experimental features exist but trying to play confused to fit the narrative.

OK, nighty builds. So, some features could be coded, but haven't been tested for a long enough time to say "this feature is rock solid and the behaviour is good for all combinations of code". In the formatter, we probably would not wanna change the behaviour of a flag once it goes stable (and in the formatter there are always several ways to do anything, because it is just how code is).

So, there are more or less two options when adding new features: only merge a feature branch when you are 100% happy (that could make releasing hard) or have a feature behind a flag and document it is an experimental. In the real world - having feature behind a flag is good. For some reason people assume that open source projects have a huge team, and all their time is free. So, adding a new feature to a formatter is "easy and trivial" (and make that feature stable is "trivial" too).

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

#166
post #123

Earlier quoted context omitted.

What if you aren't in the REPL? Using __repr__ at all seems like an abstraction violation. It should be the REPL's job to layer on special casing for exit.

The actual behavior is indeed a bit ridiculous: >>> print('%r' % str) >>> def whatisit(x): ... print('It is %r' % x) ... >>> whatisit(min) It is >>> whatisit(exit) It is Use exit() or Ctrl-D (i.e. EOF) to exit Excuse me? IMO if the REPL wanted a friendly feature like this, it should be a generic REPL feature, not a hack applied to the function exit.

Also a bit funny:

    >>> def get_function():
    ...     return exit
    ... 
    >>> a = get_function()
    >>> a
    Use exit() or Ctrl-D (i.e. EOF) to exit

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

#167

The author provides very surface-level criticism of two Rust tools , but they don't look into why those choices were made. I'm ignoring the Python complaint since it's discussed in other comments. With about five minutes of my time, I found out: wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue…

5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?

Code reformatting is, apparently, surprisingly hard. This classic article has popped up on HN a few times over the years: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr... (one reappearance at https://news.ycombinator.com/item?id=30566111)

So I can understand why such a feature remains behind an experimental flag. "But you are not touching code, only reformatting comments!" - well, not just thta. Adding whitespace and N+1 effectively empty lines will at some point cascade into whatever logic the wider code formatter will have to consider. The number of edge cases must be non-trivial.

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

#168

Earlier quoted context omitted.

> Right, it's nothing to do with it being "newly added". It absolutely was, but now it seems to be mostly that the stabilization process is tedious enough that nobody has done it yet for this tiny utility function. There are tens of other tiny utility functions in the same situation that have been sitting for years, I run into them all the time. The whole situation surrounding "unstable features" is just super disapp…

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

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

#169

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.

Yes, I completely agree. If you want to teach the user the rules, then you follow the rules. The problem with the Python example is that they DID special-case it, but in an unhelpful way.

How is it unhelpful? It literally tells what to do.

Is it too hard to write exit() or press Ctrl+D after having incorrectly entered exit?

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

#170
post #2

>I understand that might be confusing for newcomers, and exiting might be too destructive. But denying you the normal REPL behavior and denying you the ability to exit is just insulting. Sentence 1 provides a clear justification for the behavior. Then sentence 2 declares, by bare assertion, that it's "insulting". I find sentence 1 more persuasive than sentence 2.

The correct behavior is to print:

Are you sure you want to exit? [y]

and then you press enter again to exit.

Post reply on HN