87
\$\begingroup\$

I've been thinking for a long time that our non-competing policy for newer languages (or language versions) is harmful. Just for context, we currently require all answers which require implementations that are newer than a challenge to be marked as non-competing. At the core there was a good intention behind this rule and that is to prevent people from adding a built-in to their language which solves the challenge in one byte, but I think that in 99% of cases the rule ends up hitting the wrong answers.

Some arguments for allowing all languages and versions on all challenges:

  • Just empirically it seems that the vast majority of all non-competing answers on the site are either a) people wanting to give old challenges a spin with new languages, b) people encountering a bug in their language when solving a challenge and having to fix that bug before being able to solve the challenge, or c) people wanting to use well-specified, old languages which need to be (re-)implemented before they can be used. Neither of those lead to problematic answers but are disappointing or frustrating for the answerer.
  • We regularly get people suggesting that sufficiently old challenges should be allowed to be reposted (the most recent example), with one of the main arguments that new languages have since been created which can't compete on the old challenge. But reposting challenges leads to all sorts of other problems, in particular what to do with old valid answers. It would be much easier if we didn't discourage people from answering old challenges.
  • I believe the community has come a long way from competing for the overall shortest answer on a challenge. Most people who aren't using Jelly or 05AB1E or the like are usually competing within their own language (or maybe with languages of comparable verbosity). Adding a built-in to the language just for that challenge simply makes the language uninteresting for the problem at hand. Improving the language in a way that shortens the current problem but is also useful in general doesn't seem problematic to me (and the change will also be available to other users who might still be able to outgolf the answer). Either way, the non-competing label seems meaningless if we're not comparing the answer to solutions in other languages anyway.
  • Many of our most-answered challenges (those which started out as "catalogues", i.e. the challenges for certain standard programming problems) already override the non-competing policy explicitly without any detrimental effect (and thereby becoming more useful repositories of golfed solutions for these problems in all languages, regardless of the language's age).
  • Adding a built-in to solve a challenge isn't very interesting and will likely be discouraged by downvotes more than anything else, especially if someone does it repeatedly.
  • The non-competing rule doesn't even reliably solve the problem it's trying to solve. While the Hello, World! challenge already allows newer languages, this answer wouldn't have been non-competing anyway (I realise this is a counterexample to my previous point, but HNQ can sometimes do that). And there are other ways to get a 1 byte or 0 byte program working before a challenge is posted.
  • While we're not doing this consistently yet, we have a well supported proposal to combine trivial answers into a single CW answer. That would further reduce the incentive to add built-ins to languages unless they're generally useful.

Yes, we'll probably get the occasional answer that adds a built-in after the fact and gets a lot of undeserved votes for it, but I really don't think that this rare case outweighs all the disadvantages this policy brings with it.

\$\endgroup\$
  • 14
    \$\begingroup\$ I agree with this. Many times I have actually refrained from posting an answer simply because I found a bug in my language which discouraged me from posting a non-competing answer. This also removes this controversial debate: "what about people implementing built-ins based on sandbox challenges which they then use when the challenge is posted" and all kinds of weird situations like that. \$\endgroup\$ – Fatalize Jun 14 '17 at 9:16
  • 5
    \$\begingroup\$ I can definitely get behind this, +1. One of the problems I always have is trying to figure out if a solution I'm posting should be non-competing or not. \$\endgroup\$ – Shaggy Jun 14 '17 at 10:35
  • \$\begingroup\$ Regarding the "well-supported proposal": There are two well-supported proposals on that post, but they oppose each other. We'd really need another meta post to decide which route we want to take. \$\endgroup\$ – Nathan Merrill Jun 14 '17 at 14:11
  • \$\begingroup\$ @NathanMerrill Indeed, but I've been watching that thread for a while, and xnor's proposal has been gaining support while Dennis's has been losing support. \$\endgroup\$ – Martin Ender Jun 14 '17 at 14:15
  • \$\begingroup\$ While that may be true, I still wouldn't feel comfortable merging answers without a more solid victor \$\endgroup\$ – Nathan Merrill Jun 14 '17 at 14:16
  • 6
    \$\begingroup\$ Do this, and if somebody tries to cheat, let everyone know and watch as it (hopefully) gets downvoted into oblivion. \$\endgroup\$ – Esolanging Fruit Jun 14 '17 at 17:26
  • \$\begingroup\$ The vast majority of all non-competing answers on the site are... Neither of those lead to problematic answers But we don't know if that would still be true without the "non-competing" rule \$\endgroup\$ – Luis Mendo Jun 14 '17 at 18:39
  • 1
    \$\begingroup\$ Adding a built-in to solve a challenge isn't very interesting and will likely be discouraged by downvotes How about adding a function that is not blatantly a one-byte builtin for the specific challenge? Often the creator of a language notices something missing in the language that would help for a given challenge, but it's not a builtin that trivializes the task \$\endgroup\$ – Luis Mendo Jun 14 '17 at 18:39
  • 1
    \$\begingroup\$ @LuisMendo I think that's perfectly fine. See ais's answer below. \$\endgroup\$ – Martin Ender Jun 14 '17 at 18:39
  • \$\begingroup\$ @MartinEnder Yes, I just realized he addresses that :-) \$\endgroup\$ – Luis Mendo Jun 14 '17 at 18:41
  • 1
    \$\begingroup\$ Evidence #313 that this non-competing policy of ours is doing more harm than good... \$\endgroup\$ – Erik the Outgolfer Jun 16 '17 at 9:12
  • \$\begingroup\$ I think they still need to be labeled as "code newer than challenge" but they shouldn't be given the negative stigma of "non-competing". Maybe if we change the wording people will then treat them differently but still be wary. \$\endgroup\$ – Magic Octopus Urn Jun 16 '17 at 13:35
  • \$\begingroup\$ @carusocomputing I'd be fine with that (and I think most well-meaning language authors would mention it in the post anyway). Feel free to make that an answer though. \$\endgroup\$ – Martin Ender Jun 16 '17 at 14:13
  • 2
    \$\begingroup\$ @MDXF At a score of 35 I'd say this proposal has been accepted. But all that means is that you should leave out the noncompeting label in the future. Don't go through existing answers to remove the label. There are thousands of them, and editing them all will make the front page useless for hours (or days). If you happen to edit an older post that has the label, feel free to remove it, but don't go editing old answers just for that purpose. \$\endgroup\$ – Martin Ender Jun 19 '17 at 6:37
  • 1
    \$\begingroup\$ @isaacg According to this proposal, nothing at all. Disclosing it in the answer would be nice though once the author finds out. \$\endgroup\$ – Martin Ender Jun 20 '17 at 6:01
