Temos um desafio para gerar sua própria pontuação , mas parece que todas as respostas lá codificam a saída e isso é chato ¹ . Então, vamos ter um novo desafio. Seu programa deve gerar seu próprio comprimento em bytes, seguido pela string " bytes", mas para evitar soluções codificadas permanentemente, se reduzirmos seu tamanho removendo qualquer byte, o novo programa também deve gerar sua nova contagem de bytes, ainda seguida por " bytes". A saída não precisa fazer distinção entre maiúsculas e minúsculas. Você também pode optar por gerar uma nova linha à direita.

Suas respostas serão pontuadas em bytes, com menos bytes sendo melhores.

^{1: Na verdade, eu gosto de algumas respostas lá.}

Backhand , 40 36 29 bytes

vv""sseettyybb  ""jjHHOO]

Experimente online! Verificação!

Na dúvida, dobre tudo. Isso usa a capacidade do Backhand de mover mais de uma etapa por vez para implementar a redundância. Todos os imprimíveis têm o valor de bytes 28.

Explicação:

Programa não irradiado:

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

Programa irradiado:

Se qualquer caractere for excluído, todos os caracteres serão alterados para baixo.

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

No entanto, em vez de pular para o ], ele reflete o final do programa e aterrissa no Olugar.

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

Encantos Rúnicos , 47 bytes

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

Experimente online!

O que é mais ou menos uma porta da minha resposta do contador Geiger , mas com saída diferente (que é, por si só, uma porta da resposta de Klein).

>>yyLLé necessário para o Runic gerar (pelo menos) um IP, mesclar dois IPS e refletir novamente para a esquerda, para que todas as variações resultem em um único IP que se move para a esquerda. Pode ser substituído por, yy<<mas não salva bytes.

Os refletores à direita forçam o IP à corda inferior esquerda, de modo que a remoção da parte superior direita permite que o IP entre na corda superior direita. A remoção de um byte em qualquer outro lugar na linha superior ajusta o refletor superior para ficar acima do L (permitindo que o programa fique no canto inferior direito). A remoção de um byte ao longo da parte inferior ajusta esse refletor (ou remove) para que o último caractere seja implicitamente preenchido com um espaço, o que permite ao IP ricochetear nos dois lados do refletor superior direito e na corda superior direita.

Os espaços em excesso são decepcionantes. Mas todas as tentativas de reduzi-las resultaram em programas maiores, programas do mesmo tamanho ou programas que não são 100% à prova de radiação. As respostas Klein e> <> aqui usam recursos não disponíveis no Runic.

> <> , 43 39 bytes

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

Experimente online! Verificação!

No programa não irradiado, adicionamos 0ao '(39), e no programa irradiado pulamos o 0 e adicionamos -1a ele. Se algo for removido da linha superior, passamos para a linha inferior e apenas produzimos 38 bytes.

Hexagonia , 71 bytes

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

Experimente online! Verificação!

Passei muito tempo tentando colocar isso em um hexágono tamanho 5, mas tive que me contentar com um tamanho 6 abaixo da média :(.

Expandido:

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

Inicialmente, fiz isso com a )linha uma mais baixa, mas acontece que é exatamente onde está a divisão entre o tamanho 5 e o tamanho 6 dos hexágonos. Isso significa que, quando um byte é removido, o tamanho muda e diminui os caminhos. Definitivamente, tenho certeza de que um tamanho 5 é possível.

Klein 000, 41 bytes

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

Experimente online! Verificador de JoKing

Eu acho que essa resposta é semelhante à resposta> <> de JoKing , mas eu não leio> <>, portanto, não tenho certeza.

Existem 4 tipos diferentes de remoção de bytes aqui

1. Um byte é removido da primeira linha antes /. Nesse caso, a barra é efetivamente movida para a esquerda, deixando um espaço, desviando-a para a linha inferior e impedindo a execução da parte modificada do código. Isso nos leva a executar o código ("40 bytes"@, que gera 40 bytes.

2. O primeiro /é removido da primeira linha. Nesse caso, executamos o código "0"+"4"$" bytes"@, que é uma forma ou impressão complicada 40 bytes.

3. A nova linha é removida. Isso nos faz começar do final da segunda linha e o código resultante (com os noops removidos) é 1("40 bytes"@, que apenas imprime 40 bytes.

4. Um byte da última linha é removido. Isso faz 1com que o final da primeira linha seja movido para a esquerda e evita que seja adicionado à pilha quando o apontado é desviado /. O código, "0"+por esse motivo, empurra em 0vez de 1, o resto do código transforma o código 0em 40 bytes.

Klein 001, 41 bytes

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

Experimente online! Verificador de JoKing

Aqui está uma resposta usando uma topologia diferente. É do mesmo tamanho, mas acho que há espaço para melhorias.