# Can numeric input/output be in the form of byte values?

This answer just prompted a question, which I've wondered about a few times when answering challenges in esoteric languages:

For some esoteric languages, the only means of input/output is reading and writing individual bytes from STDIN to STDOUT, and interesting golfing of numeric challenges is near impossible with decimal input, since 80% of your code will be implementing atoi() and itoa().

If a challenge specifies that a program should take a number as input, can that number be taken as the value of a byte read from STDIN? The same question applies to output (although answers may of course address these two parts individually and with differing opinions).

For the purpose of this question, please assume that the limitations on the range of inputs/outputs is not an issue for the challenge in question.

• This is a standard procedure in brainfuck. Let me look up an off-site precedent. Jan 26 '15 at 13:08
• It's not entirely clear what character codes have to do with this question. Is this an accurate restatement of the question? If so, I think clarification as to the scope of the question would be useful for two reasons: firstly, many non-esoteric languages seem to fall into the same category (e.g. Java); secondly, the linked answer also seems to output raw bytes rather than implement itoa. Jan 26 '15 at 14:20
• @PeterTaylor Thanks, that is much clearer. Jan 26 '15 at 14:26
• It would save me 139 characters :P Jan 26 '15 at 16:57
• This also affects Java - compare System.in.read() to new java.util.Scanner(System.in).nextInt() Jan 29 '15 at 16:55

# Yes, numerical input and output may be given as a character code

As long as this doesn't give an unfair advantage (e.g. for a challenge that is "given a character code, output the character"), I don't see any problem with this. It's similar to allowing each language to use its native string representation of arrays when talking about list-based questions.

The languages in question are probably not going to win normally anyway, and I don't like to discourage answers in interesting esoteric languages, just because the author couldn't be bothered to include the atoi implementation.

PS: Also, technically, taking numbers as just the value of a byte or byte stream is in some ways more natural than reading its decimal representation encoded in ASCII characters. ;)

# No, numerical input and output as a character code should not be valid by default

(I say "by default" because, like any good rule, it can be broken. If the question asker specifies then it should override whatever this thread decides.)

Part of the challenge of using languages like brainfuck is that even incredibly simple things become massive undertakings. What would be "read an int" becomes "read all characters of input, subtract 48 from each cell, multiply the leftmost cell by 10 and move it on top of the cell to the right until there's only one character remaining". That's what brainfuck is all about.

But more importantly than my ideology about bf, I don't like the idea of giving some languages an advantage because they're hard. Sure, this isn't technically giving an explicit advantage for any one language since anyone could choose to do i/o this way, but it's even mentioned in the question that this would be helpful for certain esoteric languages. There are no other languages (that I'm aware of, at least) where the community has decided "this feature is hard to use so let's change the way questions work to make it easier". The difficult feature is a part of the language.

We don't give Java a bonus because there's a lot of boilerplate, we don't give golfscript a penalty because it's short (though, people have proposed these, and I wasn't a fan then either). I don't feel we should make a rule change like this for the purpose of throwing a specific set of languages a bone.

• I don't think "If the question asker specifies then it should override whatever this thread decides." is relevant here. I don't see anyone thinking of and explicitly overruling this default, as it's quite an edge case. Regardless, I see where your coming from, but I think penalties or bonuses for language terseness is quite a different issue. The question is about input encoding, and in that I think it's not much different from allowing CJam to expect arrays like [1 3] and Python like [1,3]. If anything reading a byte is more natural than an ASCII-encoded decimal number. Jan 26 '15 at 17:59