60
\$\begingroup\$

Trust the community and add a standard loophole

I think the community can handle the add-a-builtin problem (I may be very wrong). I think that if someone adds a feature to their language that is clearly meant to only solve one particular challenge, the community will probably downvote that answer into oblivion.

However, I still think we need a rule against adding a builtin to a language so that when a new user comes and tries to do it we can have an actual reason for downvoting. It could possibly be added to the list of standard loopholes.

\$\endgroup\$
  • 2
    \$\begingroup\$ Note that if we're stopping this problem subjectively (which is something I'm OK with), it still needs a subjective rule that such answers are invalid (rather than should be downvoted). Otherwise, we'll end up with highly negatively voted answers which nonetheless win the challenge, which seems like an undesirable state of affairs; are you supposed to post such answers, or not? \$\endgroup\$ – user62131 Jun 16 '17 at 1:15
  • 5
    \$\begingroup\$ I'm not a big fan of this. Such a standard loophole would inevitably be used to justify downvoting answers where the author genuinely improved the language in general if it may not be immediately obvious how the change is useful beyond the present challenge. \$\endgroup\$ – Martin Ender Jun 16 '17 at 6:58
  • 7
    \$\begingroup\$ Arguably these loopholes (1 2) already cover exactly that. \$\endgroup\$ – Mego Jun 16 '17 at 12:00
  • \$\begingroup\$ I think adding a clause about ex-post-facto standard built-ins could lead to a slippery slope of "well, this isn't allowed because it trivially solves the problem" even if the problem is already somewhat trivial to begin with. I agree with the core of the answer though. Trust the community, and vote score should reflect the legitimacy of the answer, in the long run, regardless of whether we put it in the standard loopholes. \$\endgroup\$ – Patrick Roberts Aug 3 '17 at 14:25
  • \$\begingroup\$ Just for a better understanding: Is this competing or not? It´s not an older challenge and DJ modified his language for it. It doesn´t matter much in that case, because there are shorter submissions. But what if not? \$\endgroup\$ – Titus Aug 26 '17 at 4:53
