Currently, custom oracles (or custom check functions) can be written in any of the supported programming languages (except C or Bash). This issue is to consider if we might want to remove the ability to do so in anything but Python. The Python custom oracles are already the recommendation in the docs.
The benefits are:
Custom oracles in Python are the fastest, as they execute in-process of the judge (this is a special case).
This reduces internal complexity for custom oracles significantly in TESTed.
This reduces the work needed to implement new languages.
Less maintenance work of keeping all implementations in sync.
One argument might be that someone who is writing an exercise in a programming language (e.g. JavaScript) might also want to write a custom oracle in JavaScript. While this is valid, it should also be noted that they basically have to use the Python syntax in the DSL anyway. Additionally, Python is not a very complex language.
Another point against is that this is nice theoretically: we can say we support custom oracles in all languages.
A quick grep on the server reveals that we are currently the only ones who use this, and we always use Python.
Note that is purely the custom oracles, which are programming language independent as they pass through the TESTed pipeline. This is not the "programmed" oracles, which are programming language dependent and will still be available in every programming language, by their nature.
Currently, custom oracles (or custom check functions) can be written in any of the supported programming languages (except C or Bash). This issue is to consider if we might want to remove the ability to do so in anything but Python. The Python custom oracles are already the recommendation in the docs.
The benefits are:
One argument might be that someone who is writing an exercise in a programming language (e.g. JavaScript) might also want to write a custom oracle in JavaScript. While this is valid, it should also be noted that they basically have to use the Python syntax in the DSL anyway. Additionally, Python is not a very complex language.
Another point against is that this is nice theoretically: we can say we support custom oracles in all languages.
A quick grep on the server reveals that we are currently the only ones who use this, and we always use Python.
Note that is purely the custom oracles, which are programming language independent as they pass through the TESTed pipeline. This is not the "programmed" oracles, which are programming language dependent and will still be available in every programming language, by their nature.