Il presente e il futuro della programmazione nelle lingue locali [chiuso]

Ci sono stati tentativi di introdurre sapori linguistici di programmazione tradotti in una lingua parlata locale in tutto il mondo. Tuttavia non sono mai venuti per essere più che esperimenti.

Alcune lingue orientate al cliente sono localizzate come la lingua delle macro di Excel. Ma questi sono veramente orientati all'utente finale.

I programmatori avranno sempre bisogno di qualcosa di universalmente compreso. Per ora è inglese.

Will we ever be able to program in a language other than English?

Improbabile. Per una semplice ragione, non vi è alcun vantaggio. Il linguaggio di programmazione stesso, non c'è così tanto contenuto linguistico all'interno, quindi è possibile per tutti imparare alcune parole chiave in inglese.

Ma il resto deve essere compreso in tutto il mondo in modo non ambiguo. Output del compilatore, messaggi di errore, documentazione per strumenti e librerie. È importante per la condivisione e lo scambio di conoscenze a livello mondiale.

Inoltre, ai tempi della globalizzazione e dei team distribuiti, deve esserci l'unica lingua per i commenti nel codice, nella documentazione e nella collaborazione. Articoli tecnologici, blog, libri. Conferenze internazionali Le persone devono capirsi l'un l'altro altrimenti le cose si complicano inutilmente.

In effetti, la programmazione è già "indipendente dalla lingua" (suppongo che tu volessi dire "linguaggio naturale ..."). Vedete dalle 3-4mila lingue parlate oggi sulla Terra, dipende solo da una delle principali lingue naturali, quella inglese.

Immagina come sarebbe se le dozzine dei principali linguaggi di programmazione in uso fossero basati su swahili, francesi, svedesi, russi, slovacchi, bosniaci, ungheresi, spagnoli, catalani ...?

