Iromeisters Abenteuerreise

Von einem, der auszog, Vertrauen zu üben

Das Gesetz des Karma ist aufgehoben. Alle Wesen sind frei.
« Ein Regenbogenkrieger holt sich selbstverständlich Unterstützung Videos im Blog jetzt mit 2-Klick-Aktivierung »

Komplexität ist der Feind

2018-08-6

Fefe bringt in seinem Beitrag zu Mozillas Vorstoß, in Firefox DNS over HTTPS zu nutzen und dafür ausschließlich über Cloudflare zu gehen, die übergeordnete Problematik auf den Punkt:

Komplexität ist der Feind. Die Anzahl der Bugs steigt mit der Codegröße. Die Leute stöpseln heute nur noch Komponenten aus Libraries zusammen. Das ist Schönwetter-Programmieren! Ein Programm, das nur beherrschbar ist, wenn es zufällig gerade gut funktioniert, ist wertlos. Wir brauchen Programme, die überschaubar wenig Dinge tun, und dafür vollständig beherrschbar sind. Am besten nicht nur vom Programmierer, sondern auch vom Benutzer. Die Geschwindigkeit, mit der wir uns mit unbeherrschten und unbeherrschbaren Technologien umzingeln, ist aus meiner Sicht ein Vorbote der Apokalypse.

Das ist die Anwendung der Maxime Weniger ist mehr auf die Software- und allgemein die Technik-Welt. Im Angelsächsischen ist dafür auch die Bezeichnung KISS principle verbreitet.

Zur Veranschaulichung der Codegröße schaut einfach mal auf How Many Millions of Lines of Code Does It Take?

"Die Geschwindigkeit, mit der wir uns mit unbeherrschten und unbeherrschbaren Technologien umzingeln" hängt dabei vielleicht schlicht mit der patriarchal-kapitalistischen Geisteshaltung zusammen, also dem ganzen Gegenteil obigen Prinzips: "Mehr ist mehr".

Und ich erinnere in diesem Zusammenhang noch mal daran, dass es eine schlechte Entscheidung der Linux-Community war, nahezu geschlossen zu systemd als Initsystem zu wechseln.

Nachtrag vom 27.08.: Ebenfalls von Fefe verlinkt, ein Artikel über "Ridiculously Complicated Algorithms".

We don’t want an optimal algorithm. We want one simple enough that an expert can look at it and say nothing crazy is happening here.

Nachtrag vom 24.05.2019: Unbedingt sehenswerter Vortrag zum Thema:

Damals im Informatik-Grundstudium wurde uns gesagt, ein Kern des Informatiker-Denkens sei, wenn ich ein spezifisches Problem zu lösen habe, dann am besten gleich die ganze Problemklasse zu lösen; Abstraktion als Allheilmittel sozusagen. Genau dieses Denken hat uns in den Schlamassel überhaupt erst hineingeführt! Es lässt nämlich eine Sache ausser Acht:

Auf jeder Abstraktionsschicht kann etwas schiefgehen.

Wenn ich also eine zusätzliche Abstraktionsschicht einziehe, dann kann ich damit zwar tatsächlich mehr machen als vorher, es kann aber eben auch mehr schiefgehen als vorher.

Dabei kommt es, wie auch Jonathan Blow in seinem Vortrag betont, auf das gesunde Maß an. Natürlich ist es unter dem Strich sinnvoll, dass wir heutzutage nicht mehr alles in Assembler programmieren. Docker-Container für einzelne Programme schiessen allerdings deutlich über das Ziel hinaus.

Dabei ist zu beachten, dass die möglichen Seiteneffekte zwischen den Abstraktionsschichten kombinatorisch ansteigen, weil diese Schichten eben auch miteinander interagieren (direkt oder indirekt).

Nachtrag vom 29.05.2019: Ein Fragensteller nach dem Vortrag weist auf den Artikel The Humble Programmer aus dem Jahr 1972 (!!!) von Edsger Dijkstra hin, in dem dieser vorschlägt:

I now suggest that we confine ourselves to the design and implementation of intellectually manageable programs.

Er führt dazu aus:

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

Na, bei wem kommen da keinerlei Schuldgefühle auf?
Ausserdem wünscht er sich auch beherrschbare Programmiersprachen:

Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages.

Weiterer Nachtrag vom 29.05.2019: Docker: Lücke erlaubt Root-Zugriff auf Dateien. Merke: Wer dir Virtualisierung als Sicherheitsfeature verkauft, lügt! Qubes OS erfreut sich drum auch nicht gerade flächendeckender Verbreitung…

Nachtrag vom 07.06.2019: Mehr von Fefe, auf der Seite zu seiner dietlibc findet ihr Vortragsfolien zu einem Vortrag Wie man kleine und schnelle Software schreibt. Darin widerspricht er direkt dem, was ich an der Uni über Abstraktion gelernt habe:

Nur generalisieren, wenn es nichts kostet

Und weiter:

Shared Libraries sind die eine Technologie, die am stärksten für den Bloat in der Software-Industrie verantwortlich ist. Denn der Programmierer sieht nicht mehr die tatsächliche Code-Größe.

Nachtrag vom 12.08.2019: Kubernetes-Audit hält System für zu kompliziert:

Interessant an der Auswertung ist vor allem die Einordnung von Kubernetes durch die Prüfer unabhängig von den gefundenen Lücken selbst. So wird Kubernetes als System mit "erheblicher Komplexität" bezeichnet. Ebenso seien die Konfiguration und das Deployment nicht trivial. Das wieder liege an "verwirrenden Standardeinstellungen, fehlenden Steuerungselementen und nur implizit definierten Security-Kontrollelementen".

Die Kritik geht aber noch weiter: So habe die riesige Codebasis große Teile mit nur "minimaler Dokumentation" sowie zahlreiche externe Abhängigkeiten. Außerdem gebe es viele Stellen, an denen bestimmte Programmlogik einfach reimplementiert wird. Hier wäre es besser, diese in zentrale Helferbibliotheken auszulagern.

Nachtrag vom 13.08.2019: Stack Overflow-Gründer Joel Spolsky sagt im Interview mit c't:

Wenn ich auf vierzig Jahre als Programmierer (oder so was Ähnliches) zurückschaue, kann ich nur sagen: Produktivität verbessert man am besten, indem man Komplexität verringert. Man beginnt mit einer simplen Sprache, dann findet man eine Bibliothek, mit der man ein paar Zeilen Code einsparen oder ein neues Feature umsetzen kann. Dadurch hat sich aber die Zahl der Dinge, die der Programmierer im Kopf behalten muss, um eins vergrößert – und die Zahl der Interaktionen um N oder N2.

Letztens habe ich versucht, ein GPS-Gerät auszulesen, das einen String zurückgibt. Heute nimmt man für das Parsen eine Library. Ich lud mir eine Bibliothek herunter und fand sie buggy. Schließlich habe ich den Code selbst geschrieben – das Ergebnis passt in ein paar Zeilen, läuft sehr schnell und ich verstehe den Code. Dieser Erkenntnisgewinn macht dich effizient als Programmierer, statt deine Zeit damit zu vergeuden, alle möglichen Bibliotheken verstehen zu müssen und dich um Abhängigkeiten und Updates zu kümmern.

Und weiter:

Aber das ist der Grund, warum Stack Overflow so wichtig geworden ist: Man arbeitet in einem Ökosystem, das man nicht wirklich verstehen kann. Man programmiert auf Grundlage von Code anderer Leute.

Nachtrag vom 14.08.2019: Fefe über HTTP/2:

Ich hab ja vor einer Weile herumgerantet, dass ich HTTP/2 für einen Rückschritt halte. Meine Hauptbeschwerde bei neuen tollen Framework-Standards ist ja die explodierende Komplexität, die zu kaputten Implementationen führen wird. Und tatsächlich ist ein aktueller Feldversuch etwa so vernichtend, wie man sich das denken würde.

Und weiter:

Das Protokoll ist schlicht ein Clusterfuck, und die einzige Implementation, die ich überhaupt erwägen würde, ist eine großflächig lobotomierte.

Nachtrag vom 27.08.2019: Es gibt sogar einen Verein, der sich auf die Fahnen geschrieben hat, software that sucks less zu entwickeln, den suckless.org e.V..

0 Responses to Komplexität ist der Feind

Feed for this Entry

0 Comments

    There are currently no comments.

Über dich

E-Mail-Adresse ist nicht veröffentlicht

Zur Diskussion hinzufügen

Schenken

Spenden

Suchen

Archiv

Browse Archives