... and that's why Matt S Trout is brilliant

I should really have made this a series long ago, but generally, I don't care enough to bother.

Yet today, my attention was directed at yet another brilliant FUD attempt by Matt S Trout, who seems to have made it his plan to badmouth me and my modules by spreading lies wherever possible. And it's very nicely done, by replying to a bug report on rt.cpan.org, where I usually don't see any replies because I don't bother to look.

And since it is picture-book FUD spreading, I decided to blog about it to improve critical thinking. Maybe. Hopefully. Well, it would be good if... one can hope, no?

Fear, Uncertainty, Doubt.

Fear, uncertainty, doubt, or in short, FUD, is a technique used to discredit products, people, or just about anything by spreading more or less outright lies that readers cannot instantly disprove - it's a classical disinformation strategy, and typically works very well, especially if your target doesn't defend itself.

With me as target, it usually works especially well, because I rarely bother to reply to the bullshit (some) people claim about my person or modules.

Anatomy of a FUD posting

So, what am I talking about?

Somebody else made a bug report about common::sense on rt.cpan.org, claiming FATAL warnings are fundamentally broken and common-sense needs to not use them, citing some documentation and discussion as evidence that clearly isn't. There are indeed many small things wrong with perl's warnings, and indeed, FATALising all of them does cause problems, but that isn't true in general.

The details of said bugreport are not important here, the point is that Matt S Trout, who is not affiliated with common::sense in any way felt he needed to reply (here quoted in full):

From: Matt S Trout

On Wed Jul 26 04:35:22 2017, <original submitter> wrote:
> Perl fatal warnings are fundamentally broken and should not be used.

They *can* be used fine, the rant you linked to on p5p is only one side
of the equation.

Note that strictures v2+ is very careful about which warnings it
fatalizes - we defatalize 'exec' specifically to avoid the fork/exec
issues, for example.

I would encourage common::sense to follow our lead in defanging the
riskier warnings, and encourage all common::sense users to switch to
strictures unless/until it's fixed.

There is an amazing amount of information in this message. Among other things, we learn or might be lead to believe:

• There is another, similar module called strictures.
• In version 2+ it gets it right by (among other things) defatalizing the exec warning.
• common::sense somehow doesn't get it right.
• strictures therefore takes a lead (in defatalising exec and others).
• strictures seems to be a drop-in replacement for common::sense.
• It's good to switch from common::sense to strictures, because common::sense is in need of fixing.
• common::sense isn't in the same "careful about which warnings to fatalise" category as strictures.

It's not always spelled out explicitly, but it's all there, or at least heavily implied, in the last two paragraphs. What he doesn't mention is that fact that he is self-advertising here (like, why would a professional climate change denier openly admit that he is paid by the oil industry?), but that isn't a big problem compared to the rest.

No, this sounds like some great advice to some poor Perl user who was (possibly) bitten by a buggy module somehow, pointing him or her (actually, everybody!) at another, better module. Incidentally written by Matt S Trout, who clearly only wants your best and isn't biased in any way.

Frankly, if you don't switch immediately (who actually uses common::sense besides me?), you should feel ashamed. At least I would, after reading his message: strictures seems to be the obvious choice, despite it being very different and therefore carrying a strong risk of breaking things that worked before.

Except, it's pure fabrication. Or rather, manure - practically pure horse shit really.

Here are some quick facts, easily verifiable (even for Matt S Trout, had he desired to be honest in his claims) by using the public repository which goes back to the earliest release of common::sense, and then some:

• common::sense was released 2009-07-09.
• No warnings were fatal in that release.
• Warnings were fatalised in version 2.0, released 2009-08-22. exec and many other problematic warnings were disabled.
• These facts and the rationale for the changes are clearly documented in both module documentation and Changes entries, which makes it easy to check.
• No release of common-sense, ever had exec fatalised, warnings are hand-selected and tested before releases, and problematic warnings have been removed over the years,
• According to its documentation, strictures was released almost exactly one year after common::sense, 2010-07-18.
• It apparently had exec fatalised in some or all version before 2.0, released 2015-02-26.

So, to summarise it, first, the actual reality:

common::sense did never, ever, had exec (and many other dangerous warnings) fatalised, and this goes back to 2009, while strictures only fixed this in 2015, almost six years later.

Then, Matt S Trout's fake reality:

Everybody should switch to strictures at least until common::sense follows the lead of strictures and fixes this.

Or, to bring it to the point, you should switch to his module because he fixed - in 2015 - what has always been correct in common::sense, and, eh, common::sense really needs to have this fixed.

That sentence not very sense, right?

Right, that is a common issue with FUD in general, and Matts public utterances specifically: when they collide with the facts, they utterly break apart, but boy do they sound good in isolation.

And that is what makes it classic FUD - he creates fear, uncertainty and doubt by hinting that common::sense somehow breaks your code, and his product is the better product because it is less broken. Making PR-type statements such as his module taking "the lead" is just the icing on the cake.

Now, I wouldn't call Matt out here if this was a singular case (I would call out his posting anonymously because it is such a nice case of FUD), but Matt does this constantly so it is fairly safe to assume it's not a simple oversight.

And he is really good at it - just re-read his original mail and see how nicely it packages his fantasy story in a few convincing paragraphs, impossible to see through it unless you actually go the long way of checking everything yourself instead of taking his presumably well-meaning advice for granted.

I should make this into a series - if only I had more time for this.

But to not end this blog entry as it started...

Why did I bother this time?

Well, I obviously don't give a shit whether you use common::sense or not, simply because I don't think common::sense is the only correct approach (I hope the FAQ makes this clear, but I failed before).

And I obviously don't stalk Matt and correct all his bullshit postings he makes - that would take far too much time :)

And, well, this is a really tiny thing, even less than the typical first-world problem, really.

So why now?

Well, first of all, my nose was basically pushed towards it by some folks, so I actually did have to read it. And to change working code to a whole different set of (partially fatal) warnings is not just risky, it's absolutely irresponsible. And, hey, it is such an archetypical example of the FUD genre.

I don't care that much about his FUD, but it is painful for me to think that somebody would follow his evil-minded advice and really replace use common::sense in working code by a different such module. Not because I think strictures is bad (it might be, it might also be better than common::sense - common::sense was made to fulfill my needs, not yours, after all), but because it has a high chance of breaking things, causing unnnecessary grief.

Yup. It's pure griefing, and I think griefing is only fun for the griefer.

So by all means, throw away common::sense in favour of strictures, but please don't do it for all the wrong reasons...