Was nützt es, verschiedene Sprachimplementierungen mit Unterstützung für Unicode-IDs zu versehen?

Ich persönlich finde den Lesecode voller Unicode-Identifikatoren verwirrend. Meiner Meinung nach verhindert es auch, dass der Code einfach gewartet werden kann. Ganz zu schweigen von dem Aufwand, den Autoren verschiedener Übersetzer für die Implementierung dieser Unterstützung leisten müssen. Ich bemerke auch ständig das Fehlen (oder Vorhandensein) von Unicode-Identifikatoren in den Listen der (Un) Vorteile verschiedener Sprachimplementierungen (wie es wirklich wichtig ist). Ich verstehe es nicht: warum so viel Aufmerksamkeit?

Wenn Sie an Unicode denken, denken Sie an chinesische oder russische Zeichen, wodurch Sie an einen Quellcode denken, der in Russisch geschrieben ist, den Sie im Internet gesehen haben, und der unbrauchbar war (es sei denn, Sie sprechen Russisch).

Aber wenn Unicode kann in einer falschen Weise verwendet werden, bedeutet dies nicht , dass es schlecht ist , selbst im Quellcode.

Wenn Sie Code für ein bestimmtes Feld mit Unicode schreiben, können Sie den Code kürzen und lesbarer machen . Anstatt von:

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

Du kannst schreiben:

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

Das mag für einen durchschnittlichen Entwickler nicht leicht zu lesen sein, ist aber für eine Person, die täglich mathematische Symbole verwendet , immer noch leicht zu lesen .

Oder wenn Sie eine Anwendung im Zusammenhang mit SLR-Fotografie ausführen, anstatt:

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

Sie können die ersetzen Öffnung durch das Symbol ƒ, mit einem Schreib näher an ƒ/1.8:

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

Dies kann unpraktisch sein : Wenn ich allgemeinen C # -Code eingebe, würde ich es vorziehen, Folgendes zu schreiben:

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

eher, als:

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

Im ersten Fall hilft mir IntelliSense, den gesamten Code zu schreiben, fast ohne etwas zu tippen und vor allem ohne meine Maus zu benutzen. Im zweiten Fall habe ich keine Ahnung, wo ich diese Symbole finden kann, und bin gezwungen, mich auf die Maus zu verlassen und suchen Sie sie in der Auto-Vervollständigungsliste.

Trotzdem ist es in einigen Fällen immer noch nützlich. currentLens.GetMaximumƒ();meines vorherigen Beispiels kann sich auf IntelliSense verlassen und ist so einfach zu tippen wie GetMaximumAperture, weil es kürzer und lesbarer ist. Für bestimmte Domänen mit vielen Symbolen können Tastenkombinationen auch dazu beitragen, die Symbole schneller als ihre wörtlichen Entsprechungen im Quellcode einzugeben .

Gleiches gilt übrigens auch für Kommentare. Niemand möchte einen Code voller Kommentare auf Chinesisch lesen (es sei denn, Sie sprechen selbst gut Chinesisch). In einigen Programmiersprachen können Unicode-Symbole dennoch nützlich sein. Ein Beispiel sind Fußnoten¹.

