Codifica in altre lingue (parlate)

Questo è qualcosa che mi sono sempre chiesto e non riesco a trovarne alcuna menzione da nessuna parte online. Quando un negozio proveniente, ad esempio, dal Giappone, scrive codice, sarei in grado di leggerlo in inglese? Oppure le lingue, come C, PHP, qualsiasi altra cosa, hanno traduzioni giapponesi che scrivono?

Immagino che quello che sto chiedendo è che ogni singolo programmatore nel mondo conosce abbastanza l'inglese per usare le stesse identiche parole riservate che conosco io?

Questo codice:

If (i < size){
    switch
        case 1:
            print "hi there"
        default:
            print "no, thank you"
} else {
    print "yes, thank you"
}

visualizzare esattamente lo stesso che vedo io adesso in inglese, o qualcun altro non anglofono vedrebbe le parole "if", "switch", "case", "default", "print" e " altro "nella loro lingua madre?

EDIT - sì, questo è serio. Non sapevo se diverse localizzazioni di una lingua hanno parole chiave diverse. o se ci sono anche diverse localizzazioni.

Se ho capito bene la domanda in realtà è: "ogni singolo programmatore del mondo conosce abbastanza l'inglese per usare le stesse identiche parole riservate che ho io?"

Bene .. L'inglese non è l'argomento qui ma parole riservate al linguaggio di programmazione. Voglio dire, quando ho iniziato circa 10 anni fa, non avevo la minima idea dell'inglese, eppure ero in grado di programmare cose semplici imparando il linguaggio di programmazione, anche quando non sapevo cosa significassero (in inglese). In effetti questo mi ha aiutato a imparare l'inglese.

Per esempio. So che per fare una "iteración" (iterazione ovviamente) ho dovuto scrivere:

 for( i = 0 ; i < 100 ; i++ ) {}

Per me il "per", il ";" e il "++" dove semplici parole o simboli stranieri. Più tardi ho imparato che "per" significava "para" e "while" significava "mientras" ecc. Ma nel frattempo non avevo bisogno di conoscere l'inglese, ma nel mio caso quello che mi serviva era sapere "C".

Ovviamente quando avevo bisogno di imparare più cose, dovevo imparare l'inglese, perché la documentazione è scritta in quella lingua.

Quindi la risposta è: no, non vedo se, mentre, per ecc. Nella mia lingua madre. Li vedo in inglese, ma per me non significavano altro che significassero a loro volta per il linguaggio di programmazione.

È come l'istruzione switch in bash: case .. esac. Cos'è "esac" ... per me la fine dell'istruzione switch in bash.

Immagino sia ciò che chiamiamo "astrazione"

Nel linguaggio Java alcuni metodi devono essere denominati (almeno parzialmente) utilizzando la lingua inglese a causa della convenzione JavaBeans.

Questa convenzione richiede che una proprietà X venga stabilita tramite una coppia di metodi getX () e setX (). Qui in franco-canadese, dove alcuni sviluppatori sono obbligati a codificare in lingua francese, questo porta alla seguente farsa:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

Ho problemi a trovare riferimenti, ma mi vengono in mente tre storie.

Un hacker Lisp difende funzioni prive di significato come "cdr" e "car" confrontandole con la programmazione nella tua lingua non nativa: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171. html

Quando Yukihiro Matsumoto ("Matz") ha iniziato a sviluppare Ruby, ha usato parole chiave inglesi anche se scriveva tutta la documentazione in giapponese! . Non c'era documentazione in inglese per Ruby per un paio d'anni e pochissimi americani che usavano la lingua. Ma ora è una lingua di livello mondiale, e il fatto che sia nato in Giappone è solo di interesse storico. Se la lingua avesse utilizzato parole chiave in hiragana, sarebbe stato molto più difficile guadagnare popolarità.

Una volta ho letto un saggio - forse qualcun altro può trovarlo, Google oggi non aiuta - che suggeriva che la traduzione delle parole chiave era fuorviante perché le parole non sono effettivamente inglesi - sono gergo. Non solo (per usare gli esempi sopra) para e pour non hanno esattamente il significato esatto che for ha in inglese, per i non programmatori la frase "for loop" è scherzosa. Anche gli americani devono imparare un nuovo significato. Quindi tradurre il significato superficiale delle parole in un'altra lingua è più come fare un gioco di parole incrociato piuttosto che essere effettivamente d'aiuto.

