Perché i vecchi nomi dei metodi in stile C continuano ad essere utilizzati nelle lingue moderne? [duplicare]

But why do modern languages like python and go still use the less readable names from the C apis?

1. Perché tutti (nel loro dominio) conoscono i nomi brevi. Se facessi nomi diversi, le persone metterebbero in discussione "che cosa rende questo diverso da mkdir ?" e generalmente si confondono che roba non è dove si aspettano.

2. Perché senza il completamento automatico in un IDE, i nomi lunghi con caratteri generalmente difficili da digitare come _ disturbano i programmatori esperti. I programmatori infastiditi limitano l'adozione di una lingua, il che significa che i progettisti non fanno i nomi o non si sentono mai parlare delle lingue che li hanno utilizzati poiché non sono mai decollati.

Questi sono entrambi argomenti delicati, ovviamente.

Il codice leggibile è noto per essere meglio del codice scrivibile in questi giorni. E avere un IDE con le maniglie di completamento automatico, opzione 2, anche se ci sono ancora persone che sostengono che gli IDE sono ingombranti o una stampella che ostacola le abilità dei programmatori. Avere un IDE con intellisense (o l'equivalente) aiuta anche un gruppo con # 1, sebbene abbia gli stessi argomenti e funzioni meno bene in un ambiente non orientato agli oggetti.

Tuttavia, questi argomenti fragili (e le bizzarrie del gusto umano) sono sufficienti per mantenere la tendenza in corso.

Perché continuiamo a usare il vecchio "Albert" germanico come nome di un ragazzo e non la traduzione inglese moderna "Shining Hero"?

Perché un nome è solo un'etichetta. È bello dare alle nuove cose un nome significativo, ma, dopo un lungo utilizzo, il nome stesso diventa il significato.

printf significa qualcosa di molto specifico per generazioni di programmatori - una funzione di stampa con un modello che utilizzerà %2d per indicare dove vuoi stampare un numero a due cifre, ecc.

D'altro canto print_format indica una funzione che in qualche modo formatta e stampa alcuni dati e dovrai cercare i documenti per scoprire come usarli.

È semplice. Usare i nomi tradizionali è conveniente per milioni di programmatori esperti. Sappiamo cosa significano "mkdir" e "printf". È un po 'scomodo per i principianti, ma presto lo superano.

Allo stesso modo, la maggior parte (tutti?) dialetti LISP continuano a utilizzare "auto" e "cdr" invece di "testa" e "coda".

Come altri hanno già detto, molte di queste parole chiave hanno significati ben stabiliti e rendono molto facile la ripresa di una nuova lingua ecc. Di solito sono abbreviazioni di parole esistenti omettendo alcune lettere (principalmente vocali), non è come qualcuno purificate lettere casuali e deciso, 'eokjgv' sarà la mia funzione per make_directory.

I nomi più brevi hanno vantaggi effettivi oltre a non dover fare affidamento sul completamento automatico:

• Può contenere più contesto in un numero inferiore di righe o in uno schermo singolo
• Nessuna confusione nel tentativo di conciliare il significato rigoroso della scienza informatica con il linguaggio comune che significa
• Disambiguazione più rapida: se vuoi distinguere tra print_formatted_string , print_formatted_string_from_file , print_string_with_line ci vorrà molto più tempo di printf , sprintf , println .

Naturalmente, anche l'inerzia e la cultura sono fattori importanti: nelle lingue comuni, la tua domanda è simile a chiedere: Perché le persone non passano all'esperanto anziché all'inglese con la sua grammatica confusa e un enorme vocabolario?

Puoi vedere programmi prolissi leggendo pseudocodice: crea pseudocodice per un piccolo metodo e vedi quanto volume viene aggiunto ad esso, e ricorda che la memoria umana a breve termine è anche una quantità finita.

Perché la tua ipotesi che "i nomi più lunghi sono meglio leggibili" non è semplicemente vera!

Al contrario, più breve è il nome, maggiori sono le possibilità (a parità di altre condizioni) che è possibile identificare il nome contemporaneamente, come un'icona.

Ma c'è di più: le possibilità di confondere gli identificatori che hanno solo poche differenze sono tanto maggiori quanto più lunghi sono i nomi.

Come sempre, c'è una via di mezzo. Un metodo pubblico in un'API non deve essere una singola lettera e una variabile locale temporanea non deve essere una poesia.

Riferimento xkcd obbligatorio:

Supponiamochetuabbiaprogettatounalingua,ounaversionesuccessivadiunalinguaesistente,edica"dimentichiamo i vecchi nomi in stile C, ho un'idea migliore". Si rinomina mkdir in make_directory . Qualcun altro, seguendo lo stesso modo di pensare, inventa create_directory , un terzo create_dir , il prossimo new_directory , e così via. Ora i programmatori hanno molto più difficile imparare una nuova lingua o un nuovo dialetto, perché invece di riconoscere istantaneamente cosa fa un comando e quali parametri si aspetta, devono leggere il manuale. Non avendo gli stessi nomi e la stessa struttura, può essere molto più probabile avere un uso diverso o un diverso ordine di parametri (se ricordo bene, a .NET piaceva farlo all'inizio, alcuni metodi avevano i parametri come source, destination , altri come destination, source ). Rende la programmazione più incline agli errori, o molto più lenta in quanto il programmatore deve leggere il manuale ogni volta che usa una funzione, perché non si può mai essere sicuri di quali parametri questa funzione in questa lingua sia utilizzata in questa versione.

Se i ALL designer di lingua potrebbero accettare di cambiare i nomi in stile C per tutte lingue future in esattamente allo stesso modo, potrebbero un po 'di buon senso per farlo Buona fortuna per averlo fatto!

Le radici comuni e il patrimonio culturale non esistono senza una ragione.

Come altri hanno già detto, è principalmente perché questi sono spesso solo wrapper attorno alle chiamate C. E c'è un enorme vantaggio in questo caso (compreso il nome breve), fondamentalmente i programmatori nuovi al linguaggio sanno cosa aspettarsi da esso - quali argomenti prende, quali effetti collaterali potrebbe avere, come vengono gestite le condizioni di errore.

Se vedo:

printf ("Traccia della larghezza:% * d \ n", 5, 10)

So che (a) questo è un diritto giustificato e (b) che può richiedere fino a 5 spazi. Se vedo:

printf_formatted_string("Width trick: %*d \n", 5, 10)

Non ho idea di cosa significhi, senza cercarlo.

Anche i nomi in stile C più corti trasmettono che sebbene questa lingua non sia C; la lingua ha un retaggio C e questa stampa è la nostra interpretazione della nostra funzione di printf dei venerandi antenati adattata alla nostra lingua.

C è un linguaggio fondamentale e le nuove lingue possono guadagnare molto affermando che sono "C-style".

Allo stesso modo, altri linguaggi possono incorporare intenzionalmente il modo Unix di svolgere alcuni compiti e rinforzarlo adottando nomi Unix per fare cose simili (o identiche). Se hai familiarità con il comando chmod di Unix e implementa funzionalità chmod-like nella tua lingua con forse un'API simile, allora potrebbe essere meglio chiamarlo chmod nella tua lingua piuttosto che change_mode o altro. Significa che puoi riutilizzare la tua esperienza Unix

Alcune persone credono che ciò che potresti fare spesso in una lingua dovrebbe avere un nome più breve.

Per fare qualcosa di utile, tutte le lingue devono interagire con i sistemi operativi, ma non tutte le lingue effettuano chiamate al sistema operativo direttamente perché non esiste un'API definita per queste lingue. POSIX, ad esempio, definisce solo API con associazione a C e Ada.

Una parte molto importante del sistema operativo è la libreria C (libc), che implementa almeno l'API del sistema operativo dopo che POSIX è stato definito. POSIX è stato sostanzialmente definito in base alle implementazioni libc esistenti.

Se non esiste un'API specifica per una lingua, allora deve utilizzare le funzioni disponibili in libc. Spetta quindi al designer del linguaggio rinominare o riutilizzare i nomi delle funzioni di libc ed esportarli come librerie.

Penso che i linguaggi che girano su macchine virtuali (vm come in jvm) non dovrebbero avere lo stesso problema (se è davvero un problema).