[samhw]

I really dislike this ubiquitous attitude:

> My X broke while doing Y.

> Well, you shouldn't be doing Y with X. That's the real problem.

What does it matter? If people are doing Y with X, and you as the author of X can improve that path, then you should do that. Normative ideas about what people should be doing don't make a difference.

(You can see this a lot with the Go community. "Go doesn't support [language feature in common use for longer than Keith Richards has been alive]" "Well, you shouldn't be using [language feature in common use for longer than Keith Richards has been alive]" etc etc.)

[WesolyKubeczek]

I prefer this response:

> X wasn't really designed/is not very suitable to do Y. Why did you resort to do Y with X?

It opens a lot more possibilities and doesn't sound too hostile. Maybe you get to learn that Z which is made to do Y is broken. Maybe a part of that person's workflow requires X specifically. One can learn a lot of things this way.

Consider a person asking about using some surgical equipment on themselves (though they likely wouldn't ask it on StackExchange). Normally, you shouldn't perform surgeries on yourself, but what if you're stranded in Antarctica during the winter night and your life depends on it?

[jjoonathan]

Sure, do you want me to fix every other bug in the shitty Android 7 headunit it's running on while I'm at it?

If you don't pick your battles, you'll be doomed to fight for bad causes. Like this one.

[samhw]

It's worth adding that I agree with the main point that software should be fun, and Easter eggs should be allowed. I'd just prefer to argue for it on the grounds that (a) it's possible to make software fun without making it dangerous, rather than (b) software is fun, dammit, and if that crashes your plane then your plane was built wrong.