4 ms·

I wish HN had a downvote option for submissions

8 points by hivolix 6y ago

I think a dislike button option could be helpful to stop spreading biased and false information like this recent highly upvoted HN submission (please see its comments why not credible) : https://news.ycombinator.com/item?id=24108109 Link title is: "C will never stop you from making mistakes"

verdverm 6y ago
There is a downvoting feature for comments when you have enough HN karma points. 500 iirc
- hivolix 6y ago
  Thanks. I updated the title to be more precise
pwg 6y ago
Once you accumulate a "small karma threshold" (quote from the HN FAQ) you can 'flag' submissions. Flagging is the closest to a "dislike" option available. But it is suggested to use it for items that are off topic. The better way to make sure items you find to be "positive" make the front page is to upvote everything you think deserves to get there. Upvote the positive, ignore the negative, and the negative will fade from view. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html [edit]: add additional clarity
- deleted 6y ago
  [deleted]
lemoncurd 6y ago
bias is not bad
tmaly 6y ago
To be honest, I think the down vote is abused sometimes. It would be nice to see who down voted a comment. Transparency could help correct the abuse.
- hivolix 6y ago
  I agree
- giantg2 6y ago
  Or make a comment necessary to downvote so hopefully there is an explanation. I have gotten downvotes and wonder why.
  - yen223 6y ago
    I reckon 90% of downvotes I made were accidental. The buttons are really tiny on a mobile phone!
    - giantg2 6y ago
      I know the upvote button is small. I'm a noob so I don't have a downvote button so I can only guess they put it right next to the upvote one.
      - yen223 6y ago
        The downvote button is below the upvote button
        giantg2 6y ago
        Oh, that makes sense.
- zzo38computer 6y ago
  I think what would be helpful is to have an option to ignore all voting for purpose of sorting, so that you can vote if you want to, but if you don't like to, you can disable that option and it will display only in the chronological order (it could hide the voting options too if you wanted to, but I suppose it doesn't have to do).
  - tmaly 6y ago
probinso 6y ago
I know there exists one because one of my posts has -4 lol
keiferski 6y ago
Disagree strongly. Downvotes add a level of toxicity that should be avoided as much as possible. Ignoring an undesirable link is better than having a negative reaction to it. The lack of a downvote button also forces any critics to leave a comment explaining their criticism, rather than just mindlessly pressing the down arrow.
kazinator 6y ago
Credible or not, the article was evidently written by someone on the ISO C committee, which makes it noteworthy and topical for HN. > please see its comments why not credible Most of the comments are of low-quality; I can hardly find a single nugget of anything that stacks against the opinions given in the article. I'm on the fence. I'm actually surprised that, for instance, strerror doesn't return "const char * ". However, the proposed change is a low-value fix. Except for the dynamically generated cases for unknown error numbers, the strings are static text that can be represented by write-protected string literals. GNU Linux: $ cat strerror.c #include <string.h> #include <errno.h> int main(void) { char *x = strerror(ERANGE); *x = 0; return 0; } $ gcc strerror.c -o strerror $ ./strerror Segmentation fault (core dumped) This arguably not as good as a compile-time check. Though in some ways it is better because it cannot be casually dismissed with a cast! No matter what tortuous paths the returned pointer takes through the bowels of the program, and how it is converted, at the end, if it is dereferenced to perform a write, the machine will catch it. In any case, the main point is that we don't have a heisenbug here. If the offending code executes at all, there is a predictable and instant access violation. The insidious problems in C programs that people struggle with are the ones where something is inadvertently modified without detection and causes a misbehavior at some later time, in an unrelated part of the program. The const qualifier helps with this, if people use it judiciously in their code bases. Adding a sprinkling of const to a code base that was developed without const can find some of these kinds of bugs. There is no chance of that happening here; the hardware protects the strerror strings, and will kill the program at the first misuse. Which means, people have already debugged those situations, and all we will get from the const is a bunch of annoying false positives. No, not every hardware has a MMU for the above to be possible; ISO C is not just for platforms with memory management. But anyway, we have those platforms. Maybe people should port as much of their code as possible to more robust platforms with better tooling and test the heck out of it. A code base that has been Valgrind-ed and Asan-ed to smithereens on Linux, but is running on some MMU-less embedded chip, is probably in better shape than similar code that hasn't been so treated. ISO C is a portability standard; it can help people write code which is portable, which then allows it to be exposed to the tools and approaches available from diverse platforms. Not every kind of bug has to be caught on every available platform. It's okay to use one platform that has good diagnostics and tools to harden some code, which then gets ported to some obscure chip using a compiler that has poor diagnostics, and where the run-time has very little error checking in the hardware or libraries. Okay, now here is an alternative opinion. strerror obviously should return a const-qualified pointer. What, I'm surprised that it doesn't; how did that even happen? Anyway, we can do that without introducing any false positives for existing code. The reason is that people compiling legacy code should be using the compiler options to select the legacy dialect. So, that is to say, compiling code in C90 or C99 mode would produce the old strerror declaration without const. If old code is breaking for you due to a new standard, it's because you're inappropriately failing to restrict the dialect to the one in which the code was written! C99's introduction of // comments broke contrived C90 code like this: z = x//*divide by y*/y ; But, in 2020, I can still compile that with "gcc -std=c90" or "gcc -ansi", and it nicely divides x by y. The "can't make the slightest change that will diagnose or break old code!" knee-jerk reaction betrays an ignorance about compiler support for multiple historic standards.