15
\$\begingroup\$

Allow languages / language features to be used on challenges that predate them, if that language or feature is useful on several other challenges too

It strikes me that the main purpose of our "language postdates challenge" rule is to prevent situations where people write a language, or modify a language, specifically for the purpose of gaining an unfair advantage on a single question. However, if the language or language feature is shown to be widely useful, that's another way of demonstrating that it wasn't (just) for cheating on a challenge.

We've seen this with Brachylog, for example; it's quite common to see a challenge, and realise that Brachylog is missing a feature that really should have been in the language (with the challenge demonstrating why). Because Brachylog's under active development at the moment, the feature tends to be added (but not used on the challenge that inspired it). Nearly always, there'll soon be another challenge posted which can make use of it. (This is part of the reason that Brachylog's score relative to other golfing languages has been improving over time.)

In this case, it feels a little unfair to bar the best solution, in the new Brachylog interpreter, to the original challenge; sure, the challenge inspired adding a new language feature, but the feature was for the benefit of the language as a whole rather than an attempt to cheat on that challenge specifically.

Note that I'm not taking an opinion here on an exact number for how many challenges the feature has to be useful on to count as not being an attempt to cheat. In most of the cases I've seen so far, the difference between cheating and non-cheating is such a large one that you could place the number almost anywhere reasonable and still have a working rule. We'll need to see some more borderline cases before we can decide where exactly the border should go.

\$\endgroup\$
  • 21
    \$\begingroup\$ I like the spirit of this, but I'm not sure how objectively enforceable this is. \$\endgroup\$ – Martin Ender Jun 14 '17 at 14:44
  • 2
    \$\begingroup\$ It's certainly possible to define objectively in terms of language features: "solutions using the feature score better than the best solution in the same language which doesn't use the feature on n different challenges". Defining it for languages is harder, though, because we're optimized for competition within a language rather than competition between languages. \$\endgroup\$ – user62131 Jun 14 '17 at 14:47
  • \$\begingroup\$ I feel this could be a de-facto standard that people could consider when deciding whether to upvote an answer, rather than explicitly placing it in standard loopholes due to lack of objectivity. \$\endgroup\$ – Patrick Roberts Aug 3 '17 at 14:28
8
\$\begingroup\$

Also, ad hoc languages only hurt the ad hoc-er, not the community

Another point is this. The whole idea behind competitions on this site is not to determine who is the Best or the Smartest. It's to give individuals a hurdle to leap over, so that they can maybe learn something new or even just exercise the ol' gray cells. If a person decides to make a new language with a built-in single-byte command to solve a challenge, they willingly take that hurdle away from themself. That's their own problem, not the community's.

Perhaps all answers could be required to show the date of the last update of the language they're using?

\$\endgroup\$
  • 5
    \$\begingroup\$ Requiring all answers to show the date seems like needless work in 99% of cases. Maybe just those that have had an update since the challenge that affects the code in question? \$\endgroup\$ – xnor Aug 2 '17 at 3:56
  • \$\begingroup\$ @xnor Yeah that sounds good. Then people wouldn't have to find the date that, say, python 3 was published. \$\endgroup\$ – benzene Aug 2 '17 at 4:06
-15
\$\begingroup\$

All builtins used must have existed before the challenge

By builtin, I mean:

  • An instruction that is a part of a language's implementation
  • A single function/method/procedure that exists in a language's standard library

For clarity "the language" refers to the language being used to answer the question / solve the challenge.

Explanation

Now, this may sound like what we already do, but allow me to clarify: all builtins used in an answer must have existed before the challenge either in another language or in the language's spec. This means that:

  • If the builtin is already well-defined (conceptually) in the language's spec, but just needs to be implemented in the language, then it would be legal to implement the builtin and use it (this would also apply to builtins that require bug fixing - one's which do not behave as described by the spec)
  • If the builtin exists in some form in another language, it can be implemented into the language and then used on other challenges
  • If a language is newer than the question, all the builtins used to answer the question, in that language, must have existed (either in the language's spec or in another language) before the challenge was created

Advantages

  • Not very restrictive: consider languages like Matematica, famous for having too many builtins for too many stuff, or languages like Java, with expansive standard libraries. Furthermore, there are simply many, many languages in existence, all with a different combination of builtins. That means that all/most general purpose builtins are covered by this rule, as well as many, many more specific ones (like Matematica's CellularAutomata, for example)
  • Objective: PPGC really likes its objective rules & scoring methods, and this rule would be one of those. It can be directly proven by pointing to a spec that was posted before the challenge or to a builtin that was included in another language before the challenge.
  • Good estimate of what we want: obviously, it would be easiest and most accurate to just say "don't be unfair, and don't use builtins specifically designed to answer a specific challenge" but that's awfully subjective. The goal then, is to find an objective rule that provides a good (if slightly rough around the edges) estimation of that goal. This rule is just that. You'd be hard-pressed to find a builtin that completely solved many of the non-trivial challenges on this site, in any language, but with the wide range of builtins out there, very few builtins that would improve the language would be restricted by this rule

Disadvantages

  • Could be abused: a scenario could be envisioned where people pick and choose the best sequence of builtins for any challenge, implement them into a language, and then solve it. However, I feel this is basically what code-golfing is anyway - selecting the right series of builtins. It may be made slightly easier by the ability to choose any builtins, but in most cases doing this would probably on put answers on par with Jelly and the like, and not only that, but it would also require quite a bit of effort (updating a language for every challenge), and would probably be considered in the vein of MetaGolfScript, and thus would be downvoted and banned by loopholes such as this one and this one.
  • Difficult to find rule breakers: as stated in the advantages section, it is particularly objective to prove when an answer follows this rule, however, on the other hand, it is rather difficult to prove when an answer does not follow this rule. This is due to the massive number of languages in existence, the massive number of functions in their various libraries, etc. However, my argument here is that if an answer comes under scrutiny for potentially breaking this rule, then it either 1) is breaking the rule, or 2) is using an extremely specific builtin (which may or may not have existed before the challenge), implemented after a challenge was created, to make solving it trivial - and would thus be against what we want to accomplish anyway.