Come qualcuno potrebbe non capire queste lingue (tutti sono certamente molto più difficili dell'inglese in grammatica) essere in grado di fare anche un avanzamento di carriera modesto, o semplicemente mantenere un sé aggiornato. L'inglese oggi è ciò che il latino era 2000 anni fa. In realtà oserei dire che offre la promessa dell'esperanto senza il fastidio di reinventare il whe .. err .. il linguaggio.

Rispondi alla parte filosofica della tua domanda:

Tu pensi e programmi in categorie e idee astratte, né in inglese, né in Java o C ++. Tutti questi sono solo mediatori. L'inglese, come Jas mentioined è la sua risposta, è il più conveniente perché la maggior parte dei programmatori ne parla o lo capisce.

Rispondi alla parte tecnica della tua domanda:

Il compilatore classico è costituito da frontend specifico per la lingua, ottimizzatore indipendente dalla lingua e backend specifico per l'hardware. Una volta creato un frontend coerente ed efficiente per il linguaggio naturale (per esempio per GCC), il compilatore sarà in grado di generare il codice. La neuance è, una volta che questo parser è stato sviluppato, i programmatori non saranno più necessari. Solo manager (per gestire i computer). Ma la complessità del dominio del riconoscimento della lingua naturale è così alta che spero che il problema non possa essere risolto in tempi brevi.

L'inglese è la lingua franca della programmazione, come il latino per i medici.

Considera perché vuoi parole chiave alternative e poi considera ciò che dovrai rinunciare.

Penso che sia molto difficile programmare senza le parole chiave / functionnames in inglese e anche senza i concetti che portano. Perché molti dei concetti sono appresi dalle risorse inglesi. Trovare una traduzione non renderà le cose più facili, perché devi comunque imparare i concetti. Quando lavoravo con un gusto locale di Excel, non potevo ad esempio abituarmi a qualcosa di diverso da "se". Perché "se" è in tutti i linguaggi di programmazione e ormai è cablato nel mio cervello. ('Se' è una versione semplicistica, ma va all'allocazione di memoria dei cicli cpu - quelli sono termini specifici del dominio quindi sono nuovi per chiunque non conosca il dominio, e quelli che sanno che conosceranno comunque i termini inglesi. )

Ma non penso che tu stia solo programmando principi astratti. Quando scrivi applicazioni o modelli di dati, ti relazioni al "mondo reale", quindi è logico scegliere nomi che descrivono ciò a cui si riferiscono, e talvolta questi concetti sono utili solo nella tua lingua perché si riferiscono (ad esempio ) ai termini legali.

Quindi un punto o un altro, le lingue si incroceranno.

Certamente potrebbe, ma richiederebbe un cambiamento nel modo in cui scriviamo i programmi. Attualmente, siamo uniti a un modello di sviluppo del software "scrivi file di testo, dai il testo al computer". Ogni sistema di programmazione funziona così e questo rende molto difficile renderlo indipendente dalla lingua. Non penso che sia l'unico modo, però.

Molto tempo fa, su piccole macchine, non sempre funzionava in questo modo. Su computer con memoria molto bassa (si pensi al Commodore PET da 16K) non era ragionevole memorizzare l'intero testo in memoria di un programma. Anche un banale programma BASIC avrebbe esaurito la memoria se "GOTO" richiedesse 4 byte. Quindi questi sistemi hanno tokenizzato l'input mentre hai digitato. Hai digitato "GOTO" e questo è stato immediatamente tradotto in un token. Quando hai elencato il tuo programma e i token sono stati convertiti in parole chiave leggibili dall'uomo.

In un sistema del genere, la creazione di una lingua alternativa sarebbe banale. Gli oratori inglesi vedrebbero "GOTO" e gli oratori giapponesi vedrebbero "行 く" e poiché la conversione avvenne al momento della creazione / visualizzazione del codice, gli oratori inglesi e giapponesi potevano condividere la fonte. La fonte stessa sarebbe stata tokenizzata. Non vedo alcun motivo per cui non potresti farlo con i linguaggi moderni.

Quello che richiederebbe sarebbe quello di infrangere il modello "file di testo come codice sorgente". Il linguaggio dovrebbe essere completamente integrato nel processo di modifica. In questo mondo immaginario, quando si attiva l'editor e si carica, ad esempio, il sorgente Python, tutti i token indipendenti dalla lingua nel file vengono tradotti nelle parole chiave delle impostazioni internazionali della lingua. Quando digiti le parole chiave, queste vengono automaticamente tradotte in token. In altre parole, non stai modificando direttamente il testo ma piuttosto creando il file tokenizzato. L'interprete verrebbe quindi scritto per operare su token anziché su testo. Probabilmente renderebbe anche l'interpretazione / compilazione un po 'più veloce dato che tutto sarebbe tokenizzato nella fase di editing.

Questo è tutto possibile e avrebbe alcuni vantaggi. Quello che perdi è la capacità di leggere l'origine usando editor di testo arbitrari. Richiederebbe editor di linguaggio. Quando ero al college, volevo costruire un sistema come questo, ma la vita reale si intrometteva.

Naturalmente, questo non risolve tutto, che è probabilmente il motivo per cui non è mai stato fatto. Le parole chiave potrebbero essere indipendenti dal linguaggio, ma gli identificatori e le costanti non lo sarebbero. Potrebbe non essere di grande aiuto se il codice fosse simile a questo:

for(unsigned int 人=人リスト.begin();人!=.end();人++)

Questo probabilmente non influenza solo il codice scritto dall'utente ma anche le librerie. In quanto sopra, begin e end non sono parole chiave della lingua, ma metodi di libreria. Per risolvere ciò, avresti bisogno della traduzione automatica e non siamo ancora arrivati. Come oratore inglese che a volte ha letto il codice C ++ scritto in Giappone, posso dire che il fatto che le parole chiave della lingua siano in inglese aiuta solo marginalmente.