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

43

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?

Benjoyo
la source
42
Parce qu'ils ont été inventés des décennies avant que la notation hongroise, les étuis à chameaux, à étuis à serpents, etc., ne deviennent à la mode. De plus, à l'époque, les compilateurs disposaient de très peu de ressources et les noms d'identifiant étaient limités à 8 caractères (IIRC).
lcd047
3
@phresnel Vous ne savez pas quelle relation observez-vous entre les noms de fichiers et les identifiants de variables, mais oui, j'hésitais entre 8, 12 et 14. Peut-être que la limite était également de 14 pour les identifiants de variables. Ce n'était certainement pas 256+. Quant aux notations: veuillez définir "toujours". Arminius a- t-il utilisé des mots CamelCase? Peut être pas. AFAIR, la notation hongroise a été introduite pour Windows au début des années 1990. CamelCase et sneak_case sont des variantes ultérieures. Les deux étaient bien sûr utilisés avant cela. Ce que je dis, c'est qu'ils sont devenus populaires au milieu des années 90.
lcd047
6
@phresnel: Notez que votre lien parle des limitations du premier système de fichiers Unix . Lorsque Thompson, Richie et al. En concevant Unix, ils ont dû amorcer Unix sur des machines n’exécutant pas encore Unix , c’est-à-dire dans des environnements probablement encore plus restreints.
DevSolar
11
Vous pourriez aussi bien vous demander pourquoi ils ne sont pas écrits en allemand, car il s'agit de l'approximation en langage naturel la plus proche à laquelle je puisse penser pour les monstruosités trop longues que Java a appris aux programmeurs à accepter ...
R ..
12
Je suis tellement content que c'est comme ça. Imaginez comment un ls -la | grepressemblerait à ceci: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().
Pouya

Réponses:

61

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:

dr01
la source
5
Je ne pense pas que les contraintes techniques s'appliquent. Vous pourriez avoir des fichiers de plus de 6 octets, vous pourriez avoir des programmes couvrant plusieurs milliers de lignes de code; Les arbres de syntaxe abstraite sont bien plus profonds que six niveaux et avec beaucoup plus de nœuds par niveau. Juste pour des raisons, la limite de 6 caractères ne peut pas être technique, mais plutôt conçue. Et cela n'explique pas pourquoi "creat" est meilleur que "create". Aussi, pouvez-vous nommer les différents compilateurs C dont vous parlez? Votre réponse se lit vraiment comme "entendu quelque part quelque part".
phresnel
41
@phresnel: il ne parle pas de la taille du fichier, du nombre de lignes ou de la profondeur de l'arbre de syntaxe. Les anciennes versions du langage C ne nécessitaient pas que les compilateurs et les lieurs conservent plus de 31 caractères pour les identifiants avec liaison interne, ou plus de 6 pour les identifiants externes . Ainsi, get_current_date()et get_current_time()ne pouvait pas être dit à part par certains de ces premiers toolchains. La raison en était que ces systèmes fonctionnaient sur de minuscules empreintes de quelques kilo-octets.
DevSolar
34
Mais vous avez raison creat(). On a un jour demandé à Ken Thompson ce qu’il ferait différemment s’il modifiait le système UNIX. Sa réponse: "J'épelle creat avec un e."
DevSolar le
8
@phresnel: N'avoir qu'une mémoire limitée n'est pas une limite stricte. Ayant seulement une longueur prise en charge limitée des identifiants garantie est . Si vous ne disposez que de 6 personnages significatifs, c'est ce que vous travaillez si vous en valez la peine.
DevSolar
6
FWIW, l’ancienne norme Fortran limitée identifie à 6 caractères. De ce livre : "La règle de Fortran de six caractères dans un identifiant découle du fait que six caractères peuvent être représentés dans un mot IBM 704". Je ne peux pas parler pour C, mais j'imagine que la limitation a une origine très similaire (ou peut-être une origine identique)
tpg2114
26

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.

