12
\$\begingroup\$

In this standard loophole, we forbid gaining an unfair advantage by creating new language features or implementing a new language specifically to be competitive for a particular challenge that's either in the sandbox or on the main site. This loophole, along with the fact that we define languages by their implementations and not their specifications, is one of the reasons that languages and language versions newer than challenges are marked noncompeting.

However, one thing remains unclear: What do we consider an "unfair advantage"? That is, what specifically is covered (and what isn't covered) by this loophole?

\$\endgroup\$
2
  • 6
    \$\begingroup\$ Thing is, "unfair" is inherently subjective. I'm not sure how well a rule like this would work on a site that's built around empirical and clear-cut rules. This isn't a problem for, say, question closure, but since there's no "vote for whether this answer is valid or not," a non-objective rule for answer validity is dubious at best. \$\endgroup\$
    – Doorknob Mod
    Commented Feb 21, 2016 at 21:18
  • 2
    \$\begingroup\$ @Doorknob: I actually see this as being less about the validity of an answer and more about it's..."quality". Hence why I suggested downvotes as the solution to unfair tactics, not flagging or deletion. I see this as less of a right vs. wrong (or rather, valid vs. invalid) and more of a okay vs. not okay issue. \$\endgroup\$
    – El'endia Starman
    Commented Feb 21, 2016 at 23:25

2 Answers 2

Reset to default
22
\$\begingroup\$

"I know it when I see it"

Not the easiest definition to enforce, but I think this is the best way to put it.

If we try to nail down this definition of "unfair", we could make ourselves more vulnerable to being rules-lawyered. I don't recall exactly where I saw it, but I do remember that this inspired Stack Exchange's "be nice" policy: there was a forum with just one administrator, whose only rule of conduct was "Be nice." He simply banned everyone who disregarded that rule, and the community was well-off for it. Anyone that knew of that rule and disregarded it via some attempt to exploit a loophole showed that they did understand said rule, and chose not to follow it.

I propose we treat "unfair advantage" similarly. If you believe someone has gained an unfair advantage by updating their language after the challenge was posted or sandboxed, downvote and comment as such. With sustained negative feedback, people will stop being unfair, or stop participating. With regards to the Sandbox especially, very few people see a challenge in the Sandbox (comparatively). If someone's abusing this loophole, that'll be apparent.

I think we should care more about "fun" than "winning". Hence, we should "enforce" fairness when it improves the "fun-ness" of the site, not solely for the sake of fair competition. (Jelly's gonna win everything anyway. :P)

Guidelines/examples

  • Bugfixes - Let's say someone fixes a bug in their language after a challenge is posted. (I've done this.) I'd let it slide because I know how frustrating it is to know that your language is supposed to act a certain way, but it doesn't and you get penalized for it. I understand the general "the implementation defines the language" idea, but I think I wasn't around for the discussions. Doesn't the language's creator get a say? In any case, if said person then reverts their change later on, or the "bugfix" doesn't make much sense (or even introduces a bug), that's fishy, and probably would get a downvote from me.
  • New features - they do provide an unfair advantage, but only if they're relevant to the challenge. This is already how most people operate anyway, I think.
  • When is a (claimed) bugfix really an improvement? Well, how many grains of sand do you have to remove from a heap of sand until it's no longer a heap? There are fuzzy boundaries in every aspect of human life, and we deal with them just fine, considering. I'd likely downvote if a "bugfix" confers a substantial advantage, like more than a handful of bytes or percentage points (about 5, in both cases).

Note: I only suggest downvotes and not deletion because unfair answers are merely bad, not invalid. (In my opinion, that is.)

Fuzzy and murky, yeah, but ultimately, I think this is the best way to go.

\$\endgroup\$
5
  • 2
    \$\begingroup\$ Based on our current policy, it's important to note that answers that make use of newer languages/features are not invalid, but just non-competitive (despite the loopholes in the loophole post typically making answers invalid). \$\endgroup\$
    – user45941
    Commented Feb 22, 2016 at 0:17
  • \$\begingroup\$ Incorrect-Jelly doesn't win with strings. \$\endgroup\$
    – CalculatorFeline
    Commented Feb 27, 2016 at 20:49
  • 2
    \$\begingroup\$ @CatsAreFluffy: Yet. \$\endgroup\$
    – El'endia Starman
    Commented Feb 28, 2016 at 0:32
  • \$\begingroup\$ Somewhat related: in Jeff Atwood's blog post on "Good Subjective" questions, he writes "I know it when I see it". \$\endgroup\$
    – Rainbolt
    Commented Mar 2, 2016 at 21:39
  • \$\begingroup\$ @BrainLot: It is almost certainly the case that we're both referencing the same thing. \$\endgroup\$
    – El'endia Starman
    Commented Mar 3, 2016 at 8:06
-5
\$\begingroup\$

Always

Simple, sweet, concise. If there has been a change in the interpreter, you cannot use that version of the interpreter. That way, there is no further debate: a hard-and-fast rule.

\$\endgroup\$

You must log in to answer this question.

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