This question already has an answer here:
- Command-line flags on front ends 1 answer
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:
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 -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
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.