Perché i compilatori non supportano parole chiave non inglesi? [chiuso]

In parole semplici:

Lo fanno.

In questo articolo di Wikipedia puoi vedere che ci sono molti linguaggi di programmazione / compilatori / interpreti basati su lingue diverse dall'inglese.

Ecco un codice sorgente di esempio in Linnotte , un linguaggio di programmazione francese:

 nombre Fibonacci : 
  a est un nombre
  début
   questionne a sur "Entrez un nombre :" 
   affiche fibo(a)

 fibo :    
  * n est un nombre     
  début
   si n est < 2, retourne n          
   retourne fibo(n-1) + fibo(n-2) 

.. e un programma Hello World in SAKO , uno basato su polacco:

K) PROGRAM DRUKUJE NAPIS HELLO WORLD
   LINIA
   TEKST:
   HELLO WORLD
   KONIEC

La domanda sarebbe perché la maggior parte delle lingue / compilatori / interpreti usano le parole riservate in inglese.

I compilatori e le lingue sono più utili più persone nel mondo hanno accesso ad esso e i progetti software sono una delle discipline che richiedono sforzi da persone in paesi diversi. Per ragioni storiche l'inglese è diventato il linguaggio di comunicazione predominante nel mondo moderno, quindi è logico che la maggior parte dei linguaggi di programmazione utilizzi le parole chiave inglesi. Se il corso della storia fosse stato diverso, forse i linguaggi di programmazione sarebbero per lo più basati su latini o su base francese.

L'inglese ha alcuni altri vantaggi: non usa accenti e segni come áéíúóâêîôûäëïöü ecc. che lo rende il minimo comune denominatore per quanto riguarda i layout di tastiera.

È interessante sapere che Niklaus Wirth che ha progettato PASCAL tra le altre lingue era svizzero, eppure ha scelto l'inglese per le parole riservate, come menzionato in questo MSDN articolo.

Un'altra curiosità:

While Perl's keywords and function names are generally in English, it allows modification of its parser to modify the input language, such as in Damian Conway's Lingua::Romana::Perligata module, which allows programs to be written in Latin or his Lingua::tlhInganHol::yIghun Perl language in Klingon. They do not just change the keywords but also the grammar to match the language.

Troppo sforzo per troppo poco valore aggiunto.

La quantità di inglese richiesta per dare un senso alle parole chiave di qualsiasi linguaggio di programmazione è davvero molto piccola - per la maggior parte degli oratori della seconda lingua è probabilmente molto meno di quanto già sapessero della lingua prima ancora che diventassero programmatori. Viceversa, consentire a tutte le parole chiave di essere sostituite dalle loro traduzioni in altre lingue (e ci sono migliaia di altre lingue!) Aggiungerebbe alla complessità dell'implementazione del linguaggio, inquinerebbe lo spazio dei nomi predefinito con migliaia di token che non sono più identificatori legali, e corrono il rischio che ogni volta che devi rivedere qualsiasi codice, improvvisamente devi sapere cosa significa "se" in ceco per farlo bene. Quasi tutti i professionisti trovano questi costi troppo alti per il beneficio di permettere alle persone di programmare senza un comando rudimentale dell'inglese.

Si noti che il metodo ei nomi dei campi nelle librerie standard o contribuite sono un altro campo. La maggior parte dei venditori si attengono all'inglese anche per quelli, per lo stesso motivo, ma in particolari circostanze può essere utile il trade-off, quindi ci sono alcune lingue di terze parti con identificativi pubblici non inglesi, ma ancora una piccola minoranza.

Si noti inoltre che questo non ha assolutamente nulla a che fare con la questione se l'inglese sia particolarmente adatto ad esprimere la logica di programmazione, o se sia equo che i programmatori statunitensi e britannici avere un vantaggio. Il linguaggio ha acquisito il suo attuale stato di fatto come standard per computer in gran parte attraverso processi storici contingenti (eventi che potrebbero essere risultati altrimenti, ma in realtà non lo erano). Anche se a molte persone questo non piace, pochi non amano così tanto che sono disposti a tornare indietro e reintrodurre deliberatamente la possibilità della frammentazione solo per fare dispetto agli americani.

Il motivo principale è che tutto il codice sorgente dovrebbe essere scritto in inglese . Questo vale anche per nomi variabili, commenti, ecc.

La ragione diventa ovvia quando vedi per la prima volta un pezzo di codice che è scritto in una lingua che non conosci. Ad esempio:

// Записать изменения конфигурации.
var имя = this.RefreshMeta().ПолныйПуть;
this.Хостинг.Записать(имя);

All'improvviso, non puoi capirlo, quindi non puoi rivederlo, modificarlo o testarlo unitamente. Inoltre, nel mio esempio, non puoi nemmeno lavorarci perché non hai la tastiera russa. In altre parole, non puoi più lavorare con questo codice.

