-3
\$\begingroup\$

Recently in this question, I had a discussion with ████████████████ whether I should get rid of built-ins.

I'm VTCing this since the built-in ban is particulary subjective here. I'd recommend just getting rid of it, and maybe encouraging not using built-ins.

Apparently, the question got closed, however when I added this, it was reopened:

EDIT: When I said "No built-ins", I meant that built-ins that automatically calculate the weekday for a particular date were discouraged, not prohibited. If the built-in aids in finding the weekday, no problem, but if it directly calculates the weekday then I discourage it

After that, this is what ████████████████ posted (second part is irrelevant here):

@py3programmer "so shortest answer (that doesn't use built-ins) wins" is a clear statement that built-ins invalidate answers. Also, for the built-in answers won't be accepted part...

So the point of this is that should I explicitly allow built-ins or disallow them?

As it stands, I'm all for built-ins but I'm not accepting any of them as they normally take lesser bytes than a non-built-in answer. What I fear is that answers like the 05AB1E one will not have a chance as they cannot compete with built-in answers (since doing formulas takes more bytes).

This is the midline: allowing all languages to compete fairly.

But, as I see it, ████████████████ wants it another one of these ways:

  • Invalidate built-ins that calculate weekdays automatically completely
  • Freely allow built-ins and give them a chance to be accepted too

Well I find two problems in these approaches, one for each:

  • Already 24 answers are posted, majority using built-ins. I don't want to invalidate those majority using a single approach; it could cause outrage
  • Same as above; built-in answers take lesser bytes (normally) and so will find it much easier to get accepted. Answers lacking built-ins will find it really hard to get accepted, and the competition will be unfair.

These are obviously not the only possible approaches; you can post your own.

The answer that has good reasons and can be tried without risk and which comes within 7 days will be accepted. Accepted answers will be tried upon.

What should I do?

Note: apparently this is my first meta question, if there are any suggestions write to me in the comments!

\$\endgroup\$
1
  • 4
    \$\begingroup\$ As an aside: in future discussions, I'd avoid specifically naming one user as the "opposition" in this discussion. It places an unfair spotlight on that user and their opinions in a forum where they have less opportunity to defend themselves \$\endgroup\$ Oct 9, 2022 at 1:15

2 Answers 2

9
\$\begingroup\$

Disclaimer: I am relatively new to Code Golf, so I definitely cannot speak for the community.

Generally forbidding any built-ins is bad practice. For one, it's not clear what built-in functions are actually disallowed, since how much of the work a built in does before it's disqualifying is subjective. From Adám (in the comments to your post):

What exactly do you mean by "built-ins"? Does it only cover things to solve the entire problem, like Mathematica's DayName or does it include any type of date-handling capability? Isn't + a built-in?

How about a built-in that computes a date serial number (number of days since an epoch)? Such a number has the inherent property which is its remainder when divided by seven, and that's the weekday. Forbidden or not? Also, you allow built-in date objects, but they might well have an accessible day-of-week property. Forbidden or not?

It seems your primary concern is that some languages without built-ins that can solve most of the problem will be left behind, but that's true for every code golf challenge. Some languages are always going to fare worse than others; BrainFuck answers are basically never shorter than Vyxal answers, but that doesn't mean that we should ban most of the functions in Vyxal because BrainFuck doesn't have them.

But I think the primary issue here is a lack of clarity: you seem to be saying that you want people to post all answers, including those that use built-ins, but that you weren't going to accept (give a check mark to) any answers that you deemed as too reliant on built-ins. And that's fine -- honestly, it doesn't really matter what answer you accept; I don't think people really care. However, people interpreted that statement as meaning that you didn't want anyone to answer with "built-ins", whatever those are.

\$\endgroup\$
8
\$\begingroup\$

I'm just gonna briefly challenge the entire premise of the question: regardless of what the answer is, you shouldn't accept any answer, builtin or not.

I'll set aside the builtin ban question for the moment, and just address the implicit implication in the question: stop accepting answers to challenges. At best, the fair thing to do is to constantly update the accepted answer as new answers are posted; at worst, you accept some arbitrary answer due to arbitrary disqualifications such as "it uses a builtin". Additionally, accepting an answer is contrary to our policy that languages compete within themselves in . Accepting answers is, all around, a bad idea.


But, returning to the builtin ban question: stop talking about builtins. Given the sheer variety of languages out there (600+ on TIO, which has been out of date for 3 years now), there's almost always going to be some language with some obscure, convoluted builtin that "trivialises" a challenge. And so what? If AmazingGolfLang can do your challenge in a single character, good for the language. No one else really cares - the intent behind golfing is to demonstrate clever tricks and coding in specific languages. We're all here to watch other people do these clever programming tricks, and to do them ourselves from time to time. Builtins are the exact opposite of this. They are trivial and boring, but they do the challenge as specified, so they should be allowed. But, we shouldn't care.

We already have an ability to reward clever solutions and "punish" boring ones1: voting. People upvote clever but longer answers (after all, Arnauld, who almost exclusively golfs in Javascript, is the third highest rep earner on the site), and will ignore trivial, single builtin answers. The system works as intended.

Builtin-only answers are a problem that challenge authors create for themselves. Most of the time, it's unlikely to even arise, and when it does, voters make it clear how the community feels about such answers: bored apathy. Banning them in your challenge only serves to make your challenge unclear, and open for debate and closure. Don't worry about them.


1: I say "punish", but I feel this is inappropriately harsh. There is nothing inherently wrong with boring, builtin only answers. They shouldn't be downvoted, flagged or deleted. But, people who upvote interesting and clever answers will generally withhold their upvotes, and "punish", these trivial builtin answers.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ For the actual problem behind banning builtins, I do recommend 97's answer, as it sets out the general arguments as to why banning builtins is a bad idea. This answer is meant as a more abstract approach to the problem, in that it doesn't address the specific reasons as to why banning builtins in problematic, but attempts to indicate that such course of action is inherently unnecessary, and why. \$\endgroup\$ Oct 9, 2022 at 1:33

You must log in to answer this question.

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