Advice for hosting a language agnostic King of the Hill contest
A King of the Hill contest requires that a controller program provided by the person hosting the contest communicate (both input and output) with each of the entries to the contest. For some contests these entries may be functions to be called by the controller, and in other contests the entries may be stand alone programs that communicate with the controller by some other means.
Some methods of communication (such as function calls) tend to make the contest language specific. For example, a controller that calls functions often means that each entry must be a function written in the same language as the controller.
Language specific contests are permitted, but language agnostic contests have the advantage of including more potential players. They also add an extra layer to the competition, as there is now competition between languages as well as competition between players.
What advice should I bear in mind when designing a language agnostic King of the Hill contest? What approaches would you recommend and what advantages and disadvantages do they have?
1 answer
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.
0 comment threads
0 comment threads