We have a consensus here on multi-part challenges, and that they should only be allowed if there is a strong interaction between parts.

Now there are challenges that ask for multiple tasks, but only ask for a single program. For example, this one asks to print the union, intersection, relative complement and cartesian product of the input.

This is different from the multi-part challenges as described in the first meta-post as those asked for one program per sub-challenge, whereas multi-task challenges ask for only one program.

My concern is that although those multi-task challenges require only one program, being competitive in them usually boils down to:

  • Implementing each task independently from the other tasks
  • Stitching all tasks into the same program, eventually grouping the output printing part, which is almost always a trivial operation.

What should we do with those challenges?

  • Make no assumption about the tasks asked, and that a language might be able to take advantage of the shared code to shorten the implementation of one task using another task. Therefore those challenges are allowed.

  • Apply the same principles that we have with multi-part challenges, in that we only allow challenges where the tasks are strongly related to one another.

Subsequent question (might need another meta-post)

This challenge was closed as a duplicate of this challenge.

The question is: can we close as duplicate on the basis that the challenge is a subset of something that must be done in another challenge? (For example, can we close a challenge asking to compute a*b as a duplicate of a challenge asking to compute the factorial with no built-in?).

  • If multi-task challenges are not allowed anymore unless strong relations exist between tasks, then the challenge should not be a dupe and instead the second one should be closed.

  • If we allow multi-task challenges, the question still holds (because the implementation we do for that subset task in the second challenge might not be optimal for the first if it's implemented with the other tasks in mind) and will require another meta-post.

  • 3
    \$\begingroup\$ I don't have time for a full answer right now, but I'd say that for a single program with multiple subtasks the threshold of when there is sufficient interaction between the tasks gets lower. These aren't necessarily interesting challenges (although they might be), but if it's possible to save bytes by reusing code between the parts, I think they're fine. As for the duplicate-ness, no I don't think they should act as dupe targets for the subtasks. If that is possible there's a good chance that the challenge in question does have too little code reuse. \$\endgroup\$ Commented Feb 16, 2017 at 10:08


You must log in to answer this question.

Browse other questions tagged .