14
\$\begingroup\$

In light of a recent code golf challenge in which the specification restricts participation to JavaScript, I think it's time we revisited making a hard rule about language-specific golfs. We may discourage such challenges, but ultimately they aren't off topic. Consider Sklivvz's comment:

Either single language questions are forbidden or they aren't. If they are forbidden, close this. If they are allowed, let the OP restrict the question as they like.

There are situations in which language-specific challenges make sense, such as . I'm not talking about those. For , do we have a good reason to allow them at all? We already discourage them, and arguably it falls under the things to avoid when writing challenges, since it disallows all languages but the one specified.

Should we make a rule explicitly banning code golf challenges that are specific to a single language?

\$\endgroup\$
7
  • \$\begingroup\$ I still think GoL-restricted golf is interesting. Banning all language-restriction challenges bans these. \$\endgroup\$
    – Conor O'Brien
    Commented Mar 24, 2016 at 19:36
  • 2
    \$\begingroup\$ @CᴏɴᴏʀO'Bʀɪᴇɴ Since GoL restricted challenges wouldn't be scored on bytes, they wouldn't be code-golf and wouldn't be affected by this meta-discussion. Such challenges are safe... \$\endgroup\$
    – trichoplax is on Codidact now
    Commented Mar 24, 2016 at 19:54
  • \$\begingroup\$ @trichoplax \o/ thanks! \$\endgroup\$
    – Conor O'Brien
    Commented Mar 24, 2016 at 19:55
  • 6
    \$\begingroup\$ I don't have time to write a full answer, but it's important to consider not just the idea of the community overriding language restrictions; this issue is really a far more general one. I/O format, unjustified rule changes, other arbitrary prohibitions—this question is just a special case about to what extent the community should be able to override the OP in general. \$\endgroup\$
    – Doorknob Mod
    Commented Mar 24, 2016 at 20:54
  • 2
    \$\begingroup\$ To elaborate, the question of whether a restriction—any restriction at all—is arbitrary or justified ("JS only" vs. regex golf) is inherently subjective. What we need to decide as a community is how to determine what is going too far ("I/O in format A, B or C" is okay, "must read from a file" is not unless there's a good reason) and how to consistently enforce whatever policy we decide on. \$\endgroup\$
    – Doorknob Mod
    Commented Mar 24, 2016 at 21:02
  • \$\begingroup\$ Related, possible duplicate \$\endgroup\$
    – user45941
    Commented Mar 25, 2016 at 16:52
  • 2
    \$\begingroup\$ @Mego Related yes, but not a duplicate. \$\endgroup\$
    – Alex A. Mod
    Commented Mar 25, 2016 at 17:31

3 Answers 3

Reset to default
20
\$\begingroup\$

No (with caveats) -- Language-specific challenges are on-topic

Challenge authors are allowed to add other arbitrary restrictions (banning built-ins, banning capital letters, requiring out to be base-10 integers, etc.), and so requiring all answers to be in one language should be treated no different; it's just another method of restricting answers.

That said ...

  • The challenge should explicitly require some feature of that language to make sense. Arbitrarily restricting a challenge to a particular language should be downvoted/off-topic'd appropriately. An example would be the various regex-golf challenges, which require the answer(s) to be regex for the challenge to make sense, or the Official Dyalog APL 2016 Year Game
  • If a challenge author desires a particular language answer, but is open to allowing all languages to compete, they should consider making the challenge all-inclusive with a bounty for an answer in that particular language. This should be the default.
\$\endgroup\$
5
  • 2
    \$\begingroup\$ Would you feel differently if regex golf challenges were separated into their own tag, say [regex-golf], that was distinct from code golf and exempt from this rule? \$\endgroup\$
    – Alex A. Mod
    Commented Mar 24, 2016 at 20:28
  • 1
    \$\begingroup\$ @AlexA. That would solve one example, but things like the linked Dyalog APL challenge would thus still fall under this rule. Obviously we wouldn't want to have [dyalog-apl-golf] and [javascript-golf] and ... \$\endgroup\$
    – AdmBorkBork
    Commented Mar 24, 2016 at 20:43
  • 1
    \$\begingroup\$ The linked Dyalog challenge has answers in a lot of languages, not just APL. \$\endgroup\$
    – Alex A. Mod
    Commented Mar 24, 2016 at 20:44
  • 3
    \$\begingroup\$ @AlexA. Yes, the Dyalog APL challenge has a lot of non-APL answers. That's fine. Authors should be allowed to say "I'm only going to accept answers in XYZ language" without worry about repercussions. The author is still restricting the challenge where only APL answers are considered contending. \$\endgroup\$
    – AdmBorkBork
    Commented Mar 24, 2016 at 20:47
  • 1
    \$\begingroup\$ Agreed, bookmarklet golf challenges could only be done in JavaScript \$\endgroup\$
    – Konijn
    Commented Oct 6, 2016 at 16:18
17
\$\begingroup\$

Only allow challenges to restrict languages indirectly via requirements

The one good reason for a challenge to restrict languages is that the spec makes sense only for languages with certain features or properties. So, let specs have requirements that not all languages meet, but don't allow them to whitelist or blacklist languages by name.

For example, if a challenge relies on variables having declared types and there's no way to get around that, it's OK to require this so that only languages with declared types can participate. It's not OK to make the challenge Java only for this reason.

There's two advantages I see over simply allowing language restrictions:

  • Posters can't limit languages without reason. The limitation automatically requires some element of the spec that only certain languages satisfy.
  • The restriction is as loose as possible. All languages that fit the requirements can participate, even ones the asker was not aware of.

It's OK if the limitations are so restrictive that only one language qualifies, and if the asker says what language they're aiming for. This rule is not meant to prevent a challenge from being language-specific if necessary, but to ensure that the restriction necessarily follows from the spec.

\$\endgroup\$
5
  • 2
    \$\begingroup\$ I'm not sure whether you meant to include that or not, but one type of challenge that makes sense in any language but is better held per-language is busy-beaver challenges. Busy beavers (and sometimes even their definition) depends a lot on the underlying computational model, and I don't think it makes a lot of sense to mix Brainfuck BBs with Befunge BBs in a single challenge. \$\endgroup\$
    – Martin Ender Mod
    Commented Mar 27, 2016 at 11:35
  • \$\begingroup\$ @MartinBüttner I didn't realize these existed. I'm don't see though why these should be separated per language. How is the dependence on the computational model and the language mixing different from code golf? \$\endgroup\$
    – xnor
    Commented Mar 27, 2016 at 23:23
  • 1
    \$\begingroup\$ because especially esoteric programming languages will admit their own definitions of busy beavers in terms of ticks instead of output. Also scoring will likely be by the busiest beaver for some fixed size and calibrating that fixed size across multiple languages will be impossible. \$\endgroup\$
    – Martin Ender Mod
    Commented Mar 28, 2016 at 5:51
  • \$\begingroup\$ Say I wanted to make a challenge based around Javascript closures. Other languages have closures, but defining what counts as a closure can be hard to do. Is that cause to allow only Javascript? \$\endgroup\$
    – Nathan Merrill
    Commented Mar 28, 2016 at 16:22
  • \$\begingroup\$ What about this challenge? Where would it fall according to what you've written? Or should "puzzles" be viewed in an entirely different light than "challenges" \$\endgroup\$
    – Liam
    Commented Mar 31, 2016 at 0:48
-7
\$\begingroup\$

Yes, language-specific challenges should be disallowed.

There is no good reason to make challenges language specific.

If you want longer languages to have an advantage, then reconsider your policies.

If the challenge can only be done in a certain language then it either:

  1. May not be a good challenge idea.
  2. Leave it open for other languages, if they can find a way, that's great.

Non-code golf challenges don't follow these rules.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Also, it is hard to have much of a competition when you have only one language to compete in. There probably won't be too many different approaches. \$\endgroup\$
    – Riker
    Commented Mar 24, 2016 at 19:43
  • \$\begingroup\$ This stance would also seem to ban regex golf. I think the problem is that people restrict questions because they want to see an answer in a language, not when it makes sense. I think regex golf makes sense, this challenge wouldn't really work with other languages. \$\endgroup\$
    – FryAmTheEggman
    Commented Mar 24, 2016 at 19:50
  • 3
    \$\begingroup\$ @FryAmTheEggman Hm, I think I'd actually support separating regex golf into its own tag since (at least IMO) it's pretty distinct from other code golf challenges. If that were the case, regex golf challenges would be unaffected by this rule. \$\endgroup\$
    – Alex A. Mod
    Commented Mar 24, 2016 at 19:55
  • \$\begingroup\$ @AlexA. While that would be fine, I don't see why Regex golf would be that different from, say, challenges where we effectively ban classes of languages that would either trivialise a task or not be usable. If challenges can ban some languages, why not all but one? I'd say it almost never makes sense, but I don't think preventing it all the time is necessary because of that. \$\endgroup\$
    – FryAmTheEggman
    Commented Mar 24, 2016 at 20:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .