Perché i nomi delle chiamate di sistema UNIX / POSIX sono così illeggibili?

43

Qual è la ragione per usare nomi di chiamate di sistema così indicativi come timee creatinvece di getCurrentTimeSecse createFileo, forse più adatti su Unix get_current_time_secse create_file. Il che mi porta al punto successivo: perché qualcuno dovrebbe voler qualcosa di simile cfsetospeedsenza custodia per cammello o almeno sottolineature per renderlo leggibile? Ovviamente le chiamate avrebbero più caratteri ma sappiamo tutti che la leggibilità del codice è più importante, giusto?

history posix system-calls

— Benjoyo
fonte

42

Perché furono inventati decenni prima della notazione ungherese, la custodia del cammello, la custodia del serpente e simili diventarono di moda. Anche perché allora i compilatori avevano pochissime risorse e i nomi degli identificatori erano limitati a (IIRC) 8 caratteri.

— lcd047

3

@phresnel Non sono sicuro di quale relazione vedi tra nomi di file e ID variabili, ma sì, esitavo tra 8, 12 e 14. Forse il limite era anche 14 per gli ID variabili. Non era certo 256+. Per quanto riguarda le notazioni: definire "sempre". Ha Arminio usare parole CamelCase? Forse no. AFAIR, la notazione ungherese è stata introdotta per Windows all'inizio degli anni '90. CamelCase e sneak_case furono variazioni successive. Entrambi sono stati ovviamente usati prima di quello. Quello che sto dicendo è che sono diventati popolari verso la metà degli anni '90.

— lcd047

6

@phresnel: prendi nota che il tuo link parla dei limiti del primo filesystem Unix . Quando Thompson, Richie et al. sono stati la progettazione di Unix, hanno dovuto bootstrap Unix su macchine che non hanno ancora eseguito Unix , vale a dire in ambienti probabilmente ancora più vincolati.

— DevSolar,

11

Potresti anche chiederti perché non sono scritti in tedesco, perché si tratta dell'approssimazione del linguaggio naturale più vicina che mi viene in mente per le mostruosità troppo lunghe che Java ha insegnato ai programmatori ad accettare ...

— R ..

12

Sono così felice che sia così. Immaginare come un ls -la | grepapparirebbe così: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya,

61

È dovuto ai vincoli tecnici del tempo. Lo standard POSIX è stato creato negli anni '80 e si riferiva a UNIX, che era nato nel 1970. Diversi compilatori C a quel tempo erano limitati a identificatori che erano lunghi 6 o 8 caratteri, quindi stabilirono lo standard per la lunghezza della variabile e della funzione nomi.

Domande correlate:

— DR01
fonte

5

Non credo che si applichino i vincoli tecnici . Potresti avere file più grandi di 6 byte, potresti avere programmi che si estendono su migliaia di righe di codice; alberi di sintassi astratti molto più profondi di soli sei livelli e con molti più nodi per livello. Solo per ragione, il limite di 6 caratteri non può essere tecnico, ma piuttosto progettato. E non spiega perché "creat" sia meglio di "create". Inoltre, puoi per favore nominare quei diversi compilatori C di cui parli? La tua risposta dice davvero "sentito da qualche parte quando".

— galleria

41

@phresnel: non sta parlando della dimensione del file, del numero di righe o della profondità dell'albero della sintassi. Le vecchie versioni del linguaggio C non richiedevano compilatori e linker per mantenere più dei primi 31 caratteri di identificatori con collegamento interno o più di 6 per identificatori esterni . Quindi, get_current_date()e get_current_time()non poteva essere distinto da alcune di queste prime toolchain. Il motivo era che questi sistemi stavano lavorando su piccole impronte di pochi kilobyte.

— DevSolar,

34

Ma hai ragione creat(). A Ken Thompson una volta fu chiesto cosa avrebbe fatto diversamente se avesse ridisegnato il sistema UNIX. La sua risposta: "Scriverei creat con una e".

— DevSolar,

8

@phresnel: avere solo una memoria limitata non è un limite rigido. Avere solo una lunghezza supportata limitata di identificatori è . Se sei garantito solo 6 personaggi significativi, è quello con cui stai lavorando se valga la pena.

— DevSolar,

6

FWIW, i vecchi standard Fortran limitati identificano 6 caratteri. Da questo libro : "La regola Fortran di sei caratteri in un identificatore deriva dal fatto che sei caratteri potrebbero essere rappresentati in una parola IBM 704". Non posso parlare per C, ma immagino che la limitazione abbia un'origine molto simile (o forse un'origine identica)

— tpg2114

26

dr01 ha ragione, ma c'è anche un'altra ragione: l'usabilità. In passato, non avevi qualcosa di comodo come una tastiera su cui scrivere. Se sei stato fortunato, hai avuto qualcosa di simile a una macchina da scrivere della vecchia scuola. Se sei stato sfortunato, dovevi gestire i sistemi che richiedevano il vero lavoro fisico per funzionare (come in, ci voleva molta forza per premere il "tasto"), oppure facevi manualmente i buchi in una carta.

Ciò significava che anche entro il limite di 6-8 caratteri, hai cercato di mantenere i tuoi comandi il più corti possibile. Ecco perché hai lsinvece liste creatinvece di create. Il codice di quell'epoca è pieno di variabili come a, xe i- e ovviamente, x2e amici. La digitazione è stata molto impegnativa - oggi sei meno esercitato dalla digitazione di listIndexquanto non lo fossi dalla "digitazione" i- e non è nemmeno più così lento (specialmente con tecnologie aggiuntive come il completamento automatico).

