4 Wochen 4 Sprachen: Epilog

Die letzten vier Wochen habe ich vier verschiedene Sprachen vorgestellt, von denen ich aktuell überzeugt bin, dass sie für ihr jeweiliges optimales Einsatzgebiet als bevorzugte Sprache verwendet werden sollten und die eine Zukunft haben. Alle Sprachen sind unter einer freien Lizenz oder gar als internationaler Standard verfügbar. Das ist ein wichtiges Kriterium. Nur so ist sichergestellt, dass nicht der Profit einer einzelnen Firma über den Fortbestand der Sprache entscheiden kann. Nachfolgend eine Übersicht der vier Sprachen mit den wichtigsten Einsatzgebieten:

Wie erwähnt ist dies meine aktuelle Sicht im "Sprachen-Dschungel". Dazu kommen natürlich noch weitere Computer-Sprachen, die je nach Gesichtspunkt auch als Programmiersprache oder eben auch nicht, angesehen werden. Es sind u.a. die folgenden Sprachen und Formate, welche jeder Entwickler, je nach Tätigkeitsgebiet versteht sich, ebenfalls anwenden können sollte: SQL, HTML, CSS, JSON, YAML etc. Dazu kommen Standards wie OpenAPI und Konsorten. All die Frameworks, die noch viel mehr als die Sprachen selber wie Pilze aus dem Boden schiessen, lassen wir an dieser Stelle einmal aussen vor. Wie schrieb es einst Michael Ende: "Aber das ist eine andere Geschichte und soll ein andermal erzählt werden." Wir werden sehen, ob ich dieses Fass hier einmal öffnen werde.

"meine worte sind sortiert"

Warum funktionieren die Programme in den vorgestellten Sprachen beim String "Meine Worte sind sortiert" alle scheinbar nicht korrekt? Um diese Frage zu beantworten, müssen wir etwas tiefer in die Implementierung eintauchen. Die meisten Sprachen, resp. eigentlich präziser, die meisten API-Implementierungen von Arrays oder Listen, die eine alphabetische Sortierung anbieten, sortieren die einzelnen Elemente anhand der Unicode-Zahlen, welche die einzelnen Zeichen repräsentieren. Unicode ist ein Standard der definiert, welche Codes (Zahlen), welches Zeichen repräsentieren sollen, wenn man die Zahl als Zeichen interpretiert (was bspw. bei einem String der Fall ist). Nun ist es so, dass in Unicode die Grossbuchstaben vor den Kleinbuchstaben kommen. Sortiert man nun nach Unicode, so kommt bspw. der "Z" vor dem "a". Entsprechend sind die Wörter "Meine Worte sind sortiert", nach Unicode sortiert identisch, nämlich immer noch "Meine Worte sind sortiert". Die Programme funktionieren also richtig per Design. Auch wenn wir Menschen als User in der Regel wohl ein anderes Resultat erwarten würden. Wollen Sie es jeweils unabhängig von der Gross- und Kleinschreibung, müssen Sie den String jeweils vor der Sortierung in Gross- oder Kleinschreibung umwandeln. Sortieren und dann die einzelnen Elemente wieder der Ursprungsform zuordnen zur korrekten Ausgabe (in Gross- und Kleinbuchstaben).

Nun gut, dass ist aber nicht die einzige Eigenheit von Unicode. Eine weitere ist, dass gewisse Sonderzeichen auf zwei Arten abgebildet werden können. Zum einen als ein Zeichen inkl. dem "Sonderzeichenteil", bspw. "ñ". Zum anderen kann man es auch getrennt machen: "n" und ein höher gestelltes "~". Der erste Fall ist mit dem Unicode-Zeichen \xF1 codiert, der zweite mit "n" und \u0303. Optisch wird beides gleich dargestellt. Man sieht den Unterschied jedoch, wenn man bspw. in JavaScript ein String auf Char-Basis in ein Array umwandelt und dieses dann neu sortiert. Man kann dies korrigieren, wenn man Strings vor der Verwendung normalisiert, bspw. mit normalize('NFC'). Nachfolgend Beispiele in JavaScript, die das veranschaulichen:

Im zweiten Fall oben, landet die "Schlange" ober dem Buchstaben "n" plötzlich ober dem Buchstaben "b". Daran sieht man, dass im zweiten Fall der Buchstabe ñ mit zwei Unicode-Zeichen codiert worden ist: n\0303. Es sind zwei Chars. Dies sieht man übrigens auch an der Länge:

Obwohl in beiden Fällen der Output optisch identisch ist: abñam, ist die String-Länge im zweiten Fall um 1 grösser. Es werden eben die Chars gezählt. Daher ist es wichtig, vor String-Operationen eine Normalisierung vorzunehmen.

Die erste wird die letzte sein

Die vorliegende Serie war inspiriert vom Buch, Sieben Wochen sieben Sprachen. Zwischendurch ist es inspirierend, den Fokus zu öffnen und sich 2-3 andere Sprachen und vor allem, andere Sprachkonzepte, anzuschauen. Es erweitert den Horizont und gibt vielleicht auch für die bereits bekannten Sprachen neue Inputs.

Wir starteten die Miniserie mit dem Prolog. Der Name ist Programm. Prolog heisst eine bereits recht alte, interessante Programmiersprache. Ich habe sie bereits einmal in einem Beitrag erwähnt. Prolog steht für "PROgramming in LOGics". Prolog ist eine logische und vor allem deklarative Programmiersprache. Abgesehen von SQL, wo man es meist gar nicht so wahr nimmt, sind es heute viele Entwickler gewohnt, imperativ zu programmieren. Prolog lässt sich nicht befehlen, wie etwas zu tun ist. In Prolog kann man die Spielregeln definieren. Wie es gelöst wird, ist Prolog überlassen. Ich würde nicht behaupte, dass man Prolog können muss und viel brauchen wird. Ehrlich, ich brauche es operativ auch nicht. Dennoch ist es erfrischend, bspw. in den Ferien, einmal damit zu experimentieren. Gewisse Problemstellungen lassen sich damit einfach ungemein schneller lösen als mit anderen, vorallem imperativen Sprachen. Eine nette Abwechslung, in Form einer kalten Dusche. Da denkt man, man kann in fast allen Sprachen rasch programmieren, und dann dass. Sie können es bspw. hier online ausprobieren, ohne zuerst Software installieren zu müssen: onecompiler.com/prolog. Daher, wie im Prolog bereits angedeutet, die Programmiersprache Prolog als Bonus zum Abschluss dieser Mini-Serie.

In dem Sinne, happy coding!

#rust #javascript #python #scala #prolog #unicode