Self Scoring Program

Question

We have a challenge to output your own score, but it seems like all the answers there just hardcode the output and that's boring¹. So lets have a new challenge. Your program must output its own length in bytes followed by the string " bytes", but in order to prevent hardcoded solutions if we reduce its size by removing any one byte, the new program must also output it's new byte count, still followed by " bytes". Output does not need to be case sensitive. You may also choose to output a trailing newline.

Your answers will be scored in bytes with fewer bytes being better.

---

^{1: I actually like some of the answers there.}

• dylnan: Maybe you could change the name of the challenge to "self scoring modifiable program" or something similar.
• user36046: Can you use complied languages or only interpreted?
• Wheat Wizard: @Logern You can use either.
• Jo King: Argh. I spent half an hour making a Hexagony solution, but when I went to test it, removing the byte made the hexagon shrink! :(
• user202729: @WW What I mean is "1 bytes is technically wrong grammar, but assuming languages don't have a built-in to output the string "bytes" in <= 2 bytes, the program will be longer than 3 bytes, so it doesn't matter" -- it doesn't matter anyway.

Answer 1

Backhand, (削除) 40 36 (削除ここまで) 29 bytes

vv""sseettyybb ""jjHHOO]

Try it online! Verification!

When in doubt, double up on everything. This uses Backhand's ability to move more than one step at a time to implement the redundancy. The unprintables all have the byte value 28.

Explanation:

Non-irradiated program:

v Reduce step count to 2
 " Start string literal
 s e t y b Push the " bytes" part of the output
 " Push 28 twice and end the string literal
 j Jump to the 28th position (0 indexed) 
 ] Increment the 28 to 29
 O Print the 29
 H Halt and output the entire stack

Irradiated program:

If any character is deleted, every character after that is shifted down.

vv"sseettyybb
v " s e t y b The same instructions are still executed

However, instead of jumping to the ], it instead reflects off the end of the program and lands on the O instead.

 v 28th character (0 indexed)
vv""sseettyybb ""jjHHOO]
v""sseettyybb ""jjHHOO]OOHHjj"".....
 ^ 28th character, reflecting off the end of the code

Answer 2

Runic Enchantments, 47 bytes

>>yyLL @"setyb 64"/
"47 bytes"@"setyb 64"L\

Try it online!

Which is more or less a port of my Geiger Counter answer, but with different output (which is, itself, a port of a Klein answer).

>>yyLL is required for Runic to generate (at least) one IP, merge two IPS, and reflect back to the left, so that all variations result in a single left-moving IP. Could be replaced by yy<< but it doesn't save any bytes.

The reflectors on the right force the IP to the lower left string, so the removal of top right one of them allows the IP into the top right string. Removing a byte anywhere else along the top line adjusts the top reflector to sit above the L (allowing the program into the lower right). The removal of a byte along the bottom adjusts that reflector (or removes it) so that the last character gets implicitly filled with a space, which allows the IP to bounce off both sides of the top right reflector and into the top right string.

The excess spaces are disappointing, though. But all attempts to reduce them have resulted in either larger programs, same size programs, or programs that are not 100% radiation proof. Both the Klein and><> answers here use features not available in Runic.

Answer 3

><>, (削除) 43 (削除ここまで) 39 bytes

||vn-{"' bytes"-10/
 o>o<"38 bytes"[0/0

Try it online! Verification!

In the un-irradiated program, we add 0 to the ' (39), and in the irradiated program we skip the 0 and add -1 to it instead. If something is removed from the top row, we shift to the bottom row instead and just output 38 bytes.

Answer 4

Hexagony, 71 bytes

//.........||.>e;s;@..\;t;y;b<>}F"+!P0;/|/F!P0$@;<...t;ye;bs/.........)

Try it online! Verification!

I spent way too long trying to get this into a size 5 hexagon, but I had to settle for a subpar size 6 instead :(.

Expanded:

 / / . . . .
 . . . . . | |
 . > e ; s ; @ .
 . \ ; t ; y ; b <
 > } F " + ! P 0 ; /
 | / F ! P 0 $ @ ; < .
 . . t ; y e ; b s /
 . . . . . . . . .
 ) . . . . . . .
 . . . . . . .
 . . . . . .

I initially made this with the ) one row lower, but it turns out that's exactly where the divide between size 5 and size 6 hexagons are. This means when a byte is removed, the size all shifts down and ruins the pathways. I'm definitely sure that a size 5 is possible.

• Edgex42: If I'm understanding this correctly, can't you put the ) a row lower and then just put a no-op after it so it is a size 6 hexagon?
• Jo King: @EdgyNerd If you put a no-op after it than it can be removed without affecting the program

Answer 5

Klein 000, 41 bytes

<<@"setyb "$"4"+"0"/
..@"setyb 04"(....<1

Try it online! JoKing's Verifier

I think this answer is similar to JoKing's><> answer, but I don't read><> so I can't be sure.

There are 4 different types of byte removals here

1. A byte is removed from the first line before /. In this case the slash is effectively moved left one space, deflecting it onto the bottom line and preventing the modified part of the code from being executed. This causes us to run the code ("40 bytes"@, which outputs 40 bytes.

2. The first / is removed from the first line. In this case we run the code "0"+"4"$" bytes"@, which is a convoluted way or printing 40 bytes.

3. The newline is removed. This makes us start from the end of the second line and the resulting code (with noops removed) is 1("40 bytes"@, which just prints 40 bytes.

4. A byte from the last line is removed. This causes the 1 at the end of the first line to be moved left and prevents it from being added to the stack when the pointed is deflected by /. The code "0"+ for that reason pushes 0 instead of 1, the rest of the code turns the 0 into 40 bytes.

Klein 001, 41 bytes

\("40 bytes"@......1
..@"setyb "$"4"+"0"/

Try it online! JoKing's Verifier

Here's an answer using a different topology. It's the same size but I think there is room for improvement.

• Jo King: 37 bytes in 200