Zum Inhalt springen

Computernerds unter sich - Der Computerschwampf


Empfohlene Beiträge

Das könnte morgen noch lustig werden:

Let's Encrypt muss drei Millionen Zertifikate zurückziehen

 

Zitat

Die kostenlose Zertifizierungsstelle Let's Encrypt muss drei Millionen Zertifikate zurückziehen. Der Hintergrund ist ein Fehler bei der Prüfung von CAA-Records, die nicht nach den vorgegebenen Regeln stattfand. Die Zertifikate werden bereits am morgigen Mittwoch, den 4. März, ungültig, betroffene Nutzer sollten diese daher umgehend erneuern.

 

Link zu diesem Kommentar
  • 2 Wochen später...

Im Rahmen meiner Freizeitbeschäftigungen mit C# bin ich mal wieder über das Faktum gestolpert, dass man nur vorgegebene mathematische Operatoren überladen kann. Wenn es sich bei den Operanden aber gar nicht mehr um Skalare handelt dann wäre aus wissenschaftlicher Sicht eine Schreibweise mit einer größeren Bandbreite an Operatoren durchaus sinnvoll weil unter Umständen besser lesbar. ich denke da an so nützliche Teichen wie ∩, ∪ (Durchschnitt und Vereinigung von Mengen), ∈ (ist Element von) und noch einigen mehr.
Ich mag einfach die wissenschaftlichen Schreibweisen. Sie sind kompakt und jeder mit der entsprechenden Fachkenntnis versteht es sofort.

Ich kann mir auch kaum vorstellen, dass es ein Problem wäre, dem Compiler zu sagen, dass jedes Unicode-Operator-Zeichen als Operator im Overload-Befehl zugelassen wird.

Was haltet ihr davon? Schnapsidee oder sinnvoll?

Link zu diesem Kommentar

Unter Haskell habe ich das schon verwendet. Allerdings ist die von Toro angesprochene Eingabe ein Problem. Es gibt für verschiedene Editoren ein paar Vereinfachungen, wirklich gut lässt sich das allerdings noch nicht einsetzen.

Link zu diesem Kommentar
vor 2 Stunden schrieb dabba:

Zudem sind Unicode-Zeichen (bzw. allgemein Nicht-ASCII-7-Bit-Zeichen) im Quellcode sowieso immer so eine Sache.

Wir benutzen ja auch keine Umlaute in Variablen-Namen, oder? :lookaround:

Bei Swift gehen auch Emojis in Variablennamen. Ich mag ja Swift. Aber sie Entscheidung den kompletten Unicode-Umfang zuzulassen halte ich für übertrieben. 

Ich hab das noch nie verwendet - kann also sein dass das mittlerweile nicht mehr möglich ist. Ich glaube aber das ist noch drin. 
 

3400D89E-1CEF-48ED-BD92-FD25BC25EAA6.png

Link zu diesem Kommentar

Wobei der volle Unicode Umfang ja nicht weiter stört, sobald die Toolchain auf UTF8/UTF16 umgestellt wurde. Dann ist es dem Softwareentwickler überlassen, was davon er verwenden will.

Wie gesagt, die Möglichkeit mathematische Symbole native verwenden zu können hätte Charm. Vermutlich landet man dann bei einem extra Fenster, indem man die ganzen Zeichen vorrätig hat und per Copy-Paste einfügt oder man hat eine Wolke Tastatur-Shortcuts für seinen persönlichen Symbolsatz.

Bearbeitet von Toro
  • Like 2
Link zu diesem Kommentar
Am 14.3.2020 um 10:25 schrieb dabba:

Wir benutzen ja auch keine Umlaute in Variablen-Namen, oder? :lookaround:

In C# kann man meines Wissens Unicode-Zeichen in Variablen- und Methodennamen verwenden. Sicher bin ich mir da aber nicht, ob wirklich alles geht was in Unicode als Buchstaben- oder Ziffernartig gekennzeichnet ist. Umlaute, die schon im erweiterten Ascii 8 Bit definiert waren, gehen aber mit ziemlicher Sicherheit.

Aber der Einwand, wie man die Zeichen eingeben soll, leuchtet mir ein.

Mir fällt auch noch ein anderes Argument auf, das Probleme bereitet. Programmierer sind ja Weltmeister im Abschreiben. Irgendwer hat irgendwo mein Problem sicher schon mal gelöst. Ich selbst kann  den Begleittext nicht entziffern, wenn ich mit meiner Suche mal wieder in russischen oder chinesischen Programmierforen lande - aber den Sourcecode kann ich lesen. Das fiele mit Unicode auch weg oder würde wesentlich schwieriger.

Bearbeitet von Airlag
  • Like 1
Link zu diesem Kommentar

