Perché non ci sono più linguaggi di programmazione in più lingue naturali?

I nomi delle funzioni nelle formule di Excel sono localizzati, dove puoi usare sia la dicitura inglese che l'equivalente locale.

Ciò ha portato a innumerevoli occorrenze di fogli di calcolo che si interrompono mentre ci si sposta tra le regioni e le lingue degli utenti. Inoltre, rende difficile la ricerca di informazioni sulla funzionalità, poiché la documentazione locale è localizzata e non menziona i nomi inglesi delle cose e, al contrario, chiedere a SO i propri nomi locali è sostanzialmente privo di significato per la maggior parte dei lettori.

Le parole chiave dovrebbero essere viste come moniker opachi, che capita di tipo allineare con il significato delle parole inglesi usate per scriverle. Ci sono molti programmatori non di lingua inglese là fuori che non sanno cosa significhi la metà delle loro parole chiave.

Nel secolo precedente, in particolare negli anni '60 e '70, sono stati alcuni linguaggi di programmazione non in inglese. In Francia, abbiamo PAF & LSE con parole chiave dall'aspetto francese. WW2 Germania ha Plankalküll di K.Zuze. Nell'Unione Sovietica, A.Ershov ha progettato alcune lingue (ad esempio Rapira ) con parole chiave russe. IIRC PAF (progettato e realizzato dal mio defunto padre quando ero bambino - primi anni '60) poteva anche essere venduto con parole chiave dall'aspetto inglese (o dall'aspetto russo o dall'aspetto tedesco). E alcune lingue, ad es. APL , non ha avuto alcuna parola chiave. Altre lingue ( PL / I ) non avevano parole chiave riservate . E potresti ridefinire le parole chiave con le tecniche del preprocessore (es. Oggi, in C, #define si if e% #define sinon else per studenti francesi ....; simile macro suggerimenti sono possibili in PL / I o anche Common Lisp).

Tuttavia, IT è stato sviluppato principalmente in un paese di lingua inglese (Stati Uniti). Quindi i linguaggi di programmazione e le loro implementazioni avevano specifiche e documentazione inglesi e parole chiave inglesi. Quindi, ogni sviluppatore deve essere in grado di leggere l'inglese tecnico, e non vi è alcun valore aggiunto per "localizzare" il linguaggio di programmazione (e, anche così, rende più difficile l'utilizzo di altri software, come è stato risposto altrove). L'attuale dominio tecnico ed economico dei paesi di lingua inglese richiede a tutti gli ingegneri di leggere l'inglese oggi (sono sicuro che persino gli ingegneri del software nordcoreano, cinese o iraniano sono in grado di leggere la documentazione in inglese e di leggere il codice con parole chiave e identificatori inglesi) . Quindi non c'è più abbastanza valore aggiunto per "localizzare" un linguaggio di programmazione (tranne forse per insegnare la programmazione elementare ai bambini delle scuole superiori).

Inoltre, l'inglese ha molte parole chiave brevi (confronta sinon in francese a else in inglese, o mettre in francese a put in inglese), quindi c'è un piccolo vantaggio nell'utilizzo di parole chiave in inglese ....

^{Forse in un secolo, la Cina potrebbe diventare il paese IT dominante e potrebbe svilupparsi un linguaggio di programmazione basato sulla lingua cinese. Non sappiamo cosa succederebbe allora ....}

PS. Il predominio dell'inglese non è specifico dell'IT. Anche se il Regno Unito lascia l'Unione Europea - lo scenario Brexit -, la lingua ufficiale ufficiale di EC rimarrà inglese (che quindi non sarà la lingua di nessun paese membro dell'UE) e H2020 I progetti ICT sono scritti in inglese.

Ci sono ottime ragioni per cui i linguaggi di programmazione professionale non sono tradotti.

1) Sforzo: sarebbe un compito enorme tradurre un linguaggio moderno. Prendi Java: sarebbe una piccola operazione tradurre 50 parole chiave, ma dovresti anche tradurre la libreria standard completa che consiste di migliaia di classi e metodi e documentazione correlata.

2) Compatibilità: anche se la lingua di base e la libreria degli standard sono state tradotte, non è comunque possibile utilizzare librerie e codici di terze parti che non sono stati tradotti. Le librerie e il codice di terze parti sono una parte importante di ciò che rende un linguaggio attraente e utile. Con le versioni tradotte, ogni lingua dovrebbe avviare l'ecosistema per ogni traduzione da zero. Tutti starebbero peggio.

3) I programmatori devono comunque conoscere l'inglese. Molti standard come HTTP, CSS, HTML usano comunque la lingua inglese per gli identificatori. Questi non possono essere tradotti dal momento che le parole sono cotte nello standard.

Poiché i programmatori devono comunque conoscere l'inglese, ci sarebbero solo inconvenienti e nessun vantaggio per creare versioni tradotte dei linguaggi di programmazione.

Detto questo, per le lingue destinate ai programmatori occasionali e non ai programmatori professionisti, potrebbe essere opportuno creare versioni tradotte. Questo è il caso di VBA e credo che AppleScript esistesse anche nelle versioni tradotte.

Non conosco altre lingue tranne forse una versione esoterica del BASIC molto vecchia, che tendeva a ricevere molti strani favori, quindi mi limiterò alla domanda bonus: perché ci sono così poche programmazioni tradotte lingue:

