When are flags fair play and when are they not?

Conversation started Sep 22, 2021 at 21:46.

Redwolf Programs

Sep 22, 2021 21:46

I'd consider the output of Vyxal j to be an array, not a string joined by newlines. If you're outputting as an array, and just using j for nicer formatting, I'm 100% fine with it (but you should probably move it out of the header). But if the question specifically wants a string with newlines, I would consider j to be cheating.

Same with all of the other I/O flags

dzaima

+1. imo flags are cheating when they explicitly solve a part of the challenge

hyper-neutrino

my opinion on vyxal j is just the same as jelly ÇY lol

DLosc

@RedwolfPrograms I think I come at it more from a language-design perspective. Some languages use 0-based indexing; other languages use 1-based. When you're designing a language, you have to pick one. But you could have picked the other. To me, those two possible choices lead to two different languages, just like a different set of builtins makes for different languages.

Wheat Wizard

What do you think about e.g. Klein flags?

caird coinheringaahing

@AaronMiller jLrSOoKWṡSJ are grey areas for me, vcfaṠR5BbT are fine, not sure about D, the rest are cheating

Wheat Wizard

Sep 22, 2021 21:49

Klein is kind of just 12 related programming languages bundled together. So Klein flags end up making a huge difference for how a program behaves.

A lot of times they can also make for a huge difference in golfing.

Redwolf Programs

@DLosc Different indexing is one of the more gray area flags maybe, but I think it takes all of the fun out of golfing language design when instead of having to make hard decisions you give the user both options at no byte count cost

caird coinheringaahing

I think Klein flags are fine because it's the most sensible way to do something so central to the idea of the language

Redwolf Programs

If a program written with one of the flags isn't just a trivial variation of any of the other flags, I'd say it's 100% fine

caird coinheringaahing

You can never relegate a step of the program with Klein's flags, only change how to approach that program

hyper-neutrino

klein flags are totally fine IMO cuz the language functionality depends on a specific config but the core is still going to be the same, so the flags don't really "alter" the behavior, more so define (or rather select) what the behavior will be

Redwolf Programs

Sep 22, 2021 21:52

I think the author's intent when making the flags also plays a role, but that's about as subjective as you can get :p

caird coinheringaahing

Mostly disagree, as other people use your langs in ways you could never have predicted

DLosc

@RedwolfPrograms And that's a fair point. I designed Pip back when a flag cost a byte. Putting behavior in a flag should cost something, IMO. But a) that's not the consensus anymore, and b) even back then you had slightly different versions of the same language being used (e.g. 05AB1E vs 2sable).

caird coinheringaahing

I've always considered the flag cost debate to be like the famous quote about democracy: "Flags being free is the worst way to count flags, aside from every other way we've tried"

Wheat Wizard

My opinion is that mostly I can just sort of feel flag abuse. Like there's edge cases, but mostly I feel it.

caird coinheringaahing

hyper-neutrino

Sep 22, 2021 21:54

@AaronMiller vcfarOoKṠDV5bBT are fine / probably fine, jLMmṀSWṡJ are grey area, and HsdClGgRṪ are cheating

basically, flags that alter I/O encoding etc are fine, and that are like for debug / alter interpreter timeout. flags that format the I/O are grey area because they are good for formatting but if the format is important it falls into the third category, which is just flags that take pre/post-computing out of the program

caird coinheringaahing

@WheatWizard I kind of like those answers, because I can downvote, and when someone inevitably complains about the downvote, I can point to "flag abuse IMO"

Redwolf Programs

I kind of like my three black boxes model, I might refine it a bit and update my flag manifesto

hyper-neutrino

like the l flag is literally just taking 1 byte, the length command, and moving it from the code into the flags, which is just "-1 bytes cuz i said so"

however, i agree with caird here that it's still best to just count all these flags as free because we've had more issues with other ways

Redwolf Programs

Even counting them as one byte each gives a slight, slight advantage to flag usage, and also makes it more "legal"

hyper-neutrino

an interesting idea: if 1 flag = 1 byte then it'd be interesting to try to create a language where the same characters mean different things in the two halves so you can sort of shove 512 built-ins into your codepage

caird coinheringaahing

Sep 22, 2021 21:57

What'll happen first, a utopic political theory will emerge, or we'll find a perfect way to count flags? :P

hyper-neutrino

probably the former tbh

Redwolf Programs

With flags costing one byte each, you basically get 257 operators, one of which you can only use once

caird coinheringaahing

What if you had a meta flag to indicate which commands the flag becomes active on and which it isn't?

...I should giving lyxal ideas :P

hyper-neutrino

also how were flags scored in the past again

by bytes in your codepage?

dzaima

non-ascii flags just weren't a consideration i think

hyper-neutrino

Sep 22, 2021 22:00

Redwolf Programs

@RedwolfPrograms Additionally, having the capability to use flags but not doing so encodes a slight amount of information, so you'd still have an advantage if your languages uses flags even if you use weird math stuff in the scoring to compensate for this

hyper-neutrino

and this is probably why we gave up scoring them

DLosc

Hmm... if Pip's list-formatting flags were considered cheating for e.g. ASCII art challenges, I think I could add a way to set the behavior in the program itself for 1 byte each...

caird coinheringaahing

Just make each flag double the bytes score, ez :P

This seems totally fair and balanced, says the golfer who doesn't ever use flags :P

dzaima

@hyper-neutrino which I think is equivalent to my opinion that flags shouldn't be explicitly solving parts of the challenge

user

Sep 22, 2021 22:07

Oh dear, y'all are back to the flag debate

hyper-neutrino

@dzaima basically

Redwolf Programs

@user More of a discussion

dzaima

@cairdcoinheringaahing new language, 0 * 2^36 = 0 bytes

user

@RedwolfPrograms Has anything new been brought up this time? Because TNB's talked about it lots of times before, and each time it's pretty much the same points

Redwolf Programs

Yes

I came up with my three black boxes model

And we've discussed specific flags

Rather than arguing about hypothetical stuff

But I think we're all mostly in agreement here

user

Sep 22, 2021 22:09

Oh good

DLosc

(inb4 pro-flag people show up)

user

@RedwolfPrograms C'mon, give us some context

Redwolf Programs

No :p

user

@DLosc Might be too late for that, I'm pro-flags-that-don't-do-actual-computing-stuff

Redwolf Programs

I think everyone here is, depending on how you define "actual-computing-stuff"

DLosc

Sep 22, 2021 22:11

Redwolf Programs

Pip's flags are great when you're trying to debug a long program, but using them to save bytes would be pretty generally agreed to be cheating from what people here have said so far

user

@RedwolfPrograms Flags that literally have a one- or two-byte builtin to do the exact same thing

Redwolf Programs

And that seems to be the most common opinion, just with slightly different opinions on how much counts as I/O and how much is actually saving bytes

Conversation ended Sep 22, 2021 at 22:12.

all rooms

Sep '2122

The Nineteenth Byte

The Nineteenth Byte: General discussion for codegolf.stackexc...

context of the conversation
join this room
about this room

Participants

Redwolf Programs 29%
hyper-neutrino 20%
caird coinheringaahing 18%
user 10%
DLosc 7%
dzaima 6%
Wheat Wizard 6%

all times are UTC