Por que não existem mais linguagens de programação de linguagem multi natural?

Existem linguagens de programação disponíveis e extensíveis em mais de uma linguagem natural?

Por exemplo, uma versão em inglês com um do..whileloop, uma versão em espanhol com um hacer..mientasloop, uma versão em francês com a faire..pendante uma versão em holandês com a doe..terwijl.

A única 'linguagem de programação' que consigo pensar nesse tipo de implementador é o Microsoft VBA.

Pergunta bônus: Por que existem tão poucas linguagens de programação que vêm em várias linguagens?

Os nomes das funções nas fórmulas do Excel são localizados, onde você pode usar o texto em inglês ou o equivalente local.

Isso levou a inúmeras ocorrências de quebra de planilhas à medida que você se move pelas regiões e idiomas do usuário. Também dificulta a busca de informações sobre a funcionalidade, pois a documentação local está localizada e não menciona os nomes das coisas em inglês, e, inversamente, solicitar SO com seus nomes locais é essencialmente sem sentido para a maioria dos leitores.

As palavras-chave devem ser vistas como apelidos opacos, que acabam alinhando-se com o significado das palavras em inglês usadas para escrevê-las. Existem muitos programadores que não falam inglês e não sabem o que significa metade das palavras-chave.

No século anterior, notadamente nas décadas de 1960 e 1970, foram algumas linguagens de programação que não eram do inglês. Na França, tínhamos PAF e LSE com palavras-chave de aparência francesa. A Segunda Guerra Mundial teve o Plankalküll da K.Zuze. Na União Soviética, A.Ershov projetou alguns idiomas (por exemplo, Rapira ) com palavras-chave em russo. O IIRC PAF (projetado e implementado por meu falecido pai quando eu era bebê - no início dos anos 1960) também poderia ser vendido com palavras-chave de aparência inglesa (ou russa ou alemã). E alguns idiomas, por exemplo, APL , não tinham nenhuma palavra-chave. Outras línguas ( PL / I ) não tinham reservadopalavras-chave. E você pode redefinir palavras-chave com técnicas de pré-processador (por exemplo, hoje, em C, #define si ife #define sinon elsepara estudantes franceses ....; truques semelhantes baseados em macro são possíveis no PL / I ou mesmo Common Lisp).

Mas TIfoi desenvolvido principalmente em um país de língua inglesa (os EUA). Portanto, as linguagens de programação e suas implementações tinham especificação e documentação em inglês e palavras-chave em inglês. Portanto, todo desenvolvedor precisa ser capaz de ler inglês técnico, e não há valor agregado para "localizar" a linguagem de programação (e, mesmo, isso dificulta o uso de outros softwares, conforme respondido em outros lugares). O domínio técnico e econômico atual dos países de língua inglesa exige que todos os engenheiros leiam o inglês hoje (tenho certeza que até os engenheiros de software norte-coreanos, chineses ou iranianos são capazes de ler a documentação em inglês e ler o código com palavras-chave e identificadores em inglês) . Portanto, não há mais valor agregado suficiente para "localizar" uma linguagem de programação (exceto, talvez, para ensinar programação elementar para crianças do ensino médio).

Além disso, o inglês possui muitas palavras - chave curtas (compare sinonem francês para elseinglês ou mettreem francês para putinglês), portanto, há uma pequena vantagem em usar palavras-chave em inglês ....

^{Talvez em um século, a China possa se tornar o país de TI dominante e alguma linguagem de programação baseada na China possa florescer. Não sabemos o que aconteceria então ....}

PS. O domínio do inglês não é específico para a TI. Mesmo que o Reino Unido abandone a União Europeia - o cenário do Brexit - , o idioma oficial da CE permanecerá em inglês (o que não será o idioma de nenhum país membro da UE) e os projetos de TIC do H2020 serão escritos em inglês.

Existem boas razões para que as linguagens de programação profissional não sejam traduzidas.

1) Esforço: Seria uma tarefa enorme traduzir uma linguagem moderna. Pegue o Java - seria uma tarefa pequena traduzir as 50 palavras-chave, aproximadamente, mas você também precisaria traduzir a biblioteca padrão completa, que consiste em milhares de classes e métodos e documentação relacionada.

2) Compatibilidade: Mesmo que a biblioteca de idiomas e padrões base tenha sido traduzida, você ainda não poderá usar bibliotecas e códigos de terceiros que não foram traduzidos. Bibliotecas e códigos de terceiros são uma parte importante do que torna uma linguagem atraente e útil. Com as versões traduzidas, cada idioma teria que iniciar o ecossistema para cada tradução do zero. Todo mundo ficaria pior.

3) Os programadores precisam saber inglês de qualquer maneira. Muitos padrões como HTTP, CSS e HTML usam o idioma inglês de qualquer maneira para identificadores. Eles não podem ser traduzidos, pois as palavras estão inseridas no padrão.

Como os programadores precisam saber inglês de qualquer maneira, haveria apenas desvantagens e nenhum benefício em criar versões traduzidas das linguagens de programação.

Dito isto, para idiomas destinados a programadores casuais, em oposição a programadores profissionais, pode fazer sentido criar versões traduzidas. É o caso do VBA e acredito que o AppleScript também existia nas versões traduzidas.

Eu não conheço outras línguas, exceto, possivelmente, uma versão esotérica realmente antiga do BASIC, que costumava ter muitos favores estranhos, então vou me ater à pergunta bônus: por que existem tão poucas linguagens de programação traduzidas:

