self denial of service

Warum die Programmiersprache C endlich auf den Müll gehört.

Manchmal passieren einem so die saublöden Sachen. Vorhin war ich per ssh auf einem weit entfernten Debian-System eingeloggt. Ich bevorzuge die tcsh, weil ich für das Kommandozeilen-Tippen schon immer die csh-Syntax bevorzugt habe. Irgendwann hab ich mich ausgeloggt und wollte mich wieder einloggen. Ging nicht mehr. Immer sofort session terminated.

Ursache:

Ich hatte mich von einem System eingeloggt, das etwas platzbeengt steht. Deshalb hatte ich da nach einer besondern schmalen aber noch brauchbaren Tastatur gesucht und war bei Conrad fündig geworden, sogar noch sehr preisgünstig. Hatte ich vor ein paar Tagen angeschlossen, und vorhin gemerkt, daß die Tastatur – obwohl ansonsten prima und sehr angenehm – eine ganz entscheidende Macke hat. Die Taste mit <> und |, die normalerweise unten links neben der Shift-Taste ist, fehlt. Einfach nicht da. Was denken die sich, solche unter Unix so wichtigen Zeichen einfach wegzulassen?

Aufgefallen war mir das, als ich auf besagtem System eingeloggt war und in der Kommandozeile ein Pipe-Zeichen eingeben wollte. Laut geflucht und dann versucht, ob ich mit Alt-Gr auf irgendeiner anderen Taste das |-Zeichen finde. Alles durchprobiert, nichts gefunden. Hab dann halt irgendwann Return gedrückt und damit im Prinzip eine gaaaanz lange Zeile aus unsinnigen Zeichen eingegeben. Befehl nicht gefunden. Aber die tcsh hat das in die .history geschrieben. Und zwar so, daß sie beim nächsten Einloggen beim Versuch das einzulesen mit Segmentation Fault abgebrezelt ist. Und deshalb gab es dann auch kein Login. Das heißt, genau genommen gabs das schon, aber die Shell war halt vorbei, bevor man was eingeben konnte.

Wieso werden heute eigentlich immer noch so Murks-Sprachen verwendet, die beim Einlesen einer ordinären Textdatei einen Segmentation Fault produzieren können?

Die Menge an Pufferüberläufen und anderen verwandtem Schrott ist doch nicht auszuhalten. Dazu kommt, daß man es nicht geschafft hat, ordentliche und einheitliche Standardbibliotheken zu schaffen und der typische C-Code sowas von unlesbar ist. Die meiste Software, die wir heute haben, einschließlich des Linux-Kernels, ist qualitativ mangelhaft, einfach weil sie auf einer veralteten, überkomplizierten und unsicheren Sprache beruht. (Was paradox ist, weil C doch eigentlich eine ganz einfache Sprache ist und sein soll.) Tatsache ist aber, daß Software, die in C geschrieben ist, von sprachspezifischen Problemen nur so wimmelt.

Um das klarzustellen: Ich habe sehr lange sehr gerne sehr viel in C und C++ programmiert. Und weiß wovon ich rede. Die Sprache ist nicht mehr zeitgemäß. Allein wenn ich an den Murks mit den Präprozessor-Orgien und den configure-Krämpfen denke. Strings, deren Länge man implizit wissen muß. Nullterminierte Strings. Wilde Pointer-Arithmetik. Das sind alles Sachen, die im normalen Programmieren überhaupt nichts verloren haben. Allein die Mühen die man hat, um ein fremdes Programm zu debuggen und den Spaghetti-Code zu verstehen.

Software in Ruby ist viel klarer, viel prägnanter und kürzer, viel fehlerärmer, keine Segmentation faults und Pufferüberläufe, viel bessere Behandlung von Sonderfällen und Events, viel bessere Standardisierung und Laufzeitbibliothek. Und, und, und…

Zugegeben, das heißt Äpfel mit Birnen zu vergleichen, weil Ruby ein langsamer Interpreter ist. Was aber mit der viel besseren Syntax und der objektorientierten Laufzeitumgebung nichts zu tun hat, die könnte man auch als Compilersprache gestalten.

Java kann man in der Hinsicht vergessen. Weil Java sehr erfolgreich viele Schwächen von C nachahmt. Java ist eine zwar prinzpiell sichere, aber völlig sperrige und unleserliche Sprache. Um dasselbe Problem zu lösen brauche ich unter Java etwa 3 bis 10mal soviel Code wie unter Ruby, und die Kürze und einfache Lesbarkeit von Ruby und dessen bessere Syntaxelemente kommen der Verständlichkeit, Lesbarkeit und Fehlerarmut sehr zugute.

Im Prinzip müßte man eine neue Sprache mit neuem Compiler kreiieren und dann alles neu schreiben.