Is the "no MetaGolfScript" rule somehow formalized?

Question

A disadvantage of the "default rules as answers" is that the rules don't have a common, organizing, "formal" thought behind them. I'm talking about this one here. I understand it as applying to "anything similar", but is there any exact way that could be understood? I was thinking about making an advanced brainfuck program compression algorithm and a language that would interpret the compressed form. But different versions of brainfuck (like with 32-bit integer vs unbounded cells) are optimal for different challenges. The obvious solution is to add a flag to the interpreter but then that has to be counted in a code-golf score. If I generated completely separate, uncompressed interpreters for each flag would that count? What if they were in separate commits? Separate repos? It's hard for me to come up with any good objective criteria because someone could always generate 5000 different compression algorithms and related interpreters and choose the best one for a particular code every time, which does feel like cheating.

Answer 1

This answer contains some personal opinions, which I express as my own thoughts and not as a moderator.

---

As you've correctly pointed out, the strategy of enumerating a set of exhaustive rules, carefully designed to eliminate all possible corner cases that people could possibly come up with to work around them, isn't really a sustainable model, because there will always be tricks or loopholes that people haven't thought of, or which technically abide by the rules as written.

Nevertheless, that was the model that the site tried to use for most of its history, ever since the "curl short.link|sh" answers and the like stopped being amusing. Recently, though, the general attitude of the community has shifted away from this mindset in terms of placing restrictions on which languages people are allowed to use. In particular, about two years ago (wow, was it really that long?) a consensus seemed to be reached that adding the size of flags to byte counts was silly, and that it made more sense to simply consider a distinct compiler/interpreter invocation (with a particular set of flags) as a distinct language.

This coordinated nicely with the idea that languages shouldn't compete against one another, but with themselves (i.e. an 80-byte Java answer isn't competing against a 2-byte Jelly answer, but it's certainly better than a 90-byte Java answer). In particular, yes, it may be the case that you have a 0-byte metagolfscript -n 209180605381204854470575573749277224 answer, but this is not a particularly impressive feat seeing as there are no possible longer answers to compete with.

A far more eloquent summary of the same idea can be found in this post by former moderator Martin Ender, which argued that our previously existing rule that languages created after the creation of the challenge should be considered "non-competing" was also silly:

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.

[...]

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.

Both of these semi-recent policy changes are based on the same idea: different languages are mostly incomparable, so exploits that rely on modifying or inventing new languages to fit a specific challenge are uninteresting (and will likely be deemed as such by voters, barring a few older answers like the 0-byte Hello World, which was posted before this view was as widespread).

---

While the above answers the question you've posed, I'll also note that not all of our rules have caught up to this change in mindset. For example, it is still the case that we have a seemingly-arbitrary set of conditions that an executable must meet to be considered a "programming language" and thus eligible for answering challenges. This made sense when it was introduced, because it aimed to eliminate e.g. the 0-byte rot13 answer to the challenge "output ROT13 of input." But the more general philosophy described above already deals with this -- such an answer is boring, because the language was literally designed to do what the challenge asks.

Another example is the policy regarding "serious contenders," which is described by former moderators Mego and Dennis as well as in our current Help Center. Currently, by a literal interpretation of the rules, it is the case that answers that impose a source restriction on themselves, despite being well-golfed under such a restriction, violate this policy. This has the unfortunate effect of disallowing some answers that are legitimately good, such as this program which decides whether a string follows a rule, whose source code itself follows the rule (deleted, requires 10k rep to view).

But ah well, I'm getting sidetracked, and this is really a topic for a different meta post. Thanks for asking this one, and apologies for hijacking it to soapbox a bit :)