Summary

All builtins used in an answer must have existed before the challenge, either in another language, another language's standard libraries, or in the language's (being used to answer the challenge) specification. An answer should be considered breaking this rule if it has implemented an overly specific builtin that cannot be found in any other language, or if it cannot easily point to an implementation/specification of this builtin that was implemented/created before the challenge was posted.

\$\endgroup\$
  • 5
    \$\begingroup\$ "It can be directly proven by pointing to a spec that was posted before the challenge or to a builtin that was included in another language before the challenge." The entire point of requiring implementations is that specs generally aren't rigorous enough to use them to prove anything. It's also going to be hard to say whether I've exactly implemented a built-in from another language if that other language has a completely different memory and execution model. There are also languages where the concept of a built-in isn't well-defined. [ctd.] \$\endgroup\$ – Martin Ender Jun 23 '17 at 13:53
  • 3
    \$\begingroup\$ I think this just overly complicates things without really solving an actual problem we have. Yes, this community likes objective rules (and I don't even think this is an objective rule) but this community also notoriously has so many of them that we're better off without rules we don't really need. \$\endgroup\$ – Martin Ender Jun 23 '17 at 13:54
  • \$\begingroup\$ @MartinEnder true... \$\endgroup\$ – Socratic Phoenix Jun 23 '17 at 14:04

You must log in to answer this question.

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