^{¹ Ich würde Fußnoten in C # -Code auf keinen Fall mögen, wenn es strenge Regeln für das Schreiben von Kommentaren gibt. In PHP hingegen, wenn es viele Dinge zu erklären gibt, die aber nicht sehr wichtig sind, warum sie nicht am Ende der Datei einfügen und eine Fußnote im PHPDoc der Methode erstellen ?}

Ich würde sagen:

1. Nichtprofis und Anfänger, die Programmieren lernen (zB in der Schule) und kein Englisch können. Sie schreiben sowieso keinen Produktionscode. Ich habe schon oft Code gesehen wie:

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

   Lass es den Armen einfach in seiner Sprache schreiben:

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

2. Gefällt es dir nicht

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

Natürlich muss sich heute jeder moderne Compiler mit Unicode-Quellcode auseinandersetzen. Beispielsweise müssen Zeichenfolgenkonstanten möglicherweise Unicode-Zeichen enthalten. Aber wenn dies erreicht ist, warum nicht auch Unicode-IDs zulassen? Es ist keine große Sache, wenn Ihr Compiler-Code von Zeichen abhängt, die 7-Bit-Codes sind.

Aber das OP hat insofern Recht: Es ist jetzt möglich, dass ein Hindi-sprechender Inder einen Code mit russischen Bezeichnern und arabischen Kommentaren führen muss. Was für ein Albtraum für die armen Chinesen, die die Qualitätsprüfung durchführen sollen und keines der oben genannten 3 Alphabete lesen können!

Daher ist es nun eine organisatorische Aufgabe, sicherzustellen, dass die Bezeichner und Kommentare eines Programms in einer gemeinsamen Sprache geschrieben sind. Ich kann nichts dagegen tun, aber ich denke, dass dies für einige Zeit Englisch sein wird.

Ich halte es für sehr sinnvoll, Unicode-Zeichen in Zeichenfolgen und Kommentaren zuzulassen. Und wenn der Lexer & Parser dafür sowieso Unicode unterstützen muss, erhält der Compiler-Writer wahrscheinlich kostenlose Unicode-Zeichenunterstützung in Bezeichnern. Es scheint also eine willkürliche Einschränkung zu sein, nur ASCII-Zeichen in Bezeichnern zuzulassen.

Für mich ist dies rein aus Marketinggründen . Und kann unser Leben zusätzlich erschweren.

Die Marketingargumente

Sie kennen diese verrückten Listen von Funktionen, die die meisten Sprachen bieten? Es ist im Allgemeinen ziemlich nutzlos, weil es so weit von der Sprache entfernt ist, dass es nicht viele Informationen zu bestimmten Themen liefert, aber es erlaubt, Tabellen schnell mit Häkchen und Kreuzen zu versehen und zu Recht zu folgern, dass X mehr Häkchen als Y hat sei besser.

Nun, Unicode-Unterstützung für die Bezeichner ist eine dieser Zeilen. Es spielt keine Rolle, dass im Vergleich zu Lambda-Unterstützung, generischer Programmierunterstützung usw. nicht viel dabei ist. Die Leute, die die Tabellen zeichnen, kümmern sich nicht um die Qualität jeder Zeile, sondern nur um die Anzahl der Zeilen.

Und so können sie sich rühmen: "Ah, mit Y haben Sie keine Unicode-Unterstützung für Ihre Bezeichner! In X tun wir das, für Studenten ist es also viel einfacher!"

Der Irrtum der Zugänglichkeit

Leider ist das Argument der Zugänglichkeit trügerisch.

Oh, ich verstehe, dass die Möglichkeit, "résultatDuJetDeDé" anstelle von "diceThrowResult" (ja, ich bin Franzose) zu schreiben, auf kurze Sicht wie ein Gewinn erscheinen könnte ... es gibt jedoch Nachteile!

Beim Programmieren geht es um Kommunikation

Ihr Programm ist nicht nur für den Compiler gedacht (was sich weniger um die von Ihnen verwendeten Bezeichner kümmern könnte), sondern auch für Ihre Kollegen. Sie müssen es lesen und verstehen können.

• Wenn Sie es lesen, müssen Sie in der Lage sein, die von Ihnen verwendeten Zeichen zu visualisieren. Unicode wird nicht von allen Schriftarten so gut unterstützt
• Wenn Sie das verstehen, müssen Sie sich auf Bezeichner verlassen - es sei denn, Sie ergänzen sie mit langen Kommentaren, was jedoch gegen die DRY-Regel verstößt.

Natürlich kann Ihr Klassenkamerad die Sprache sprechen, die Sie sprechen (nicht selbstverständlich, ich hatte Programmierunterricht mit Deutschen, Spaniern, Libanesen und Chinesen), und Ihr Lehrer auch ... aber nehmen Sie an, dass Sie zu Hause daran arbeiten und Brauche plötzlich Hilfe: Das Internet ist großartig. Sie können mit Tausenden von Menschen sprechen, die die Lösung kennen. Sie werden nur antworten, wenn sie Ihre Frage verstehen. Und Sie müssen auch ihre Antwort verstehen.

Programmierung erfordert Verständnis

Für die Zugänglichkeit und den Einstieg müssen Sie sich auf Bibliotheken stützen, um das Heavy-Lifting für Sie durchzuführen: Sie möchten keine E / A-Schicht neu erfinden, um bei Ihrer ersten Aufgabe von der Konsole zu lesen / auf die Konsole zu schreiben.

• In welcher Sprache sind diese Bibliotheken geschrieben?
• In welcher Sprache sind diese Bibliotheken dokumentiert?

Wenn Sie Marokkanisch-Arabisch antworten, werde ich überrascht sein.

Es sei denn , Sie nur auf die Vorträge verlassen unterstützen Sie, und die Anwesenden umfangreiche Dokumentation zu jeder Bibliothek - Funktion werden Sie verwenden müssen (und vielleicht sogar übersetzt Bibliotheken), dann Sie werden eine modicrum der englischen Sprache zu lernen. Aber wahrscheinlich haben Sie das schon lange vor Beginn dieses Programmierkurses getan.

Englisch ist...

... die Verkehrssprache der Programmierer (und der meisten Wissenschaftler).

Je eher man es zugibt und damit einhergeht, anstatt dagegen zu kämpfen, desto eher kann man wirklich lernen und Fortschritte machen.

Einige werden sich unweigerlich dagegen aussprechen und ihr Recht verteidigen, die Sprache ihrer Wahl zu sprechen (normalerweise ihre Muttersprache). Wie Babel jedoch gezeigt hat, wird die Kommunikation umso schwieriger, je mehr Sprachen verwendet werden.

Immer noch...

Ja, wie immer wieder argumentiert wurde, kann eine gewisse Unicode-Unterstützung (hauptsächlich Symbole) das Verständnis für Menschen, die beispielsweise mathematische oder physikalische Formeln in Code übersetzen müssen, erheblich erleichtern. Es gibt den Nachteil, dass einige Symbole überladen sind, aber es könnte trotzdem helfen.

Warum also ?

Wie gesagt, es geht nicht wirklich um Benutzerfreundlichkeit, sondern vielmehr um Marketingansprüche. Es ist auch kinderleicht, da der Parser bereits Unicode-fähig ist und trotzdem Zeichenfolgen und Kommentare enthält.

Und für bestimmte Benutzer kann dies von Vorteil sein.

Ich persönlich werde mich jedoch nur mit Code befassen, der mit englischen Bezeichnern geschrieben wurde. Es ist mir egal, ob Sie meine Hilfe bei Ihrem Code benötigen oder ob Ihre Bibliothek einfach nur großartig ist und ich viel davon profitieren könnte: Wenn ich es nicht verstehe, muss ich es einfach ignorieren.

Wie werden Sie ASCII-Bezeichner auf einer chinesischen Tastatur eingeben? Ein paar Sprachschlüsselwörter sind eine Sache, und es ist eine andere, den gesamten Code auf diese Weise ausführen zu müssen.

Programmierer sollten das Recht und die Fähigkeit haben, ihre Variablen nach Belieben aufzurufen. Es geht Sie nichts an, in welcher Sprache.

Wenn Sie sich so verwirrt fühlen, wenn Sie Code mit Bezeichnern lesen, in denen Symbole aus anderen Sprachen vorkommen, dann verstehen Sie sicher genau, wie verwirrt sie sind , wenn sie Bezeichner mit Symbolen aus Ihrer Sprache verwenden müssen.

Gemäß PEP 3131 - Unterstützung von Nicht-ASCII-Bezeichnern aus dem Jahr 2007 lautet der erste Teil von Rationale:

Python-Code wird von vielen Menschen auf der Welt geschrieben, die nicht mit der englischen Sprache vertraut oder mit dem lateinischen Schriftsystem vertraut sind. Solche Entwickler möchten häufig Klassen und Funktionen mit Namen in ihrer Muttersprache definieren, anstatt eine (häufig falsche) englische Übersetzung des zu benennenden Konzepts erstellen zu müssen. Durch die Verwendung von Bezeichnern in ihrer Muttersprache wird die Codeklarheit und Wartbarkeit des Codes unter den Sprechern dieser Sprache verbessert.

Ich habe andere Sprachen noch nicht untersucht, aber es sollte einer der Gründe sein, warum sie die Unterstützung hinzugefügt haben.

Es würde das Leben (für einige von uns jedenfalls) wirklich erleichtern, wenn der Compiler Unicode nicht unterstützen würde . Bezeichner von rechts nach links sind schrecklich. Die Kombination aus lateinischem Alphabet und Unicode-Bezeichnern von rechts nach links ist noch schlimmer.

Das Schlechte an der Nicht-Unterstützung ist, dass bestimmte GUI-Assistenten den von Ihnen eingegebenen Text für ein Element verwenden und diesen Text automatisch als Element-ID verwenden. Was genau würden sie mit Unicode-Text für diese Elemente tun? Keine einfache Antwort, fürchte ich.

Unicode-Kommentare von rechts nach links können auch lustig sein. In VS 2010 werden XML-Kommentare beispielsweise (korrekt) als RTL im Code angezeigt. Wenn Sie den Bezeichner jedoch mithilfe von Intellisense an einer anderen Stelle im Code aufrufen, wird in der QuickInfo die LTR (falsch) angezeigt. Besser vielleicht, wenn es überhaupt keine Unterstützung gäbe? Wieder kein einfacher Anruf.