Questo potrebbe essere accettabile per i progetti a codice chiuso fatti da piccole aziende. Con lo svantaggio di vietare a se stessi di assumere un giorno uno sviluppatore abile all'estero che non parla la lingua in cui è scritto il codice.

Lavorando in un'azienda in cui il francese è preferito per i commenti e la documentazione del codice, noto diversi problemi con questo:

1. Come detto sopra, l'assunzione è di fatto limitata alle persone che parlano francese.

   Se la lingua stessa è localizzata, questo significa ancora più fastidio rispetto a un caso in cui sono presenti solo commenti o nomi di variabili.

2. Se un giorno il codice viene rilasciato come open source, la maggior parte degli sviluppatori al mondo non sarà in grado di lavorare con esso.

3. Mentre lavoriamo con .NET Framework e SQL Server che sono pienamente compatibili con Unicode, i colleghi hanno spesso paura di inserire accenti appropriati sulle lettere, risultando in nomi appena leggibili ed estremamente brutti come DELAI_EXPIRE .

   ^{Per le persone che non parlano il francese, DELAI_EXPIRE deve essere scritto DÉLAI_EXPIRÉ . Scritto nella sua prima forma, lo rende difficile da capire e può avere due significati: o significa che un ritardo è attualmente in scadenza, o che il ritardo è già scaduto.}

   Se le parole chiave di una lingua sono localizzate, dovrebbero essere inclusi gli accenti? Dovrebbero essere rimossi?

4. Anche in relazione agli accenti, le tastiere francesi sono piuttosto cattive quando si tratta di scrivere lettere con caratteri maiuscoli. Puoi scrivere la lettera À o Ê , ma non É , come in Également . Ciò rende piuttosto difficile l'auto-completamento all'interno di un IDE.

   Che cosa accadrebbe se una delle parole chiave di una lingua inizia con un carattere difficile o impossibile da digitare su una tastiera?

Una nota sugli IDE

Gli IDE sono localizzati perché:

1. Contengono molti termini, a volte complicati.

   In confronto, la maggior parte delle lingue contiene solo poche decine di parole chiave, che sono spesso parole imparate nelle scuole.

2. Contengono testo che si intende leggere.

   Per confronto, le parole chiave sono ... parole chiave. Ad esempio, la parola chiave var in C # non ha alcun significato in inglese. È un'abbreviazione di variable , ma non è ancora una parola inglese. Sapere che var è un'abbreviazione di variable non mi aiuterà a comprendere il concetto di variabili implicitamente tipizzate. Potrebbe essere stato implicit o imptype o unknown .

3. L'uso di una lingua in un IDE da parte di un collega non influisce sugli altri sviluppatori. Si può avere Eclipse in italiano, mentre i suoi colleghi lavorano felicemente in portoghese.

   In confronto, usare una lingua specifica nel codice sorgente significa che tutti dovrebbero capirlo, perché il controllo della versione non tradurrà magicamente commenti o parole chiave scritti in russo da uno sviluppatore russo in giapponese per i suoi colleghi in Giappone.

Quindi perché l'inglese (il 5,52% della popolazione mondiale è madrelingua) e non, ad esempio, il mandarino, (il 14,1% della popolazione mondiale è madrelingua) o spagnolo (il 5,85% della popolazione mondiale è madrelingua)?

A causa di ragioni storiche, l'inglese è usato a livello internazionale e imparato nelle scuole nella maggior parte dei paesi. È ancora più predominante sul web e ancor più tra i programmatori. Puoi restare fedele a questo e usare l'inglese per comunicare con coppie, o provare a cambiare il mondo in modo che lo spagnolo, il rumeno o il curdo diventino la lingua successiva che ogni programmatore accetta di utilizzare.

È un errore affermare che "[in] linguaggi di programmazione tutte le sintassi sono scritte in inglese" o "Il codice semplice (...) è scritto in inglese". I linguaggi di programmazione e le lingue naturali sono cose diverse. Il linguaggio di programmazione tende a prendere in prestito alcune parole dalla maggior parte dell'inglese (l'eccezione più importante è probabilmente null dal tedesco), allo stesso modo la lingua inglese prende in prestito la parola "programma" dal francese.

Oltre a poche parole, praticamente nulla dall'inglese è preso in prestito dal linguaggio di programmazione: sintassi, tempi verbali, coniugazione, declinazione ecc.

Ci si può chiedere perché l'inglese sia la lingua da cui i linguaggi di programmazione prendono in prestito il loro vocabolario. La risposta è piuttosto geopolitica che di natura tecnica.

Detto questo, conosco diverse persone che non parlano inglese che codificano i proficint in diversi linguaggi di programmazione.