Por que ainda há distinção entre maiúsculas e minúsculas em algumas linguagens de programação?

Não vejo utilidade para a distinção entre maiúsculas e minúsculas em uma linguagem de programação, além do código ofuscante.

Por que implementar isso em uma linguagem de programação?

Atualizar:

Parece que alguém que você conhece fez uma declaração sobre isso .

Embora a dobra de casos seja bastante trivial em inglês, é muito menos em alguns outros idiomas. Se um programador alemão usa ßum nome de variável, o que você considera o equivalente em maiúsculas? Apenas para sua informação, "ß" é usado apenas em letras minúsculas. OTOH, "ss" é equivalente - você consideraria um compilador obrigado a combiná-los? Quando você entra no Unicode, obtém problemas ainda mais interessantes, como caracteres com marcas diacríticas pré-compostas e diacríticos combinados separados. Então você começa alguns scripts em árabe, com três formas separadas de muitas letras, em vez de apenas duas.

Na idade das trevas, a maioria das linguagens de programação diferenciava maiúsculas de minúsculas quase por necessidade. Por exemplo, Pascal começou nos mainframes dos Dados de Controle, que usavam apenas seis bits por caractere (64 códigos, total). A maioria dessas máquinas usava o conjunto de caracteres "CDC Scientific", que continha apenas caracteres maiúsculos. Você poderia mudar para outros conjuntos de caracteres, mas a maioria tinha letras maiúsculas ou minúsculas, mas não as duas - mas usava os mesmos códigos para ambas. O mesmo aconteceu com os códigos Baudot antigos e considerados padrão nos primeiros dias de COBOL, FORTRAN, BASIC, etc. Quando o hardware mais capaz estava amplamente disponível, a distinção entre maiúsculas e minúsculas era tão arraigada que a alteração era impossível. .

Com o tempo, a real dificuldade de diferenciar maiúsculas de minúsculas tornou-se mais aparente, e os designers de linguagem decidiram ("percebido" provavelmente seria um termo mais preciso) que quando / se as pessoas realmente querem insensibilidade a maiúsculas e minúsculas, é melhor manipulado por ferramentas auxiliares do que na própria linguagem.

Pelo menos na IMO, o compilador deve receber a entrada exatamente como apresentado, e não decidir que "você escreveu isso, mas vou assumir que você realmente quis dizer outra coisa". Se você deseja que as traduções ocorram, é melhor fazê-las separadamente, com ferramentas criadas para lidar bem com isso.

Por que alguém iria querer insensibilidade ao caso? Em que cenário é útil poder se referir a uma única variável como VARIABLEem um lugar, Variableem outro e variableem um terceiro? Insensibilidade ao caso é exasperante. Prefiro obter um erro de compilador quando digito acidentalmente, VAriableem Variablevez de deixar erros de digitação como esse entrarem no meu código.

Em conclusão, muitas linguagens de programação têm distinção entre maiúsculas e minúsculas, não apenas por razões históricas / inerciais, mas porque a insensibilidade a maiúsculas e minúsculas é uma má idéia.

No caso Java, a sensibilidade NÃO é usada para fornecer mais opções no código, mas para um significado semântico muito claro e consistente. ClassesLookLikeThis. objectsLookLikeThis. methodLookLikeThis (). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. NÃO oferece maior liberdade: permite que você coloque algumas informações de forma concisa no que é uma linguagem excessivamente detalhada.

Eu acho que em linguagens explicitamente tipadas estaticamente com compilador mucho e suporte a IDE, a distinção entre maiúsculas e minúsculas é uma ótima maneira de comunicar informações (por exemplo, Java). Em idiomas como Ruby, a distinção entre maiúsculas e minúsculas provavelmente causaria ainda mais resultados inesperados, embora eu estivesse aberto a tentar Ruby sem distinção entre maiúsculas e minúsculas.

Penso que a distinção entre maiúsculas e minúsculas com um sistema rigoroso não ofusca o código, mas na verdade o torna mais claro. Considere o possível código Java:

      joe blah = new hUf();

isso é bem claro, mas e quanto a:

      hUf.WTF();

No Java como está, você saberia automaticamente o que é isso. No Java que não diferencia maiúsculas de minúsculas, é ambíguo; portanto, você precisa recorrer a outro mecanismo para diferenciar classes de instâncias de pacotes de métodos. E esse mecanismo provavelmente faria você vomitar com o quão feio é :)

