I am currently developing a golfing language for a specific type of task. I was hoping to use some command line flags for different options in the language. Since the language is intended to be a golfing language I thought I would try to make these additional flags as cheap as possible.

The first idea I had was to make a -r flag that is required to run all programs so that adding additional flags would cost only one additional byte, as per the meta-consensus (in this question):

[Extra command line flags are counted] as a difference in character count to the shortest equivalent invocation without them.

Reading this rule I had another idea. I maintain the -r flag but make it redundant when other flags are present (e.g. -a is the same as -ra). That way the first flag is free.

However you can go even further, you can require an option


and require it to run programs normally but consider it redundant when other flags are preset. This would be the current reading of the rules allow you to use pretty much every command line flag you want for free, for a more strict reading of the rules it would even allow for negative scores in . I could make it so that programs can be embedded in the command line arguments thus making a language that can obstensibly solve every challenge on ppcg in zero (or less bytes).

Surely this is not what was intended by the rules. What should we do to prevent this type of shenanigan?

  • 3
    \$\begingroup\$ If you can run programs without -r, then it is evidently not a required flag, and thus should be counted in all cases where it is used. \$\endgroup\$
    – feersum
    Commented Apr 10, 2017 at 6:00
  • \$\begingroup\$ Related \$\endgroup\$
    Commented Jun 23, 2018 at 6:43

5 Answers 5


What should we do to prevent this type of shenanigan?

Firstly, we should all solemnly commit to downvoting every answer we see in a language which is deliberately designed to try to exploit PPCG-specific loopholes. This kind of rules-lawyering funny-at-most-once loophole-seeking is bad sportsmanship and detrimental to the site.

Secondly, I think that a close reading of the cited consensus gives an argument that this doesn't work anyway:


I maintain the -r flag but make it redundant when other flags are present (e.g. -a is the same as -ra). That way the first flag is free.


options to request different behaviors from the interpreter. This is the n/p/l/a/f family of options in perl/sed/awk/ruby. I count those as a difference in character count to the shortest equivalent invocation without them.

On a narrow reading, this only applies to a handful of languages. On a moderate reading it can be generalised to other situations which have additive flags. But to generalise it to subtractive flags should require a good justification that that was the intent, and I can't see that justification.

The other answer, although it's newer and only at +4/-0 rather than +18/-2, is also worth taking into account. It explicitly says "Every Additional Command Line Byte" (my emphasis).

