Pourquoi tant de langues traitent-elles les nombres commençant par 0 comme octaux?

J'ai lu Où sont les octales utiles? et il semble que les octales soient quelque chose qui étaient autrefois utiles.

De nombreux langages traitent les nombres précédés d'un 0 comme octaux, donc le littéral 010est en fait 8. Quelques-uns d'entre eux sont JavaScript, Python (2.7) et Ruby.

Mais je ne vois pas vraiment pourquoi ces langues ont besoin d'octal, surtout lorsque l'utilisation la plus probable de la notation est de désigner un nombre décimal avec un 0 superflu.

JavaScript est un langage côté client, octal semble assez inutile. Tous les trois sont assez modernes dans un autre sens, et je ne pense pas qu'il y aurait beaucoup de code utilisant la notation octale qui serait rompu en supprimant cette "fonctionnalité".

Donc, mes questions sont:

• Est-il utile que ces langages prennent en charge les littéraux octaux?
• Si des littéraux octaux sont nécessaires, pourquoi ne pas utiliser quelque chose comme 0o10? Pourquoi copier une ancienne notation qui remplace un cas d'utilisation plus utile?

Copie aveugle de C, comme l'a dit un monstre à cliquet dans son commentaire

La grande majorité des "concepteurs de langage" de nos jours n'ont jamais rien vu d'autre que C et ses copies (C ++, Java, Javascript, PHP, et probablement quelques dizaines d'autres dont je n'ai jamais entendu parler). Ils n'ont jamais touché FORTRAN, COBOL, LISP, PASCAL, Oberon, FORTH, APL, BLISS, SNOBOL, pour n'en nommer que quelques-uns.

Il était une fois, l'exposition à plusieurs langages de programmation était OBLIGATOIRE dans le programme d'informatique, et cela n'incluait pas le comptage de C, C ++ et Java comme trois langages distincts.

Octal était utilisé dans les premiers jours car il facilitait la lecture des valeurs des instructions binaires. Le PDP-11, par exemple, BASICALLY avait un opcode 4 bits, 2 numéros de registre 3 bits et 2 champs de mécanisme d'accès 3 bits. Exprimer le mot en octal rendait tout évident.

En raison de l'association précoce de C avec le PDP-11, la notation octale a été incluse, car elle était très courante sur les PDP-11 à l'époque.

D'autres machines avaient des jeux d'instructions qui ne correspondaient pas bien à l'hex. Le CDC 6600 avait un mot de 60 bits, chaque mot contenant généralement 2 à 4 instructions. Chaque instruction était de 15 ou 30 bits.

Quant à la lecture et à l'écriture de valeurs, il s'agit d'un problème résolu, avec une bonne pratique bien connue de l'industrie, du moins dans l'industrie de la défense. Vous DOCUMENTER vos formats de fichiers. Il n'y a aucune ambiguïté lorsque le format est documenté, car le document VOUS INDIQUE si vous regardez un nombre décimal, un nombre hexadécimal ou un nombre octal.

Notez également: si votre système d'E / S par défaut est à 0, ce qui signifie octal, vous devez utiliser une autre convention sur votre sortie pour indiquer les valeurs hexadécimales. Ce n'est pas nécessairement une victoire.

À mon avis, Ada a fait mieux: 2 # 10010010 #, 8 # 222 #, 16 # 92 # et 146 représentent tous la même valeur. (Cela me donnera probablement au moins trois votes négatifs, juste pour mentionner Ada.)

Ils l'obtiennent de C. Pourquoi copier? Parce que l'implémentation de base des 3 est en C. L'implémentation par défaut de Python est CPython . Ruby a été construit en C ainsi. Javascript est le cas le plus intéressant ici. Il est exécuté dans le navigateur. Vous voulez deviner dans quoi le premier navigateur Web a été écrit?

Alors pourquoi ces trois langages seraient-ils implémentés en C? Parce qu'ils proviennent tous de systèmes UNIX. C'est donc un cas de convention dictée par l'écosystème. Perl le fait aussi. Lua le ferait probablement si Lua utilisait des entiers plutôt que des doubles .

Il est donc une question de l'environnement de ces langues étant écrit en C afin qu'ils prennent leurs conventions de C. Un bon corollaire est le soutien Visual Basic qui utilisations et O au lieu. En ce qui concerne le besoin, il semble être plus une convention transformée par abstraction qui fuit qu'autre chose.

La cohérence a une valeur. Si vous ne pouvez pas déterminer de manière fiable comment un nombre va être traduit, vous aurez de réels problèmes à utiliser une valeur dans différents contextes.

Cela signifie également que vous n'avez pas à écrire votre propre analyseur. Il est très utile d'utiliser des routines de bibliothèque bien testées.

De plus, si vous ne supportez pas la syntaxe 0 principale, vous n'avez pas un moyen simple d'écrire des valeurs octales.

Bien que nous ne dépendions pas autant des nombres octaux que par le passé, ils ont toujours de la valeur. Alors que les mêmes résultats peuvent être obtenus avec des nombres hexadécimaux, dans certains contextes, l'octal est plus facile à comprendre.

Jusqu'à présent, je n'ai vu qu'une seule utilisation pour les zéros de tête en nombres décimaux. C'est dans l'affichage et la saisie de champs décimaux de longueur fixe comme les numéros d'identification. Cela fait des années que je n'ai pas vu de tels champs avec un zéro en tête. Bien que cela réduise les valeurs disponibles de 10%, cela élimine le problème que les utilisateurs oublient souvent les zéros de tête lorsqu'ils les saisissent.