2

I asked the following question that was closed due to a supposed lack of research. I believe this was a mistake for the following reason:

I'm well aware of how to time the execution of a command, but timing the command on my Cygwin system - itself not very representative of most systems that bash is running on - would have told me nothing about which method would be in theory faster to run. There are a lot of variables in the specifics of any one system that could affect benchmarks, but how the actual code works is something that can be objectively known, irrespective of whether it holds true on all systems.

The answer that I'm looking for is clearly stated: something that includes an actual understanding of the theoretical differences between the two implementations in their function, and how those theoretical differences affect the speed of the two, with benchmarks being optional. This is something that someone with knowledge of bash's inner workings would readily have knowledge of, and I've seen many such questions across the Stack Exchange network, including on SU.

Therefore I believe that prioritising my own benchmarks would result in an overly myopic take on the question that misses the much broader, more useful question being asked.

| |
  • Under the question I asked: which method is faster on your computer? Believe it or not, the emphasis on "your" is there because I really meant your computer, no matter how exotic. It's trivial to test, especially after you were given useful links, so neglecting this basic research with obstinacy seems almost rude. The help center states "you should only ask practical […] questions […]". IMO "theoretical differences" alone do not fit. You may disagree, sure. Then what is your research effort concerning theoretical differences? Any research effort? – Kamil Maciorowski Jun 30 at 20:45
  • 1
    @KamilMaciorowski I have been told in the past that arguing about close votes in the comments is unproductive and to make meta threads instead, so I'm not sure why you are personally offended by my making this thread, but you should not be - it's not personal. I've already addressed your first point in two whole paragraphs in my question - it might be trivial to test, but what would testing have added to my question except to narrow it down to a benchmarks question? I wanted a more in-depth understanding of the speed based on the inner workings of the code. – Prometheus Jun 30 at 22:36
  • As for your second point, some of SuperUser's highest voted questions are theoretical explain-the-technology questions, and I've seen and upvoted many of your answers to them, so I'm unsure what your particular gripe is there. Original research is not provided for any of these questions either because of the self-explanatory or advanced technical nature of them - what would even be researched? - and this has not been considered a problem there either. – Prometheus Jun 30 at 22:40
  • Just a handful of examples of highly-voted, well established explain-the-technology questions. – Prometheus Jun 30 at 22:40
  • In fact here's one of your own that is similar and shows as much original research as mine does. What research do you propose you could have done for that question, and what difference would it have made? – Prometheus Jun 30 at 22:43
  • My point is what you wrote shows no research effort. IMO the question requires a lot of knowledge and skills to answer. On the other hand showing any research was easy. "My tests in Cygwin indicate … but I'd like to know the theoretical …" or "Here's a link to the code of Bash, I tried to analyze it but it's huge and I'm lacking knowledge". You chose not to show research, even after being prompted and given helpful links. I'm not offended by this meta thread; I'm almost offended by obstinacy in avoiding research. The impression was "you do the hard part and I do nothing". – Kamil Maciorowski Jul 1 at 4:33
  • My question you linked to started as self-answered; and the most upvoted answer is still 97% mine. You're trying to defend your case, where you refused to do even the easiest research, by referring to a question where I did the vast majority of work. What? If you answered your own question and I asked "where's your research effort?" (as I in fact did), your reply would be "it's down there in my answer" and it would be great. – Kamil Maciorowski Jul 1 at 4:33
  • @KamilMaciorowski Fair enough, your question that I linked to isn't an example of what I'm referring to since you answered it yourself. What of the first five examples I gave? All of them are explain-the-technology questions with no clear problem to solve, and no further research was asked of any of them - so on what basis is it fair to expect my explain-the-technology question to need research? Again, there are many, many examples of such questions, many of them recent - those linked are just the highest-voted ones with the bash tag. – Prometheus Jul 1 at 18:01
  • I've already explained several times how useless individual benchmarks are for an objective view of speed across systems, and how including them would only detract from my question when I'm not looking for benchmarks, and this community's persistence in asking me to produce them in spite of this indicates to me that it prefers empty gestures over actual productive output, for the sake of ritual or power or something else I'm not sure of, so I think I'll just this question over at SO or U&L instead, where it will hopefully actually be valued. – Prometheus Jul 1 at 18:02
1

I'm well aware of how to time the execution of a command, but timing the command on my Cygwin system - itself not very representative of most systems that bash is running on - would have told me nothing about which method would be in theory faster to run.

Your question does not mention the use of Cygwin. The moderator who closed your question, for not being clear, provided several potential references that you could use to clarify your question.

The answer that I'm looking for is clearly stated: something that includes an actual understanding of the theoretical differences between the two implementations in their function, and how those theoretical differences affect the speed of the two, with benchmarks being optional. This is something that someone with knowledge of bash's inner workings would readily know of, and I've seen many such questions across the Stack Exchange network, including on SU.

You are right. What you are looking for is indeed programming, like one very familiar with a bash script, and perhaps even familiar with the source code to bash itself. Unfourtantly, your not likely to find that very specific person on Super User since we are not typically programmers.

Therefore, I believe that prioritizing my benchmarks would result in an overly myopic take on the question that misses the much broader, more useful question being asked.

In this case, additional information from your benchmark runs would have helped. We are not necessarily looking for broad questions; we are looking for questions that have been researched and are about practical problems within the scope of our help center.

As it's currently written, your question is unlikely to garner the required votes to be reopened, unless you clarify your question. It certainly could not hurt to provide some improvement to your question.

My question doesn't mention the use of Cygwin because it's unnecessary detail.

I don't use bash very often, but from what I have experience on my own Unix and Linux systems, it certainly seems to be Cygwin would impact what any potential answers.

I have made a slight edit to the question to make it clearer what I'm after, but aside from that, I cannot see how the question can be improved any further without changing the focus of it.

This slight edit was enough for me to justify a reopen vote.

| |
  • If you're referring to the "references" to how to run time, I've already stated why including benchmarks isn't a solve for my question and would only help to narrow it down unnecessarily. My question doesn't mention the use of Cygwin because it's an unnecessary detail. There are lots of things that could affect bad benchmarks, reliable benchmarking to determine an objective speed across systems is hard. You might be right about SU not being home to enough programmers, something I had a hunch about myself before asking the question... – Prometheus Jun 30 at 22:55
  • ...but I assumed there would at least be enough Bash experts. I have made a slight edit to the question to make it clearer what I'm after, but aside from that I cannot see how the question can be improved any further without changing the focus of it. If it still fails to be re-opened I'll probably just ask it and any similar questions in the future on SO or even U&L since it's clear SU only selectively keeps these kinds of questions around (and as ever, unclear on what basis it chooses to do so). – Prometheus Jun 30 at 22:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .