Meikrosoft des tages

Könnt ihr euch noch erinnern, wie meikrosoft damals den erfolg der programmiersprache java gesehen hat und prompt (nach einem von sun gestoppten versuch, ein zu java inkompatibles java an seine gläubigen mikrosklaven zu bringen) damit angefangen hat, die ganzen konzepte einmal selbst völlig inkompatibel nachzuproggen, in die eigenen entwicklungswerkzeuge einzubetten und das ergebnis .NET zu nennen. (Das müsst ihr verstehen, zu der zeit war alles ganz toll, wenn irgendwie drin klang, dass es irgendwas mit netzen oder gar diesem internetz zu tun habe oder gar besonders dafür geeignet sei, und deshalb der etwas alberne name. Tatsächlich ist .NET recht brauchbar.)

Warum mir das gerade wieder einfällt. Nun, es gibt zurzeit eine vielversprechende, allerdings noch in der entwicklung befindliche programmiersprache namens rust, die einerseits systemprogrammierung möglich macht, aber andererseits viele sicherheitsrelevante fallen und probleme der programmiersprache C vermeidet.

Ich halte rust für eine programmiersprache der zukunft — zumindest überall dort, wo es auf hardwäjhrnahes proggen und effizjenz ankommt, so etwas wie benutzerschnittstellen kann man auch in einer skriptsprache schreiben.

C ist wirklich gut geeignet für systemprogrammierung. Das sieht man allein schon daran, dass diese programmiersprache aus den siebziger jahren mit verhältnismäßig wenigen veränderungen (ja, prototypen für funkzjonen haben sie irgendwann eingeführt, und das war ein segen) immer noch aktiv benutzt wird. Viereinhalb verdammte jahrzehnte später! Das sind zwei dutzend erdzeitalter der informatik! Es gibt sonst keine so alte programmiersprache mehr, bei der man sagen kann, dass grundkenntnisse in dieser sprache zur allgemeinbildung eines programmierers gehören. (Vor anderthalb bis zwei jahrzehnten hatten einige progger noch so viel mit dem ähnlich alten FORTRAN zu tun, dass es ebenfalls zur allgemeinbildung gehörte, zu wissen, dass FORTRAN beim funkzjonsaufruf keine werte auf dem stack legt, sondern adressen von werten.)

Die eignung von C ist hier seine einfachheit; es handelt sich um eine sprache, die sehr direkt in instrukzjonen für einen prozessor übersetzt werden kann. Es gibt in C keine komplizierten, abstrakten konzepte. Alles sind structs, funkzjonen, variablen und adressen dieser objekte, ergänzt um den dreck, den der präprozessor ermöglicht — und diese werden in übersetzungseinheiten (in der regel: einzelnen kwelltext-dateien) organisiert. Die sprache selbst ist sehr minimal und dabei richtig gut entworfen, aber auch völlig ohne jedes sicherheitsnetz; die in die siebziger jahre zurückgehende standardbiblotek ist zwar ebenfalls praktisch, aber teilweise fürchterlich entworfen (man fragt sich manchmal, ob mehr kiffe oder doch noch ein bisschen LSD daran beteiligt war) und macht es sehr leicht, sehr schlimme fehler zu machen. C wird nicht benutzt, weil es toll ist. C wird benutzt, weil es da ist, weil es standardisiert ist, weil es gute kompeiler dafür gibt und weil es so leistungsfähig ist, dass man ein ganzes betrübssystem damit schreiben kann.

An der stelle setzt rust an. Es ist eine sprache, die viele sicherheitsprobleme von C beseitigt, aber immer noch effizjenten kohd erzeugt (etwa so effizjent wie gut programmiertes C++) — und damit rust für die systemprogrammierung geeignet ist, gibt es die möglichkeit, kohdpassagen als „unsicher“ zu kennzeichnen und damit explizit ohne sicherheitsnetze zu proggen. Das ist ja auch nötig, wenn man etwa einen treiber für ein stück hardwäjhr schreiben will. Der vorteil dieser vorgehensweise liegt darin, dass der potenzjell gefährliche kohd explizit vom programmierer ausgezeichnet ist, mit werkzeugen aufgespürt und für eine analyse isoliert werden kann. In C ist jede verdammte zeile gefährlich, und ein sicherheitskritischer fehler (der etwa wild speicherbereiche überschreibt oder ausliest), kann sich überall befinden und beim überfliegen des kohds unfassbar harmlos aussehen. Es ist leicht, in C fehler zu machen, und es ist schwierig, in C fehler zu finden.

Ich hoffe, dass jetzt auch völligen laien klar geworden ist, warum ich rust für eine programmiersprache der zukunft halte. Im moment ist rust noch zu jung und zu sehr in der entwicklung begriffen, als dass jemand ein größeres projekt nach rust portieren würde oder ein großes neues projekt in rust beginnen würde. Das wird sich aber ändern, denn rust wird reifen. Der bedarf an sicherer und effizienter programmierung ist da, und er wird nicht kleiner werden. Es sollen ja demnächst autos „autonom“ am straßenverkehr teilnehmen… oh, da pfeift man noch auf security-erwägungen… na, das wird man irgendwann nicht mehr tun.

Lange einleitung für eine kurze meldung, ich weiß. Hat einige menschen gelangweilt, ich weiß.

Und jetzt die meldung: Bei meikrosoft hat man das — wie üblich in ziemlich später geburt — auch gemerkt und unterstützt jetzt nicht etwa die entwicklung von rust mit eigenen beiträgen und mit portierungen von softwäjhr, bei der es auf sicherheit ankommt, sondern versucht wie damals bei java mit .NET eine art eigenes rust namens „checked C“ zu implementieren. Wäre ja auch — aus der sicht von etisch verrotteten marketingheins — schade, wenn die programmiersprache der zukunft der „mozilla foundation“ gehörte und frei wäre…

Es ist eben immer noch meikrosoft, böse und hinterfotzig wie eh und je…😦

5 Antworten zu “Meikrosoft des tages

  1. Ich sehe keinen Anlass, von C++ auf Rust umzusteigen. Klar, wer zu doof für Pointer ist, dem mag’s gefallen. (Das war jetzt etwas polemisch.) Aber die meisten Sprachen, die neu entstehen, lösen keine neuen Probleme.

    • Nix Pointer. Referenzen sind da schon besser. Können nicht NULL sein, können nicht implizit mit Arithmetik manipuliert werden, und jeder Compiler kann referenzierte einfache Objekte in inline-Funktionen komplett in Registern halten.

      Seit C++11 sollten Sternchen zum allergrößten Teil nur noch in Kommentaren vorkommen. Ansonsten sind es wahrscheinliche Fehlerstellen, egal ob Multiplikation mit potentiellem Überlauf oder Pointer mit zuviel Manipulationsmöglichkeiten.

    • Der Reiz von Rust und D liegt wohl auch daran, dass C++ (zumindest C++98) im Gegensatz zu C mehrdeutige Syntax hat: Man denke an int a(foo…). Auch deswegen sind ja seit C++11 fast überall Initialisierungen mit {…} möglich. Und dann ist immer noch der Charme einer Steuererklärung mit viel Klassen- und Template-Bürokratie. Habe mal Primitiven für volle Multiplikation (mit High-Wort) im C++-Stil definiert. Über 500 Zeilen. Aber ja, es hat funktioniert. Wurde auch wirklich in die kürzest möglichen Assembler-Instruktionen übersetzt, für jede relevante Wortbreite. Das gibt’s immer noch nur mit C++. Ich mag die Möglichkeiten, aber ncht den Ausdruck der Sprache.

    • Noch so ein Ärgernis an C++: Dass die Bedeutung eines Wortes (Typname oder etwas anderes) die Syntax beeinflusst. Klar, das kommt von C, aber da war es, abgesehen von Folgefehlern bei Schreibfehlern kein Problem. Seit C++98 muss man bei Template-Komponenten typename davorsetzen, nur damit der Compiler den Rest richtig parsen kann. Da rächen sich solche Design-Entscheidungen.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s