4 ms·

Sure, but it would still be nice to have at least one such example. Looking at the rest of the discussion thread here on HN as of now it's still only hypothetic

• mannykannot 4y ago
  It would be even nicer to see convincing evidence that it is not going to be a problem.
  • teddyh 4y ago
    You can’t prove a negative.
    • mannykannot 4y ago
      There is no largest prime.
      • teddyh 4y ago
        Using that model, we can prove conclusively that, since a behavior has changed (a warning printed), it might cause problems. Therefore, we cannot prove that it cannot cause problems. What we would really like, though, is an actual problem shown to exist. Just like in mathematics; it’s one thing to prove that it’s impossible to prove something could not exist, but another thing entirely to show it existing.
        • mannykannot 4y ago
          You are overlooking something here: I never said anything about proof. I explicitly wrote 'convincing evidence' because proof is too demanding! It's rather amusing how you have flipped from saying "you can't prove a negative" to an argument for the certainty of observable effects and the probability of consequences! (you wrote might cause problems, but everyone can see that's an unrealistic understatement of the implications of the argument you are using.) The NASA managers prior to the Challenger crash thought that what they really wanted was something showing them an actual problem existed. Erring on the side of caution is generally prudent, even in relatively small matters.
          • teddyh 4y ago
            > everyone can see that's an unrealistic understatement of the implications of the argument you are using If nobody can show an actual existing problem, or even an example of reasonable code someone could have written which would be impacted by a the printed warning, then yes, I would think that I was charitable when I wrote “might cause problems”.
            • mannykannot 4y ago
              What does 'charitable' mean here? Generous towards what person or point of view? As you say you have conclusively proved that there is a non-zero probability of there being problems, the use of 'might' is already trying to persuade that this possibility is next to zero.
              • teddyh 4y ago
                I thought I was being charitable when acknowledging that there might be a chance of a problem, when I in fact believe there not to be one.
                • mannykannot 4y ago
                  If you were presented with an actual case, would you change your mind over whether introducing this warning is advisable?
                  • teddyh 4y ago
                    Yes, of course. If the case is reasonably likely to occur in the real world and have real world impact, that is. And I would assume that the GNU grep developers would agree with me.
                    • mannykannot 4y ago
                      I think that is a very reasonable position to hold. It would only be the rejection of plausible cases, on the basis of no actual case having been uncovered, that I would take issue with. When assessing the downside of a proposal, there should not be much, if any, difference between how highly plausible and certain consequences are assessed. If we could prove there would be no downside, then plausible problems could be ignored as merely hypothetical, and there would be no need to posit offsetting benefits. The question the GNU grep developers might want to consider is whether the supposed upside will have sufficient material consequences for their purposes.
• cestith 4y ago
  Here's one example. This is in code my team inherited a long time ago, and there are many more like it. databases=`find /var/lib/mysql -type d | sed 's/\/var\/lib\/mysql\///g' | egrep -v 'mysql|test|performance|schema'`
  • TillE 4y ago
    That doesn't do anything with stderr, so it doesn't break.
    • cestith 4y ago
      It does output to STDERR an extra warning.
      • int_19h 4y ago
        But that doesn't actually break your script, because backticks only capture stdout.
        • cestith 4y ago
          But it changes the behavior of the script in the UI. It can cause things like cron to send mail. It can cause other things wrapped around the script that are capturing both STDOUT and STDERR from the script to capture extra content. Any tool that's monitoring STDERR and expecting it to be empty may consider that an erroneous run, which may impact other scripted decisions. It's a breaking change in multiple circumstances, even if you don't consider extraneous warnings shown to a user manually running a script a breaking change. Does that code look like something you'd log into a system and manually run on a regular basis? Does it maybe instead look like one layer of a legacy automation stack absorbed into other tools?
    • deleted 4y ago
      [deleted]