Given that both answers are written thinking about languages with standard UNIX-style command-line parsing (Perl, PHP, ...), I think that should be assumed when interpreting intent and resolving ambiguities.

  • Changing -r to -a is really removing the flag and inserting a new one, and the new one should be scored at full cost. The question of how removing the old one should be scored is a separate issue, and about as urgent an issue as the question of how many angels can dance on the head of a pin. Quite simply: the fact that the issue has never come up before strongly suggests that there aren't any notable existing languages which have such subtractive flags, and if anyone is thinking of creating one solely for the purpose of having a meta discussion on how to score it, they should find more entertaining ways of wasting other people's time.
  • If -rrrr1rr doesn't behave in the same way as -r -r -r -r -1 -r -r (and -r -1 -r -r -r -r -r, etc.: the only flag whose position may be significant when combining single-letter flags is the final one, if it takes arguments) then changing -rrrrrr to -rrrr1rr is adding a new 8-byte flag and should be scored as 9 bytes.
  • 6
    \$\begingroup\$ +1 for the opening paragraph. I'd love to see more focus on sportsmanship, and less focus on the minutia of obscure rules. \$\endgroup\$
    – DJMcMayhem
    Commented Apr 10, 2017 at 16:38
  • 12
    \$\begingroup\$ I, Geobits, do solemnly swear... \$\endgroup\$
    – Geobits
    Commented Apr 10, 2017 at 17:29
  • \$\begingroup\$ This is the best answer I've seen. Though it would be nice to be able to have objective rules for everything, I'll concede that some rules need to be subjective, to be able to say whether or not something is in the spirit of the site. \$\endgroup\$
    – user45941
    Commented Apr 10, 2017 at 17:57
  • \$\begingroup\$ @Mego, the last paragraph is intended to be my view on what the rules should be. \$\endgroup\$ Commented Apr 10, 2017 at 22:22
  • 1
    \$\begingroup\$ I think this is still exploitable, isn't it? If you have -abcdefghijklmnopqrstuvwxyz as the simplest, "basic" way to run a program, -abcdefgsijklmnopqrstuvwxyz contains 2 letters' worth of information but is only a 1-byte change. I think you have to score the facts that h was removed, and that s was added, as one byte each. Also, the fact that each flag can be added or removed doubles the size of your character set, so really they'd need to be scored as 1⅛ bytes each. \$\endgroup\$
    – user62131
    Commented Apr 10, 2017 at 23:01
  • \$\begingroup\$ I got as far as "solemnly commit to downvoting" before thinking "I'd bet money that this is Peter... oh, what do you know." Great answer though, +1 from me. \$\endgroup\$ Commented Apr 11, 2017 at 0:47
  • \$\begingroup\$ @ais523, why do you not think that my proposal would cause that change to count as 28 bytes? \$\endgroup\$ Commented Apr 11, 2017 at 10:08
  • \$\begingroup\$ @PeterTaylor: I'm assuming that the options are all independent of each other and can be reordered without issue. \$\endgroup\$
    – user62131
    Commented Apr 11, 2017 at 12:25
  • \$\begingroup\$ @ais523, that final sentence wasn't intended to be interpreted as applying to subtraction of flags, just to addition. I've reworked the final paragraph to make it clear that I'm not proposing that subtractive flags should be free. There's no existing consensus which covers them, and there's no need for one. \$\endgroup\$ Commented Apr 11, 2017 at 15:57
  • 1
    \$\begingroup\$ "commit to downvoting every answer we see in a language which is deliberately designed to try to exploit PPCG-specific loopholes" - does that include every Bubblegum answer ever? \$\endgroup\$ Commented Apr 22, 2017 at 16:51
  • 1
    \$\begingroup\$ @JanDvorak, I have been applying this policy to Bubblegum answers for a long time. \$\endgroup\$ Commented Apr 22, 2017 at 21:04
  • \$\begingroup\$ But, I like to see how it compares to actual languages... \$\endgroup\$ Commented Apr 22, 2017 at 21:04

I'm starting to think that our general rule for byte counting, etc., is all wrong.

First, a thought experiment. I think the fairest way to compare programs would be like this: for each language, we define an infinite sequence that contains all possible programs in that language (taking into account compiler flags, nonstandard conditions, and everything else that might affect the way the program runs). Then each program is scored by its position in the sequence. In most cases, the sequence would/could just come down to "sort all possible programs by their length in bytes" and lead to approximately the same scores we have now, but languages that intentionally went for this sort of shenanigans would find the score much worse.

That said, I suspect we probably shouldn't/can't move to a system like this; it's much harder to understand than the present system, even if it is a lot fairer and less exploitable, and it'd therefore make it much harder for new users to join the site. However, it's a good test to use to judge whatever actual scoring rules we come up with to see if they make sense or not.

We can apply these general principles to this case. In this case, we learn that what's important is that the score penalty for changing command-line options is based on the of those changes. In the case of adding options, that's trivial (as even uncompressed, the changes take up no more space than the options themselves), but when deleting or editing options, the number of deleted/edited bytes is clearly capable of being an underestimate of the number of bytes required to specify the change.

Perhaps the best solution is to define language variants in which the command-line options for the language are somehow part of the program itself. (This is what, e.g., Anarchy Golf does for Perl, which makes heavy use of options.) This is along similar lines to defining a new encoding, or a new I/O wrapper around a language, or whatever. As far as I can tell, this would prevent all possible forms of cheating, while still being fairly easy to understand.

  • \$\begingroup\$ In mentioning Perl flags as part of the program itself, are you referring to the use of hashbang lines? \$\endgroup\$
    – feersum
    Commented Apr 10, 2017 at 5:20
  • \$\begingroup\$ @feersum: Right, Perl will parse (most) options after a #!perl comment on the first line, which is an "in-band" way of signalling options. (Options are so helpful for Perl that that is, amazingly, still often shorter than going without.) \$\endgroup\$
    – user62131
    Commented Apr 10, 2017 at 5:29

The simplest rule to apply would be "don't take the mickey".

If a language sometimes requires a flag which does absolutely nothing, it's clearly trying to game the rules. So your idea for -r / -a would be a no-go. You'd basically be getting a byte of code for free.

