Why are golfing languages allowed?

Question

I'm a bit confused about the use of golfing languages in golfing challenges. In the standard loopholes there is a point about using self-made languages that solve the problem in one symbol. And it's a fair point. Golfing challenges lose their purpose if you can just make up a new language for each of them which does exactly what you need.

Golfing languages then, which are purpose-made especially for golfing, are coming awfully close to this. Most of them are either self-made or maintained by just a few people, if at all. They're not used for anything else BUT code golf challenges, and are specifically designed for them. Sometimes they're even focused on specific types of code golf challenges. OK, so they don't have a "one symbol solution", but... it feels to me like they go against the spirit of code golf challenges in the same way that a one-symbol language would.

On the other hand, it seems that the community has readily accepted these languages (and they do always win, of course). Has there been a discussion about this? I suppose there must have been, but I can't find it.

P.S. I'm not complaining and I'm not hurt about it. In fact, I'm not even participating in code-golf challenges. I just find this situation genuinely perplexing and am curious about the reasoning behind it.

Answer 1

Because any language is allowed

We very consistently have a policy that any language is allowed, even those that are incredibly limited, such as HQ9+. We previously required that languages be capable of 2 basic tasks, but that's since been superseded. As we have a policy that the implementation defines the language, the only thing we require is a working interpreter.

You do correctly note that making up a language specifically to win is a standard loophole - and rightly so. The standard loopholes are supposed to be a list of things that are no longer funny, and we don't want every question flooded with a bunch of zero byte submissions in "MyLanguage". We mitigate this in two ways: downvotes and a site policy.

Downvotes are easy: if you see an answer that breaks a standard loophole, leave a comment letting them know, downvote the answer, and potentially flag for a moderator to delete it. You can essentially consider these answers to be VLQ, and should be treated as such.

Additionally, we have a site policy that, officially, languages only compete with themselves. If I post a Jelly solution, technically, I'm only competing against other Jelly solutions. Now, I might look at answers in 05AB1E, Vyxal, Husk, etc. and try to beat them, but, as far as the site rules are concerned, I'm only ever competing against other Jelly answers (incidentally, this is why we discourage accepting answers). If you have a language where you've added the command x specifically to solve a challenge, congrats, you've got the winning solution in your language.

Finally, note that golfing languages generally aren't these kind of languages. Some builtins in such languages are included because of how common a task is in code golf, but that's no different than Python having sorted as a builtin because sorting is a common task. The only difference is that in a golfing language, it's a single byte.

---

In short:

• Golfing languages are allowed because any language is allowed
• Submissions officially only compete within their language
• We have sufficient means to prevent and remove answers that attempt to cheat by deliberating adding a builtin to solve a challenge
• Golfing languages generally aren't adding builtins to solve specific challenges; language designers aim to balance specific builtins vs being golfy across a large range of challenges