La vera domanda è: perché così tanti idiomi Unix persistono anche se non sono più desiderabili?

— Luaan
fonte

23

Il giorno mio kernel cambia da timea getCurrentTimeSecso qualcosa del genere, mi limiterò a riqualificazione fermarlo. Anche con la mia tastiera comoda e l'hardware recente, questi nomi rimangono estremamente comodi e semplici (la semplicità è uno dei fondamenti di UNIX). Non sento davvero il bisogno di portare quel tipo di denominazione in stile Java / C # nel linguaggio C, figuriamoci in un kernel Linux. IMO, dal punto di vista di uno sviluppatore del kernel, o di uno sviluppatore UNIX in generale, questi idiomi non sono nulla di indesiderabile .

— John WH Smith,

11

@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionè brutto per me, e preferirei essere sicuro di ciò che fa facendo man 2 timepiuttosto che indovinare cosa sembra fare.

— muru,

7

@Benjoyo Beh, chiunque non sia abituato a questo ambiente non dovrebbe usare le chiamate di sistema in primo luogo, poiché sono specificamente pensate per coloro che lo sono. Le librerie (standard) sono qui per gli altri. UNIX non segue queste "regole" di design alla moda che lo renderebbero facilmente comprensibile a prima vista. Coloro che lo usano senza consultare alcun documento hanno molti problemi e poche persone nella comunità UNIX considererebbero che un problema sarebbe stato risolto.

— John WH Smith,

4

@JohnWHSSono certi che gli sviluppatori in modalità kernel conosceranno il loro sistema e i suoi documenti, ma questo non è un motivo per non avere nomi concisi e dire.

— Benjoyo,

7

@JohnWHSmith Essendo un modesto sviluppatore che ha sempre e solo scritto driver del kernel e preferisce nomi significativi che non sono pieni di abbreviazioni, non sono d'accordo. Ma va bene, perché se cerchi ad esempio il codice sorgente originale di Git, troverai almeno uno sviluppatore del kernel d'accordo con me. Anche se dite Linus che il suo get_Xo remove_file_from_cache(potrei proporre rmfc?) Sono indesiderabili per gli sviluppatori del kernel, si prega di farlo pubblicamente - Mi piacerebbe amore per vedere la sua reazione.

— Voo,

22

Oltre alle altre risposte, vorrei sottolineare che Unix è stato sviluppato come reazione a Multics, CTSS e altri sistemi operativi contemporanei, che erano significativamente più dettagliati sulle loro convenzioni di denominazione. Puoi avere un'idea di questi sistemi operativi su http://www.multicians.org/devdoc.html . Ad esempio, http://www.multicians.org/mspm-bx-1-00.html fornisce change_nameil comando per rinominare un file; confrontare Unix mv.

Inoltre, il motivo principale per cui persistono i nomi di chiamate di sistema molto brevi è la compatibilità con le versioni precedenti. Noterai che le API più recenti tendono ad essere più esplicite; ad es. gettimeofdaye clock_gettimenon solo time.

(Ancora oggi, usare al whateverIndexposto di iun indice di loop è un errore di revisione automatica del codice nel mio libro ;-)

— Zwol
fonte

2

Si. È divertente ascoltare l'argomento tecnologico sulle capacità hardware quando le macchine LISP precedono UNIX. Certo, le macchine UNIX erano più economiche da acquistare , ma questo è tutto. L'aggiunta di costi di manutenzione (che ovviamente non contano nella terra * nix) ha cambiato le tabelle anche allora, ma non è stato comunque un argomento abbastanza convincente. (E sì, iva bene per un indice quando, per esempio, stai ripetendo una matrice. Coordinate? Usa xe y. Attraversando un po 'di ordinale? Sii descrittivo.)

— Luaan

Le macchine LISP di @Luaan NON precedono Unix. Hai fallito.

— seleziona il

@pizdelect È tecnicamente vero, ma la verità tecnica non è una ragione sufficiente per aggredire qualcuno.

— zwol,

@pizdelect Spiacente, intendevo che Lisp precede UNIX (e C). Ma le macchine LISP erano essenzialmente contemporanee, se si confronta il loro impatto commerciale (UNIX aveva un vantaggio di circa tre anni, ma quando arrivarono le macchine LISP, le macchine commerciali UNIX erano ancora poche e lontane tra loro; la maggior parte di UNIX era in accademia o senza supporto). In ogni caso, è una risposta agli argomenti tecnologici comuni a quel tempo, che erano gli anni '80, quando le persone stavano effettivamente decidendo tra macchine UNIX e LISPM, e si sbagliavano. Ciò è cambiato con i microcomputer che potevano comunque eseguire LISP più velocemente.

— Luaan,

10

Dennis Ritchie si è posto un vincolo con C che non si baserebbe su alcuna funzionalità di linker che non era richiesta anche da Fortran. Da qui il limite di 6 caratteri per i nomi esterni.

— user207421
fonte

@downvoter Potresti non essere d'accordo con Denni Ritchie su questo, ma è quello che ha fatto. Eliminarlo con questa risposta è inutile.

— user207421