Jump to content

Computernerds unter sich - Der Computerschwampf


Recommended Posts

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 to comment
  • 2 weeks later...

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 to comment

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 to comment

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:

Edited by dabba
Link to comment
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 to comment

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.

Edited by Toro
  • Like 2
Link to comment
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.

Edited by Airlag
  • Like 1
Link to comment

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 to comment

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 to comment
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.

Edited by Lukarnam
  • Thanks 1
Link to comment
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 to comment
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 :, ÷, /.

Edited by Meeresdruide
  • Sad 1
Link to comment
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 to comment
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 to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...