# Language util name byte counting

I'm trying to figure out how the byte counting works in "Sum the numbers on standard in". In one answer using the jq util counts the non-space bytes after the util name, but not the util or the spaces. Using similar reckoning, (i.e. don't count the util name), one could get a byte count of 0 from numsum.

Possibly the distinction is between programs which are also languages, (i.e. jq describes itself as a language, therefore don't count the language binary name), and utils that are not, (so do count the util name). If so, perhaps the question is what distinguishes a language from a util with a lot of switches.

Supposing a clear distinction exists between language executables and utils, there's then the question as to language executables used as utils, as in this answer where the pipe |bc is counted even though bc describes itself as a language.

• The program "add" is being run with the flag -s. They are simply giving instructions as to how to run this from terminal. The way you are saying it should be scored would be if it was submitted as bash + utils – fəˈnɛtɪk Mar 25 '17 at 18:05
• @fəˈnɛtɪk, If add is a jq program, then explain why + is not a bc program. To simplify, assume the input to stdin is strictly two numbers. – agc Mar 26 '17 at 7:43
• I don't know if + is a bc program. However, if it only adds 2 numbers it does not fit the IO requirements of that problem – fəˈnɛtɪk Mar 26 '17 at 11:59
• @fəˈnɛtɪk, Re "the IO requirements": the "Sum the number..." OP states that "The input will contain at least one integer." – agc Mar 26 '17 at 14:55
• And + would fail for over 2 integers. Which is included in the requirements for that challenge. – fəˈnɛtɪk Mar 26 '17 at 15:02
• @fəˈnɛtɪk, Please suppose that OP said "the input will contain exactly two numbers" -- all of that Q's answers, and the SECG counting rules, would still apply. – agc Mar 26 '17 at 15:20
• @agc: In that case, + would be a perfectly valid answer. When a challenge is very easy (such as adding two numbers), it will often have a very short answer in many languages; that's not really a problem (except possibly with the challenge itself). – user62131 Mar 26 '17 at 15:24
• @ais523, Please note this thread is about whether or not to count |bc as three bytes. It's not about what's passed to |bc. – agc Mar 27 '17 at 3:39

Basically, the rule is that the name of an executable counts if you have to access that executable during the course of running the code, rather than it being the thing that runs the code in of itself. In the example of the bash + bc answer, bc is counted as 2 bytes because those two characters are part of the Bash program (it needs them to figure out that it has to call into bc rather than some other executable), rather than anything to do with bc itself. bash isn't counted, even though you'd likely need to type it to run the program, because the program's a Bash program.
For what it's worth, I believe this challenge has a valid 0-byte answer () in numsum, and a valid 6-byte answer (numsum) in Bash + numsum. (Note how those are different languages. The former isn't a programming language; atm we don't consider that disqualifying but views on that have gone back and forth over time.)
• If data-prep (pre-compiling in a way) were regarded as separate step, the |bc example therefore wouldn't need to count those three bytes? – agc Mar 26 '17 at 15:19