Computernerds unter sich - Der Computerschwampf

[Mitel]

vor 4 Stunden schrieb LO Kwan-Tschung:

Sonst fand ich keinen Shop, der mir das zusammengebaut und lauffähig verkauft.

Hat mir da einer einen Tipp?

Alternate.de baut dir auch die Rechner zusammen.

Aber wie Prados schon fragt: warum kein Ryzen?

[LO Kwan-Tschung]

Upgrade ist bestellt, danke an alle.

[Sulvahir]

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.

 

[Abd al Rahman]

vor 6 Stunden schrieb Sulvahir:

Das könnte morgen noch lustig werden:

Let's Encrypt muss drei Millionen Zertifikate zurückziehen

 

 

Ich hab zumindest keine Mail bekommen  

[Widukind]

Habe gestern im Deutschlandfunk gehört, dass in meinem Wohnort der erste Quantencomputer Deutschlands aufgebaut wird. Cool!

https://www.welt.de/newsticker/dpa_nt/infoline_nt/netzwelt/article200086664/IBM-bringt-Quantencomputer-nach-Deutschland.html

[Airlag]

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?

[Toro]

Finde ich prinzipiell sehr gut. Allerdings wird es ggf. unhandlich zu schreiben, wenn die Operatoren nur über wilde Code Folgen eingetippt werden können.

[Gast]

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.

[Abd al Rahman]

Ich sehe es wie Tom. Gute Idee, ich befürchte nur, dass es beim tippen unhandlich wird. 

 

[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?

Bearbeitet 14. März 2020 von dabba

[Abd al Rahman]

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?

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. 
 

[Toro]

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 14. März 2020 von Toro

[Gast]

Wir bräuchten wieder solche Tastaturen 😉

[draco2111]

 

[Airlag]

Am 14.3.2020 um 10:25 schrieb dabba:

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

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 16. März 2020 von Airlag

[Gast]

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.

[metallian1]

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

[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.

[Lukarnam]

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.  Halt von chinesischen oder japanischen Experten.

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

Bearbeitet 16. März 2020 von Lukarnam

[Airlag]

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.

[Lukarnam]

vor 36 Minuten schrieb Airlag:

Da stimme ich dir grundsätzlich zu, aber ...

...lokale Behörden haben in wenigen speziellen Bereichen besonders lokale Anforderungen. Nichts internationales.

[Meeresdruide]

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 17. März 2020 von Meeresdruide

[Meeresdruide]

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.

[Toro]

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.

[Toro]

Bin gerade in der c't über folgende Webseite gestolpert. Passt gut zum Thema Programming Fonts