# Codegolf rules and boundaries

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?

• Welcome! Take a look at How can we help users who are put off by the use of golfing languages?. – xnor Nov 2 '16 at 3:46
• There is no rule against designing a language to be good at golfing in general. We just are not allowed to use a feature/language which was implemented after the challenge was posted. – trichoplax Nov 2 '16 at 3:48
• Just to note when I created that built-in, there was a stream of about 3-4 questions where it would have been useful had it been implemented (back in July) so it wasn't intended to be completely useless except for this challenge – Blue Nov 3 '16 at 10:26
• Possible duplicate of Loopholes that are forbidden by default – pppery Jun 20 at 2:26

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.

• Okay, accepting only answers based on implementations prior to the question totally makes sense. Also, you say it makes no sense to compare different languages, which I agree with, but I still saw a lot of challenges asking for the shortest solution, regardless the language... Anyway, I guess that choice might be left to the author of the challenge. Thank you for your answer! PS: Please forget that そ thing, I had forgotten it wasn't ASCII... though I like your idea of using an alternative encoding! – Right Leg Nov 2 '16 at 4:29
• Well, the idea of a non-golfing-language tag wasn't well-perceived, so, I guess we have to say with "I will not accept an answer because I want the shortest solution in each language, not among all languages." or such. – Erik the Outgolfer Nov 5 '16 at 9:14

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.