Nous avons un défi pour produire votre propre score , mais il semble que toutes les réponses y codent simplement la sortie et c'est ennuyeux ¹ . Permet donc d'avoir un nouveau défi. Votre programme doit sortie sa propre longueur en octets suivi par la chaîne " bytes", mais afin d'éviter des solutions si nous réduisons codées en dur sa taille en supprimant tout nombre d' un octet, le nouveau programme doit également produire son nouveau octet, toujours suivi par " bytes". La sortie n'a pas besoin d'être sensible à la casse. Vous pouvez également choisir de sortir une nouvelle ligne de fin.

Vos réponses seront notées en octets avec moins d'octets mieux.

^{1: En fait, j'aime certaines des réponses.}

Revers , 40 36 29 octets

vv""sseettyybb  ""jjHHOO]

Essayez-le en ligne! Vérification!

En cas de doute, doublez tout. Cela utilise la capacité de Backhand à déplacer plus d'une étape à la fois pour implémenter la redondance. Les non imprimables ont tous la valeur d'octet 28.

Explication:

Programme non irradié:

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

Programme irradié:

Si un caractère est supprimé, chaque caractère après cela est rétrogradé.

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

Cependant, au lieu de sauter vers le ], il réfléchit plutôt à la fin du programme et atterrit à la Oplace.

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

Enchantements runiques , 47 octets

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

Essayez-le en ligne!

Ce qui est plus ou moins un port de ma réponse Geiger Counter , mais avec une sortie différente (qui est, elle-même, un port d'une réponse Klein).

>>yyLLest requis pour que Runic génère (au moins) une IP, fusionne deux IPS et réfléchisse vers la gauche, de sorte que toutes les variations entraînent une seule IP se déplaçant vers la gauche. Peut être remplacé par yy<<mais il n'enregistre aucun octet.

Les réflecteurs à droite forcent l'IP à la chaîne inférieure gauche, donc la suppression de l'un d'eux en haut à droite permet à l'IP de pénétrer dans la chaîne supérieure droite. La suppression d'un octet n'importe où ailleurs le long de la ligne supérieure ajuste le réflecteur supérieur pour qu'il se trouve au-dessus du L (permettant au programme en bas à droite). La suppression d'un octet en bas ajuste ce réflecteur (ou le supprime) de sorte que le dernier caractère soit implicitement rempli d'un espace, ce qui permet à l'IP de rebondir des deux côtés du réflecteur supérieur droit et dans la chaîne supérieure droite.

Les espaces excédentaires sont cependant décevants. Mais toutes les tentatives pour les réduire ont abouti à des programmes plus importants, des programmes de même taille ou des programmes qui ne sont pas à 100% résistants aux radiations. Les réponses Klein et> <> ici utilisent des fonctionnalités non disponibles dans Runic.

> <> , 43 39 octets

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

Essayez-le en ligne! Vérification!

Dans le programme non irradié, nous ajoutons 0au '(39), et dans le programme irradié nous sautons le 0 et nous y ajoutons -1à la place. Si quelque chose est supprimé de la rangée du haut, nous passons à la place à la place et nous sortons simplement 38 bytes.

Hexagonie , 71 octets

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

Essayez-le en ligne! Vérification!

J'ai passé beaucoup trop de temps à essayer de mettre cela dans un hexagone de taille 5, mais j'ai dû me contenter d'une taille inférieure à 6 à la place :(.

Étendu:

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

J'ai d'abord fait cela avec )une rangée plus bas, mais il s'avère que c'est exactement là où se situe le fossé entre les hexagones de taille 5 et de taille 6. Cela signifie que lorsqu'un octet est supprimé, la taille diminue et ruine les voies. Je suis sûr qu'une taille 5 est possible.

Klein 000, 41 octets

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

Essayez-le en ligne! Vérificateur de JoKing

Je pense que cette réponse est similaire à la réponse de JoKing> <> , mais je ne lis pas> <> donc je ne peux pas être sûr.

Il existe 4 types différents de suppression d'octets ici

1. Un octet est supprimé de la première ligne précédente /. Dans ce cas, la barre oblique est effectivement déplacée d'un espace vers la gauche, la déviant sur la ligne inférieure et empêchant l'exécution de la partie modifiée du code. Cela nous amène à exécuter le code ("40 bytes"@, qui sort 40 bytes.

2. Le premier /est supprimé de la première ligne. Dans ce cas, nous exécutons le code "0"+"4"$" bytes"@, qui est une méthode alambiquée ou d'impression 40 bytes.

3. La nouvelle ligne est supprimée. Cela nous fait commencer à partir de la fin de la deuxième ligne et le code résultant (sans noops supprimé) est 1("40 bytes"@, qui s'imprime simplement 40 bytes.

4. Un octet de la dernière ligne est supprimé. Cela provoque le déplacement 1vers la gauche de la fin de la première ligne et l'empêche d'être ajouté à la pile lorsque le pointeur est dévié par /. Le code "0"+pour cette raison pousse 0au lieu de 1, le reste du code le transforme 0en 40 bytes.

Klein 001, 41 octets

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

Essayez-le en ligne! Vérificateur de JoKing

Voici une réponse utilisant une topologie différente. C'est la même taille mais je pense qu'il y a place à amélioration.