Luaan
la source
23
Le jour où mon noyau passe de timela getCurrentTimeSecsou quelque chose comme ça, je vais juste la mise à niveau l' arrêter. Même avec mon clavier confortable et mon matériel récent, ces noms restent extrêmement pratiques et simples (la simplicité étant l’un des principes fondamentaux de UNIX). Je ne ressens vraiment pas le besoin d'intégrer ce genre de nom de style Java / C # dans le langage C, et encore moins dans un noyau Linux. OMI, du point de vue d'un développeur de noyau, ou d'un développeur UNIX en général, ces idiomes ne sont pas très indésirables .
John WH Smith
11
@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionest moche pour moi, et je préférerais être sûr de ce qu'il fait en faisant man 2 timeque de deviner ce qu'il semble faire.
Muru
7
@ Benjoyo Eh bien, quiconque n'est pas habitué à cet environnement n'est pas censé utiliser les appels système, car ils sont spécifiquement destinés à ceux qui le sont. Les bibliothèques (standard) sont là pour les autres. UNIX ne suit pas ces "règles" de conception à la mode qui le rendraient facilement compréhensible à première vue. Ceux qui l'utilisent sans chercher dans aucun document ont beaucoup de problèmes, et peu de personnes dans la communauté UNIX considéreraient cela comme un problème à résoudre.
John WH Smith
4
@JohnWHSmith sûr que les développeurs en mode noyau connaîtront leur système et sa documentation, mais ce n'est pas une raison pour ne pas avoir de noms concis et éloquents.
Benjoyo
7
@JohnWHSmith En tant que petit développeur qui n'a jamais écrit que les pilotes du noyau et qui préfère les noms significatifs qui ne sont pas pleins d'abréviations, je ne suis pas d'accord. Mais ça va, car si vous regardez par exemple le code source original de Git, vous constaterez qu’au moins un développeur du noyau est en accord avec moi. Bien que si vous dites que son Linus get_Xou remove_file_from_cache(pourrais - je proposer rmfc?) Ne sont pas souhaitables pour les développeurs du noyau, s'il vous plaît le faire publiquement - j'adore voir sa réaction.
Voo le
22

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 ;-)

zwol
la source
2
Ouais. Il est amusant d'entendre l'argument technologique concernant les capacités matérielles lorsque les machines LISP sont antérieures à UNIX. Bien sûr, les machines UNIX étaient moins chères à l’achat , mais c’est à peu près tout. L'ajout des coûts de maintenance (qui bien sûr ne comptent pas dans * nix) a fait basculer les tables, même à ce moment-là, mais ce n'était pas un argument suffisamment convaincant. (Et oui, ic'est bien pour un index quand on itérera un tableau, par exemple. Coordonnées? Utilisez xet y. Traversant un ordinal? Soyez descriptif.)
Luaan
Les machines LISP @Luaan NE sont PAS antérieures à Unix. Vous échouez.
pizdelect
@pizdelect C’est techniquement vrai, mais la vérité technique n’est pas une raison suffisante pour s’en prendre à quelqu'un.
dimanche
@pizdelect Désolé, je voulais dire que Lisp était antérieur à UNIX (et à C). Mais les machines LISP étaient essentiellement contemporaines, si l’on comparait leur impact commercial (UNIX avait une avance d’environ trois ans, mais au moment où les machines LISP arrivaient, les machines commerciales UNIX étaient encore rares et lointaines; la plupart d’UNIX était dans les universités ou sans support). Quoi qu'il en soit, il s'agit d'une réponse aux arguments technologiques courants de l'époque, à savoir les années 80, lorsque les gens décidaient réellement entre des machines UNIX et des LISPM, et ils avaient tort. Cela a changé avec les micro-ordinateurs capables d'exécuter LISP plus rapidement de toute façon.
Luaan
10

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.

utilisateur207421
la source
@ downvoter Vous n'êtes peut-être pas d'accord avec Denni Ritchie à ce sujet, mais c'est ce qu'il a fait. Déclarer cette réponse est futile.
user207421