Quel est l'intérêt d'ajouter la prise en charge des identificateurs Unicode à diverses implémentations de langage?

Personnellement, je trouve la lecture du code plein d'identifiants Unicode déroutant. À mon avis, cela empêche également le code d'être facilement maintenu. Sans oublier tous les efforts nécessaires aux auteurs de divers traducteurs pour mettre en place un tel support. Je remarque également constamment le manque (ou la présence) de prise en charge des identificateurs Unicode dans les listes des (dés) avantages de diverses implémentations de langage (comme si cela comptait vraiment). Je ne comprends pas: pourquoi tant d'attention?

Lorsque vous pensez à l'unicode, vous pensez aux caractères chinois ou russes, ce qui vous fait penser à un code source écrit en russe que vous avez vu sur Internet et qui était inutilisable (sauf si vous connaissez le russe).

Mais si l'unicode peut être utilisé de manière incorrecte, cela ne signifie pas qu'il est mauvais en soi dans le code source.

Lorsque vous écrivez du code pour un champ spécifique, avec unicode, vous pouvez raccourcir votre code et le rendre plus lisible . Au lieu de:

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

tu peux écrire:

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

qui peut ne pas être facile à lire pour un développeur moyen, mais qui l' est tout de même pour une personne qui utilise quotidiennement des symboles mathématiques .

Ou, lorsque vous faites une application liée à la photographie SLR, au lieu de:

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

vous pouvez remplacer l' ouverture par son symbole ƒ, avec une écriture plus proche de ƒ/1.8:

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

Cela peut être gênant : lorsque je tape du code C # général, je préfère écrire:

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

plutôt que:

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

parce que dans le premier cas, IntelliSense m'aide à écrire le code entier presque sans taper et surtout sans utiliser ma souris, alors que dans le second cas, je n'ai aucune idée où trouver ces symboles et je serais obligé de compter sur la souris pour aller et recherchez-les dans la liste de saisie semi-automatique.

Cela étant dit, il est toujours utile dans certains cas. currentLens.GetMaximumƒ();de mon exemple précédent peut s'appuyer sur IntelliSense et est aussi facile à taper que GetMaximumAperture, étant plus court et plus lisible. De plus, pour des domaines spécifiques avec beaucoup de symboles, les raccourcis clavier peuvent aider à taper les symboles plus rapidement que leurs équivalents littéraux dans le code source.

Soit dit en passant, il en va de même pour les commentaires. Personne ne veut lire le code plein de commentaires en chinois (sauf si vous connaissez bien le chinois vous-même). Mais dans certains langages de programmation, les symboles Unicode peuvent toujours être utiles. Un exemple est les notes de bas de page¹.

