Codegolf rules and boundaries

Question

So last time, I was hanging on codegolf, and came across the question Print the digital root, where one guy replied here with a one-byte code.

Of course, it takes advantages of the built-in and standard functions of the language, so it seems okay to end up with very short codes, in Jelly, Pyth, or such golfing languages.

But where is this gonna end?!

I'm actually pretty enthusiast with esoteric languages and such stuff, but if golfing's purpose is to find the shortest code possible, why couldn't I develop my own language, with my own compiler, where I would add one-byte functions every time a new golfing question is asked?

For instance, since s in Pyke means "Print the digital root of the input", what prevents me from creating a built-in function called そ that means "Spell out the input numbers in German" (although it might sound a bit Intercal-ish)?

Besides, I was scrolling the loopholes page when I came upon the Using a made-up language specifically designed for the challenge rule (whose title must be explicit enough). But if we do accept golfing languages, that are actually designed for golfing, this rule becomes null and void, doesn't it?

I am looking for something like a rule that says (though I doubt it can be clearly defined) where golfing begins and where it stops. Any thoughts?

Answer 1

Answers that use a language (or a feature thereof) that postdates the challenge should be labeled non-competing. From Can I ever answer with a language invented after the challenge was posted?:

These answers can still be posted but should not be considered as a candidate for the accepted answer.

But if a language is specifically designed to have a clear advantage for the question, it should not be considered as an answer and should be deleted. This case would ideally be clearly distinguishable.

That means add[ing] one-byte functions every time a new golfing question is asked is out of the window. If you add a built-in with the intention of solving a challenge in one step, your submission violates a site-wide policy and is subject to deletion.

Also, code golf competitions are scored in bytes, so unless your language uses a custom code page, the answer そ will be at least two bytes long.

Regarding a broader issue, yes, some recreational programming languages have a few Easter eggs: printing Hello, World!, FizzBuzz, 99 bottles of beer, or an ASCII art goat; perform a rickroll; generate the RATS sequence; etc. That means they'll be able to solve some challenges using only one byte (or even zero bytes), but it also means they've wasted a one-byte token on something that will be useful at most in a single challenge. That's their loss.

Note that production languages also have their Easter eggs. Python, e.g., has import __hello__, import this, import antigravity, from __future__ import braces, and probably others. If a challenge asks to print The Zen of Python, Python will most likely win.

Finally, it usually makes no sense to compare different languages, especially if production languages are involved. The designers (and users) of golfing languages definitely get a kick out of outscoring other golfing languages (at least I do), but comparing Python with a golfing language is just as pointless as comparing it with Java or APL.

Answer 2

So long as the language you want to use existed prior to the posting of the challenge (either on the main site, in the Sandbox, or in chat), wasn't specifically made for the challenge, and is a programming language by our definition (though there is some contention currently on that rule), it's fair game. Since we define languages by implementation, not specification, a working implementation of a language must exist in order for it to be used.