Live data from Hacker News

You can't do that because I hate you

bvisness.me

71–80 of 216 posts

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

#71

I feel the same way about Rust unstable features. Either you can only use features that are "stabilized"—guaranteed to never change—or you can throw all guarantees out the window, and use the unstable, experimental version of the toolchain. This would be fine if "unstable" features were actually experimental messes, but all sorts of completely-benign utility functions are "unstable". You have to throw out all guarant…

> but is still unstable due to being "newly added". Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695

Right, it's nothing to do with it being "newly added".

That issue had been filed by its OP as a feature request. It then got repurposed into a tracking issue for the feature, but it's not following the standard tracking issue template that lists any blockers, stabilization steps, etc. (Compare to https://github.com/rust-lang/rust/issues/119364 that happens to be the newest "Tracking issue" atm.) Also since the OP didn't intend for it to be the tracking issue, it's possible they're not intending to do the rest of the bureaucracy to get it stabilized either, which is why it's stalled.

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

#72
post #52

Earlier quoted context omitted.

How about def __repr__(self): import warnings warnings.warn("Use exit() or Ctrl-Z plus Return to exit") return super().repr()

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.

You could use the same pattern as DeprecationWarning. It's suppressed by default and test runners like pytest enable it. A new ReplWarning could be enabled by interactive tools only.

I think I agree though: what you really want to special case is the situation where the user types precisely 'exit' at a REPL prompt, and that hack needs to exist further up the stack than in the implementation of __repr__.

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

#73
post #10

Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation. Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be g…

Writing code should be part of the OS as fundamentally as web browsing. You should get a cursor to write code, have a tree worth of files and have a button to publish the application as a single clickable program.

Anything else is a tribute to the rant.

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

#74
This rant is spot on and it's disappointing (but not surprising) that there are so many commenters here that don't get it. Honestly a few years ago I'm not sure I would have got it.

It definitely seems to be specific developers/communities that suffer from this "UX doesn't exist" sort of attitude.

I have also run into Rustfmt issues when trying to format single files (necessary for Phabricator's arc lint) and they have an unreleased "version 2" which we dutifully used from source... for 5 years. It turns out their plan is to never actually release this.

Python also seems to fuck over its users quite a bit. Two examples:

1. Setuptools has broken editable installs so that static tooling (IDEs, linters, type checkers etc.) can't work with editable installs. Because who would want to edit Python code with an IDE, amiright? Facepalm.

2. On Windows there is no python3.exe. Say goodbye to portable instructions/scripts. Why you ask? Well there's some obscure situation if you have multiple Python installs in your PATH and by some miracle that hasn't totally trashed your system already (relevant XKCD) that it would trash your system slightly more. So we won't ever fix that. And please don't point out that if you install Python from the Microsoft store it does install python3.exe.

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

#75

The unstable warning preventing you from wrapping the comments actually seems pretty reasonable to me. It is implemented, but there are probably edge cases where the proper way to wrap and retain the best possible formatting is still disputed. Since a lot of people format on save, via commit hooks or during CI, having this feature enabled as stable and _changing the behavior later_ would cause massive annoying diffs…

Gating it behind nightly is just bizarre though. Today's nightly, where the feature is available, will turn into 1.76 or whatever, but then the feature will become unavailable again. That is not how normal software works.

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

#76
post #44
post #32

Earlier quoted context omitted.

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.

Nothing is looking for exit. The REPL is calling repr(result) to show the result of the expression to the user. repr(exit) is the string "Use exit() or Ctrl-D (i.e. EOF) to exit". You _really_ don’t want repr(builtin) to have a side-effect like terminating the program. Stop being toxic and patronizing towards open-source developers out of ignorance.

ipython has specifically implemented an Autocall that allows you to exit by typing exit, quit, exit() or quit().

https://ipython.readthedocs.io/en/stable/api/generated/IPyth...

And repr(exit) also works fine:

> In [1]: repr(exit)

> Out[1]: ''

Maybe don't be so eager to accuse people of ignorance and toxicity.

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

#77
post #32

Earlier quoted context omitted.

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.

Perhaps a variable `exit = True` or something was defined previously, you don't want to have the language or REPL handle a myriad of possible corner cases, that would be very brittle. But a printing warning or lint-like suggestion is ok and actually useful.

It's not brittle. ipython has a special case for exit and quit. See my sibling comment. If you try to assign to exit you get a syntax error. Which is weird, but also fine in practice.

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

#78

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

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.

I believe /? started well before Windows, with DOS. IIRC, it was used because -? was common with Unix and CP/M (and DOS is basically half Unix and half CP/M) -- but Microsoft made the decision to have '/' be the switch character rather than '-'. So, /? was inherited from what came before, just slightly modified.

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

#79

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?

The conversation was about why the feature wasn't stable.

I have no idea how the Rust project organizes itself, but my guess is that this simply isn't a high enough priority for them, which would explain why it hasn't been made stable.

Large backlogs with stale are a common problem that software projects have.

Post reply on HN