# How should program size be calculated if an interpreter has multiple binaries with different behaviors?

This question is specifically prompted by my using ImageMagick in a challenge, but applies in general. This is somewhat an extension of

All of the IM tools take the same syntax of operations and expressions. However, each tool has a different name and a different default behavior.

convert -resize 50% foo bar shrinks image foo to half size and saves it to new image file bar

mogrify -resize 50% foo shrinks image foo to half size and overwrites it with the new version

display -resize 50% foo shrinks image foo to half size and puts it on the screen

If there is a challenge to resize an image to half size, and it doesn't specify where the output has to go (so that any of the three are valid), is -resize 50% the whole program? If it does specify that the output has to go to a new file, do I then add 8 bytes for mogrify_?

## Make the specific binary used part of the language definition

In other words, let convert, mogrify and display count as three different "languages" (assuming that all three binaries meet the "programming language" requirement), and specify which is being used in the answer header.

If multiple different binaries are needed, then the language should be given as "bash w/ imagemagick" or similar, and the full names of the binaries added to the byte count.

• This is the obvious answer. The implementation (read: binary) defines the language. – Mego Mar 29 '16 at 22:57

## Add it to the byte count, but using as few bytes as possible

In the specific case under question, there could theoretically be a single imagemagick selector program which selected which of the binaries to use on the basis of a flag value. Since there are less than 256 different binaries, one byte of information is enough to distinguish them. My preference would be to add one byte to the total (or even three bits if you like fractional bytes) to account for the selection of the binary.

Moreover, there are other situations in which an interpreter requires a certain flag to work in a specific way, and the will of the community has been to add 2 bytes to the total for the use of this flag. This is a slightly different scenario, as in these cases, there has been a single "default" (no flag) setting, while in the case under consideration, there is no "default". I think 1 byte is a fair compromise when it's not clear which of the binaries is the "default" and which ones are the ones we are "adding flags to".

• Can you supply citations for the 2 byte flag convention? I'm used to one byte per flag in perl golf. – Sparr Mar 29 '16 at 19:35
• Maybe it was one byte. I couldn't find the link and ran out of time and just posted – quintopia Mar 29 '16 at 21:34
• Note that you can simply write a new "interpreter" that does the flag parsing and calls the other programs. – isaacg Mar 30 '16 at 2:36
• @isaacg yes this is the "selector program" i was referring to – quintopia Mar 30 '16 at 3:38
• @Sparr My understanding is that perl adds one byte per flag because you're already using -e and you can add other flags to that same hyphen, but in some other languages every flag needs its own hyphen – undergroundmonorail Apr 3 '16 at 12:38