Les langages de programmation doivent être sensibles à la casse, point. Les gens peuvent s'y adapter très facilement: ils doivent simplement se rappeler de travailler principalement en minuscules et de faire attention aux identificateurs à casse mixte ou à majuscules dans les API existantes.
Il semblait autrefois évident de rendre les langues insensibles à la casse. En effet, les minuscules n'étaient pas disponibles sur tous les systèmes informatiques et leurs périphériques d'E / S (claviers, imprimantes et périphériques d'affichage). Les implémentations de langage de programmation devaient accepter des programmes écrits en majuscules, car seuls ceux-ci pouvaient être affichés ou imprimés. Et pour cela, ils devaient être insensibles à la casse, car accepter les majuscules et être sensibles à la casse en même temps signifie rejeter les minuscules. Les minuscules étaient quelque chose que les programmeurs voulaient, mais ne pouvaient pas toujours avoir. Personne ne voulait vraiment travailler avec des programmes qui criaient en majuscules; c'était juste une limitation matérielle.
Pendant un certain temps, il était même courant de replier les boîtiers dans les terminaux. Si un terminal ne pouvait afficher que des majuscules, mais que vous deviez vous connecter à un système informatique prenant en charge les majuscules et les minuscules, le terminal plierait les minuscules en majuscules. Vous pensez que c'était il y a si longtemps? "Comme l'Apple II, l'Apple II Plus n'avait aucune fonctionnalité en minuscules." (http://en.wikipedia.org/wiki/Apple_II_Plus) Lorsque les utilisateurs des premiers ordinateurs Apple se connectaient à un BBS qui avait un contenu à casse mixte, l'émulateur de terminal (ou l'hôte) devait tout replier en majuscules. Les messages écrits en majuscules étaient courants sur les babillards à cette époque. Cette fonctionnalité se trouve toujours dans les systèmes d'exploitation de type Unix, comme le noyau Linux. Par exemple, tapez le stty olcuc
à l'invite de votre shell.La discipline de ligne Unix tty peut mapper les minuscules aux majuscules en sortie, et elle peut mapper les majuscules en minuscules en entrée. Cela vous permet de travailler dans un langage de programmation en minuscules, sur un terminal qui n'a pas de minuscules.
L'insensibilité à la casse est un concept dépassé d'une ère informatique révolue qui ne fonctionne pas très bien dans le monde moderne de l'informatique internationalisée. Étendez-vous cela dans d'autres langues? Et le français: considérez-vous que È et è sont équivalents? Ou japonais? Considérez-vous que hiragana et katakana ne sont que des cas, de sorte que フ ァ イ ル et ふ ぁ い る sont le même identifiant? La prise en charge d'une telle folie compliquera considérablement votre analyseur lexical, qui devra disposer de cartes d'équivalence de cas pour l'ensemble de l'espace Unicode.
Notez que les mathématiques sont sensibles à la casse. Par exemple, le sigma en majuscules peut désigner la sommation, tandis que le sigma en minuscules indique autre chose, comme l'écart-type. Cela peut se produire dans la même formule sans créer de difficultés. (Le langage de programmation rendra-t-il Σ et σ équivalents?)
L'orthographe anglaise est sensible. Par exemple, de nombreux noms propres correspondent à des noms ordinaires ou même à d'autres parties du discours. "peut" est un verbe, mais "mai" est un mois, ou le nom d'une femme. De plus, si un acronyme ou une abréviation est écrit en minuscules, cela peut prêter à confusion. SAT signifie test d'aptitude scolaire, tandis que "sat" est le participe passé de "sit". Les gens intelligents prêtent attention aux détails et capitalisent correctement.
Fondamentalement, tout nouveau langage de programmation créé depuis 1985 qui ne respecte pas la casse est POUR CEUX QUI CRIENT ENCORE DANS DES COURRIELS ET DES AFFICHAGES SANS UNE SECONDE PENSÉE.
Que faire si votre langue est utilisée comme cible de génération de code pour traduire du code dans une autre langue et que cette autre langue est sensible à la casse? Vous devrez en quelque sorte transformer tous les noms pour capturer la distinction. (Donc, affirmer que ce n'est pas une décision technique, et seulement une question de préférences émotionnelles du public cible, est ridicule.)
Regardez les problèmes gênants causés par la gestion des cas dans Windows, lorsque les fichiers sont importés d'un autre système d'exploitation. C'est un problème technique. Les systèmes de fichiers sensibles à la casse ont un problème avec les données étrangères qui ne respectent pas la casse.
Common Lisp a adopté l'approche idéale: les noms de symboles sont sensibles à la casse, mais lorsque les jetons sont lus, ils sont pliés en majuscules. Cela signifie que les jetons foo
, fOO
, FOO
et Foo
tous désignent le même symbole: le symbole dont le nom est stocké sous forme de la chaîne de caractères "FOO"
. En outre, ce comportement est uniquement la configuration de table de lecture par défaut. Le lecteur peut plier des lettres en majuscules, en minuscules, inverser la casse ou la conserver. Les deux derniers choix donnent naissance à un dialecte sensible à la casse. De cette façon, les utilisateurs ont la flexibilité maximale.