Pourquoi les noms d'appels système UNIX / POSIX sont-ils si illisibles?

Quelle est la raison d'utiliser de tels noms d'appel système peu révélateurs comme timeet creatau lieu de getCurrentTimeSecset createFileou, peut-être plus appropriés sous Unix get_current_time_secset create_file. Ce qui m'amène au point suivant: pourquoi quelqu'un voudrait-il quelque chose comme cfsetospeedsans étui à chameaux ou au moins soulignés pour le rendre lisible? Bien sûr, les appels auraient plus de caractères, mais nous savons tous que la lisibilité du code est plus importante, non?

Cela est dû aux contraintes techniques du moment. Le standard POSIX a été créé dans les années 1980 et faisait référence à UNIX, né en 1970. Plusieurs compilateurs C d'alors étaient limités à des identifiants de 6 ou 8 caractères, ce qui a défini le standard de longueur et de fonction. noms.

Questions connexes:

• Pourquoi "umount" ne s'écrit-il pas "démonter"?
• Qu'est-ce que Ken Thompson voulait dire quand il a dit: "J'orthographierais creat avec un 'e'"?
• Quelle convention, le cas échéant, a été utilisée pour les commandes Unix standard?
• https://stackoverflow.com/questions/682719/what-does-the-9th-commandment-mean

dr01 a raison, mais il y a aussi une autre raison - la convivialité. À l'époque, vous n'aviez pas quelque chose d'aussi confortable qu'un clavier à saisir. Si vous aviez de la chance, vous aviez quelque chose qui ressemble à une machine à écrire de la vieille école. Si vous n’êtes pas chanceux, vous devez faire face à des systèmes nécessitant un travail physique réel (par exemple, il faut beaucoup de force pour appuyer sur la "touche"), ou des perforations manuelles dans une carte.

Cela signifiait que même dans la limite de 6 à 8 caractères, vous essayiez de garder vos commandes aussi courtes que possible. C'est pourquoi vous avez lsau lieu de list, et creatau lieu de create. Le code de cette époque est plein de variables comme a, xet i- et bien sûr, x2et d'amis. Taper était un travail fastidieux - de nos jours, vous êtes moins sollicité listIndexque ipar le passé "en tapant" - et ce n'est même plus si lent (en particulier avec des technologies supplémentaires comme la saisie automatique).

La vraie question est de savoir pourquoi autant d’idiomes Unix persistent même s’ils ne sont plus souhaitables.

En plus des autres réponses, je voudrais souligner qu'Unix a été développé en réaction à Multics, à CTSS et à d'autres systèmes d'exploitation contemporains, qui étaient beaucoup plus explicites sur leurs conventions de dénomination. Vous pouvez avoir une idée de ces systèmes d’exploitation à l’ adresse http://www.multicians.org/devdoc.html . Par exemple, http://www.multicians.org/mspm-bx-1-00.html donne change_namela commande permettant de renommer un fichier; comparez Unix mv.

De plus, la principale raison pour laquelle les noms d’appel système très courts persistent est la compatibilité avec les versions antérieures. Vous remarquerez que les nouvelles API ont tendance à être plus explicites. par exemple gettimeofdayet clock_gettimeau lieu de juste time.

(Même aujourd'hui, utiliser whateverIndexau lieu de ipour un index de boucle est un échec automatique de révision du code dans mon livre ;-)

Dennis Ritchie s'est fixé comme contrainte que C ne repose sur aucune fonctionnalité de l'éditeur de liens qui n'était pas également requise par Fortran. D'où la limite de 6 caractères pour les noms externes.