This I/O format is fair for many languages – it should be corrected because it isn't fair for all languages, but is normally being used in good faith and we can easily modify answers in languages where it works
I think it's worth thinking about why people use this I/O format in the first place (on other sites). It isn't necessarily a "natural" I/O format for most languages. However, it has the advantage of being very easy to parse; and most competitive programming sites take submissions only as full programs and run them automatically, so they need to have some concrete I/O format to use.
The most notable thing about the "newline-separated length-prefixed array" format is that it isn't cumbersome, at least by the standard of practical languages. Let's imagine we have a challenge whose input format is "the input is an array, specified via a length as a decimal integer on the first line, followed by the elements, each as a decimal integer, on the subsequent lines". Here's a sample input in this format:
5
1
3
6
10
15
representing the array \$[1,3,6,10,15]\$. Let's look at what it takes to parse this in various languages.
Practical languages
If I were to write a Perl snippet that reads data in this format, I'd write it like this:
map<>,1..<>
Try it online!
This is trivially easy to write, short compared to the average Perl program, and simple to memorise. It isn't detracting much from competing in Perl. (I'm not 100% sure that this is optimal, but if we used this sort of I/O format, we'd find the optimal way to write it very quickly.)
What about lower-level languages, like C?
int l;scanf("%d",&l);int*a=malloc(l*4),*b=a;for(;b<a+l;scanf("%d",b++));
Try it online!
This is getting a bit more cumbersome, and a bit harder to write, now (especially because if we aren't taking advantage of the limited range of int, we need a dynamic allocation to be able to handle arbitrarily large lengths, although C's lack of an array type also causes complications); I made an attempt to golf it (under the restriction that I had to declare all the variables I used correctly, without relying on predeclared variables, implicit int, or using variables as the wrong type), but there are almost certainly improvements I missed. However, parsing more or less any other format would be worse. In Perl, we could simplify the snippet by changing the input format to Perl's array notation (1, 3, 6, 10, 15), so that we could parse it with eval<>, but C has neither an array notation nor an eval operator so we can't really go any simpler. (Note in particular that different languages are good at parsing different formats; JavaScript would want [1, 3, 6, 10, 15], for example. But the newline-separated format is "fair" in the sense that practical languages generally don't vary in respect to which builtins they have available for parsing it.)
It's also worth noting that the length prefix on this format makes it fast to parse – delimited formats like Perl's and JavaScript's mean that you don't know the length of the array until you've finished parsing, so might have to allocate more memory mid-parse, whereas knowing the length in advance avoids this issue (sufficiently so that in languages like Rust and Java, the built-in list classes allow you to specify in advance how many elements you expect the list to eventually grow to). Offsite programming competitions often have at least some emphasis on speed (and we do fastest-code even over here), so you wouldn't want the I/O mechanism to artificially slow down the program.
Golfing languages
So if this format is intended to put practical programming languages on a level playing field when it comes to parsing input, what about golfing languages? Many of those, especially more recently, are designed to abuse CGCC's lenient I/O rules.
If this format were more common (say it were standard on CGCC and the history of golfing languages were influenced by that environment), we'd probably see golfing languages adding builtins for it (and I'm currently planning to add builtins for handling this sort of I/O format to the next golfing language I write – it'd make the language more useful in places other than CGCC). As it is, though, the most popular languages don't have knowledge of this format in particular. For those that have builtins for reading from standard input, it hardly matters, though:
ƓƓ€
Try it online!
IEIˆ}
Try it online!
(Note: I don't really know 05AB1E; I suspect I've missed a builtin and that this is doable in 4. These snippets are written under the assumption that we aren't allowed to read beyond the end of the part of standard input that represents the array; the 05AB1E would be simpler otherwise.)
Notable here is that the Jelly program is actually identical to the Perl program I wrote above; the builtins have shorter names, but it's the same builtins connected together the same way.
So our golfing languages might not have been designed to abuse this format, but if they're capable of reading input interactively, it doesn't matter – it's fair for them just the same as it is for the practical languages.
We do run into a bit of a dead end with some golfing languages, though; there are languages like GolfScript and Brachylog that are incapable of taking input interactively (GolfScript reads the entirety of standard input before it starts to run the program, whereas Brachylog doesn't really have the concept of a "full program" – just functions – and the concept of a Brachylog full program is primarily defined by the behaviour of TIO's wrapper). So parsing input, for these languages, is something that's out of scope, and the fact that they're excluded is a good reason to not use formats like this.
Challenge esolangs
Now let's look at esolangs which are designed to be hard to program in (or else naturally become hard to program in due to being excessively low level), rather than easy to golf in. The main issues with these are that they a) might not have the concept of an array and b) frequently can't read numbers in decimal, which makes the I/O format very unfair when it comes to these languages – parsing the input might be harder than solving the rest of the problem, and will be very repetitive if it isn't.
7, 61 non-whitespace characters, 23 bytes
177166177236623716405 7 131 7 740561726405 7 023 7 40352174640555400
Try it online!
(Whitespace added for readability.) 7 is an example of a low-level esolang which, among this genre, is particularly good at handling this sort of I/O format – it has I/O in decimal as a built-in. What it doesn't have is arrays, or even integers, so in order to be able to parse this sort of format, those have to be defined from scratch. (In case you're wondering how it does numerical I/O without integers: input is done via repeating the body of a function a number of times equal to the input, and the function can then be executed to effectively create a loop where the number of iterations is given by the input.)
Indeed, the program wasn't amazingly hard to implement – I managed to write the whole thing in one session without giving up in frustration, and it ends up shorter than the equivalent C program (despite the need to do all the "plumbing" from scratch, and to define formats for integers and for arrays of integers). The interesting thing here is that this "cumbersome" I/O format is actually a better fit than CGCC's "flexible" formats – those are trying to provide input using the language's data types, but 7 doesn't have those, and thus it would prefer to use a text format that's particularly easy to parse (like this one is!). In general, it's very unclear to me how I'm meant to take input in languages that don't have the standard data types that people normally use when specifying inputs to challenges.
The problem comes when we have languages with the opposite properties – they have arrays and integers built in, but no builtins for parsing numbers in decimal. In this case, the decimal parsing routine may well be extremely long, and need to be copied from answer to answer once the most optimal way to do it is found.
Conclusions
This really isn't a bad I/O format – it leads to a fairer comparison between languages than most I/O formats do (less important on CGCC because it isn't a cross-language competition, but still a nice property), and most languages can implement it in a fairly easy way. If you're using a language like Perl or Jelly, the parser for it can trivially be worked into your program without needing to put any thought into it at all, and might potentially even give golfing opportunities in which you do the input parsing and computation at the same time. If you're using a language like 7, it's still fairly easy to handle relative to the rest of the language, despite our normal I/O rules not working at all in that context. I'm not surprised that it's standard on most competitive programming sites.
However, there are some languages which hugely struggle when an I/O format like this is introduced. Some languages can't read from standard input interactively, and can't handle this format. Some don't have built-ins to read integers in decimal, and those will be faced with a huge amount of boilerplate (which will probably be identical from answer to answer) when trying to deal with this format. As a consequence, we don't have this format as standard and prefer to correct challenges that use it.
What to do about answering the challenge before the question is corrected? Well, if you're using a language for which the I/O format works, it'll probably simply be a matter of deleting the parser once you're done (and the parser will be very simple to write). If you're using a language for which the format doesn't work, you probably won't be able to answer the challenge before it's corrected. Either way, that's no reason to avoid answering it (keeping up with edits to the challenge will likely be trivial) and also no reason to avoid correcting the question.
