If you post a code-golf challenge after you designed a code-golfing language, it may be argued that you are somehow at an advantageous position. Knowing your language features may have influenced your challenge choice.

With this in mind, I posted a challenge today, answered in a language I had previously created, and added a disclaimer in my answer:

Since the creator of the language and the author of the challenge are the same, this answer is not eligible for winning.

However, from comments to my answer I realized there doesn't seem to be a consensus regarding this. So I'm asking here.

What do you think? Some possible positions regarding this are:

  1. The answer is not eligible for winning. This was my initial, perhaps too conservative idea.
  2. The answer is eligible, as long as you don't plan a challenge specifically as a use case for a built-in in your language. This is Alex A.'s suggestion.
  3. ...?
  • 1
    \$\begingroup\$ I agree with Alex A. on this one. \$\endgroup\$ Commented Dec 20, 2015 at 19:36
  • \$\begingroup\$ @FlagAsSpam I'll add mine. I'd rather let Alex A's express himself, perhaps more clearly \$\endgroup\$
    – Luis Mendo
    Commented Dec 20, 2015 at 19:42
  • 3
    \$\begingroup\$ @FlagAsSpam Meta should not be used as a poll. If you write an answer, it should reflect your opinion. As the questions lists two different opinions, Luis should post at most one of them. (ninja'd) \$\endgroup\$ Commented Dec 20, 2015 at 19:42

3 Answers 3


I'm slightly side-stepping the question here:

Although the whole catalogue experiment backfired in this regard, I still hope that as a community we will gradually move from considering code golf as a challenge for the shortest overall solution to considering it a separate challenge in each language.

In that sense, whether you've created the language yourself, or even whether your language contains a built-in that immensely helps with the challenge, feel free to post your own answer. We shouldn't be comparing different languages in the first place, and anyone else who uses the same language would have the same advantage.

  • 1
    \$\begingroup\$ "anyone else who uses the same language would have the same advantage" That's a good point. On one hand, for very recent languages you probably know your language better than others. But that's probably circumstantial \$\endgroup\$
    – Luis Mendo
    Commented Dec 20, 2015 at 19:49
  • 2
    \$\begingroup\$ -1 for "We shouldn't be comparing different languages in the first place" but +2 for everything else. (So +1 overall) I don't think there's anything inherently wrong with comparing across languages, but that's a different issue. \$\endgroup\$
    – Alex A.
    Commented Dec 20, 2015 at 20:50
  • 6
    \$\begingroup\$ How about "feel free to make comparisons across languages if it pleases you, but let's not restrict policy for it"? \$\endgroup\$
    – xnor
    Commented Dec 21, 2015 at 3:56

Firstly, I think the concept of creating a language or adding a built-in specifically for a challenge just to get a solution in one (or zero) bytes isn't even cheating; it's just boring.

What's the point in golfing if all you do is write a fancy long solution, make your program just require an empty input file and call it an interpreter?

I think answers in such languages should be allowed and eligible to win as long as the language was created/updated before the challenge, but still I'd recommend the creators of the challenges to listen to their conscience before accepting any "cheating" answers.

More general-purpose additions to the language just before posting a challenge, like the golden ratio example from Luis, shouldn't hurt that much, but if you implement something that clearly won't be useful later, it seems like plain old cheating to me.

After this point, my answer will be somewhat off the question, and more of a reply to Martin. (Sorry about the wall-of-text.)

I partially agree with Martin in that we shouldn't always compete between all languages. However, I think that competition between somewhat similar languages is a healthy feature of code golf. For example, languages could be divided like this:

  • the "cheating" languages
  • the "meant for golfing" languages
    • Pyth, CJam and all the other old & new ones
  • the "usable for golfing" languages
    • Python, C, Haskell, TI-Basic and friends
  • the "bad for golfing, but still fun" languages
    • Java, C# and other verbose ones
  • the "challenging to use at all" languages
    • Brainfuck, Befunge, Malbolge, Shakespeare and other, mostly esoteric languages

I'm not saying this should be any sort of official system; I think most people will still agree that the languages in these groups will often compete at totally different levels. While competition between, for example, C# and CJam, is often rather useless, competition between Java and C# is not, just like between Pyth or CJam.

Contents still need a winner (especially in the SE system where you can only accept one answer), so accepting the shortest valid answer seems like the best practice to me. I do like the idea of not finding the shortest solution though; for example, not accepting any answer to mark it as a "winner" could be an idea.

  • 2
    \$\begingroup\$ Don't forget APL/J in category 3! \$\endgroup\$
    – lirtosiast
    Commented Dec 30, 2015 at 3:07

As I wrote in the question, my view is that we should apply the same criterion as for languages created or modified after a challenge: you can post your answer, but it's not eligible for winning.

My view is based on the following reasons:

  • When you are creating the challenge you probably have your language in mind, and that may influence how the challenge is designed. You may for example add a special twist (perhaps even unconsciously) that is likely to favour your language.

  • You probably know your language better than others do.

The combination of thse two items may put you in an advantageous position.

Here's a specific example:

  1. You think of a nice challenge. It involves using the golden ratio.
  2. You realize your language doesn't include the golden ratio as a predefined literal, and it would be nice if it did, as it's obviously a useful constant.
  3. You update the language and then post the challenge.
  • \$\begingroup\$ This is already (sorta) discussed in this question. \$\endgroup\$ Commented Dec 23, 2015 at 17:56
  • \$\begingroup\$ The thing is that no one (AFAIK) has done this yet, as self-answers to questions are relatively rare \$\endgroup\$
    – Beta Decay
    Commented Aug 11, 2016 at 14:04

You must log in to answer this question.

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