Qual o sentido de adicionar suporte a identificadores Unicode a várias implementações de idiomas?

Pessoalmente, acho confuso o código de leitura cheio de identificadores Unicode. Na minha opinião, também impede que o código seja facilmente mantido. Sem mencionar todo o esforço necessário para que autores de vários tradutores implementem esse suporte. Também noto constantemente a falta (ou a presença) do suporte a identificadores Unicode nas listas de (des) vantagens de várias implementações de linguagem (como realmente importa). Não entendi: por que tanta atenção?

Quando você pensa em unicode, você pensa em caracteres chineses ou russos, o que faz você pensar em algum código-fonte escrito em russo que você viu na internet e que era inutilizável (a menos que você saiba russo).

Mas se o unicode pode ser usado de maneira errada, isso não significa que seja ruim por si só no código-fonte.

Ao escrever o código para um campo específico, com o Unicode, você pode encurtar o código e torná-lo mais legível . Ao invés de:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

você pode escrever:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

que pode não ser fácil de ler para um desenvolvedor comum, mas ainda assim é fácil para uma pessoa que usa símbolos matemáticos diariamente .

Ou, ao fazer um aplicativo relacionado à fotografia SLR, em vez de:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

você pode substituir a abertura pelo seu símbolo ƒ, com uma escrita mais próxima de ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Isso pode ser inconveniente : ao digitar código C # geral, prefiro escrever:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

ao invés de:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

porque no primeiro caso, o IntelliSense me ajuda a escrever o código inteiro quase sem digitar e, especialmente, sem usar o mouse, enquanto no segundo caso, não tenho idéia de onde encontrar esses símbolos e seria forçado a confiar no mouse para ir e pesquise-os na lista de preenchimento automático.

Dito isto, ainda é útil em alguns casos. currentLens.GetMaximumƒ();do meu exemplo anterior pode contar com o IntelliSense e é tão fácil de digitar quanto GetMaximumAperturemais curto e legível. Além disso, para domínios específicos com muitos símbolos, os atalhos de teclado podem ajudar a digitar os símbolos mais rapidamente do que seus equivalentes literais no código-fonte.

O mesmo, a propósito, se aplica aos comentários. Ninguém quer ler um código cheio de comentários em chinês (a menos que você também saiba bem chinês). Mas em algumas linguagens de programação, os símbolos unicode ainda podem ser úteis. Um exemplo são as notas de rodapé¹.

^{Certainly Eu certamente não gostaria de notas de rodapé no código C #, onde há um conjunto estrito de regras de estilo de como escrever comentários. Por outro lado, no PHP, se há muitas coisas para explicar, mas essas coisas não são muito importantes, por que não colocá-las na parte inferior do arquivo e criar uma nota de rodapé no PHPDoc do método?}

Eu diria:

1. para facilitar não profissionais e iniciantes que aprendem programação (por exemplo, na escola) e não sabem inglês. Eles não escrevem código de produção de qualquer maneira. Já vi muitas vezes códigos como:

   double upsos, baros;
   cin >> upsos >> baros;
   

   Apenas deixe o pobre rapaz escrever no seu idioma:

   double ύψος, βάρος;
   cin >> ύψος >> βάρος;
   

2. Você não gosta?

   class ☎ {
   public:
       ☎(const char*);
       void 📞();
       void 🎧(👨);
   };
   
   ☎ ☏("031415926");
   ☏.🎧(👨("Bob"));
   ofstream f;
   f.💾();
   

Obviamente, todo compilador moderno deve lidar com o código-fonte Unicode hoje. Por exemplo, as constantes de sequência podem precisar conter caracteres Unicode. Mas uma vez que isso seja alcançado, por que não permitir identificadores unicode também? Não é grande coisa, a menos que o código do compilador dependa de caracteres sendo códigos de 7 bits.

Mas o OP está certo: agora é possível que um indiano de língua hindi mantenha código com identificadores russos e comentários em árabe. Que pesadelo para os pobres chineses que devem fazer a verificação da qualidade e que não conseguem ler nenhum dos três alfabetos acima!

Portanto, agora é uma tarefa organizacional garantir que os identificadores e comentários de um programa sejam escritos em um idioma comum. Não posso evitar, mas acho que isso será em inglês ainda por algum tempo.

Eu acho que faz muito sentido permitir caracteres unicode em strings e comentários. E se o lexer e o analisador precisam suportar unicode para isso, o gravador do compilador provavelmente obtém suporte de caracteres unicode nos identificadores gratuitamente, portanto, seria uma limitação arbitrária permitir apenas caracteres ASCII nos identificadores.

Para mim, isso é puramente por razões de marketing . E, adicionalmente, pode tornar nossas vidas mais difíceis.

Os argumentos de marketing

Você conhece essas loucas listas de recursos que a maioria dos idiomas possui? É praticamente inútil em geral, porque está tão longe do idioma que não fornece muita informação específica, mas permite vestir rapidamente tabelas com tiques e cruzamentos e concluir com razão que, como X tem mais tiques do que Y, deve sê melhor.

Bem, o suporte a Unicode para os identificadores é uma dessas linhas. Não importa que, em comparação com o suporte ao Lambda, suporte à programação genérica, etc ... possa não ser muito, as pessoas que desenham as tabelas não se importam com a qualidade de cada linha, apenas com o número delas.

E assim eles podem se gabar: "Ah, com Y você não tem suporte Unicode para seus identificadores! No X, nós temos, então para os alunos é muito mais fácil!"

A falácia da acessibilidade

Infelizmente, o argumento da acessibilidade é falacioso.

Ah, eu entendo que ser capaz de escrever "résultatDuJetDeDé" em vez de "diceThrowResult" (sim, eu sou francês) pode parecer uma vitória a curto prazo ... no entanto, existem desvantagens!

A programação é sobre comunicação

Seu programa não se destina apenas ao compilador (que poderia se importar menos com os identificadores que você usa), mas também a seus colegas. Eles precisam ser capazes de ler e entender.

• a leitura implica a capacidade de visualizar os caracteres que você usou, o Unicode não é tão bem suportado por todas as fontes
• entendê-lo significa confiar em identificadores - a menos que você os complete com comentários longos, mas isso está violando a regra DRY.

É claro que seu colega de classe pode falar o mesmo idioma que você (não é óbvio, eu tive aulas de alemão, espanhol, libanês e chinês), assim como seu professor ... mas suponha que de alguma forma você esteja trabalhando nele em casa e de repente, preciso de ajuda: a Internet é ótima, você pode falar com milhares de milhares de pessoas que conhecem a solução; elas responderão apenas se entenderem sua pergunta. E você precisa entender a resposta deles também.

A programação requer compreensão

A acessibilidade e a iniciação exigem que você se baseie nas bibliotecas para fazer o trabalho pesado: você não deseja reinventar uma camada de E / S para ler / gravar no console em sua primeira tarefa.

• Em qual idioma essas bibliotecas são escritas?
• Em qual idioma essas bibliotecas estão documentadas?

Se você responder o árabe marroquino, ficarei surpreso.

A menos que você confie apenas nas palestras para as quais presta assistência e que apresentem documentação abrangente sobre todos os recursos da biblioteca que você precisará usar (e talvez até mesmo as bibliotecas traduzidas), será necessário aprender um pouco do idioma inglês. Mas então, você provavelmente já fez muito antes de iniciar este curso de programação.

Inglês é...

... a língua franca dos programadores (e da maioria dos cientistas).

Quanto mais cedo a admitirmos, e seguirmos em frente, em vez de lutar contra ela, mais cedo podemos realmente aprender e progredir.

Alguns inevitavelmente se levantam contra isso e defendem corretamente o direito de falar o idioma de sua escolha (o idioma materno geralmente); no entanto, como Babel demonstrou, quanto mais idiomas são usados, mais difícil a comunicação fica.

Ainda...

Sim, como foi discutido várias vezes, algum suporte Unicode (principalmente símbolos) pode facilitar bastante a compreensão de pessoas que precisam traduzir fórmulas matemáticas ou físicas, por exemplo, em código. Existe a desvantagem de alguns símbolos estarem sobrecarregados, mas isso ainda pode ajudar.

Então por que ?

Bem, como dito, não se trata realmente da conveniência do usuário, mas de reivindicações de marketing. Também é fácil demais, já que o analisador já reconhece Unicode para seqüências de caracteres e comentários de qualquer maneira, para que a maioria dê o salto.

E pode haver um benefício para certos usuários.

Mas eu pessoalmente lidarei apenas com o código escrito com identificadores em inglês. Eu não me importo se você precisar da minha ajuda com seu pedaço de código ou se sua biblioteca é simplesmente incrível e eu poderia ganhar muito usando-o: se eu não conseguir entender, terei que ignorá-lo.

Como você digitará identificadores ASCII em um teclado chinês? Algumas palavras-chave de idioma são uma coisa, e ter que fazer todo o código dessa maneira é outra.

Os programadores devem ter o direito e a capacidade de chamar suas variáveis ​​como quiserem. Não é da sua conta em que idioma está.

Se você se sente tão confuso lendo código com identificadores que contêm símbolos de idiomas de outras pessoas, tenho certeza de que você entende exatamente como eles se sentem confusos quando precisam usar identificadores com símbolos do seu idioma.

De acordo com o PEP 3131 - Supporting Non-ASCII Identifiers, datado em 2007, a primeira parte do Rationale declara:

O código Python é escrito por muitas pessoas no mundo que não estão familiarizadas com o idioma inglês, ou mesmo familiarizadas com o sistema de escrita latino. Esses desenvolvedores geralmente desejam definir classes e funções com nomes em seus idiomas nativos, em vez de precisar criar uma tradução (geralmente incorreta) para o inglês do conceito que desejam nomear. Ao usar identificadores em seu idioma nativo, a clareza e a manutenção do código entre os falantes desse idioma aumentam.

Ainda não investiguei outros idiomas, mas deve estar entre os motivos pelos quais eles adicionaram o suporte.

Realmente facilitaria a vida (para alguns de nós) se o compilador não suportasse Unicode. Identificadores da direita para a esquerda são terríveis. Alfabeto romano combinado e identificadores Unicode da direita para a esquerda são ainda piores.

O lado ruim do não suporte é que determinados assistentes da GUI pegam o texto que você coloca para um item e automaticamente o usam como o identificador do item. Então, o que exatamente eles fariam com o texto Unicode nesses itens? Receio que não seja uma resposta fácil.

Os comentários Unicode da direita para a esquerda também podem ser engraçados. Por exemplo, no VS 2010, os comentários XML são exibidos (corretamente) como RTL no código ... mas quando você usa o Intellisense para acessar o identificador em outro lugar no código, a dica de ferramenta exibe a LTR (incorretamente). Melhor, talvez, se não houvesse apoio em primeiro lugar? Novamente, não é uma ligação fácil.