Eu não acho que foi "implementado" tanto quanto "permitido". A distinção entre maiúsculas e minúsculas é o estado padrão das comparações de strings; é necessário um trabalho extra para o engenheiro do compilador tornar um idioma sem distinção entre maiúsculas e minúsculas, pois é necessário adicionar código extra para realizar comparações sem distinção entre maiúsculas e minúsculas e preservar os nomes de tokens originais para corrigir erros e relatórios de aviso.

É quase certamente por isso que acabou em C; eles queriam criar uma linguagem simples e fácil de implementar um compilador, às custas da usabilidade. Quanto ao motivo pelo qual está nos idiomas modernos? Porque está em C, é claro, então deve ser o caminho certo para fazê-lo! </ modo sarcasmo>

Se nada mais, simplifica a análise e permite mais combinações para nomes de variáveis ​​/ classes.

Com a análise sem distinção entre maiúsculas e minúsculas, você estaria restrito a usar identificadores exclusivos, pois 'myClass' e 'MyClass' seriam a mesma coisa. Como alternativa, você teria que adicionar camadas de complexidade ao seu analisador para garantir que você pudesse determinar qual identificador é usado com base no contexto.

Considere um caso como este:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Suponha que a classe XmlWriter também tenha um método estático chamado "Write". Você está chamando na instância ou na classe, se não houver distinção entre maiúsculas e minúsculas aplicada aqui?

Gosto da distinção entre maiúsculas e minúsculas se, por outro motivo, não tornar o código mais auto-documentável:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

Normalmente programa em Python, mas nos meus dias de C #, achei muito conveniente nomear instâncias de classe da mesma forma que a classe, mas com letras minúsculas (ou camelos) (como outros já disseram):

Thing thing = new Thing();

O uso de linguagens que não diferenciam maiúsculas de minúsculas requer alguma outra convenção para isso, ou seja, algum tipo de sigilo como:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

O que é uma "coisa ruim".

Também acho conveniente grep (com distinção entre maiúsculas e minúsculas) para encontrar referência a uma classe vs. usos de uma variável. Com uma linguagem que não diferencia maiúsculas de minúsculas, isso seria menos fácil. O mesmo para pesquisa e substituição.

Por fim, como programador, quando vejo palavras com casos diferentes, percebe-se que são coisas diferentes ... Eu raramente tenho bugs em que casos variáveis ​​estavam errados, mesmo em linguagens dinâmicas e com scripts em que um compilador teria ajudado.

As pessoas prestam atenção ao formato das palavras antes de lê-las. A distinção entre maiúsculas e minúsculas mantém a forma de um símbolo consistente em todo o código. Também concordo com aqueles acima que afirmam que diferentes convenções denotam diferentes tipos de símbolos. A sensibilidade e insensibilidade ao caso podem ser abusadas. Os programadores ruins sempre geram códigos ruins ... eles encontrarão uma maneira.

Tome a linguagem como exemplo. Por que começamos frases e nomeamos coisas com maiúsculas ... É também por causa do unix?

Eu acho que para linguagens de digitação estática, como C # e Java, ele realmente não agrega nenhum valor. Como na maioria dos casos, você tem um IDE que corrige automaticamente as diferenças de maiúsculas e minúsculas para você, portanto, no final do dia, se eu digitar "VAriable" por acidente, meu IDE corrigirá isso automaticamente para " Variável "para mim. Acrescente a isso as MyClass myClass;convenções de estilo e você pode ver que a distinção entre maiúsculas e minúsculas não é necessariamente uma coisa ruim.

Para linguagens de tipo dinâmico, pode haver mais argumento, já que é mais difícil para um IDE adivinhar uma autocorreção, mas no caso de linguagens de tipo dinâmico, você já tem muito mais com o que se preocupar (em termos de erros de digitação) de que o uso de uma convenção de caixa consistente não trará muito mais carga.

Portanto, sim, embora não haja uma razão real para que as línguas não possam fazer distinção entre maiúsculas e minúsculas, também não há uma razão real para que elas também sejam.

Esse artigo de Scott Hanselman sobre "SignOn" vs "Signon" era sobre comparações de strings e nada a ver com linguagens de programação. Concordo que as strings que os usuários digitam devem sempre ser comparadas sem distinção entre maiúsculas e minúsculas, mas acho que esse é um jogo diferente dos identificadores em uma linguagem de programação.

Quando uma linguagem diferencia maiúsculas de minúsculas, aproveito-a para reproduzir o uso convencional de casos em matemática e ciências. Aqui está uma lista (de maneira alguma exaustiva) de algumas convenções de casos:

• Na teoria da probabilidade, letras minúsculas fgeralmente representam uma função de densidade de probabilidade (pdf), enquanto letras maiúsculas Frepresentam a função de distribuição cumulativa correspondente (cdf).
• Também na teoria da probabilidade, as letras maiúsculas denotam variáveis ​​aleatórias Xe as letras minúsculas correspondentes indicam suas realizações x, como em $ Pr [X = x] \ leq 0,05 $.
• Na álgebra linear, as letras maiúsculas são geralmente usadas para se referir às matrizes, enquanto as letras minúsculas geralmente são usadas para se referir aos números, por exemplo, $ A = [a_ {ij}] $.
• Os símbolos das unidades são escritos em letras minúsculas (por exemplo, m para metro), exceto no litro (L) e nas unidades derivadas do nome de uma pessoa (W para Watt, Pa para Pascal, N para Newton, etc.).
• Os símbolos dos prefixos que significam um milhão ou mais estão em maiúsculas (M para mega (milhões)) e os menos de um milhão são minúsculos (m para mili (milésimos)).

Eu apenas imaginei que era por causa do Unix e C - mas isso é uma espécie de problema de galinha e ovo, que apenas os velhotes podem responder adequadamente.

Eu uso o raciocínio que as Galinhas em "O Coelhinho da Páscoa estão chegando à cidade" usaram quando perguntadas se elas vieram antes de Eggs. Porque havia galinhas na Arca de Noé, as galinhas vieram primeiro. Portanto, como o GCC roda no Unix, o Unix ficou em primeiro lugar; portanto, porque o Unix se importa tanto com maiúsculas e minúsculas, C e todas as suas variantes e descendentes, sim, qualquer coisa que imponha chaves, se importa com maiúsculas e minúsculas.

Provavelmente também existe um vínculo entre chaves e distinção entre maiúsculas e minúsculas.

Além das excelentes respostas dadas até agora, gostaria de salientar que a distinção entre maiúsculas e minúsculas fornece também "namespaces" adicionais. Por exemplo, o Perl possui alguns blocos especiais como BEGINe ENDque são executados em momentos diferentes do código normal (BEGIN em tempo de compilação, END após o término do programa normal), e ter aqueles como maiúsculas os faz sobressair e significa que as letras minúsculas variantes não são palavras reservadas.

Pode-se ir ainda mais longe e reservar nomes com letras maiúsculas para uso futuro pela linguagem, e não prejudicar os programadores normais, que geralmente NÃO ATUAM EM SEU CÓDIGO.

"Diferenciar maiúsculas de minúsculas" é sempre melhor para as pessoas técnicas reduzirem a ambiguidade. Tome o nome do arquivo como exemplo. Lidar com o nome do arquivo do Windows é mais problemático que o nome do arquivo do Unix, porque o nome do arquivo no Windows não diferencia maiúsculas de minúsculas, enquanto o nome do arquivo no Unix diferencia maiúsculas de minúsculas.

Voltar à programação. Para o nome da classe, o nome do método, o nome da variável, a maioria dos idiomas não aplica a regra do estilo de nomeação. Às vezes, para simplificar a "reflexão", podemos simplesmente usar o nome "Case sensitive" para ligar a outra fonte de dados sem conversão, ou lidar com o problema do mesmo nome, mas em casos diferentes.

Estou surpreso com este discurso retórico. Agora que ninguém deseja que você use um sublinhado ou um m_nome de campo em C #, acabei de usar camel case e, se o nome do campo for igual ao nome de uma propriedade pública, apenas o nome da propriedade pública será Pascal case e o campo de apoio é o caso dos camelos, imagino, "assim seja" - é o que a comunidade de programação em geral parece querer. Não causou nenhum problema até agora.

Especialmente, alguns programadores vêm dos primeiros dias do BASIC, onde um nome de variável pode ter apenas 2 caracteres.

E assim, quando pode haver qualquer número de caracteres, eles ficam muito felizes. E junto com a distinção entre maiúsculas e minúsculas - porque eles também não querem se preocupar em SomeNameser acidentalmente iguais SOMENAMEe causar um bug devido a coisas como essa.