Keep your golfing in your code, not in inputs and outputs

Question

I am becoming more and more annoyed at the ever-increasing number of rules about what is deemed acceptable as inputs and outputs to programs

Here is a compilation of such rules that I found:

• Interpretation of Truthy/Falsy
• Empty string as a truthy value
• Can numeric input/output be in unary?
• Should booleans be allowed where a number is required?
• Is the empty string an acceptable decimal representation of 0?
• Can numeric input/output be in the form of byte values?
• Accepting numeric inputs in mixed decimal and unary bases

To me, there is absolutely no need for all of those posts, for the following reason:

Code golf is about golfing your code, not golfing the input or the output.

• A challenge gives you numbers as input? Then you take a number as input and not something ridiculous like the empty string instead of 0.
• Booleans either exist in your language and you use them, or you use 0 and 1 as is historically done, nothing else.
• Unary is not the natural representation of numbers in almost all languages, therefore it makes no sense that you can take an input number in unary or return it in unary for said languages, instead of what's natural in said languages (almost always decimal).
• ...

In short, you should take inputs and return outputs as is naturally done in the language you use, and not abuse the format of the input/output because it shortens your code. If your algorithm is shorter on unary numbers, then fine but the conversion from and to decimal goes inside your code, not outside.

Why I think this is important

PPCG is graduating, and is often listed in the Hot Network Questions. We often have discussions e.g. in chat or in comments of "bad challenges" that it is very difficult to enter this community.

I strongly believe those input/output formats deter newcomers from participating in challenges, because, just like for me, the idea of taking as input numbers in unary in a Python program seems completely ridiculous to outsiders.

Getting rid of all this also reduces the number of rules that a newcomer needs to know before posting (which there are a lot of already).

Answer 1

I tend to agree that there are a lot of rules for new users to "discover", and that this is a bad thing (in general). However, I don't agree with your solution, because I don't see how it's any clearer at all. For many challenges and many languages, there isn't a single most "natural" representation of input:

Challenge: Sum the input list of numbers

Ok, so what's the most obvious way to take input? In Java for example, you could take them from STDIN as strings (eww), or as an int array to a function. Oh wait, maybe an ArrayList instead? Hmm, maybe some other sort of List has some nifty builtin? Oh, right, I could use one of those stream things to do this I bet...

Now obviously this isn't the same as taking input in unary. Or is it? I mean, I guess I could take input as unary and just sum the lengths. Probably wouldn't make it shorter, but it would work. But what's the actual difference between that and deciding what sort of list to use, or whether to pull it from STDIN?

I'm sure you can come up with very simple examples for many languages to illustrate the point. There are multiple ways to take inputs in most languages for a reason, and I for one wouldn't try to argue with what's considered most natural. Sure, some are less natural than others, but that's a fine line to walk, and a hard border to draw.

---

Code golf is about golfing your code, not golfing the input or the output.

This sounds right and noble, but I don't think it's actually true here at all, nor should it be. In my opinion, we should be inspiring creativity, and encourage alternative ways to shorten the code. It's why I asked "What's a string?", which isn't in your list above. Using a char[] is shorter in many cases, and it's not usually the "most natural" way you'd want to do it in production code¹, but I don't come here to write production code². Choosing between String and char[] doesn't seem like much, but it's the same class of choice you're talking about when you talk about booleans or unary.

There are many ways to shorten code, and you have to choose among them for each particular challenge. The only way I see to get around this is to write strict rules for every. single. language. I see that as a recommendation in comments, but I think that would only lead to even more chaos. Since we accept any existing programming languages (and write our own from time to time), that's simply a recipe for disaster.

After literally years of adapting our input/output rules to accommodate oddball languages and generally leaning toward leniency, I think this would be a huge step in the wrong direction.

---

^{1: Seriously. People will fight you for trying this in most workplaces. Like, a fistfight. Don't do it.}

^{2: Also, it would probably break the small piece of my soul that still likes C to hear that char arrays aren't the same things as strings, in any context.}