[tialaramex]

CADT (the "Cascade of Attention Deficit Teenagers") is about rewrites. Jamie particularly doesn't like the habit of throwing away old bugs you didn't fix on the rationale that if they were really still a problem you should take the time to install the new program that doesn't fix them and report them again...

I don't think rewrites were on the map for Perl, except arguably for Raku (Perl 6 as was) and I don't think Raku's developers were intending to throw away bug reports and just begin over next year, indeed even though Perl 6 failed in its original goals Raku seems to still be going.

I wouldn't classify any of the spectrum of language evolution strategies for popular languages as CADT, even Python where Python 3 was needlessly incompatible this wasn't part of some larger plan it just fell out from what they wanted to do and was then mismanaged. Getting to a place where strings aren't just "some bytes, who knows if they're human text, good luck" is difficult enough to justify a lot of pain on the route there, notice how C++ has tried and failed several times already.

Jamie was thinking mostly of things like GNOME where this was (is?) a big problem.

[dinom]

When speaking colloquially, making a distincntion between a "rewrite" and a "language evolution strategy" sounds like nit-picking to me.

[tialaramex]

Sure, Jamie is concerned about the practical consequences. If your response to Jamie's 2019 bug report about X in WordCount was to close the ticket because you rewrote WordCount as WordCounter even though you've got no reason to think that might fix X, that's CADT. You are wasting his time. Don't use a "bug tracker" this way just write "This is broken garbage, I don't care" so that people know what's up.

I don't see that nonsense with the programming languages. Even something egregious like provenance. There's a problem, neither C nor C++ make any actual sense on a vaguely modern computer as described if pointers are just machine addresses. So the compilers invented "pointer provenance" to explain why what they actually do is reasonable - but no such fix is actually endorsed in the Standards. A defect report was raised in, I think, 2003. But it was never repaired. Nobody is under the impression that C++ 11 magically means this doesn't count, they didn't fix the problem, it's still there, and in C++ 14 and C++ 17 and C++ 20. It's even there retrospectively (this seems to be controversial for some reason but it's obviously true) in C89 we just didn't realise.

Under CADT the C++ committee would say, well, C++ 20 is new, you need to write a new defect report if you claim it's still broken. But they don't suffer CADT, their problems are altogether different.