Non ho mai pensato molto alla programmazione in giapponese prima, ma eccoci qui, usando il codice di esempio della domanda.

Utilizzando solo le dichiarazioni della lingua in giapponese con le variabili in inglese:

// In Japanese, it makes more sense to put the keywords/modifiers as
// postfix expressions rather than prefix expressions.
(i < size)か {
     (l[i])は {
     1だ:
         「もしもし。」を書く;
     省略時値:
         「いいえ、いいですよ。」を書く;
     }
} ない {
     「はい、ありがとうございます。」を書く;
}

Come molte persone hanno già sottolineato, nella maggior parte dei linguaggi di programmazione devi solo imparare alcune parole chiave, quindi non importa molto se sono in inglese (o una lingua diversa dalla tua, se è per questo). È solo un simbolo che associ a qualche costrutto. Ad esempio, in VB hai "THEN", che in molti linguaggi in stile C sarebbe "{" e non fa una grande differenza in termini di leggibilità (beh, almeno è come la vedo io, essendo un non inglese madrelingua).

Ma dove le cose a volte possono diventare complicate e dove la scelta del linguaggio (naturale) conta è nel nominare gli identificatori. Se i nomi di variabili, funzioni, classi, ecc. Non hanno un nome significativo per te a causa di una barriera linguistica, seguire anche il codice più semplice può essere piuttosto impegnativo.

Ricordo che una volta qualcuno mi diede un breve frammento di Actionscript tratto da un blog. I nomi erano in tedesco e poiché non parlo una parola di quella lingua, le cose avrebbero potuto chiamarsi anche var_123, var_562 o func_333 (e probabilmente sarebbe stato più facile per me ricordare i nomi o almeno avere un possibilità di scriverli correttamente senza copiare e incollare). Poiché si trattava di uno snippet breve e autonomo, ho usato un traduttore online per dare a quelle variabili e funzioni nomi significativi nella mia lingua madre (spagnolo) e dopo è stato tutto chiaro. Il punto è che il codice era in realtà semplice, ma sono stato in grado di dargli un senso senza troppi (inutili) sforzi extra proprio quando ho superato la barriera linguistica.

Da allora, sono passato a utilizzare l'inglese per denominare gli identificatori. Che ti piaccia o no, è la "koine" per la programmazione, l'ingegneria e le cose tecniche in generale. La maggior parte delle API sono scritte in inglese, così come la maggior parte della documentazione (e probabilmente anche le migliori risorse che puoi trovare sono in inglese). Per inciso, mantiene il tuo codice più coerente con il codice con cui probabilmente interagirai, e penso che tenda ad essere più compatto e succinto di altre lingue come lo spagnolo (che altrimenti sarebbe la mia scelta naturale).

Naturalmente, se non riesci a capire almeno un po 'di inglese, il problema rimane lo stesso, quindi non è una soluzione perfetta. Ma, dato un numero di sviluppatori provenienti da molti paesi diversi, è probabile che la lingua comune per comunicare (tramite codice e ovviamente altri mezzi) sia l'inglese. Quindi, scegliere l'inglese è forse l'opzione migliore, anche se non sarebbe la soluzione perfetta a questo problema.

Il linguaggio di programmazione definisce parole chiave e nomi di classi standard, ed è buona pratica fornire tipi, variabili e funzioni definiti dall'utente anche nomi inglesi (come non madrelingua posso dirlo ;-).

Quindi sì, se tutto va bene, sarai in grado di leggere il codice.

Tuttavia linguaggi come Java e Perl consentono l'intero set Unicode per gli identificatori, quindi se qualcuno scrive i nomi delle sue classi in Kanji, probabilmente avrai un problema.

Aggiornamento: per Perl c'è un modulo scherzo che ti permette di scrivere Perl in latino. Ma è davvero solo questo, uno scherzo. Nessuno usa cose del genere seriamente.

