6 ms·

Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard. Especially si

by OskarS 7y ago

Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard. Especially since there's a trivial way to get rid of the warning: just write "18" instead of "2^16", if you REALLY intended the xor. Also: it's incredibly naive to think that "bad programmers" are the only ones that would make a mistake like this. I'm very familiar with all C/C++ operators and know perfectly well that the caret represents xor, but I could easily imagine myself slipping and writing 2^16 instead of 1 << 16, because that's how the rest of the world writes exponentials. Let he/she who has never written a typo and had the compiler save them cast the first stone.

mehrdadn 7y ago
> Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard. In all honesty while I don't agree with this particular instance, the reasoning isn't ridiculous. If we assume it's true that it'd only affect bad programmers, then you probably wouldn't want to add it, since it'd increase the false positive risk and/or otherwise potentially get in the way of everyone else. (Kind of like how you wouldn't make cars start honking when they're turned on as a means of protecting against bad drivers, even thought that might well save lives.) Some tools just need to assume some base level of expertise to be effective.
- OskarS 7y ago
  If you want to make the argument "this is a bad warning because it will cause many false positives", then that's a perfectly valid argument to make. It doesn't really apply in this case, but it's a valid argument to make against a warning being added. That's not the reasoning given. The reasoning given is that since only bad programmers would make this mistake, it shouldn't be a warning at all, since those kinds of programmers "will create a lot of other problems regardless". That is nonsensical. You could make the same argument against ANY warning. The whole point of a warning is to alert the developers that, while their code technically follows the rules of the language, they've probably made a mistake.
- mikeash 7y ago
  You snuck in a second premise to the argument: that it will increase the false positive risk. And if we accept that premise, we don’t need the other one. Bad programmers are the ones who need the most help from our tools. Saying there’s no need for a warning because only bad programmers will benefit is like saying there’s no need for crossing guards because only stupid children get killed crossing the street.
  - estebank 7y ago
    I think you just helped me understand where the objection comes from. The people against this warning seem to feel infantilized by these type of warnings, much in the way you're comparing it to crossing guards for children. My view, and I guess the view of people arguing for these kind of warnings see them like seatbelts: a mild annoyance that is very much worth it.
    - mikeash 7y ago
      Sounds about right. I don’t really get it myself. As a professional C and C++ programmer, every mistake is punished severely by the computer and I want all the help I can get in avoiding them. Warnings aren’t annoying, what’s annoying are one-in-a-thousand crashes that only happen on someone else’s computer.
    - ken 7y ago
      I would say this seems more like airbags: a safety feature which requires no work on the user's part, 99.999% of the time, and which you might not even know exists up until the point when it jumps into action to save you.
antirez 7y ago
Let's way that warnings are very important, they cause noise, so such noise should be deserved for instances that are really common mistakes among the population of programmers that have some clue. There are many errors like the one above that can be made by clueless programmers for which you can't emit a warning at all, like misusing postfixed/prefixed increment operators or alike.
- q3k 7y ago
  Let me clarify - you're saying that just because we can't catch all programming mistakes means we shouldn't bother catching any, even though this is a pretty solid example of one that would be worthwhile and easy to do?
  - antirez 7y ago
    Nope, I think that to catch trivial errors like that is mostly unhelpful, what bothers me about that is that could emit a warning in perfectly ok code, for instance as a result of a post-processing that maps symbols to literal values. Given that 3^5 will never be the result of some programing genuine mistake, but means not knowing the language, I think it is worse to create issues to people that know what they are doing (emitting a useless warning), than trying to advice people not knowing the basic of the language. Anyway such mistake will be realized very soon by the inexperienced programmer.
- ken 7y ago
  The vast majority of people writing C that I've seen in the past 20 years are occasional C programmers. We write in higher-level languages, and occasionally drop down into C to troubleshoot a library we're using. I haven't been a full-time C programmer since late last century. I see C code these days and think "huh, so that's valid in C now". I get that you are a full-time C programmer, but unless you're volunteering to take on all my C troubleshooting work, this seems almost punitive. Like building a balcony with no railing, because nobody would just walk off a ledge -- and yet, sadly, professionals still die from falls. To say that all such people are "clueless", regardless of skill or training or experience, is to fall back on the old test pilot mentality: the good survive, therefore, if you didn't survive, you (retroactively) must not have had The Right Stuff after all. Joel Spolsky explained the reasoning more eloquently than I could: "Now, even without going through with this experiment, I can state with some confidence that some of the users will simply fail to complete the task, or will take an extraordinary amount of time doing it. I don’t mean to say that these users are stupid. Quite the contrary, they are probably highly intelligent, or maybe they are accomplished athletes, but vis-à-vis your program, they are just not applying all of their motor skills and brain cells to the usage of your program. You’re only getting about 30% of their attention, so you have to make do with a user who, from inside the computer, does not appear to be playing with a full deck." I trust myself and the people I work with, but I still wear a hardhat when they're working overhead, and I tie all my tools to my belt when I'm working at height. It's the clueless people who don't learn from the mistakes of the past.

