A proposal on command line flags [duplicate]

Question

I've been thinking about command line flags for a while, and I think that we should stop adding them to our byte counts. And instead consider different invocations to be different languages. Now because this might be a little bit of a surprise I will walk you through my reasoning.

What are command line flags and why do they exist?

If you are not familiar with command line flags they are little bits of information that are added to the invocation of a language. For example if you were running Brain-Flak (I will be using Brian-Flak as a primary example through out) you would normally call it with:

./BrainHack program

Where program is the name of the file containing your source. You could add the -A flag to this invocation to tell the interpreter to output in ASCII. You would invoke that with

./BrainHack program -A

In general flags exist to toggle a number of compiler or interpreter options, these are called binary flags. There are also flags that take arguments, for example Brain-Flak has a -e flag that causes it to take the source from the command line rather than a file

./BrainHack -e "(()())"

How are they currently scored?

Our current rules are derived from this answer in short flags are counted as

a difference in character count to the shortest equivalent invocation without them

For most cases this means +3 bytes for the first flag and +1 bytes for every subsequent flag.

I have several issues with the current state, but I will just list the two biggest ones (I'm listing a 3rd minor point as a footnote). The first and largest issue is that its confusing and rather unclear. Take for example the -A flag in Brain-Flak, if I use it what do I need to add to my byte count? Well there are two "standard" invocations of Brain-Flak

./BrainHack program

and

./BrainHack -e "source"

Ok so which is shorter? Well this depends on the name of the file and the length of the source code which already puts us into rather murky territory. However as long as we assume the file name is 1 byte the former will always be shorter so lets say that is the shorter standard invocation. Well here is the problem, in the original post the author uses as an example perl's -e flag, which is analogous to that of Brain-Flak, and called that the shortest standard invocation. This may seem like a I'm intentionally making a stink, but members of the Brain-Flak community use both +1 and +3 for the -A flag from answer to answer. There is definitely confusion on this point.

My second problem is that its penalties can be often be sidestepped by making more interpreters. For example I could make a "new language" called Brain-Flak-A that has the following fish interpreter

function bfa --wraps /opt/brainhack/BrainHack
	/opt/brainhack/BrainHack -A $argv
end

Try it online!

I've seriously considered doing this for Klein which always has a +3 penalty on all of its answers (meta ruling), because you must specify the version of the language in a 2 byte string. This is really annoying to anyone that programs in Klein (or it least it is to me) and serves no real purpose. Its not like the version of the language

Here is the crux of my argument "If I can just make new interpreters to get around the rule then why does it exist?". If spent 20 minutes writing interpreters no Brain-Flak user would ever have to use flags again. Most of the variants caused by binary flag differences are more akin to language differences than to changes in the source code and I think we should treat them as such.

The Meta-Golfscript Problem

Meta-Golfscript is a hypothetical set of languages designed as a rule lawyer to get zero byte programs on every challenge. They encode their program via a command line flag rather than by a source file. Under our current system this is fine. The argument is (quoting Nathan Merrill here):

Making them each different languages is a slippery slope where people can make a MetaGolfScript where each "language" is defined in the flags.

I don't disagree with Nathan Merrill here and I think he is right we should not let Meta-GolfScript answers get away with anything. However I don't think this is a problem. As I touched on in a comment the would-be-Meta-GolfScripters already have a ripe opportunity to create 0 byte programs now that we allow languages that post date the challenge. Our current consensus is to just downvote and delete any abuse of our lenient policy. I feel that we should put command line flags under the same policy. Like the non-competing policy of days past, many more benign answers are hurt by the policy than malicious answers are prevented. Since the lifting of that policy we have not seen a surge of "0 byte answers" abusing the new rules. I think the old adage of optimizing for perls rather than sand applies here.

So here is my proposal:

We treat different command line invocations of the same interpreter or compiler as different languages with no byte cost, and rely on the judgement of the community to police those who seek to trivialize challenges in this manner.

Now this is a propsal, not a proclamation or declaration. I'm interested in what other people think about this. I would like to have a discussion about this. Even if the community decides that this specific proposal is not what we want I think we should definitely make changes to the current policy, which I believe is broken.

---

^{My third problem with this system is that it is not actually representative of the information gained from adding command line flags. The fact that the command line is separate from the source actually constitutes information that can be used however the current system does not account for this information.}

Answer 1

I haven't thought through all of the issues and arrived at a balance of pros and cons, but there is one con which comes to mind immediately and should be included in the discussion.

This would affect more than just scoring in code-golf

Treating different implementations of the same specification as different languages already has consequences which IMO are pernicious. A recent example is an answer-chaining question which required all answers to use a language which hadn't been used earlier in the chain. One answer used Python 3 (PyPy) on the basis that Python 3 had already been used, but that was presumed to be using the "language" "defined" by the CPython implementation, leaving the PyPy implementation up for grabs.

Taken to extremes, that approach would already "create" 19 different "languages" from CPython implementations of Python 3.5, counting all the alphas, betas, and release candidates. But if any command-line flag also creates a new "language", the following flags would not materially affect a lot of the simple programs that are posted on PPCG:

-b  or  -bb
-B
-E
-O
-OO
-Qold  or  -Qnew  or  -Qwarn  or -Qwarnall
-R
-s
-S
-t  or  -tt  (if warnings/errors are to stderr and can be ignored)
-v  or  -vv  (since I don't think answers tend to use modules)
-Wignore  or  -Wdefault  or  -Wall  or  -Wmodule  or  -Wonce  or  -Werror

So if each combination of flags defines a new language, we have 120960 languages per Python interpreter, and any answer-chaining question which wants to make languages single-use would need to explicitly overrule the proposed convention.

Answer 2

The difference between this proposal and the newer-languages proposal is that abuse is more clearly defined in the latter. I can imagine several ambiguities that can arise from this rule.

• What about interpreters that take input from the command-line arguments, like Jelly?
• What about interpreters that can use the command-line arguments for the initial stack contents, like ><>?
• Wait, are those two even different?

With the newer-languages proposal, abuse is fairly clear: if a feature was added to a language that is useful on one challenge but on very few others, then adding the feature constitutes abuse.

With this proposal, there's simply too much room for ambiguity as to what constitutes abuse. MetaGolfScript is abuse because it encodes all the program information outside of the scored section of the program. This leaves open the question of how much program information can be encoded.

The way I see it, you have two options:

• Create the alternative implementations. As you said, it would not take too long, and it completely eliminates the ambiguity problems.
• Deal with it. I don't expect Klein or Brain-Flak will be competing for 1st place, so think of the challenge as a competition in every language. The bytes for command-line flags are boilerplate, but then again lots of languages have boilerplate. Are those added 3 bytes really so bad compared to class M{public static void main(String[]a){}}?

Answer 3

This is a valid subset of "Implementation"

Consensus broadly states that a language is defined by implementation. Implementation itself is (afaik) not very precisely defined, but my understanding is that whatever your "Implementation" is, you feed your code to it and then the implementation "runs" the code to obtain the desired result.

From that understanding, I would consider flags to be a part of implementation. Versions are also a part of implementation, thus Python 2 and Python 3 answers are both acceptable. In fact, I would argue that almost anything could be considered "part" of implementation for an answer that chose it to be so; for example, using statements in C#. I believe that leaving all such information as a part of "implementation" is valid. If someone were to abuse this by claiming that the "Implementation" they're using causes a 0 byte program to do whatever the challenge asked, then it would be indistinguishable from somebody who created a new language which did whatever the challenge asked when provided with a 0 byte program; something which is already considered forbidden. Since Implementation in this sense is being treated as identical to the concept of a "language", your listing of language should indicate what your implementation is, but not affect your code's length either way.

To illustrate, these would be some viable language names under this proposal with no byte penalties:

• Klein 101
• C# w/ LINQ
• Cubically 2.6
• Python 2.7

To be perfectly honest, this seems to me like it most closely lines up with how the question is already treated (I see answers where a language references an external library listed as "language + library" quite often for example). With regards to how this affects Polyglots, I think it's irrelevant in challenges like The Versatile Integer Printer which are required to have different outputs for each language anyway thus most of the implementations with trivial differences are either impossible to use anyway because their output wouldn't be different, or are reasonable use because significant effort is required to make their output different. Polyglots which require identical outputs for each language are more difficult, but I think that it's probably up to the community anyway; Python 2 and Python 3 are relatively famous for being treated as separate languages, but the point at which differences between versions are enough is mostly arbitrary, while languages which are nearly identical or where one is a superset of another are common enough that I think worrying about how many extra "languages" some program becomes valid in as a result is unnecessary. As Wheat Wizard pointed out, removing the restriction that a language must be created before the challenge hasn't suddenly reduced PPCG to anarchy because abusive answers are terrible and infrequent, and get downvoted when they do appear. I agree that this change would be similar.

I don't really have a solution in regards to specifically answer-chaining though. In my opinion requiring different languages in an answer chain is only slightly better than banning built-ins in regards to it actually generating value, but I will admit that this proposal pretty much trivializes what it means for two languages to be "different".