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

Question

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.

Answer 1

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. ;)

Answer 2

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.