8 points by hivolix 6y ago

verdverm 6y ago

There is a downvoting feature for comments when you have enough HN karma points. 500 iirc

hivolix 6y ago
Thanks. I updated the title to be more precise

pwg 6y ago

Once you accumulate a "small karma threshold" (quote from the HN FAQ) you can 'flag' submissions. Flagging is the closest to a "dislike" option available. But it is suggested to use it for items that are off topic. The better way to make sure items you find to be "positive" make the front page is to upvote everything you think deserves to get there. Upvote the positive, ignore the negative, and the negative will fade from view. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html [edit]: add additional clarity

deleted 6y ago
[deleted]

lemoncurd 6y ago

bias is not bad

tmaly 6y ago

To be honest, I think the down vote is abused sometimes. It would be nice to see who down voted a comment. Transparency could help correct the abuse.

hivolix 6y ago
I agree
giantg2 6y ago
Or make a comment necessary to downvote so hopefully there is an explanation. I have gotten downvotes and wonder why.
- yen223 6y ago
  I reckon 90% of downvotes I made were accidental. The buttons are really tiny on a mobile phone!
  - giantg2 6y ago
    I know the upvote button is small. I'm a noob so I don't have a downvote button so I can only guess they put it right next to the upvote one.
    - yen223 6y ago
      The downvote button is below the upvote button
      - giantg2 6y ago
        Oh, that makes sense.
zzo38computer 6y ago
I think what would be helpful is to have an option to ignore all voting for purpose of sorting, so that you can vote if you want to, but if you don't like to, you can disable that option and it will display only in the chronological order (it could hide the voting options too if you wanted to, but I suppose it doesn't have to do).
- tmaly 6y ago

probinso 6y ago

I know there exists one because one of my posts has -4 lol

keiferski 6y ago

Disagree strongly. Downvotes add a level of toxicity that should be avoided as much as possible. Ignoring an undesirable link is better than having a negative reaction to it. The lack of a downvote button also forces any critics to leave a comment explaining their criticism, rather than just mindlessly pressing the down arrow.

kazinator 6y ago

Credible or not, the article was evidently written by someone on the ISO C committee, which makes it noteworthy and topical for HN. > please see its comments why not credible Most of the comments are of low-quality; I can hardly find a single nugget of anything that stacks against the opinions given in the article. I'm on the fence. I'm actually surprised that, for instance, strerror doesn't return "const char * ". However, the proposed change is a low-value fix. Except for the dynamically generated cases for unknown error numbers, the strings are static text that can be represented by write-protected string literals. GNU Linux: $ cat strerror.c #include <string.h> #include <errno.h> int main(void) { char *x = strerror(ERANGE); *x = 0; return 0; } $ gcc strerror.c -o strerror $ ./strerror Segmentation fault (core dumped) This arguably not as good as a compile-time check. Though in some ways it is better because it cannot be casually dismissed with a cast! No matter what tortuous paths the returned pointer takes through the bowels of the program, and how it is converted, at the end, if it is dereferenced to perform a write, the machine will catch it. In any case, the main point is that we don't have a heisenbug here. If the offending code executes at all, there is a predictable and instant access violation. The insidious problems in C programs that people struggle with are the ones where something is inadvertently modified without detection and causes a misbehavior at some later time, in an unrelated part of the program. The const qualifier helps with this, if people use it judiciously in their code bases. Adding a sprinkling of const to a code base that was developed without const can find some of these kinds of bugs. There is no chance of that happening here; the hardware protects the strerror strings, and will kill the program at the first misuse. Which means, people have already debugged those situations, and all we will get from the const is a bunch of annoying false positives. No, not every hardware has a MMU for the above to be possible; ISO C is not just for platforms with memory management. But anyway, we have those platforms. Maybe people should port as much of their code as possible to more robust platforms with better tooling and test the heck out of it. A code base that has been Valgrind-ed and Asan-ed to smithereens on Linux, but is running on some MMU-less embedded chip, is probably in better shape than similar code that hasn't been so treated. ISO C is a portability standard; it can help people write code which is portable, which then allows it to be exposed to the tools and approaches available from diverse platforms. Not every kind of bug has to be caught on every available platform. It's okay to use one platform that has good diagnostics and tools to harden some code, which then gets ported to some obscure chip using a compiler that has poor diagnostics, and where the run-time has very little error checking in the hardware or libraries. Okay, now here is an alternative opinion. strerror obviously should return a const-qualified pointer. What, I'm surprised that it doesn't; how did that even happen? Anyway, we can do that without introducing any false positives for existing code. The reason is that people compiling legacy code should be using the compiler options to select the legacy dialect. So, that is to say, compiling code in C90 or C99 mode would produce the old strerror declaration without const. If old code is breaking for you due to a new standard, it's because you're inappropriately failing to restrict the dialect to the one in which the code was written! C99's introduction of // comments broke contrived C90 code like this: z = x//*divide by y*/y ; But, in 2020, I can still compile that with "gcc -std=c90" or "gcc -ansi", and it nicely divides x by y. The "can't make the slightest change that will diagnose or break old code!" knee-jerk reaction betrays an ignorance about compiler support for multiple historic standards.