Discussion between Mego and Peter Taylor

5:18 PM

@Mego I'd argue that "built-in" cannot be well defined. e.g. your Gamma challenge forbade built in gamma functions. Suppose in my language the gamma function really just calls two other functions, negativeGamma and nonNegativeGamma. Do those count as built-ins I can't use?

What if nonNegativeGamma is in turn implemented as calls to intGamma (basically factorial, which you allowed) and floatGamma. Do those count as built-ins I can't use?

What if floatGamma is implemented as 10 different functions depending on the first decimal digit (a contrived example but still). Do those count as built-ins I can't use?

Anonymous

9:26 PM

@Calvin'sHobbies That's needless pedantry. Forbidding the use of builtins is a well-understood concept. It means you cannot use anything provided by the language or a library (whether it be the standard library or a 3rd-party library) that does the lion's share of the work.

Calvin's Hobbies

9:44 PM

@Mego But in my example all the intermediate functions are built ins as well. Where do you draw the line?

It's easier to forbid languages

Anonymous

> It means you cannot use anything provided by the language or a library (whether it be the standard library or a 3rd-party library) that does the lion's share of the work.

Anonymous

Line drawn.

Anonymous

@Calvin'sHobbies Easy != best

Calvin's Hobbies

How is "lions share" defined?

Anonymous

@Calvin'sHobbies With common sense

Calvin's Hobbies

9:50 PM

But that's not objective. (And as annoying as it can be, people dislike that around here.)

Anonymous

If all you have to do is do I/O operations and possibly some basic arithmetic/string manipulation, then you're not doing the lion's share of the work

Anonymous

If using the builtin drastically reduces the size of your code, it's doing the lion's share

Calvin's Hobbies

Still not objective. Don't get me wrong, I understand that saying "no-built ins" requires some common sense. But saying "no language X" is a less ambiguous rule, and there's no reason to forbid such a rule from challenges. (You can always downvote the challenge if you have a problem with the rules.)

El'endia Starman

@Calvin'sHobbies I would still consider the gamma function to be a built-in. And negativeGamma and nonNegativeGamma as well. Probably intGamma too, and floatGamma. And the 10 functions that make up floatGamma.

I think a reasonably good definition of "built-in" would be anything that encapsulates multiple operations like addition, subtraction, memory management, etc.

Anonymous

Making a purely-objective definition would almost surely produce false positives and false negatives. "no built-ins" isn't ambiguous if you apply common sense to it. I would like to believe that every user on this site has at least enough common sense to be able to correctly judge what constitutes a built-in. If there is confusion, that's what the comments on the question are for - they can ask for clarification if needed.

El'endia Starman

10:02 PM

So + is not a built-in. (Though you could consider it as one because of what it takes to actually carry it out with the CPU.)

Anonymous

The obsessive pedantry is ridiculous - we could spend weeks arguing over the precise definition of a "library".

Calvin's Hobbies

That's my point. There is no objective definition for these things. Hence less ambiguous rules are better.

Anonymous

Or we could just use common sense.

El'endia Starman

...I'm more on Calvin's side than Mego's.

It'd be good to have a definition for "built-in" that's better than "common sense".

Because really, common sense ain't all that common.

Anonymous

22 mins ago, by Mego

> It means you cannot use anything provided by the language or a library (whether it be the standard library or a 3rd-party library) that does the lion's share of the work.

El'endia Starman

10:09 PM

But what's "lion's share"?

More than half?

Anonymous

Define half, please

Anonymous

Half of the code? Half of the operations?

Anonymous

Half of the complexity?

El'endia Starman

You're the one saying "lion's share".

Calvin's Hobbies

^

Anonymous

10:12 PM

Fine, let's go down this etymological rabbit hole

Anonymous

Lion's share

The lion's share is an idiomatic expression which refers to the larger part - or most - of something. The phrase derives from the plot of a number of fables ascribed to Aesop and is now used as their generic title, although they exist in several different versions. Other fables featuring the same basic situation of an animal dividing up a prey in such a way that it gains the greater part, or even all, exist in the East. == AesopEdit == The early Latin version of Phaedrus begins with the reflection that "Partnership with the mighty is never trustworthy". It then relates how a cow, a goat and a...

El'endia Starman

> The lion's share is an idiomatic expression which refers to the larger part - or most - of something.

Absolutely.

Calvin's Hobbies

@El'endiaStarman I'm with Mego that eventually, some amount of common sense is required for defining built-ins. But I'm against the idea that was the original debate here that saying "no built ins" is just as strong/effective as saying "no language X".

El'endia Starman

But...

4 mins ago, by Mego

Half of the code? Half of the operations?

@Calvin'sHobbies I'm not denying that common sense has to get involved at some point. After all, is + in Minkolang a built-in? Yes...but not really?

VoteToClose

^ This is my argument waaaay back.

Anonymous

10:16 PM

Lion's share = majority. For this usage, majority of the work. If the language, its standard library, or a third-party library provides a function, command, operator, expression, or whatever that cuts your code length (in bytes) by more than half, it's doing the lion's share of the work. The exception are those functions, commands, operators, expressions, or whatevers that are required for your language to meet our requirements for being a programming language.

El'endia Starman

Now that's a definition I can support.

Anonymous

@Calvin'sHobbies Take for example the sandboxed challenge linked in the meta post. It forbade the use of Retina. If just the use of regex built-ins were forbidden, then theoretically (disclaimer: I know nothing about Retina), Retina could still compete if it had the ability to solve the challenge without the use of regex built-ins.

El'endia Starman

Considering that Retina is nothing but a regex engine, then Retina is implicitly disallowed in such a case.

Retina on GitHub.

Anonymous

Ok, let's take a similar case. Let's say the challenge banned sed. It has a robust regex engine, and would trivialize the challenge. However, it could still compete with only regex built-ins disallowed, because it is TC without the regex engine.

El'endia Starman

> Retina is a regex-based programming language. It's main feature is taking some text via standard input and repeatedly applying regex operations to it (e.g. matching, splitting, and most of all replacing).

@Mego I like the idea of focusing on Turing completeness. Retina would, I think, not be Turing complete without regexes.

Anonymous

10:23 PM

@El'endiaStarman Or, rather than TC, we focus on our requirements for being a valid programming language (primality test, adding two integers, and either decision or tranformational model)

El'endia Starman

Yeah, that'd work too.

Anonymous

Disallowing built-ins rather than individual languages has many benefits. It doesn't require an enumeration of forbidden languages. It allows languages to potentially still compete, if it is possible for them to without the built-ins. And, it covers edge cases in other languages.

Calvin's Hobbies

@Mego Alright. But in the end the rules on built-ins/languages should be up to the challenge maker. People can downvote/comment if they don't like it.

Anonymous

I still maintain the original point I made in my post: challenges that forbid languages for no good reason (not because the language has functionality that trivializes the task) are against the spirit of the site, and should be closed as off-topic.

Anonymous

Forbid or penalize, for that matter

Transcript for

Discussion between Mego and Peter Taylor