Credo che sia semplicemente una complessità aggiuntiva a cui il compilatore e gli implementatori di librerie non vedono un grande bisogno. Ecco alcuni motivi che contribuiscono a mio parere.

• Limiterà il pubblico del tuo codice se non rispondi a una lingua "universale". Certo, non tutti sanno l'inglese, ma lo stesso vale per ogni lingua.
• Le parole chiave a parola singola non sono necessariamente singole parole in tutte le lingue che complicano l'analisi. Non ho mai controllato, ma posso immaginare che ci sia una buona dose di involucro speciale per gestire il singolo multi-word di tipo "long long" di c ++.
• Se inizi a tradurre parole chiave, considererai anche le impostazioni locali e in che modo vengono formattati i numeri? Virgola contro periodo come separatore decimale, ad esempio. O richiedere che i nomi tedeschi siano in maiuscolo?
• La stragrande maggioranza del testo in un dato programma sono variabili, metodi e nomi di classi, per non parlare dei commenti. Mentre ci sono certamente librerie scritte in altre lingue, dovendo mantenere le traduzioni del codice sorgente di tutte le librerie per servire tutti gli utenti sarebbe un grosso onere per la maggior parte degli sviluppatori, per non parlare della complessità aggiuntiva nelle discussioni attorno a tale codice.
• I compilatori dovrebbero comprendere tutte le lingue implementate. Forse anche più lingue nello stesso file. Una piccola impresa per un computer sicuramente, ma comunque un lavoro in più. Forse finirai per avere a che fare con la stessa parola chiave che significa cose diverse in lingue diverse o semplicemente essere troppo ambigui per leggere bene.
• (ok, supponente) Sicuramente la maggior parte delle persone che hanno avuto a che fare con documenti di MS Office programmati e formattati in lingue diverse rifiuteranno l'idea che non valga la pena.

Personalmente mi piacerebbe se fossimo in grado di lavorare con il codice in un modo più strutturato, in un editor che in realtà ha capito il codice come quello che è, affermazioni, istruzioni, ecc. che ci permetterebbe di fare molto di cose interessanti, forse supporta anche la traduzione automatica. Chiunque si chieda di cosa stia parlando, controlla l'immagine di Smalltalk e il browser di refactoring, e immagina cosa potrebbe diventare se avesse ottenuto più trazione.

Se hai un linguaggio definito in termini di "tag simbolici" su un livello e "designatori di tag di superficie" sull'altro, con mappature ben definite tra di loro, sarebbe certamente possibile.

Immagina una lingua in cui hai il tuo if , while ... do , switch e tutte le altre parole chiave definite (in qualche modo) nello standard, potresti spedire le librerie di sistema in "formato tokenizzato", con codice locale scritto in forma non tokenizzata. Quindi il vero compilatore funziona sul livello tokenizzato e le cose vanno bene.

Tuttavia, questa non è l'intera storia. Finirai comunque in situazioni in cui hai librerie ottenute da qualche parte che non è "la libreria standard", interfacciata con i nomi di funzioni. E quelli non avrebbero una mappatura canonica tra le lingue e richiederebbero la traduzione in una lingua locale per essere piacevolmente utilizzabili, o si finirà con un miscuglio di lingue nel codice sorgente.

Tutte le risposte date sono ottime risposte, ma darò comunque i miei due centesimi.

All'inizio dell'informatica il dominio tecnico, culturale ed economico degli Stati Uniti e del Regno Unito rendeva logico solo ciò che le lingue di maggior successo venivano create usando parole inglesi.

Successivamente, quando il software è diventato un settore , è diventato anche uno sforzo globale. Non è un segreto che ci siano meno programmatori del necessario, quindi le società di software e specialmente le società che definiscono il settore come IBM, iniziarono ad assumere programmatori da tutte le parti del mondo: Russia, Pakistan, India, Francia, Germania, Israele, ecc. principalmente per programmare in lingue già esistenti di successo a livello globale che erano già in inglese e che creavano anche nuove lingue, e per quella fonte disparata di programmatori la lingua comune già esistente era migliore di qualsiasi altra lingua.

Più di recente il movimento open source e il software libero hanno reso la creazione di software un'impresa ancora più globale di prima. Alcuni progetti software aperti, tra cui alcune piattaforme di programmazione, linguaggi e framework sono progetti enormi che coinvolgono centinaia di collaboratori.

Quale lingua userebbe una persona israeliana per collaborare con una persona dello Sri Lanka? Molto probabilmente non parlano né leggono la lingua nativa l'uno dell'altro. Quindi l'inglese viene in soccorso.

Ti piace o no, l'inglese è la lingua degli sforzi globali . E non perché l'America lo stia spingendo, ma perché il mondo lo sta tirando.

Parafrasando Jay Walker :

Your native tongue is the one you most use everyday, and will always be at the center of your heart and your brain, but with english you are part of a wider conversation.

Guarda il video, "Mania inglese" .

Bottom-line:

I linguaggi di programmazione che utilizzano lingue diverse continueranno ad esistere e continueranno ad essere inventati (come Scratch basato su token grafico), ma almeno nel prossimo futuro saranno relativamente pochi.

L'inglese è anche un linguaggio "accent-free", inoltre non hai caratteri strani che richiedono una codifica diversa da ASCII. Sono italiano e a volte devo affrontare errori di codifica se uso un layout di tastiera italiano o caratteri accentati come àèéìòù. Inoltre "else" è tradotto in "altrimenti", "in" è "dentro" ... sarebbe frustrante.