This is a good list, but it would be so much better with some (brief) pointers to counter-examples to the beliefs.
I honestly think this genre is horrible and counterproductive, even though the writer's intentions are good. It gives no examples, no explanations, no guidelines for proper implementations - just a list of condescending gotchas, showing off the superior intellect and perception of the author.
1. Everything said in every "Falsehoods Programmers Believe..." list is true.
The Falsehoods sound like ultimate truths only because of the literary genre. They sound like they were written by an expert who not only knows what's true, but also knows what we think we know, which kind of automatically takes him/her to the next level of expertise.
4. Every falsehood that is true CAN be accounted for.
5. Making your code compatible with a falsehood doesn't come with a price.
6. There are no falsehoods which are mutually exclusive.
Hmm.
A better approach would be to pick the list up and turn them into a collaborative work. Wiki, maybe?
The "Name" version is a good example of that, I can easily see how most of the examples on this list can be falsehoods.
On the other hand in TFA some of the affirmations leave me more perplexed. For instance, regarding color conversion: "converting from A to B is just the inverse of converting from B to A". I wonder what's meant here. Is it just a matter of rounding or is there more to it than that?
The catch 22 here is that if you understand this list then chances are you already knew about most of these gotchas.
So yeah, a pretty bad format. Now we just have to write "`Falsehood programmers believe about X` considered harmful".
Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have, so converting between them is often lossy and thus non-invertible.
Wouldn't that be overlapping but non-coextensive? Non-overlapping would be no colors in common between color spaces, which would be odd.