In my dream world, I would rather have code challenges generate a code that's actually useful in the real world, a code that makes its way to be an idiom, to be used in real world projects, and put in a language's standard library.
The prime criterion for a piece of code to be re-used is its readability, then complexity. Additionally, it's important that the code makes sparing use of third party libraries, as library writers and commercial language users are usually reluctant to burden their code with dependencies.
For this end, I propose the following scoring system:
Every language has its winner, no competition between languages.
The score is counted against the code. That is, the less the score -- the better.
The scoring rewards terseness, but in a sense of lexemes rather than characters, so readable names and nice layout do not impair the code. I believe lexemes are a well defined concept for any language. For a high level language, it's any unit of syntax, an identifier, or a literal. For machine code, it's a machine instruction. Clearly higher level languages with less visual noise are at advantage here, but we shall not have direct competition between different languages.
- For every lexeme that's built in the language, add 1 point.
- For every lexeme found in standard libraries for the language, add 2 points. If a language doesn't have a prevalent standard library, no lexeme is considered as a part of standard library for that language.
- For every lexeme that's in some other published library, add 10 points.
The statements that bring the necessary lexemes into scope are not counted.
The scoring encourages efficient algorithms. For simplicity, the largest of time and space complexities is considered, so an algorithm that's balanced between time and space is scored more favorably than a specialized algorithm that wastes one for the sake of maximizing the other.
The author of the code must attribute complexity to the algorithms they have explicitly encoded, and justify their attribution. Anyone who believes the attribution of complexity to an algorithm is justified insufficiently or wrongly, is encouraged to speak up, and the issue clarified until there are no more objections outstanding.
In this way, builtin or library procedures can be of any complexity (I assume the authors of the library are incentivized to choose the algorithms as best they can, and, in any case, providing better replacements for library functions is not the point of our exercise), but adding complexity on top of them is discouraged.
If a library of a language is closed source, official documentation may serve as justified attribution of complexity. (Again, I presume the authors of the documentation are incentivized to be honest and state the correct complexity.) If the complexity is not documented, it is considered unknown and this is as bad for the score as it gets.
- For every explicitly encoded algorithm of logarithmic complexity, add the exponent over logarithm + 1. (That is, for O(log n) add 2 points, for O(log^2 n) add 3 points.
- For every explicitly encoded polynomial algorithm, add as many points as its exponent * 2 + 1. (That is, for O(n^2) add 5 points, for O(1), one point.)
- For every explicitly encoded sub-exponential algorithm, add 8 points.
- For every explicitly encoded exponential or factorial algorithm, add 10 points.
- For algorithms of compound complexity, add scores together. (For example, O(n log n) is 5 points.)
- For algorithms of unknown complexity, add 11 points. This is as bad as it gets, because one must know one's algorithms' complexity.
Can this work?