The idea is to give the reader a more complete picture. Often we skip over what we think is good about something and focus on the problems. I'm not saying you should come up with feel-good bullshit to make something fundamentally flawed seem like a good idea. I'm just saying that, when something is "mostly good but with one problem" we can learn just as much from why it's "mostly good" as we can from what the problem is.

I was attempting to give a demonstration of where notions of completeness-of-feedback such as this can lead by wrapping what could have been a concise point in needless verbose complexity. I am reminded of "How To Make Friends And Influence People", where it is advised that any criticism be couched in complements because people are easily manipulated by the positive emotional rush of a complement.

I'd like to think that such wrapping isn't needed on HN, and people are able to separate ideas or code from themselves for the purpose of accepting useful feedback. It is possible that this assumption is incorrect and should be abandoned, as people often have difficulty separating the two.

I find that I do not agree that positive feedback is as useful as negative feedback. Being told you are right certainly feels much better and is much kinder to the ego we all seek to stroke, but it is in being told you are wrong where is opportunity for growth lies. If we're clever, we can even manage to learn from the mistakes of others and avoid them ourselves. I am uncertain that forcing a "more complete" consideration of issues that are in the main not relevant is likely to improve the level of discourse or utility of feedback.

I'm going to avoid the issue of one person's fatal flaw being another's useless nitpick - it'll come up next time someone tries to be clever with crypto anyway.