Hacker News new | past | comments | ask | show | jobs | submit login

This unfortunately follows the conventions of the genre called "Falsehood programmers believe about X": http://spaceninja.com/2015/12/08/falsehoods-programmers-beli...

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.




I agree, I think this format works when the subject matter is trivial enough that it's easy to construct counter examples yourself once the contradiction is pointed out.

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".


> I wonder what's meant here. Is it just a matter of rounding or is there more to it than that?

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.


> Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have

Wouldn't that be overlapping but non-coextensive? Non-overlapping would be no colors in common between color spaces, which would be odd.


Yes. I didn't realize that difference between my intermediate language and the output language of these comments :)



[flagged]


Presumably the post being replied to was at the top of the page at the time of the reply.


So what if it was? The reply still doesn't address the point raised by kazagistar. I looked at kdeldycke's list and some examples in fact do address it, but there's nothing in his comment to indicate it. It's not an unreasonable question to make.


Perhaps there is scope for a list of Falsehoods Programmers Believe About Falsehoods Programmers Believe.


Let's start then:

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.


3. Every falsehood that is true should be accounted for.

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.


> Every falsehood that is true

Hmm.


2. There exists a "Falsehoods Programmers Believe" list that is entirely true.


Love that idea! Please help me compile a list there: https://github.com/kdeldycke/kevin-deldycke-blog/blob/master... :)


Aren't the falsehoods inherently guidelines? They give you an idea of which assumptions aren't safe to make.


It's true that examples and explanations would be nice and make for a more helpful guide, but those can usually be found with a bit of legwork, whereas the gotchas themselves are often only discovered by trial and error. In essence, don't look a gift horse in the mouth.

A better approach would be to pick the list up and turn them into a collaborative work. Wiki, maybe?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: