Codificação em outras línguas (faladas)

Isso é algo que sempre me perguntei, e não consigo encontrar qualquer menção sobre isso em qualquer lugar online. Quando uma loja, digamos do Japão, escreve código, eu seria capaz de ler em inglês? Ou as linguagens, como C, PHP, qualquer coisa, têm traduções para o japonês que eles escrevem?

Acho que o que estou perguntando é se cada programador no mundo sabe inglês o suficiente para usar exatamente as mesmas palavras reservadas que eu?

Este código:

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

exibir exatamente o mesmo que estou vendo agora em inglês, ou alguma outra pessoa que não fala inglês veria as palavras "if", "switch", "case", "default", "print" e " else "em sua língua nativa?

EDIT - sim, isso é sério. Eu não sabia se diferentes localizações de um idioma têm palavras-chave diferentes. ou se existem localizações diferentes.

Se eu entendi bem, a questão na verdade é: "cada programador do mundo sabe inglês o suficiente para usar exatamente as mesmas palavras reservadas que eu?"

Bem ... Inglês não é o assunto aqui, mas palavras reservadas da linguagem de programação. Quer dizer, quando comecei há cerca de 10 anos, não tinha nenhuma ideia de inglês, e ainda era capaz de programar coisas simples aprendendo a linguagem de programação, mesmo quando não sabia o que significavam (em inglês). Na verdade, isso me ajudou a aprender inglês.

Por exemplo. Eu sei fazer uma "iteração" (iteração é claro) eu tive que escrever:

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

Para mim, o "para", o ";" e o "++" onde palavras ou símbolos estrangeiros simples. Mais tarde eu aprendi que "para" significava "para" e "while" significava "mientras" etc. mas nesse meio tempo eu não precisava saber inglês, mas no meu caso o que eu precisava era saber "C".

Claro que quando precisei aprender mais coisas, tive que aprender inglês, pois a documentação é escrita nessa língua.

Portanto, a resposta é: Não, não vejo se, enquanto, para etc. na minha língua nativa. Eu os vejo em inglês, mas eles não significam para mim qualquer outra coisa que significam para a linguagem de programação.

É como a instrução switch em bash: case .. esac. O que é "esac" ... para mim, o final da instrução switch no bash.

Acho que é o que chamamos de "abstração"

Na linguagem Java, alguns métodos devem ser nomeados (pelo menos parcialmente) usando a linguagem inglesa por causa da convenção JavaBeans.

Essa convenção requer que uma propriedade X seja estabelecida por meio de um par de métodos getX () e setX (). Aqui no Canadá francês, onde alguns desenvolvedores são obrigados a codificar na língua francesa, isso leva à seguinte farsa:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

Estou tendo problemas para encontrar referências, mas me lembro de três histórias.

Um hacker Lisp defende funções sem sentido como "cdr" e "carro" comparando-as com a programação em sua linguagem não nativa: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171. html

Quando Yukihiro Matsumoto ("Matz") começou a desenvolver Ruby, ele usou palavras-chave em inglês , embora estivesse escrevendo toda a documentação em japonês! . Não houve documentação em inglês para Ruby por alguns anos, e muito poucos americanos usando a linguagem. Mas agora é uma língua de classe mundial, e o fato de ter nascido no Japão é apenas de interesse histórico. Se o idioma estivesse usando palavras-chave em hiragana, teria muito mais dificuldade para ganhar popularidade.

Eu li um ensaio uma vez - talvez outra pessoa possa encontrá-lo, o Google não ajuda hoje - que sugeria que a tradução de palavras-chave foi equivocada porque as palavras não são realmente em inglês - são jargões. Não apenas (para usar os exemplos acima) para e pour não têm exatamente o significado exato que for tem em inglês, para não-programadores a frase "for loop" é um jargão. Até mesmo os americanos precisam aprender um novo significado. Portanto, traduzir o significado superficial das palavras para outro idioma é mais como fazer um trocadilho entre línguas do que realmente ser útil.

Eu realmente não pensei muito sobre programação em japonês antes, mas vamos lá, usando o exemplo de código da pergunta.

Usando apenas as declarações de idioma em japonês com as variáveis ​​em inglês:

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

Como muitas pessoas já apontaram, na maioria das linguagens de programação você só precisa aprender algumas palavras-chave, então não importa muito se elas estão em inglês (ou em uma linguagem diferente da sua, por falar nisso). É apenas um símbolo que você associa a alguma construção. Por exemplo, em VB você tem "ENTÃO", que em muitas linguagens de estilo C seria "{" e não faz uma grande diferença na legibilidade (bem, pelo menos é como eu vejo, sendo um não-inglês falante nativo).

Mas onde as coisas às vezes podem ficar complicadas e onde a escolha da linguagem (natural) é importante é na nomeação de identificadores. Se os nomes das variáveis, funções, classes, etc, não têm um nome significativo para você por causa da barreira do idioma, seguir até mesmo o código mais simples pode ser um tanto desafiador.

Lembro-me de que uma vez alguém me deu um pequeno trecho de Actionscript tirado de algum blog. Os nomes estavam em alemão e, como não falo uma palavra desse idioma, as coisas também poderiam ser chamadas de var_123, var_562 ou func_333 (e provavelmente teria sido mais fácil para mim lembrar os nomes ou pelo menos ter um chance de soletrá-los corretamente sem copiar e colar). Como este era um snippet curto e independente, usei um tradutor online para dar a esses vars e funções nomes significativos em minha língua nativa (espanhol) e, depois disso, tudo ficou claro. A questão é que o código era realmente simples, mas só consegui entendê-lo sem muito esforço extra (desnecessário) justamente quando superei a barreira do idioma.

Desde então, passei a usar o inglês para nomear identificadores. Quer você goste ou não, é o "koine" para programação, engenharia e material técnico em geral. A maioria das APIs é escrita em inglês, assim como a maior parte da documentação (e provavelmente os melhores recursos que você pode encontrar estão em inglês também). Como um bom aparte, ele mantém seu código mais coerente com o código com o qual você provavelmente estará interagindo, e eu acho que tende a ser mais compacto e sucinto do que outras linguagens como o espanhol (que de outra forma seria minha escolha natural).

Claro, se você não consegue entender pelo menos um pouco de inglês, o problema continua o mesmo, então não é uma solução perfeita. Mas, dado um número de desenvolvedores de muitos países diferentes, as chances são de que o idioma comum para eles se comunicarem (por meio de código e, claro, outros meios) seja o inglês. Portanto, escolher o inglês talvez seja a melhor opção, mesmo que não seja a solução perfeita para esse problema.

A linguagem de programação define palavras-chave e nomes de classe padrão, e é prática recomendada fornecer tipos, variáveis ​​e funções definidas pelo usuário também nomes em inglês (como um falante não nativo, posso dizer ;-).

Então, sim, se tudo estiver bem, você poderá ler o código.

No entanto, linguagens como Java e Perl permitem o conjunto Unicode completo para identificadores, portanto, se alguém escrever seus nomes de classe em Kanji, provavelmente você terá um problema.

Atualização: Para Perl, há um módulo de piadas que permite que você escreva Perl em latim. Mas é só isso, uma piada. Ninguém usa coisas assim a sério.

Segunda atualização: A ideia de linguagens de programação localizadas não é tão ridícula. O idioma da macro do Excel é localizado, mas felizmente é armazenado em um idioma canônico (inglês) no arquivo, então a localização é apenas uma camada acima do normal. Essas coisas só fazem sentido para pequenos "programas", pois para programas "reais" torna-se difícil manter.

Na verdade, existem são algumas linguagens de programação baseadas em não-Inglês (Wikipedia)

Sou norueguês, mas sempre usei o inglês para todo o código, exceto a saída (ignorando alguns códigos idiotas da escola). Na verdade, geralmente escrevo tudo em inglês e depois traduzo para minha língua nativa, usando gettext (ou algo assim).

Sou britânico e um problema que frequentemente encontramos é o conflito ortográfico americano / britânico. Isso geralmente ocorre com termos relacionados à programação, como Initialise () ou Initialize (), Analyze () ou Analyze () etc. Isso pode (tem) levar a problemas ao tentar substituir métodos e às vezes é difícil de detectar.

Como a estrutura (em nosso caso C #) foi projetada por americanos, descobrimos que é melhor ser consistente e usar grafias americanas. Nós até adotamos cores.

Temos uma mistura de nacionalidades em nossas equipes de desenvolvimento e a maioria dos não-britânicos tende naturalmente para a grafia americana.

O AppleScript já estava disponível em dialetos francês e japonês. Não sei por que foi retirado.

Levando isso para o próximo nível, que tal ser capaz de substituir símbolos?

Depois de ver linguagens como Brainf ** k e espaço em branco , pensei em fazer uma linguagem como esta: seria idêntica a C, exceto que você usa chaves de fechamento para abrir, chaves de abertura para fechar, trocar os significados de + e -, * e / ,; e:,> e <, etc.

O conceito nada mais é do que um compilador C alterado engenhosamente. Mas, como pensar em palavras-chave de maneira diferente, ele desafia você a repensar algumas suposições básicas, caso você nunca tenha pensado nessas coisas antes. Ex:

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

Estou em uma equipe francesa desenvolvendo um sistema de software em C #. Apesar do fato de que as palavras-chave da linguagem de programação são ostensivamente em inglês, imagino que você teria grande dificuldade em ler o código, pois todos os nomes de funções, variáveis, comentários de código, tabelas e colunas de banco de dados, especificações técnicas, protocolos e assim por diante, estão todos em Francês, incluindo aqueles adoráveis ​​caracteres acentuados ç, é, è, ù, etc. Não tenho certeza se o sistema seria executado em outro lugar devido a bugs de localização, como depender da vírgula para ser o separador decimal padrão.

Caso contrário, WinDev é uma plataforma de programação popular na França, e sua linguagem de programação WLanguage tem palavras-chave em francês ou inglês, veja um exemplo aqui: link text

O único idioma que vi localizado é o Excel com suas macros. Se você tentar somar uma coluna usando uma versão italiana do Office, você terá que escrever SOMMA(A1:A10)e não SUM. Isso é uma vergonha.

A propósito, só porque é divertido, veja como seu código deve ficar com palavras-chave italianas:

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

Eu vi o VBA traduzido em comandos semelhantes ao espanhol. é uma das coisas mais feias que já vi. Eu teria vergonha de ter algo assim no meu computador.

PD: Acontece que eu acho que o espanhol é uma língua muito melhor do que o inglês; mas traduzir é ERRADO

Bem, como outros apontaram, as palavras-chave e as chamadas de sistema provavelmente permaneceriam em inglês.

No entanto, entender as palavras-chave da linguagem é apenas uma pequena parte para entender o código. Nomes de variáveis, nomes de funções e comentários correm o risco de estar na língua nativa do autor.

Edit : Acabei de voltar à minha juventude, onde fui nas tabelas de mapeamento do meu BASIC embutido no TRS-80 para mudar as palavras-chave para o francês. Eu poderia alterar todas as palavras-chave, mas não poderia aumentar nenhuma delas. Feito para programas engraçados.

Não tire sarro disso. Alguns anos atrás, a Microsoft anunciou G # (German Sharp) - C # com palavras-chave em alemão e API. Claro, era uma piada do Dia da Mentira, mas todo o site sobre isso parecia tão real e profissional (e estava em microsoft.com). Assustador.

No trabalho, usamos dois sistemas de barramento de campo, ambos desenvolvidos em países de língua alemã, que têm uma mistura assustadora de alemão e inglês para identificadores, incluindo alguns falsos amigos adoráveis. É uma bagunça.

Não, palavras-chave e identificadores em inglês são adequados. Embora alguns possam discutir se deveria ser Cor ou Cor :)

Em vários projetos VBA em que trabalhei (sim, muito no início da minha carreira), tivemos que detectar a versão do Office que foi instalada na máquina do usuário e alterar as fórmulas usadas nas planilhas de acordo.

Como eu programo em português, "SUM" teria que ser traduzido para "SOMA" e assim por diante. Eu simplesmente não consigo imaginar o trabalho necessário para fazer isso acontecer em vários idiomas. Alguém mais sofreu com este problema?

Existem alguns idiomas que têm palavras-chave traduzidas. Fórmulas do Excel, por exemplo. Se você escrever alguns cálculos em uma planilha, isso será feito no seu idioma.

Felizmente, esta não é uma prática geral, e até mesmo quem não fala inglês como eu agradeço a Deus por haver uma linguagem padrão para palavras-chave:

• é mais fácil compartilhar seu trabalho.
• evita que a documentação se torne um pesadelo maior do que já é.
• As palavras e frases em inglês são geralmente curtas e sintaticamente pragmáticas. Na literatura, as línguas latinas são muito mais bonitas, mas para assuntos técnicos, o inglês é demais.

E onde parar? Você consegue imaginar um C em grego antigo?

As palavras-chave devem ficar em um idioma e, bem, começou com o inglês, deixe ficar assim. Isso poderia ter sido pior (idioma asiático?). E então temos que escrever métodos e comentários em inglês. Ok, mais trabalho para nós, mas pelo menos a base de código internacional permanece congruente.

No entanto, há um caso em que usar nomes e comentários de métodos em idiomas nativos pode ser uma boa prática: em um país do terceiro mundo. Vou para o Senegal daqui a alguns meses para gerenciar um projeto Django. O Senegal tem uma taxa de analfabetização enorme e, portanto, já é ótimo que eles gastem energia para melhorar seus conhecimentos de programação. Francês é a língua nativa aqui, então seria ineficiente forçá-los a aprender computação E uma nova língua ao mesmo tempo.

BTW, esse seria o seu código com palavras-chave francesas:

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

Não que a tradução das palavras-chave não tenha nada a ver com a tradução das strings. Claro, temos "oi, aí" traduzido em nosso idioma. Os programadores europeus tendem até a usar o I18N muito mais do que os americanos, mas seu serviço pode atingir um público mais amplo.

De um modo geral, a maioria dos programadores se adapta ao inglês. Aprendi a programar quando tinha 7 anos e só falava hebraico (que é da direita para a esquerda) e não sabia inglês, o que tornou a experiência fascinante.

O problema que você normalmente obteria é com documentação, variáveis ​​e nomes de funções. Eu vi minha parcela de variáveis ​​em outras línguas usando o alfabeto inglês.

O único idioma que conheço que foi traduzido foi o bom e velho logo (ainda incrível até hoje).

Quando eu era criança, fomos para a França e, em um museu que frequentamos, lembro-me de encontrar uma vitrine que mostrava como escrever programas de computador. A linguagem era algum tipo de variante do BASIC e eu me lembro claramente dela usando POUR em vez de FOR, e assim por diante. Eu tinha 7 anos de idade e tinha acabado de aprender BASIC, e parecia completamente natural para mim que os franceses tivessem seu próprio dialeto assim!

Eu acho que pode ter sido o LSE que eu vi.

A linguagem de script do Filemaker é localizada. Os scripts (e dados!) São armazenados em uma terrível forma "canônica".

Portanto, se você escrever um script na versão americana e abri-lo na versão francesa, todas as palavras-chave e nomes de funções incorporadas estarão em francês. Mas por que não funciona ?! Aha! A versão francesa usa "," como ponto decimal e, portanto, para evitar ambigüidade, usa ";" para separar os argumentos da função - onde a versão americana usa "." e "," respectivamente. Essa conversão você tem que fazer sozinho.

Então você trabalha com a interface de edição de script incrivelmente ruim (você não pode escrever scripts como arquivos de texto) para consertar todas essas coisas. Corre! Ótimo! Os resultados estão todos errados! Ah não! Aha! A data de 7 de janeiro de 2004 que você inseriu na versão americana está sendo interpretada como 1 de julho de 2004 - aparentemente, as datas não são apenas exibidas, mas armazenadas em ordem dependente do local. Estou brincando com você ? Não.

[Nota: Filemaker 8 e 9 podem ser lógicos - eu só trabalhei com 3 - 7.]

Sua pergunta é interessante com relação ao Perl porque sua sintaxe foi projetada para seguir a linguagem natural (inglês). Eu me pergunto se isso torna mais difícil para quem não fala inglês ...

Claro, Perl e Perlers se recusam a jogar pelas regras convencionais. O cientista maluco Damian Conway escreveu o módulo Lingua :: Romana :: Perligata que usa a magia negra dos filtros de origem para permitir que você escreva Perl em latim!

Aqui na Austrália ainda precisamos soletrar cor como cor . No entanto, acho irritante quando outros desenvolvedores (australianos), trabalhando em um projeto australiano, decidem que os nomes das variáveis ​​internas precisam ser escritos da maneira americana.

Seria inútil, IMHO, i18n uma sintaxe de linguagem . Isso acabaria com qualquer tipo de portabilidade.

A única exceção são as linguagens educacionais, como LOGO. Eles foram projetados para facilitar o aprendizado, portanto a portabilidade não é um problema.

Eu leio muito código, mas o problema sempre está em nomes de variáveis ​​/ métodos e comentários, se eles estiverem comentando seu código em sua própria linguagem, usando caracteres especiais de uma linguagem como japonês ou cirílico, estamos com problemas! mas as palavras-chave, acho que permanecerão em inglês como estão.

em italiano

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

Para confirmar as preocupações de algum autor anterior, vi um código Fortran com uma macro incluir para traduzir todas as palavras-chave do inglês para o francês. Permita-me não continuar com isso.

Também tive que trabalhar com um código simultaneamente contendo identificadores em italiano, alemão, inglês e francês, não só porque foi desenvolvido em muitos lugares diferentes, mas também porque o desenvolvedor principal achou divertido e o ajudou a não duplicar nomes de identificadores ( claro, com uma rotina de 2.000 linhas ...)

Acho que o WordBasic foi localizado. WordBasic foi usado para escrever macros para no Word antes de usar o VBA.

Se bem me lembro, apenas o WordBasic escrito na versão em inglês seria executado em todas as versões localizadas. Se você fosse escrever uma versão em holandês, só poderia executá-la em uma palavra em holandês.