Acredito que é simplesmente uma complexidade adicional que os implementadores de compiladores e bibliotecas não veem uma grande necessidade. Aqui estão algumas razões que contribuem na minha opinião.

• Você limitará o público-alvo do seu código se não ficar com um idioma "universal". Claro, nem todo mundo sabe inglês, mas o mesmo vale para todos os idiomas.
• Palavras-chave com uma única palavra não são necessariamente uma única palavra em todos os idiomas, o que complica a análise. Eu nunca verifiquei, mas posso imaginar que exista uma quantidade razoável de maiúsculas e minúsculas para lidar com o tipo de várias palavras do c ++ "long long".
• Se você começar a traduzir palavras-chave, também considerará localidades e como os números são formatados? Vírgula versus período como um separador decimal, por exemplo. Ou exige que os substantivos alemães sejam capitalizados?
• A grande maioria do texto em um determinado programa são variáveis, métodos e nomes de classes, sem mencionar comentários. Embora certamente existam bibliotecas escritas em outros idiomas, ter que manter a tradução do código fonte de todas as bibliotecas para atender a todos os usuários seria um grande fardo para a maioria dos desenvolvedores, sem mencionar a complexidade adicional nas discussões sobre esse código.
• Os compiladores precisariam entender todas as linguagens implementadas. Talvez até vários idiomas no mesmo arquivo. Um pequeno feito para um computador com certeza, mas um trabalho extra, no entanto. Talvez você acabe tendo que lidar com a mesma palavra-chave, significando coisas diferentes em idiomas diferentes ou termos simplesmente ambíguos demais para ler bem.
• (ok, opinativo) Certamente, a maioria das pessoas que teve que lidar com documentos do MS Office programados e formatados em idiomas diferentes descartará a ideia por não valer a pena.

Pessoalmente, eu adoraria se pudéssemos trabalhar com o código de uma maneira mais estruturada, em um editor que realmente entendesse o código como o que é, declarações, instruções etc., que nos permitiria fazer muitas coisas interessantes , talvez até ofereça suporte à tradução automática. Para quem quer saber o que estou falando, confira o navegador de imagem e refatoração do Smalltalk e imagine o que poderia se tornar se tivesse mais tração.

Se você tiver um idioma definido em termos de "tags simbólicas" em um nível e "designadores de tags de superfície" no outro, com mapeamentos bem definidos entre eles, certamente seria possível.

Imagine uma linguagem onde você tem a sua if, while... do, switche todas as outras palavras-chave definidas (de alguma forma) no padrão, você poderia enviar bibliotecas do sistema em "formato tokenized", com código local escrito na forma não-tokenized. Em seguida, o compilador real funciona na camada tokenizada e pode ser bom.

No entanto, essa não é a história toda. Você ainda acabaria em situações em que as bibliotecas foram obtidas de algum lugar que não é "a biblioteca padrão", com interface com nomes de funções. E esses não teriam um mapeamento canônico entre os idiomas e exigiriam que a tradução para um idioma local fosse bastante útil, ou você terminaria com uma mistura de idiomas no código-fonte.

Todas as respostas dadas são ótimas, mas darei meus dois centavos de qualquer maneira.

No início da computação, o domínio técnico, cultural e econômico dos EUA e do Reino Unido tornava lógico o que os idiomas de maior sucesso foram criados usando palavras em inglês.

Mais tarde, quando o software se tornou uma indústria , também se tornou um empreendimento global. Não é segredo que existem menos programadores do que o necessário; portanto, empresas de software e, especialmente, empresas que definem o setor, como a IBM, começaram a contratar programadores de todas as partes do mundo: Rússia, Paquistão, Índia, França, Alemanha, Israel, etc. principalmente para programar em idiomas globais de sucesso já existentes, que já eram baseados em inglês e também criavam novos idiomas, e para essa fonte díspar de programadores, o idioma comum já existente era melhor do que qualquer outro idioma.

Mais recentemente, o movimento de código aberto e software livre tornou a criação de software um empreendimento ainda mais global do que antes. Alguns projetos de software aberto, incluindo algumas plataformas de programação, linguagens e estruturas, são grandes projetos que envolvem centenas de colaboradores.

Que idioma uma pessoa de Israel usaria para colaborar com uma pessoa do Sri Lanka? Provavelmente, eles não falam ou nem leem a língua nativa um do outro. Então o inglês vem em socorro.

Goste ou não, o inglês é a língua dos empreendimentos globais . E não porque a América está pressionando, mas porque o mundo está pressionando.

Parafraseando Jay Walker :

Sua língua nativa é a que você mais usa todos os dias e sempre estará no centro do seu coração e do seu cérebro, mas com o inglês você faz parte de uma conversa mais ampla.

Veja o vídeo, "English Mania" .

Conclusão:

As linguagens de programação que usam linguagens diferentes continuarão a existir e continuarão sendo inventadas (como o Scratch baseado em token gráfico), mas pelo menos no futuro próximo, serão comparativamente poucas.

O inglês também é um idioma "sem sotaque"; também, você não possui caracteres estranhos que precisam de uma codificação diferente do ASCII. Sou italiano e algumas vezes enfrento erros de codificação se usar um layout de teclado italiano ou caracteres acentuados como àèéìòù. Além disso, "else" é traduzido em "altrimenti", "in" é "dentro" ... isso seria frustrante.