3
\$\begingroup\$

Ever since PPCG was created, answers using builtins have been an issue for challenge writers. Sometimes, an interesting challenge can be posted, only for some languages (not necessarily golfing languages) to have a builtin function that does all the work. Some people don't mind these answers, others seek to ban them. My views can be summed up by this comment.

Now, banning builtins outright isn't what we should do. Lynn puts it much more elegantly in that post, but quite often, answers without builtins get more upvotes then answers with builtins. Upvotes shouldn't matter to the more active users, but they do have a negative effect on voting: more votes equals more visibility.

However, builtin solutions aren't good answers. A good answer contributes something new, something interesting to the site. And 10 answers consisting of the same function do not do this. One suggestion is to combine equally trivial answers, but that hasn't always worked out, or been implemented. Basically we have to face it: builtin answers will be posted.

Yet, there may be a solution that satisfies both sides of the argument: forcing non-builtin answers to be posted with builtin answers. I'd be much more inclined to upvote a Mathematica answer that actually implemented goat recognition, rather than relying on a builtin function.

Therefore, I am suggesting allowing a rule in challenges where, if the challenge is fairly trivial, the challenge poster can force answers to post both the builtin and the non-trivial code in their answer. This meta post is here to ensure that the challenger can enforce this rule, if implemented.

What do you think?

\$\endgroup\$
2
  • 3
    \$\begingroup\$ I think the Mathematica case is a particularly interesting one, that's hardly "Trivial", despite it being easy for the answer author. \$\endgroup\$
    – ATaco
    Dec 18, 2017 at 0:52
  • 4
    \$\begingroup\$ Isn't this basically the same thing as Lynn's answer? You're banning builtin answers without non-builtin ones, which is pretty much the same thing. \$\endgroup\$
    – Riker
    Dec 18, 2017 at 1:45

1 Answer 1

8
\$\begingroup\$

I don't think we can or should do this

The first reason I believe this is because we will never be able to force anyone to write a good answer. By implementing these types of rules we are optimizing for sand, not pearls. There can be really quality answers that are just a built in.

For example if we had a problem that could be solved by a single builtin, but that builtin was designed to solve a different task altogether, that would a good observation by the golfer, and thus a good answer in my opinion.

And as you say

A good answer contributes something new, something interesting to the site.

I think this definitely falls under that definition.

We should not put extra obstacles in the way of producing answers.


My second point is that the term "builtin" is really vague. I've pointed it out here but using the phrase builtins instantly introduces a ton of ambiguity to the question. Even if we could come up with a concrete definition of builtins, it would likely let some answers we might all agree are builtins through the cracks and it mark some perfectly good answers as builtins. Terms as vague as builtins should not be allowed in challenges without definition.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ For example if we had a problem that could be solved by a single builtin, but that builtin was designed to solve a different task altogether, that would a good observation by the golfer, and thus a good answer in my opinion. This answer comes to mind. \$\endgroup\$
    – DJMcMayhem
    Dec 18, 2017 at 16:54

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