Secondo aggiornamento: l'idea di linguaggi di programmazione localizzati non è così ridicola. Il linguaggio macro di Excel è localizzato, ma fortunatamente è memorizzato in una lingua canonica (inglese) nel file, quindi la localizzazione è solo uno strato in cima alla cosa normale. Queste cose hanno senso solo per piccoli "programmi", per programmi "reali" diventa difficile da mantenere.

In realtà ci sono alcuni linguaggi di programmazione non basati sull'inglese (Wikipedia)

Sono norvegese ma ho sempre usato l'inglese per tutto il codice tranne l'output (ignorando qualche codice stupido dalla scuola). In realtà di solito scrivo tutto in inglese e poi lo traduco nella mia lingua madre, usando gettext (o qualcosa del genere).

Io sono britannico e un problema che spesso incontriamo è lo scontro ortografico americano / britannico. Ciò si verifica spesso con termini correlati alla programmazione come Inizializza () o Inizializza (), Analizza () o Analizza () ecc. Ciò può (ha) portare a problemi nel tentativo di sovrascrivere i metodi ed è talvolta difficile da individuare.

Poiché il framework (nel nostro caso C #) è stato progettato dagli americani, abbiamo riscontrato che è meglio essere coerenti e utilizzare l'ortografia americana. Adottiamo persino il colore.

Abbiamo un mix di nazionalità nei nostri team di sviluppo e la maggior parte delle persone non britanniche tende naturalmente all'ortografia americana.

AppleScript era una volta disponibile nei dialetti francese e giapponese. Non so perché sia ​​stato ritirato.

Portando questo al livello successivo, che dire della possibilità di sostituire i simboli?

Dopo aver visto linguaggi come Brainf ** k e Whitespace ho pensato di creare un linguaggio come questo: sarebbe identico al C tranne per il fatto che usi le parentesi graffe di chiusura per aprire, le parentesi graffe aperte per chiudere, scambia i significati di + e -, * e / ,; e:,> e <, ecc.

Il concetto non è altro che un compilatore C alterato ingannevole. Ma, come pensare alle parole chiave in modo diverso, ti sfida a ripensare ad alcuni presupposti di base se non hai mai pensato a queste cose prima. Ex:

int foo)int i, char c( }
    int six = 2 / 3:
    int two = six + 4:
    if )i > 0( }
        printf)"i is negative"(:
    {
{

Lavoro in un team francese che sviluppa un sistema software in C #. Nonostante il fatto che le parole chiave del linguaggio di programmazione siano apparentemente inglesi, immagino che avresti grandi difficoltà a leggere il codice poiché tutti i nomi delle funzioni, variabili, commenti sul codice, tabelle e colonne del database, specifiche tecniche, protocolli e così via, sono tutti presenti Francese, compresi quei bei caratteri accentati ç, é, è, ù, ecc. Non sono nemmeno sicuro che il sistema funzionerebbe anche altrove a causa di bug di localizzazione, come fare affidamento sulla virgola come separatore decimale predefinito.

Altrimenti, WinDev è una piattaforma di programmazione popolare in Francia e il suo linguaggio di programmazione WLanguage ha parole chiave in francese o inglese, vedere ed esempio qui: link text

L'unica lingua che ho visto localizzata è Excel con le sue macro. Se provi a sommare una colonna usando una versione italiana di Office devi scrivere SOMMA(A1:A10)e non SUM. È un peccato.

A proposito, proprio perché è divertente, ecco come dovrebbe apparire il tuo codice con le parole chiave italiane:

se (i < size){
    commuta
        caso 1:
            stampa "hi there"
        normalmente:
            stampa "no, thank you"
} altrimenti {
    stampa "yes, thank you"
}

Ho visto VBA tradotto in comandi simili a quelli spagnoli. è una delle cose più brutte mai viste. mi vergognerei di avere qualcosa di simile sul mio computer.

PD: penso che lo spagnolo sia una lingua molto più bella dell'inglese; ma tradurre è SBAGLIATO

Ebbene, come altri hanno sottolineato, le parole chiave e le chiamate di sistema rimarrebbero probabilmente in inglese.

Tuttavia, la comprensione delle parole chiave della lingua è solo una piccola parte nella comprensione del codice. Nomi di variabili, nomi di funzioni e commenti rischiano di essere nella lingua madre dell'autore.

Modifica : ho appena fatto un flashback alla mia giovinezza dove sono andato nelle tabelle di mappatura del mio BASIC integrato nel TRS-80 per cambiare le parole chiave in francese. Potrei cambiare tutte le parole chiave ma non potrei ingrandirle nessuna. Realizzato per programmi divertenti.

Non prenderla in giro. Alcuni anni fa, Microsoft aveva annunciato G # (tedesco Sharp) - C # con parole chiave e API tedesche. Certo, era uno scherzo del pesce d'aprile, ma l'intero sito a riguardo sembrava così reale e professionale (ed era su microsoft.com). Spaventoso.

Al lavoro, utilizziamo due sistemi di bus di campo, entrambi sviluppati in paesi di lingua tedesca, che hanno un spaventoso mix di tedesco e inglese per gli identificatori, inclusi alcuni adorabili falsi amici. È un disastro.

No, le parole chiave e gli identificatori inglesi vanno bene. Anche se alcuni potrebbero discutere se dovrebbe essere Colore o Colore :)

In diversi progetti VBA a cui ho lavorato (sì, all'inizio della mia carriera) abbiamo dovuto rilevare la versione di Office installata sulla macchina dell'utente e modificare di conseguenza le formule utilizzate negli speradsheets.

Come programma in portoghese, "SUM" dovrebbe essere tradotto in "SOMA" e così via. Non riesco proprio a immaginare il lavoro necessario per farlo accadere in diverse lingue. Qualcun altro ha sofferto di questo problema?

Ci sono alcune lingue che hanno parole chiave tradotte. Formule di Excel, ad esempio. Se scrivi dei calcoli in un foglio di calcolo, questo sarà nella tua lingua.

Fortunatamente, questa non è una pratica generale e anche chi non parla inglese come me ringrazia Dio che esiste un linguaggio standard per le parole chiave:

• è più facile condividere il tuo lavoro.
• impedisce alla documentazione di diventare un incubo più grande di quanto lo sia già.
• Le parole e le frasi inglesi sono generalmente brevi e sintatticamente pragmatiche. In letteratura, le lingue latine sono molto più belle, ma per cose tecniche, l'inglese è eccezionale.

E dove fermarsi? Riuscite a immaginare una C in greco antico?

Le parole chiave devono rimanere in una lingua e, beh, è ​​iniziato con l'inglese, lascia che rimanga così. Questo avrebbe potuto essere il peggiore (lingua asiatica?). E quindi dobbiamo scrivere metodi e commenti in inglese. Ok, altro lavoro per noi, ma almeno il codice internazionale rimane congruente.

C'è, tuttavia, un caso in cui l'utilizzo di nomi di metodi e commenti nella lingua madre può essere una buona pratica: in un paese del terzo mondo. Tra qualche mese vado in Senegal per gestire un progetto Django. Il Senegal ha un enorme tasso di alfabetizzazione, e quindi è già fantastico che spenda energia nel migliorare le proprie conoscenze di programmazione. Il francese è la lingua madre qui, quindi sarebbe inefficace costringerli a imparare l'informatica E una nuova lingua allo stesso tempo.

BTW, questo sarebbe il tuo codice con parole chiave francesi:

Si (i < taille) {
    cas par cas :
        cas 1:
            afficher "salut"
        défaut:
            afficher "non merci"
} sinon {
    afficher "oui, merci"
}

Non che la traduzione delle parole chiave non abbia nulla a che fare con la traduzione delle stringhe. Ovviamente abbiamo tradotto "ciao, là" nella nostra lingua. I programmatori europei tendono persino a utilizzare I18N molto più di quanto gli americani possano far sì che il loro servizio raggiunga un pubblico più ampio.

In generale, la maggior parte dei programmatori si adatta alla forma inglese. Ho imparato a programmare quando avevo 7 anni e parlavo solo ebraico (da destra a sinistra) e senza inglese, il che ha reso l'esperienza piuttosto affascinante.

Il problema che normalmente si verifica è con la documentazione, le variabili e i nomi delle funzioni. Ho visto la mia quota di variabili in altre lingue usando l'alfabeto inglese.

L'unica lingua con cui ho familiarità che è stata effettivamente tradotta è stato il buon vecchio Logo (ancora sorprendente fino ad oggi).

Quando ero bambino andavamo in Francia e in un museo in cui andavamo, ricordo di aver trovato un display che ti mostrava come scrivere programmi per computer. Il linguaggio era una sorta di variante BASIC e lo ricordo distintamente usando POUR invece di FOR, e così via. Avevo 7 anni e avevo appena imparato il BASIC, e mi è sembrato del tutto naturale che i francesi avessero il loro dialetto come questo !!

Immagino possa essere stato LSE quello che ho visto?

Il linguaggio di scripting di Filemaker è localizzato. Gli script (e i dati!) Sono archiviati in una forma terribile "sorta canonica".

Quindi, se scrivi uno script nella versione americana e poi lo apri nella versione francese, tutte le parole chiave e i nomi delle funzioni incorporate saranno in francese. Ma perché non funziona ?! Aha! La versione francese usa "," come punto decimale, e quindi per evitare ambiguità usa ";" per separare gli argomenti delle funzioni - dove la versione americana usa "." e "," rispettivamente. Questa conversione la devi fare da solo.

Quindi lavori attraverso l'interfaccia di modifica degli script incredibilmente pessima (non puoi scrivere script come file di testo) per sistemare tutte queste cose. Corre! Grande! I risultati sono tutti sbagliati! Oh no! Aha! La data Jan-7-2004 che hai inserito nella versione americana viene interpretata come July-1-2004 - apparentemente le date non sono solo visualizzate ma memorizzate in ordine dipendente dalla località. Ti sto prendendo in giro ? No.

[Nota: Filemaker 8 e 9 potrebbero essere sani - ho sempre lavorato solo con 3 - 7.]

La tua domanda è interessante per quanto riguarda Perl perché la sua sintassi è progettata per seguire il linguaggio naturale (inglese). Mi chiedo se ciò renda più difficile per chi non parla inglese ...

Naturalmente, Perl e Perlers si rifiutano di giocare secondo le regole convenzionali. Lo scienziato pazzo Damian Conway ha scritto il modulo Lingua :: Romana :: Perligata che usa la magia nera dei filtri sorgente per permetterti di scrivere Perl in latino!

Qui in Australia abbiamo ancora bisogno di scrivere il colore come il colore . Tuttavia, trovo fastidioso quando altri sviluppatori (australiani), lavorando a un progetto australiano, decidono che i nomi delle variabili interne devono essere scritti in modo americano.

Sarebbe inutile, IMHO, i18n una sintassi del linguaggio . Ucciderebbe semplicemente qualsiasi tipo di portabilità.

L'unica eccezione sono i linguaggi educativi, come LOGO. Sono stati progettati per facilitare l'apprendimento, quindi la portabilità non è un problema.

Ho letto molto codice, ma il problema è sempre nei nomi e nei commenti delle variabili / metodi, se stanno commentando il loro codice nella loro lingua, usando caratteri speciali di una lingua come il giapponese o il cirillico, siamo nei guai! ma le parole chiave credo che rimarranno in inglese così come sono.

in italiano

se (i < dimensione){
    scegli
        caso 1:
            stampa "ciao"
        mancante:
            stampa "no, grazie"
} altrimenti {
    stampa "sì, grazie"
}

Per confermare le preoccupazioni di qualche poster precedente ho visto un codice Fortran con una macro include per tradurre tutte le parole chiave dall'inglese al francese. Consentitemi di non continuare su questo.

Ho anche dovuto lavorare con un codice contenente simultaneamente identificatori in italiano, tedesco, inglese e francese, non solo perché è stato sviluppato in molti luoghi diversi, ma anche perché lo sviluppatore principale ha pensato che fosse divertente e lo ha aiutato a non duplicare i nomi degli identificatori ( ovviamente, con una routine lunga 2000 righe ....)

Penso che WordBasic sia stato localizzato. WordBasic è stato utilizzato per scrivere macro in Word prima di utilizzare VBA.

Se lo ricordo correttamente, solo WordBasic scritto nella versione inglese verrebbe eseguito su tutte le versioni localizzate. Se scrivessi una versione olandese, potresti eseguirla solo su una parola olandese.