Appeal to reopen a closed question

Question

I'm following the steps in this question so that I can appeal the closing of a closed question.

My case is basically that subjective questions are allowed, according to this document, as long as they:

• inspire answers that explain “why” and “how”
• tend to have long, not short, answers
• have a constructive, fair, and impartial tone
• invite sharing experiences over opinions
• insist that opinion be backed up with facts and references
• are more than just mindless social fun

I feel that this question meets those criterion.

Here is the question: https://stackoverflow.com/questions/18178200/is-developing-in-c-c-for-web-applications-using-fast-cgi-still-viable

Furthermore, I've seen a number of similar questions being closed by users that have less that 10k rep. I feel that there is a lot of loss of very useful information because of the overuse of the "subjective close". Certainly, we don't want to have a social jabber site. But perhaps we could make inroads by encouraging rewording or editing the question to fit these guidelines. Also, perhaps there could be a notice when you are "voting to close" that clearly lists the criteria above so that user have another opportunity to permit constructive, yet subjective, questions.

Any suggestions on what I should do to proceed in this matter is very much welcome.

Answer 1

So, going through each of the points that you've raised:

Performance [...]

This is the point point that you actually discuss extensively. You don't just assert an opinion, you back it up with hard facts, stories, etc. While questions along the line of "which is faster" are often not very good, but clearly there is potential here to objectively come to a conclusion as to how two options compare as to performance.

Application Lifetime Is Detached from Web Pages

This is all you say on the subject. What does this mean. What affect does this have on the consideration being made? What do the alternatives do, and how do they compare?

Scalability

This doesn't really mean much on its own. Support this assertion. What allows this particular solution to scale; what prevents other solutions from scaling; what data is there that demonstrates, using facts/evidence, that it will scale better?

Here on this point I'd say there is certainly potential for meeting the metrics mentioned, but your post hasn't actually done so.

No Context-Switch Overhead

Caching

Same arguments as to the app lifetime comment; you just mention these alone and include nothing else.

---

(the first two "Cons" I have no comment on)

The FastCGI interface is way more complex than solutions like PHP. Learning how to write multiplexing FastCGI applications will take some time. We feel that this investment of time pays off rather quickly, but sometimes other people tend to see this differently.

What is your basis for this assertion? This is just your opinion, with no supporting facts, evidence, expertise, data. Just you saying that it's more complex. It is nothing more than one person's opinion. Why and how is it more complex?

A very good security expert friend of mine said that there are just a lot more concerns with c/c++ being exposed to a web front. I would certainly agree that security is something that needs to be thought more of than on a traditional PHP environment.

This is even less helpful than the previous comment. Someone, somewhere, who isn't even here to be able to discuss his reasoning, feels that there are "concerns". What are they? What are the consequences of them? How can they be mitigated? How can anyone possibly respond to your statement that there are "concerns"? How can anyone make a decision based on this?

---

Your post was helpful when it was dealing with just those aspects that could be objectively measured or conclusively proven one way or the other, namely performance characteristics, the existence or lack of of certain features and the observable effects that they have.

As soon as you stepped away from those objective statements and tried to answer the actual question asked of "Is it viable" rather than a concrete, objective, provable statement about, say, it's performance, the value of the post plummeted down to virtually nothing.

The question should be edited such that it asks something that can be conclusively answered, rather than the vague, open ended "is this viable" question that it currently asks which is simply "primarily opinion based".

Answer 2

Sorry, but IMO the question should be closed.

Without even considering the answer you provided yourself, the question itself is too subjective. The title and first sentence ask if X is a viable solution for Y, and there is no way to provide a single, correct answer to a question that vague.

I have no idea what "viable" means to you. Execution speed? Ease of implementation? Cost of ownership? Memory footprint? Providing a definitive answer to an ambiguous question approaches the impossible. For that reason alone, the question should be closed.

You do provide some clarity in your answer as to what you think "viable" means, but in order to be a good, on-topic question, that needs to be done in the question. Assuming I have the technical knowledge you are seeking, I should be able to answer the question without having to read any of the answers first. (I should be able to grunch it.)