Return to Answer

#This is a bad idea.

I like the sentiment of challenges being completely observable. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete observability.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

6. "You cannot use multiple version of the same language". This is relevant to answer-chaining or multi-language answers. A program cannot tell if two languages are multiple version of the same language, so it wouldn't be observable.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.

#This is a bad idea.

I like the sentiment of challenges being completely observable. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete observability.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

6. "You cannot use multiple version of the same language". This is relevant to answer-chaining or multi-language answers. A program cannot tell if two languages are multiple version of the same language, so it wouldn't be observable.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.

#This is a bad idea.

I like the sentiment of challenges being completely observable. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete observability.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.

#This is a bad idea.

I like the sentiment of challenges being completely observable. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete observability.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

6. "You cannot use multiple version of the same language". This is relevant to answer-chaining or multi-language answers. A program cannot tell if two languages are multiple version of the same language, so it wouldn't be observable.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.

#This is a bad idea.

I like the sentiment of challenges being completely objective. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete objectivity.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.

#This is a bad idea.

I like the sentiment of challenges being completely observable. I think that we should aim for questions to be as close to observable as possible, but I don't think it would be good for this site to require complete observability.

As it stands, there are lots of challenges that would become trivial/impossible if we disallowed non-observable requirements.

1. No built-ins. I think this is obvious how this makes things trivial in some languages. If a builtin is shorter than any possible algorithm, then submissions in that language have no choice but to submit that built-in (to stay competitive).
2. No hard-coding. While this is a problematic statement in certain scenarios, we need it to keep some fastest-code challenges non-trivial. Primes become a lot easier to generate if you have the first 10K of them in your source code. Some sequences become exponentially harder to calculate the higher you go, which means that it is feasible to hard-code all answers.

The following challenges (as well as others) would all become off-topic:

• Extending OEIS: Counting Diamond Tilings
• Compute the maximum number of runs possible for as large a string as possible
• Sum of smallest prime factors

3. No retaining state and No reflection/modifying other submissions. Both of these are essential for running all of my KoTHs. I don't want people storing static variables to remember data from game to game, and I don't want reflection to cheat at the game. This would close nearly every KoTH challenge

4. Submissions must be competitive. There is a requirement we place on every challenge by default and is non-observable. Mego brought up in chat that the more specific meta ruling wins, so this wouldn't actually close any questions, but this would make for two rules that conflict with each other.

5. Asymptotic complexity restrictions. This includes all questions from restricted-complexity and other challenges where we put a complexity requirement to prevent brute-forcing.

Unless we are able to define all of the above non-observable requirements for every language we use on this site, we're going to kill so many challenges here.