^{¹ Je n'apprécierais certainement pas les notes de bas de page dans le code C # où il existe un ensemble strict de règles de style sur la façon d'écrire des commentaires. En PHP par contre, s'il y a beaucoup de choses à expliquer, mais que ces choses ne sont pas très importantes, pourquoi ne pas les mettre en bas du fichier, et créer une note de bas de page dans le PHPDoc de la méthode?}

Je dirais:

1. pour faciliter les non-professionnels et les novices qui apprennent la programmation (par exemple à l'école) et ne connaissent pas l'anglais. De toute façon, ils n'écrivent pas de code de production. J'ai vu plusieurs fois du code comme:

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

   Laissez simplement le pauvre gars l'écrire dans sa langue:

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

2. Vous ne l'aimez pas?

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

Bien sûr, chaque compilateur moderne doit gérer le code source Unicode aujourd'hui. Par exemple, les constantes de chaîne peuvent avoir besoin de contenir des caractères Unicode. Mais une fois cet objectif atteint, pourquoi ne pas autoriser également les identificateurs Unicode? Ce n'est pas grave sauf si votre code de compilateur dépend des caractères étant des codes 7 bits.

Mais l'OP a raison dans la mesure où il est désormais possible qu'un Indien parlant hindi doive maintenir un code avec des identifiants russes et des commentaires arabes. Quel cauchemar pour les pauvres Chinois qui sont censés faire le contrôle de qualité et qui ne peuvent lire aucun des 3 alphabets ci-dessus!

Par conséquent, c'est maintenant une tâche organisationnelle de s'assurer que les identifiants et les commentaires d'un programme sont écrits dans un langage commun. Je ne peux pas m'en empêcher, mais je pense que cela va être anglais pendant un certain temps.

Je pense qu'il est très logique d'autoriser les caractères unicode dans les chaînes et les commentaires. Et si le lexer et l'analyseur doivent prendre en charge unicode de toute façon, le rédacteur du compilateur obtient probablement la prise en charge des caractères unicode gratuitement dans les identificateurs, il semblerait donc qu'une limitation arbitraire autorise uniquement les caractères ASCII dans les identificateurs.

Pour moi, c'est uniquement pour des raisons de marketing . Et peut en outre rendre notre vie plus difficile.

Les arguments marketing

Vous connaissez cette liste folle de fonctionnalités dont la plupart des langues se vantent? C'est à peu près inutile en général, car il est si loin du langage qu'il ne fournit pas beaucoup d'informations sur des éléments spécifiques, mais il permet de dresser rapidement des tables avec des tiques et des croix et de conclure à juste titre que, puisque X a plus de tiques que Y, il doit être meilleur.

Eh bien, la prise en charge Unicode pour les identificateurs est l'une de ces lignes. Peu importe que par rapport à la prise en charge de Lambda, la prise en charge de la programmation générique, etc ... ce n'est peut-être pas grand-chose, les personnes qui dessinent les tableaux ne se soucient pas de la qualité de chaque ligne, seulement du nombre d'entre elles.

Et ainsi ils peuvent se vanter: "Ah, avec Y vous n'avez pas de support Unicode pour vos identifiants! Dans X nous le faisons, donc pour les étudiants c'est beaucoup plus facile!"

L'illusion de l'accessibilité

Malheureusement, l'argument de l'accessibilité est fallacieux.

Oh, je comprends que pouvoir écrire "résultatDuJetDeDé" au lieu de "diceThrowResult" (oui je suis français) peut sembler une victoire à court terme ... mais il y a des inconvénients!

La programmation, c'est communiquer

Votre programme n'est pas seulement destiné au compilateur (qui pourrait se soucier moins des identifiants que vous utilisez), il est également destiné à vos collègues. Ils doivent être capables de le lire et de le comprendre.

• la lire implique de pouvoir visualiser les caractères que vous avez utilisés, Unicode n'est pas si bien supporté par toutes les polices
• le comprendre signifie se fier à des identifiants - à moins que vous ne les complétiez avec de longs commentaires, mais cela viole la règle DRY.

Bien sûr, votre camarade de classe peut parler la même langue que vous (ce qui n'est pas évident, j'ai eu des cours de programmation avec des Allemands, des Espagnols, des Libanes et des Chinois), tout comme votre professeur ... mais supposez qu'en quelque sorte vous y travaillez à la maison et avez soudainement besoin d'aide: Internet est génial, vous pouvez parler à des milliers de milliers de personnes qui connaissent la solution, mais elles ne répondront que si elles comprennent votre question. Et vous devez également comprendre leur réponse.

La programmation nécessite de la compréhension

L'accessibilité et l'initiation nécessitent de vous baser sur des bibliothèques pour faire le gros du travail pour vous: vous ne voulez pas réinventer une couche d'E / S pour lire / écrire sur la console lors de votre première affectation.

• Dans quelle langue ces bibliothèques sont-elles écrites?
• Dans quelle langue ces bibliothèques sont-elles documentées?

Si vous répondez à l'arabe marocain, je serai surpris.

À moins que vous ne vous fiez qu'aux conférences auxquelles vous assistez et à celles qui présentent une documentation complète sur chaque fonctionnalité de bibliothèque que vous devrez utiliser (et peut-être même des bibliothèques traduites), vous devrez alors apprendre un module de la langue anglaise. Mais vous l'avez probablement déjà fait bien avant de commencer ce cours de programmation.

L'anglais est...

... la lingua franca des programmeurs (et de la plupart des scientifiques).

Plus tôt on l'admet et on l'accompagne plutôt que de lutter contre, plus tôt on peut vraiment apprendre et progresser.

Certains vont inévitablement s'élever contre cela, et défendre à juste titre leur droit de parler la langue de leur choix (leur langue maternelle en général), cependant, comme Babel l'a démontré, plus les langues sont utilisées, plus la communication devient difficile.

Encore...

Oui, comme cela a été soutenu à maintes reprises, une prise en charge Unicode (principalement des symboles) peut grandement faciliter la compréhension pour les personnes devant traduire des formules mathématiques ou physiques, par exemple, en code. Il y a l'inconvénient que certains symboles sont surchargés, mais cela pourrait quand même aider.

Alors pourquoi ?

Eh bien, comme je l'ai dit, il ne s'agit pas vraiment de commodité pour l'utilisateur, mais plutôt de revendications marketing. C'est aussi très simple, car l'analyseur est déjà au courant d'Unicode pour les chaînes et les commentaires, donc la plupart prennent le saut.

Et il pourrait y avoir un avantage pour certains utilisateurs.

Mais personnellement, je ne traiterai que du code écrit avec des identifiants anglais. Peu m'importe si vous avez besoin de mon aide pour votre morceau de code ou si votre bibliothèque est tout simplement géniale et je pourrais gagner beaucoup en l'utilisant: si je ne peux pas la comprendre, je devrai simplement l'ignorer.

Comment allez-vous taper des identifiants ASCII sur un clavier chinois? Quelques mots-clés de langue sont une chose, et devoir faire tout votre code de cette façon en est une autre.

Les programmeurs devraient avoir le droit et la capacité d'appeler leurs variables comme bon leur semble. Ce n'est pas votre affaire dans quelle langue c'est.

Si vous vous sentez tellement confus en lisant du code avec des identifiants contenant des symboles des langues des autres, alors je suis sûr que vous comprenez exactement à quel point ils se sentent confus lorsqu'ils doivent utiliser des identifiants avec des symboles de votre langue en.

Selon le PEP 3131 - Prise en charge des identifiants non ASCII daté de 2007, la première partie de la justification stipule:

Le code Python est écrit par de nombreuses personnes dans le monde qui ne connaissent pas la langue anglaise, ou même connaissent bien le système d'écriture latin. Ces développeurs souhaitent souvent définir des classes et des fonctions avec des noms dans leur langue maternelle, plutôt que d'avoir à proposer une traduction (souvent incorrecte) en anglais du concept qu'ils souhaitent nommer. En utilisant des identifiants dans leur langue maternelle, la clarté et la maintenabilité du code parmi les locuteurs de cette langue s'améliorent.

Je n'ai pas encore étudié d'autres langues, mais cela devrait être l'une des raisons pour lesquelles ils ont ajouté le support.

Cela rendrait vraiment la vie plus facile (pour certains d'entre nous, de toute façon) si le compilateur ne supportait pas Unicode. Les identifiants de droite à gauche sont horribles. L'alphabet romain combiné et les identificateurs Unicode de droite à gauche sont encore pires.

La mauvaise chose à propos de la non-prise en charge est que certains assistants GUI prennent le texte que vous insérez pour un élément et utilisent automatiquement ce texte comme identifiant de l'élément. Que feraient-ils exactement avec le texte Unicode sur ces éléments? Pas de réponse facile, j'en ai peur.

Les commentaires Unicode de droite à gauche peuvent aussi être amusants. Par exemple, dans VS 2010, les commentaires XML s'affichent (correctement) en RTL dans le code ... mais lorsque vous utilisez Intellisense pour extraire l'identifiant ailleurs dans le code, l'info-bulle affiche (incorrectement) LTR. Mieux, peut-être, s'il n'y avait pas de soutien en premier lieu? Encore une fois, pas un appel facile.