Unicode teilt bereits in Klassen/Kategorien ein. C# hält sich bzgl. Bezeichner z.B. ziemlich exakt an den Unicode Identifier and Pattern Syntax

Operator- bzw. mathematische Symbole sind ebenfalls eigens kategorisiert. Bis auf Haskell gibt es m.W.n. wenig Sprachen, die ein Überladen von Haus aus unterstützen. Die Wolfram Language fällt mir da natürlich ein, die ist allerdings arg domänenspezifisch.

Link zu diesem Kommentar

Ich bin oldschool, Bezeichner haben maximal Ziffern,Buchstaben und Unterstriche, wenn ich C# etwas entwickle. Ist auch bei uns der Firma die Vorgabe und wird von allen Codecheckern überprüft.

also:

private static void GetString()

oder

listview1_FocusedNodeChanged()

Was anderes gibt es nicht. Aber über Namenskonzepte wurden ja bekanntlich schon diverse Flamewars ausgefochten

Link zu diesem Kommentar
vor 11 Minuten schrieb draco2111:

Es ging ja ursprünglich um Operatorüberladung. Da fände ich es durchaus sinnvoll, wenn die Menge der unterstützten Zeichen erweitert wird.

Wenn SourceCode jetzt komplett in chinesischen oder japanischen Schriftzeichen verfasst wird, wäre das in der Tat suboptimal.

Wir haben das bereits, und man kann damit sogar in validierten Umgebungen umgehen. :dunno: Halt von chinesischen oder japanischen Experten.

Warum auch nicht, die haben den gleichen Anspruch auf ihren Zeichenvorrat, wie wir ASCII- Lateiner.

Bearbeitet von Lukarnam
  • Thanks 1
Link zu diesem Kommentar
vor einer Stunde schrieb Lukarnam:

Warum auch nicht, die haben den gleichen Anspruch auf ihren Zeichenvorrat, wie wir ASCII- Lateiner.

Da stimme ich dir grundsätzlich zu, aber die internationale Austauschbarkeit - und Lesbarkeit - nimmt mit landessprachlichen Bezeichnern in landessprachlichen Zeichensätzen natürlich im Quadrat ab ;) 

Die Idee, zumindest mal mathematische Formeln in international verbreiteter Notation auch in den Sourcecode zu bringen sollte - so meine Vorstellung - eigentlich genau dem entgegen wirken.

Link zu diesem Kommentar
8 hours ago, Airlag said:

Die Idee, zumindest mal mathematische Formeln in international verbreiteter Notation auch in den Sourcecode zu bringen sollte - so meine Vorstellung - eigentlich genau dem entgegen wirken.

Es gibt auch da Unterschiede. Noch nicht einmal die Grundrechenarten werden überall gleich geschrieben, Für Produkte gibt es ⋅, ., ×, *; für Divisionen :, ÷, /.

Bearbeitet von Meeresdruide
  • Sad 1
Link zu diesem Kommentar
10 hours ago, Curilias said:

Unicode teilt bereits in Klassen/Kategorien ein. C# hält sich bzgl. Bezeichner z.B. ziemlich exakt an den Unicode Identifier and Pattern Syntax

Was aber auch nicht unproblematisch ist. Da kann es schon sein, dass ein Programm auf dem einen System kompiliert, auf dem anderen nicht. Warum? Das eine System hat eine neuere Unicode-Version und kennt ein Zeichen als gleich zu einem anderen – das andere System mit der älteren Unicode-Version kennt das Zeichen gar nicht und sieht zwei unterschiedliche Variablennamen.

Und dann kann man noch so lustige Dinge machen, wie eine Variable A, die andere А, und eine dritte Α zu nennen.

Link zu diesem Kommentar
vor 7 Stunden schrieb Meeresdruide:

Was aber auch nicht unproblematisch ist. Da kann es schon sein, dass ein Programm auf dem einen System kompiliert, auf dem anderen nicht. Warum? Das eine System hat eine neuere Unicode-Version und kennt ein Zeichen als gleich zu einem anderen – das andere System mit der älteren Unicode-Version kennt das Zeichen gar nicht und sieht zwei unterschiedliche Variablennamen.

Und dann kann man noch so lustige Dinge machen, wie eine Variable A, die andere А, und eine dritte Α zu nennen.

Ohne Vorgaben hat Unicode definitiv das Potential für Verwirrung. Aber in einer Programmiersprache ist typischerweise definiert, welche Operatoren es gibt und wie sie zu schreiben sind. An der Stelle erwarte ich keine Reibungsverluste.

Bei eigenen Operatoren ist es wiederum egal, da der Compiler schlicht die Zeichenfolge anwendet. Wenn ein "Hacker (TM)" der Meinung ist, er muss im Sourcecode Mindfuck betreiben, kann er das auch ohne Unicode.

  • Haha 1
Link zu diesem Kommentar

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.
×
×
  • Neu erstellen...