We have never had a criteron about time making code. Do we need one? If we do, how do we calculate the time? If not, why not?
2 Answers
Probably Not
This is rather difficult to accurately measure in our format, and makes the Sandbox practically unusable. Any simple challenge may be done in minutes, making the winners basically whoever sees it first.
-
\$\begingroup\$ Hmm. Good point, I was about to apply it on a very hard question such as: 'Find the result for a chemical reaction' though. I did expect there would be some flaws on the timer. \$\endgroup\$ Commented May 5, 2017 at 7:08
-
\$\begingroup\$ Rather Difficult ones might be an exception, yet still advantage is given to those who see it first. \$\endgroup\$– ATacoCommented May 5, 2017 at 7:09
-
\$\begingroup\$ I think you misunderstood something. It's time based on the time starting making code, not time based on answer post. \$\endgroup\$ Commented May 5, 2017 at 7:10
-
1\$\begingroup\$ Regardless, it's far too easy to lie about that. \$\endgroup\$– ATacoCommented May 5, 2017 at 7:14
-
\$\begingroup\$ Ah, yes. I feared about that. That was why I posted. \$\endgroup\$ Commented May 5, 2017 at 7:15
We already have this criterion…
…in a possibly disguised way. The problem with "write this code as quickly as possible" is that you can't verify that people didn't start writing in advance, except by starting everyone at the same time. But if you start everyone at the same time, there's then no way to improve after the first answer is posted. The solution is to have a bunch of miniature challenges, posted at arbitrary times, and have people compete to be the first to solve each individual challenge.
And of course, I just described cops-and-robbers (cops setting the challenges, robbers solving them). General challenge structures for which being the first to write the code are interesting should likely be run in that format, as it already achieves most of what you're looking for in a way that fits much better onto PPCG.