Is it just pedantry? Even in the strongliest of practical strongly typed languages, two functions with the same signatures might fail to return on some inputs in the new version that it didn't in the old.
That's a practical distinction I care about that can't be computed.
Earnestly: Yes. But there may well be programming tasks or jobs that they are suited to, for which no understanding of boolean logic will make no difference on a day to day basis.
Do you have a citation for that first claim? It fits my prejudices so neatly that I'd like to see the proof. I've tried to google a little for it with no success, so my apologies for any imposition.
> And frankly, if you can't point to bugs or performance issues, it's likely you don't need to be refactoring in the first place!
I feel this is a lack of clarity around the word refactoring. Improving the code in a way that fixes bugs is "bug fixing", in a way that makes it do its job faster is "optimisation" and in a way that improves the design is "refactoring".
Of course one can do several of them at the same time. And add features, at least in the small.
Refactoring can be a valuable activity for bits of a code base where the cost of change could be usefully reduced. It's useful to have a word that can be used to describe that activity that isn't commonly conflated with bug-fixing or optimisation.
As someone who's quirked the odd sceptical eyebrow at base metabolic rate charts, that's a helpful way of looking at it. Thanks!