Explicitly disallowing or disadvantaging arbitrary (classes of) languages

This has become much rarer recently, but the occasional challenge by a new user still includes it, so here as an answer to point them to.

Disallowing arbitrary languages (or classes of languages, primarily things like "no golfing languages allowed") is not in the spirit of this community, as has been discussed many times on meta. If you don't like golfing languages beating others, a) don't pose a code golf challenge or b) look at the challenge as a separate competition in each language.

This answer also encompasses penalties that only apply to certain languages.

Suggested course of action:

• Downvote to discourage this behaviour and show that it is not welcome in this community.
• Leave a friendly comment that this is not how we roll and link them here.
• Don't edit it out without the author's permission - I don't think we have a consensus that such restrictions are disallowed or off-topic. They're just a bad idea.

A milder form of this is challenges where the task depends on the language name (e.g. "print the language name"). Those give a byte-count penalty to languages with long names. If this is necessary for the challenge to make sense/be fun, a better idea might be to subtract the language's name from the byte count and require that it appears verbatim in the source code (without the latter requirement, you'd be giving a penalty to languages with short names instead).

This answer does not encompass challenges which are impossible in some (or many) languages due to technical limitations (audio output, file system manipulation etc.). That said, challenges should strive to be as inclusive as possible without damaging the core of the challenge (do submissions really have to play the audio directly via the speakers, or could they also write an audio file to STDOUT?).

When the OP needs to run all submissions on their own machine (e.g. for fastest-code, king-of-the-hill or certain code-challenges), it's also fine to require that all languages have a freely available compiler or interpreter. I wouldn't call that "arbitrary" restriction. (Whereas, I would call it arbitrary if someone imposed the same restriction on a standard code golf where the OP isn't planning to test every answer on their own machine anyway.)

Explicitly disallowing or disadvantaging arbitrary (classes of) languages

This has become much rarer recently, but the occasional challenge by a new user still includes it, so here as an answer to point them to.

Disallowing arbitrary languages (or classes of languages, primarily things like "no golfing languages allowed") is not in the spirit of this community, as has been discussed many times on meta. If you don't like golfing languages beating others, a) don't pose a code golf challenge or b) look at the challenge as a separate competition in each language.

This answer also encompasses penalties that only apply to certain languages.

Suggested course of action: (for voters)

• Downvote to discourage this behaviour and show that it is not welcome in this community.
• Leave a friendly comment that this is not how we roll and link them here.
• Don't edit it out without the author's permission - I don't think we have a consensus that such restrictions are disallowed or off-topic. They're just a bad idea.

A milder form of this is challenges where the task depends on the language name (e.g. "print the language name"). Those give a byte-count penalty to languages with long names. If this is necessary for the challenge to make sense/be fun, a better idea might be to subtract the language's name from the byte count and require that it appears verbatim in the source code (without the latter requirement, you'd be giving a penalty to languages with short names instead).

This answer does not encompass challenges which are impossible in some (or many) languages due to technical limitations (audio output, file system manipulation etc.). That said, challenges should strive to be as inclusive as possible without damaging the core of the challenge (do submissions really have to play the audio directly via the speakers, or could they also write an audio file to STDOUT?).

When the OP needs to run all submissions on their own machine (e.g. for fastest-code, king-of-the-hill or certain code-challenges), it's also fine to require that all languages have a freely available compiler or interpreter. I wouldn't call that "arbitrary" restriction. (Whereas, I would call it arbitrary if someone imposed the same restriction on a standard code golf where the OP isn't planning to test every answer on their own machine anyway.)

Explicitly disallowing or disadvantaging arbitrary (classes of) languages

This has become much rarer recently, but the occasional challenge by a new user still includes it, so here as an answer to point them to.

Disallowing arbitrary languages (or classes of languages, primarily things like "no golfing languages allowed") is not in the spirit of this community, as has been discussed many times on meta. If you don't like golfing languages beating others, a) don't pose a code golf challenge or b) look at the challenge as a separate competition in each language.

This answer also encompasses penalties that only apply to certain languages.

Suggested course of action:

• Downvote to discourage this behaviour and show that it is not welcome in this community.
• Leave a friendly comment that this is not how we roll and link them here.
• Don't edit it out without the author's permission - I don't think we have a consensus that such restrictions are disallowed or off-topic. They're just a bad idea.

A milder form of this is challenges where the task depends on the language name (e.g. "print the language name"). Those give a byte-count penalty to languages with long names. If this is necessary for the challenge to make sense/be fun, a better idea might be to subtract the language's name from the byte count and require that it appears verbatim in the source code (without the latter requirement, you'd be giving a penalty to languages with short names instead).

This answer does not encompass challenges which are impossible in some (or many) languages due to technical limitations (audio output, file system manipulation etc.). That said, challenges should strive to be as inclusive as possible without damaging the core of the challenge (do submissions really have to play the audio directly via the speakers, or could they also write an audio file to STDOUT?).

Explicitly disallowing or disadvantaging arbitrary (classes of) languages

This has become much rarer recently, but the occasional challenge by a new user still includes it, so here as an answer to point them to.

Disallowing arbitrary languages (or classes of languages, primarily things like "no golfing languages allowed") is not in the spirit of this community, as has been discussed many times on meta. If you don't like golfing languages beating others, a) don't pose a code golf challenge or b) look at the challenge as a separate competition in each language.

This answer also encompasses penalties that only apply to certain languages.

Suggested course of action:

• Downvote to discourage this behaviour and show that it is not welcome in this community.
• Leave a friendly comment that this is not how we roll and link them here.
• Don't edit it out without the author's permission - I don't think we have a consensus that such restrictions are disallowed or off-topic. They're just a bad idea.

A milder form of this is challenges where the task depends on the language name (e.g. "print the language name"). Those give a byte-count penalty to languages with long names. If this is necessary for the challenge to make sense/be fun, a better idea might be to subtract the language's name from the byte count and require that it appears verbatim in the source code (without the latter requirement, you'd be giving a penalty to languages with short names instead).

This answer does not encompass challenges which are impossible in some (or many) languages due to technical limitations (audio output, file system manipulation etc.). That said, challenges should strive to be as inclusive as possible without damaging the core of the challenge (do submissions really have to play the audio directly via the speakers, or could they also write an audio file to STDOUT?).

When the OP needs to run all submissions on their own machine (e.g. for fastest-code, king-of-the-hill or certain code-challenges), it's also fine to require that all languages have a freely available compiler or interpreter. I wouldn't call that "arbitrary" restriction. (Whereas, I would call it arbitrary if someone imposed the same restriction on a standard code golf where the OP isn't planning to test every answer on their own machine anyway.)