Live data from Hacker News

You can't do that because I hate you

bvisness.me

191–200 of 216 posts

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

#191

Earlier quoted context omitted.

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.

`exit` is simply a function. The text it displays at the REPL now is simply the result of calling `repr()` on that function. Adding a special case would make the REPL more complicated, and would make it inconsistent. Technically it wouldn't even be an REPL anymore, since it wouldn't be doing the "P" part for certain objects. And the special case would break tools that rely on the REPL behaving consistently.

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

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

Ah yes, and when I write a new language all os vendors should be forced to integrate it, or I should be blocked from inventing a new language. None of this installing code that others wrote. If I want to write a language my only option should be writing an os from the kernel up.

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

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

I think the point is not whether certain tool does things in certain way. It's the lack of thought about how the user interacts with the tool and whether or not the particular way of doing it makes the interaction easier. Too often "technically correct" is considered the best kind of correct even though the resulting interface is infuriatingly unpleasant to use. It's hard to please everyone, but it is useful to remind people to at least try to be more thoughtful about this aspect.

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

#195
post #37
post #35

Earlier quoted context omitted.

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…

Thanks for this, it never occurred to me it used __repr__ for the message. I just added this to my .pythonrc

    exit.__class__.__repr__ = lambda _: exit()
    quit = exit
Edit, you also need this in your bashrc:

    export PYTHONSTARTUP=~/.pythonrc

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

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

I agree with the rant, but not the examples. It pisses me off when programmers add "features" which forces users to deal with them. For example, pipenv always prints a message when you activate an environment (I don't know if it's still the case because I don't use it anymore). I had to migrate a cronjob which ran a Python script and sent an error email if anything got printed to stderr. This is a pretty standard Uni…

> pipenv decided to always print to stderr that the environment got activated, even though it's not an error.

This is a pet peeve of mine. I see it every so often and every time, I wonder if the dev wasn't familiar with the norms of the platform or if the dev was being malicious.

Either way, it doesn't speak well for them.

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

#197

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.

Not all patches will be automatically pulled into the next stable release. Features can stay in nightly for a long time while their bugs are getting ironed out.

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

#198

Earlier quoted context omitted.

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

Thanks for validating my comment. I thought I was going crazy in that thread.

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

#199

Earlier quoted context omitted.

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.

You're right.

Rants are fine, and I've been frustrated by software too many times to count.

I'm being a bit protective because I would feel hurt if someone wrote that "I hate them" about some of the software I've worked on for free and open sourced.

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

#200
post #59
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…

Not having a feature is fine. Kind of having a feature but hiding it behind obnoxious gatekeeping is not fine. Features that are buggy or inexplicably complex is not fine. Some open source projects get this right, and others don't. Some projects don't care about wasting the user's time. Or they berate the user for wanting to do something in the 'wrong' way. Or they break things that worked just fine in the pursuit of…

>Features that are buggy or inexplicably complex is not fine.

really depends on so many factors that this isn't a good general sentiment. Sure, if this is a professional grade tool targeting corporate, it better be polished or have excellent support for when stuff breaks. If it's some small scrappy tool handling a complex task with all kinds of edge cases I can give some leeway to the UX and even some very esoteric use cases.

vector graphics comes immediately to mind. I won't be too griped if Krita as a FOSS has some subtle bugs. I can at the very lest throw out an issue to at least bring awareness. I'd be much more miffed if Illustrator had some issue given how closed up and hard to contact Adobe is if you're not a million dollar business (not to mention Adobe's general philosophy of how they approach software these days).

Attitude is a factor, but I do take into account the problem space when evaluating feature completeness.

Post reply on HN