If a language always requires a flag, that's OK. So your original -r / -ra is no problem. In fact, my view is that we shouldn't count the <space>- as extra chars even for languages that don't always require a flag.

If a language has a "flag" which can be adjusted to vary the program in more ways than the code itself (your 1000 rs suggestion on Mego's answer), then it's not a flag; it's an alternative input format for the code. You can't just put a - in front of something and call it a flag.

Finding explicit rules for this stuff will always leave loopholes, but common sense can trivially judge them on a case-by-case basis.

  • 4
    \$\begingroup\$ I agree with your sentiment, but we do really need objective rules. \$\endgroup\$
    – user45941
    Commented Apr 10, 2017 at 0:41

A practical rule proposal

I think that there are some problems with the current rules for counting flags. The simple fact that adding a mandatory flag to a language improves the bytecount of answers in that language that use other flags seems quite wrong to me. Another example is the case of ><>, where the -v flag is useful in a lot of situations but costs 3 bytes since there is no other argument that can be used for free.

So, the simple rule I'm proposing is:

All flags are counted as if they were part of the source. The - prefix is ignored.

I think this should be the general rule, straight and simple. Then, we could make per-language exceptions to ignore those flags that are mandatory or always used in practice, to avoid punishing languages like Jelly.

In the language of the question, the r flag could be listed as an exception and not counted. A submission using -ar would have its bytecount increased by +1, exactly like one using just -a. (Since you were adding -r exclusively to render other flags cheaper, though, you could consider simply not implementing it)

  • 1
    \$\begingroup\$ The dashes technically aren't necessary for CLI flags. They're just a convention used to distinguish them from program arguments. There's no reason to not count them, since CLI flags can be done without dashes. \$\endgroup\$
    – user45941
    Commented Apr 10, 2017 at 7:21
  • \$\begingroup\$ @Mego The fact that they are a widely accepted convention could grant them this special treatment. I think this is advisable because the alternative is having to deal with their weird behavior (we count the ` -` for each flag, but sometimes multiple flags can be combined to need only one instance of ` -`, and sometimes you have a base flag that doesn't need to be specified and can be combined with the flags you use) \$\endgroup\$
    – Leo
    Commented Apr 10, 2017 at 12:47

I propose an alternative rule:

Non-standard flags for compilation and/or execution incur a penalty equal to the Levenshtein distance from the nearest standard execution.

This would not change the byte penalty in many cases (-abc would still be +2 bytes if the standard is -a), but it would prevent such abuses like the one in the question.

  • 4
    \$\begingroup\$ I like this much better but there still is a break, albeit a more involved one. Simply make a standard invocation flag something like 10,000 rs. Within Levenshtein distance one there are 2,550,513 programs. This allows you to get more programs than a byte of code should allow you to. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Apr 8, 2017 at 17:18
  • \$\begingroup\$ @WheatWizard I agree that this isn't perfect, but I'm not sure a perfect solution exists. \$\endgroup\$
    – user45941
    Commented Apr 8, 2017 at 22:51
  • \$\begingroup\$ Number of insertions+number of deletions could be a better metric in this case. Basically it's levenshtein distance without the possibility of replacements, I don't know if it has a name. \$\endgroup\$
    – Leo
    Commented Apr 9, 2017 at 7:32
  • \$\begingroup\$ @Leo That would allow a similar exploit as detailed above. So long as the total invocation length doesn't change, there would be no insertions or deletions - only edits. \$\endgroup\$
    – user45941
    Commented Apr 10, 2017 at 0:44
  • \$\begingroup\$ @Mego what I meant is that edits are not allowed. To turn abc into axy you'd need to delete bc and insert xy, distance=4. \$\endgroup\$
    – Leo
    Commented Apr 10, 2017 at 4:34
  • \$\begingroup\$ @Leo So in other words it's twice the Levenshtein distance for edits, and exactly the Levenshtein distance for deletions/insertions. \$\endgroup\$
    – user45941
    Commented Apr 10, 2017 at 7:19
  • \$\begingroup\$ @Mego Exactly, thank you (sometimes I'm not that good at explaining myself) \$\endgroup\$
    – Leo
    Commented Apr 10, 2017 at 7:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .