Live data from Hacker News

You can't do that because I hate you

bvisness.me

51–60 of 216 posts

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

#51

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…

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

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

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

How about

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

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

#53

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…

other posts pointed out the issue, it breaks certain markdown formatted comments (mainly tables).

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

#54
post #50

Rust is a great language but the developers suffer really badly from Reddit Intellectual syndrome. If they put some people with social skills at the forefront of relations with users it would definitely get more adoption.

Rust and TypeScript came onto the scene at about the same time. Microsoft manages TS more or less, Redditeurs manage Rust.

Fun to see which is thriving and which is still niche!

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

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

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

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

-? has been a common switch for decades. I've been implementing it (along with the synonyms -h, --help, etc.) in all of my programs since about the '90s.

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

#56
It’s a hard job that requires a lot of learning, failing, adapting, and growing. It’s frustrating, but getting good can only be done through endless grind. There are no cheat codes. After encountering and overcoming the roadblocks mentioned in the article, you grow keen to that class of problem, and next time, more quickly figure it out and move on.

An apprentice woodworker is going to fuck up a cut and have to spend hours rebuilding. An aspiring musician is going to pour hours into mediocre music that nobody listens to. A new software engineer is going to get lost in the sea of complexity built on top of the rapid growth and death of fads and doctrines and tools (good and bad) that is decades deep.

It’s fucking hard. I do think the pay reflects that, though perhaps is a biiiiit inflated. Regardless, shit ain’t easy. That being said, people generally quite enjoy sharing their knowledge, and helping the next generation of software people ramp up and kick ass, so there may be hope yet :)

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

#58

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?

I mean... check out the issue tracker for any project, open source or commercial. It's just how it goes when things aren't a priority. Happens all the time.

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

#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 some abstract purity.

It's not about complexity or technology at all. It's an attitude problem.

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

#60
post #52
post #37

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

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.
Post reply on HN