I prefer Shog9's term "curiosity" questions to "why" questions; we're talking about why something is the way it is; not necessarily why something happens.
I think Lance Roberts' examples fall into the latter category rather than the former. Python code running faster in a function is a provable assertion unlike why various Vim commands behave differently. I believe Lance's examples are both definitively on-topic for Stack Overflow and constructive; so I will concentrate solely on the former set of questions.
My usual problem with curiosity questions is actually the answers, or at least their potential scope. I think Stack Overflow, and Stack Exchange, should follow an evidence-based approach. I believe that any statements or assertions made should be provable, either through the scientific method or by quoting others. The "problem" with the answers to curiosity questions is that this is not always possible.
Having said that, I strongly agree with Shog9's answer to whether there are too many Stack Exchange sites. I believe that Stack Overflow users should "be a bit jealous" of their site; chucking interesting questions to other sites because it's on-topic there as well diminishes the scope of the site and does indeed turn it into a "debugging service"; something that I would much rather avoid.
I do think there's a thin line here that can be walked down effectively. I'm going to use on-topic/constructive and their antonyms interchangeably here (my apologies but they're almost the same thing when writing about this subject).
The Examples:
Oracle <> , != , ^= operators
This question is effectively why do !=, <> and ^= behave differently. According to the "curiosity question police"1 this would be deemed to be off-topic and not constructive. There is absolutely no possible way of answering that question unless you think that Oracle is going to open up about its internals2.
But, the question has a number of great answers that answer the question in a few different ways; some refuting the original evidence for the supposed differences by quoting sources, others that prove using an evidence-based approach to do the same.
I believe this question is firmly on-topic for Stack Overflow.
Why does Firefox treat Helvetica differently from Chrome?
In its original form this question might be on-topic/constructive there's certainly an answer and people on the site who might be able to answer it. My problem with this is that, to a certain extent, you rely on specific people to answer the question, which I find uncomfortably close to asking a question of a specific user. It is possible to answer the question if the people involved have previously written up this question in a blog post or it's been chatted about somewhere. A user without direct experience can then evidence their answer.
In its new form the question hasn't changed that much but is, I believe, now firmly on-topic and constructive. The change is the difference between asking for an answer discussing what the effects a lack of web typography standards might have on the implementation of such in various browsers to asking what is happening and where.
Why doesn't C# support the return of references?
I believe this question is firmly on-topic but not constructive for Stack Overflow (I know Giles will disagree). This falls into the language design camp and the only possible answer relies on someone who's worked on the language writing up the reasons somewhere. Giles' counter-argument to this is that "There are reasons to make this or that choice, which can have to do with nice theoretical properties, ease of implementation, performance, etc... Both kinds of answers call on facts and specific expertise". I do not think this completely holds water, as although people will be able to provide possible, logical, reasons for something being the way it is there is no definitive method of actually knowing why; there's no evidence.
The problem with my argument here? The question was answered. This is an important point. Just because something seems to be not constructive and impossible to answer doesn't mean that it is.
I would like to add that this is only true in closed sources languages. These kinds of questions are much more likely to be constructive for languages such as Python where anyone can look and come up with evidence based logical reasons for something being the way it is. Maybe there'll even be comments in the code explaining it.
Why is an initialiser containing a string literal valid to initialise a `char` array?
This seems to also come under the on-topic/not constructive heading. However, C++ has a standards committee. From what I've read pretty much everything in the known universe has been documented (I'm by no means a beginner let alone an expert). The why in this question can be answered with evidence, making this question constructive.
Why does Mono exist?
This one is more difficult. The problem is Oded's answer, which effectively says it exists because someone decided that it should. Whilst almost definitely true a link to a blog rather than a specific post doesn't provide evidence of the assertion. When the sole answer is "because it does" I don't think the question can be called "constructive"
My point is that it depends. Even in heavily closed source environments it's possible to tease out an answer to a curiosity question. Some languages are open source and even if no-one who has worked on the language is around it's possible to answer the question.
In conclusion
In writing this post I've come to see the "answer" to this question from slightly different viewpoint than the one I originally intended to espouse.
- I categorically do not want Stack Overflow to turn into a debugging service.
- Curiosity questions can always be answered; but such answers must be based on evidence.
- Stack Overflow users should be jealous of their site and try to keep questions there that are on-topic (sorry Programmers and CS Theory mods).
I think that almost all curiosity questions should be allowed on Stack Overflow. However, I think they should be more heavily policed to ensure that only actual evidence based answers rather than those based upon supposition and guess-work are provided.
1. Might just as well try to coin a new phrase once.
2. In which case you're deluded.
