41–50 of 111 posts
Pretty funny how the entire HN rallied together to solve some github issue on someone's personal repo. I'll try posting some of my bugs here to see if it'll work for me as well.
I don't know about "personal repo". My employer uses this tool to help test production code.
Pretty funny how the entire HN rallied together to solve some github issue on someone's personal repo. I'll try posting some of my bugs here to see if it'll work for me as well.
There's a power-law dropoff when it comes to follow-up submissions, since the hivemind craves novelty. But it would be fun to try. Maybe it could become a thing: Bug HN! The trick would be to make the bugs interesting: weird or hard, preferably both.
Pretty funny how the entire HN rallied together to solve some github issue on someone's personal repo. I'll try posting some of my bugs here to see if it'll work for me as well.
There's a power-law dropoff when it comes to follow-up submissions, since the hivemind craves novelty. But it would be fun to try. Maybe it could become a thing: Bug HN! The trick would be to make the bugs interesting: weird or hard, preferably both.
Earlier quoted context omitted.
It is hardly just "someone's personal repo". coveragepy has 1k github stars and is used by nearly every Python project under the sun.
Ive been a Python (among other languages) dev for about 25 years and I've never heard about this project until just now.
This bug, the HN thread and how hard it is to fix ( https://bugs.python.org/issue39318 ) is a pretty good argument against exceptions. A code that looks simple and correct has been hiding a very subtle bug because no one understood the implications of an arbitrary exception being thrown at any point under the caller. And of all the people who looked at the bug not a single one looked at this seemingly simple code and…
My question is: what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using Go's `!= nil` pattern or Rust's `?` pattern. My experience is that while its true that its easy to have bugs in implicit exception handling logic, its just as easy, maybe easier, to have bugs in the explicit boil…
I like Rust's `?` operator (and Swift's `guard` statement also), but it's worth noting that the bug wouldn't have existed in Rust in the first place because the file object wouldn't have outlived the scope it was defined in.
Earlier quoted context omitted.
There's a power-law dropoff when it comes to follow-up submissions, since the hivemind craves novelty. But it would be fun to try. Maybe it could become a thing: Bug HN! The trick would be to make the bugs interesting: weird or hard, preferably both.
Yep, when I sent out a call for help for a bug on HN in 2012, I got ~190 votes. When I posted the followup I got 5. It’s a little strange because for Reddit’s r/legaladvice it’s the opposite. Follow up posts can rank much more highly than the original.
Reddit on the other hand is passive entertainment, users are more interested in a novel problem that someone else dealt with.
Earlier quoted context omitted.
There's a power-law dropoff when it comes to follow-up submissions, since the hivemind craves novelty. But it would be fun to try. Maybe it could become a thing: Bug HN! The trick would be to make the bugs interesting: weird or hard, preferably both.
That hard part would be preventing HN from doing people's job / homework here.
The only bugs that HN will want to solve, will be the ones that should be solved by the community.
Earlier quoted context omitted.
That hard part would be preventing HN from doing people's job / homework here.
I think that would be more or less self-solving. Most homework bugs won’t be interesting, and most job bugs won’t be publishable. The only bugs that HN will want to solve, will be the ones that should be solved by the community.