Post History

Contestants should read from standard input and write to standard output. This is because almost all programming languages, including most esoteric programming languages, allow reading from standard input and writing to standard output. Especially for esoteric programming languages, this is commonly the only way to communicate. Therefore this method of communication is the most inclusive.

If you want to include languages that cannot use a standard input/standard output interface (for example SQL), you can allow a translation layer in another language that turns standard input into a form that the program can read and gives the output. That translation layer would have to do nothing else but pass standard input to the program and write the output of the program to standard output; otherwise the entry would be counted as a combination of two languages (are there any general rules about language combinations here on the site?). For example, in an SQL solution, the input could be passed as argument to a stored procedure, and the output could be a one-row table with one text column, which is written to standard output by the translation layer.

Such a translation layer might also be allowed to support languages that only support non-interactive computation (that is, input is given at the program start, and output is provided at the end of the program) in round-based contests where normally programs are expected to continue running between rounds. In this case, the translation layer would accept extra data after the defined output from the program, would pass the defined output to the controller process, then for the next round it would receive input from the controller process, and pass both that input and the previous output back to the program. The translation layer should not transform that data in any other way. Obviously this part only applies if the code is allowed to keep information between rounds.

It should be on the submitter to make it evident that the translation layer does not sneak in additional behaviour. Also, the languages of the translation layer may be restricted to allow easy checking.

## Advantages

This approach is IMHO the most inclusive to all languages, including esoteric languages. The vast majority of languages support interaction though standard input/standard output. The option of a translation layer makes it inclusive also to languages that don't fulfil that requirement

## Disadvantages

Allowing a translation layer means extra effort for checking that no extra functionality is sneaked in by that translation layer. However those translation layer should be simple because their functionality is simple.