by OskarS 7y ago

mehrdadn 7y ago

> Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard. In all honesty while I don't agree with this particular instance, the reasoning isn't ridiculous. If we assume it's true that it'd only affect bad programmers, then you probably wouldn't want to add it, since it'd increase the false positive risk and/or otherwise potentially get in the way of everyone else. (Kind of like how you wouldn't make cars start honking when they're turned on as a means of protecting against bad drivers, even thought that might well save lives.) Some tools just need to assume some base level of expertise to be effective.

OskarS 7y ago
If you want to make the argument "this is a bad warning because it will cause many false positives", then that's a perfectly valid argument to make. It doesn't really apply in this case, but it's a valid argument to make against a warning being added. That's not the reasoning given. The reasoning given is that since only bad programmers would make this mistake, it shouldn't be a warning at all, since those kinds of programmers "will create a lot of other problems regardless". That is nonsensical. You could make the same argument against ANY warning. The whole point of a warning is to alert the developers that, while their code technically follows the rules of the language, they've probably made a mistake.
mikeash 7y ago
You snuck in a second premise to the argument: that it will increase the false positive risk. And if we accept that premise, we don’t need the other one. Bad programmers are the ones who need the most help from our tools. Saying there’s no need for a warning because only bad programmers will benefit is like saying there’s no need for crossing guards because only stupid children get killed crossing the street.
- estebank 7y ago
  I think you just helped me understand where the objection comes from. The people against this warning seem to feel infantilized by these type of warnings, much in the way you're comparing it to crossing guards for children. My view, and I guess the view of people arguing for these kind of warnings see them like seatbelts: a mild annoyance that is very much worth it.
  - mikeash 7y ago
    Sounds about right. I don’t really get it myself. As a professional C and C++ programmer, every mistake is punished severely by the computer and I want all the help I can get in avoiding them. Warnings aren’t annoying, what’s annoying are one-in-a-thousand crashes that only happen on someone else’s computer.
  - ken 7y ago
    I would say this seems more like airbags: a safety feature which requires no work on the user's part, 99.999% of the time, and which you might not even know exists up until the point when it jumps into action to save you.

antirez 7y ago

Let's way that warnings are very important, they cause noise, so such noise should be deserved for instances that are really common mistakes among the population of programmers that have some clue. There are many errors like the one above that can be made by clueless programmers for which you can't emit a warning at all, like misusing postfixed/prefixed increment operators or alike.

q3k 7y ago
Let me clarify - you're saying that just because we can't catch all programming mistakes means we shouldn't bother catching any, even though this is a pretty solid example of one that would be worthwhile and easy to do?
- antirez 7y ago
  Nope, I think that to catch trivial errors like that is mostly unhelpful, what bothers me about that is that could emit a warning in perfectly ok code, for instance as a result of a post-processing that maps symbols to literal values. Given that 3^5 will never be the result of some programing genuine mistake, but means not knowing the language, I think it is worse to create issues to people that know what they are doing (emitting a useless warning), than trying to advice people not knowing the basic of the language. Anyway such mistake will be realized very soon by the inexperienced programmer.
ken 7y ago
The vast majority of people writing C that I've seen in the past 20 years are occasional C programmers. We write in higher-level languages, and occasionally drop down into C to troubleshoot a library we're using. I haven't been a full-time C programmer since late last century. I see C code these days and think "huh, so that's valid in C now". I get that you are a full-time C programmer, but unless you're volunteering to take on all my C troubleshooting work, this seems almost punitive. Like building a balcony with no railing, because nobody would just walk off a ledge -- and yet, sadly, professionals still die from falls. To say that all such people are "clueless", regardless of skill or training or experience, is to fall back on the old test pilot mentality: the good survive, therefore, if you didn't survive, you (retroactively) must not have had The Right Stuff after all. Joel Spolsky explained the reasoning more eloquently than I could: "Now, even without going through with this experiment, I can state with some confidence that some of the users will simply fail to complete the task, or will take an extraordinary amount of time doing it. I don’t mean to say that these users are stupid. Quite the contrary, they are probably highly intelligent, or maybe they are accomplished athletes, but vis-à-vis your program, they are just not applying all of their motor skills and brain cells to the usage of your program. You’re only getting about 30% of their attention, so you have to make do with a user who, from inside the computer, does not appear to be playing with a full deck." I trust myself and the people I work with, but I still wear a hardhat when they're working overhead, and I tie all my tools to my belt when I'm working at height. It's the clueless people who don't learn from the mistakes of the past.