16
\$\begingroup\$

We've had discussion on a related topic before, where the general consensus is that challenges should be language-agnostic by default, but specific-language challenges were also acceptable within reason.

Spurred by this question (which was closed for an unrelated reason), the discussion was brought up in chat whether we should make challenges that explicitly exclude certain languages off-topic and therefore subject to immediate closure.

What are the thoughts of the community?

\$\endgroup\$
5
  • \$\begingroup\$ The question you brought up gives a byte penalty to certain languages, but doesn't disallow them. Are you proposing banning that too? \$\endgroup\$
    – xnor
    Nov 14, 2015 at 9:08
  • 2
    \$\begingroup\$ @xnor Yes. Penalizing certain languages is in the same spirit as banning them outright. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 9:15
  • \$\begingroup\$ Can't see the "this question" link! \$\endgroup\$
    – sergiol
    Jan 7, 2017 at 1:40
  • \$\begingroup\$ @sergiol It was deleted. Only users with sufficient rep can see it now. \$\endgroup\$
    – user45941
    Jan 7, 2017 at 1:40
  • \$\begingroup\$ I feel discouraged to ask questions if I can not forbid answers using languages intentionally made for golfing! The same goes for esoteric languages! \$\endgroup\$
    – sergiol
    Jan 7, 2017 at 1:42

2 Answers 2

38
\$\begingroup\$

It depends

I think there are (at least) two very different cases, and the question as posed doesn't distinguish them.

Case 1: banning languages the OP doesn't like

Penalties for using "golfing languages" have a number of problems. For one, the question "Is XYZ a golfing language?" is subjective. For another, borrowing from a phrase about bringing a knife to a gunfight, on this site it's like going to a rifle range and insisting that people should use epées.

Case 2: banning a specific language which trivialises the question

In general, the existence of a language which trivialises a question is a sign that it's a bad question, but there are exceptions. There is a question currently in the sandbox which is about regexes and specifically bans Retina. The question is insanely difficult (if not impossible) in most languages, but boring and trivial in Retina. I think it's sensible to want to avoid someone posting a five-character answer in Retina which would discourage people from trying to figure out a 500-character answer in CJam or Perl.

Similarly, a question which asks you to interpret a specific subset of GolfScript might be ~ in GolfScript and q~ in CJam (if it's the right subset!), but actually be an interesting question in other languages.

In these cases, I think it's as reasonable to ban specific languages as it is to ban the use of built-ins.

\$\endgroup\$
9
  • 3
    \$\begingroup\$ In Case 2, the question should ban builtins rather than specific languages, and allow languages to compete if they are capable of accomplishing the task without the use of builtins. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 18:20
  • 3
    \$\begingroup\$ @Mego, at best that's going to get you a new meta thread asking what qualifies as a built-in in Retina. \$\endgroup\$ Nov 14, 2015 at 18:26
  • 1
    \$\begingroup\$ We have a pretty clear consensus on what a builtin is - it's something provided by the language or standard library that does the lion's share of the work for the task. More pedantry is unnecessary. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 18:29
  • 1
    \$\begingroup\$ In that case, I really don't think your suggestion is good enough for the case I mentioned. \$\endgroup\$ Nov 14, 2015 at 18:31
  • 1
    \$\begingroup\$ Why not? Challenges that exclude builtins are allowed and are basically the norm. Challenges that exclude languages either are Case 1 and should be closed by my proposal, or are Case 2 and should be edited to exclude builtins rather than languages, and are a completely different issue than the issue this post is addressing. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 18:34
  • 1
    \$\begingroup\$ @Mego, because in the specific case I mentioned you either ban Retina or you don't. There's no half-way house of "You can use this subset of the language". \$\endgroup\$ Nov 14, 2015 at 19:05
  • \$\begingroup\$ That is an issue with the specific question, not the policy I am proposing. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 19:11
  • 3
    \$\begingroup\$ I see it as an issue with your policy: that it's not sufficiently flexible to cover all the cases which arise in the real world. \$\endgroup\$ Nov 14, 2015 at 19:27
  • \$\begingroup\$ Let us continue this discussion in chat. \$\endgroup\$
    – user45941
    Nov 14, 2015 at 19:30
13
\$\begingroup\$

Yes, challenges that specifically exclude certain languages or penalize them should be considered off-topic and closed as such

The spirit of this site is to write the shortest code per language for a challenge, not just the overall shortest code. We do not forbid users from posting answers which have worse scores than existing answers; in fact, we encourage it, for the purpose of getting solutions in every language.

Challenges such as the one linked are not in accordance with this spirit - they attempt to exclude languages based on a preconceived notion that some languages are universally better than others for golfing, a notion that is easy to prove false just by looking through the challenges on this site. Prejudiced questions like that one have no place on this site, and should be closed as off-topic.

Note that this does not include the implicit exclusion of languages, such as by requiring functionality that a language might not have (graphical processing, for example), or by disallowing features that the language would otherwise need to answer the challenge (such as certain builtins that trivialize the challenge). In fact, the latter would be a preferable course of action when there is a legitimate reason why using a certain language would confer an unfair advantage; not only does it accomplish the same thing by removing the unfair advantage, it also allows the language to still be used if it can solve the challenge without the unfair advantage, and it also will cover any other languages with similar unfair advantages that might be missed by excluding a specific language or set of languages.

This also does not include specific-language challenges, where answers are required to be in a certain language (or one of a certain set of languages, such as the TIOBE Top 20) - those have been decided to be on-topic in the past (see the linked meta post in the question), barring any other major issues in the challenge.

\$\endgroup\$
5
  • \$\begingroup\$ For a per-language challenge, a (scoring) penalization of a language doesn't really hurt. \$\endgroup\$ Nov 15, 2015 at 12:35
  • \$\begingroup\$ @PaŭloEbermann I disagree. Arbitrarily penalizing the use of a certain language is just as bad as banning it outright. \$\endgroup\$
    – Alex A.
    Nov 15, 2015 at 20:48
  • \$\begingroup\$ @AlexA. I agree that penalizing is not nice and should be avoided, but I don't think the argument The spirit of this site is to write the shortest code per language for a challenge, not just the overall shortest code is a justification for that – because that works just as well when each language has a (scoring) penalty on it. \$\endgroup\$ Nov 15, 2015 at 22:00
  • \$\begingroup\$ @PaŭloEbermann Language handicaps have been discussed before, and decided against. \$\endgroup\$
    – user45941
    Nov 16, 2015 at 1:37
  • \$\begingroup\$ I have "Compile regex" that is still in Sandbox. It 'compiles' with character substitution. If Retina is allowed, it is trivial and it is against spirit of challenge, since the same regex is Retina program. \$\endgroup\$
    – Xwtek
    Nov 17, 2015 at 14:25

You must log in to answer this question.