- Jonathan Blows Sorge, dass „Abstraktion die Fähigkeit schwächt, essenzielle Software zu warten“, ist im Hinblick auf Wissensweitergabe berechtigt, doch viele seiner Beispiele verfehlen Geschichte und Kontext
- Debatten über „five nines“, robuste Software, stagnierenden technischen Fortschritt und sinkende Produktivität unterscheiden oft nicht zwischen Consumer-Geräten und Hochverfügbarkeitssystemen oder stützen sich stark auf selektive Beispiele
- Die Sorge vor dem Verlust von Low-Level-Wissen ist teilweise berechtigt, doch C, Assembler, Rust, Betriebssystem-Portierungen, Compiler-Ausbildung und Open-Source-Aktivitäten bleiben weiterhin Wege, Systemkompetenz zu erhalten
- Abstraktionen wie Betriebssysteme, Dateisysteme, Netzwerke, Multitasking und Frameworks erhöhen zwar die Komplexität, bewältigen aber Hardwarewandel und Nutzererwartungen und steigern zugleich Portabilität, Produktivität und Zugang zur kreativen Arbeit
- Größere Risiken als Abstraktion selbst sind permanenter Churn, geschlossene Plattformen, Werbung, Tracker und Telemetrie sowie die Schwächung von Privatsphäre und Freiheit; die technische Basis zur Wartung wichtiger Systeme muss weiter erhalten bleiben
Grundposition zu Blows Argumentation
- Jonathan Blows Vortrag folgt der Linie, dass Software-Abstraktion zum Verlust von Low-Level-Programmierwissen führt und am Ende dazu, dass essenzielle Software nicht mehr gewartet werden kann – bis hin zum Zusammenbruch der Zivilisation
- Der Bedeutung von Wissensweitergabe stimme ich zu, doch um eine solche These zu stützen, müssen Beispiele und historischer Kontext stimmen
- Der zentrale Einwand lautet, dass Blows Beispiele stark auf Missverständnissen, selektiven Fällen und anekdotischer Evidenz beruhen und Teile der Computergeschichte ausblenden
„Five nines“ und die Robustheitsdebatte
- Blow behauptet, beim Verkauf früherer Computersysteme sei „five nines“, also 99,999 % Verfügbarkeit, als Qualitätsversprechen verwendet worden, heutige Laptops erreichten das aber nicht
- Dass five nines etwa fünf Minuten Ausfallzeit pro Jahr bedeutet, stimmt; die Behauptung, diese Kennzahl sei für Consumer-Laptops oder Textverarbeitungen genutzt worden, halte ich jedoch für falsch
- Five nines gilt typischerweise für Bereiche wie Notruf-Vermittlungen à la 911, Krankenhaussysteme oder die Verarbeitung von Finanztransaktionen
- Oft wird sie zusammen mit langfristigen Verträgen verwendet, die sehr genau festlegen, welche Situationen nicht als Ausfallzeit zählen
- Unternehmen wie IBM und Amazon verkaufen solche Systeme und Dienste weiterhin
- Auch der Behauptung, seit Jahrzehnten gebe es keine robuste Software mehr, stehen Gegenbeispiele entgegen
- Ein iPhone kann Wochen oder Monate ohne Neustart laufen
- Für Novell-Datei- und Druckserver gibt es Fälle mit 16 Jahren Uptime
- Unix-, Windows- und VMS-Maschinen sowie Turnkey-Systeme wie IBM i werden ebenfalls als Beispiele langfristiger Verfügbarkeit genannt
Einwände zu technischem Fortschritt und Produktivität
- Der Aussage, „Tech-Unternehmen treiben Technologie nicht mehr voran“, stimme ich teilweise zu; Unternehmen, denen Geld wichtiger ist, gab es jedoch auch früher schon
- Auch „langweilige“ Bereiche wie Dateisysteme, Webserver, Datenbanken und Programmiersprachen werden weiterentwickelt und verbessert
- Auch die von Blow abgelehnten Schichten aus Abstraktion, Virtualisierung und Containerisierung werden mit großem Aufwand verbessert; dass man sie nicht mag, macht sie nicht zu keinem technischen Fortschritt
- Die Behauptung, die Produktivität der Facebook-Mitarbeitenden gehe gegen null, beruht auf der Annahme, Facebooks Produkt bestehe nur aus Funktionen einer Social-Plattform
- Zu den Beschäftigten von Facebook gehören Recht, Buchhaltung, Grafikdesign, Systemadministration, Forschung, HR, mittleres Management und viele weitere Rollen
- Dazu kommen andere Geschäftsbereiche wie Instagram, WhatsApp und Oculus VR
- Facebooks eigentliches Produkt ist eine Plattform zur Auslieferung von Werbung; das Sammeln von Privatsphäre- und Nutzerdaten und deren Umwandlung in zielgerichtete Werbung ist zwar nicht als Nutzerfunktion sichtbar, erscheint aber im Umsatz
Low-Level-Wissen und die zwei Seiten der Abstraktion
- Es stimmt, dass viele Programmierer Umgebungen bevorzugen, in denen sie sich nicht mit Speicherallokation und Pointern beschäftigen müssen
- Übermäßige Abstraktion, etwa einfache Blogs mit unnötigen JavaScript-Frameworks zu rendern oder langsame Desktop-Apps in gebündelten Browsern laufen zu lassen, ist ein Problem
- Dennoch könnte es heute mehr Menschen geben, die C beherrschen, und mehr geschriebenen C- und Assembler-Code als früher
- Linux und NetBSD werden weiterhin auf verschiedenste Ziele portiert, die irgendwie wie eine CPU aussehen
- Rust konzentriert sich auf Robustheit und bietet dennoch Pointer und Speicherverwaltung
- Harvard CS50 behandelt in frei zugänglichen Vorlesungen Speicherlayout, Pointer,
malloc(),free()und ähnliche Themen
- Garbage Collection und funktionale Programmierung sind keine neuen Abstraktionen
- Lisp bot beides bereits Ende der 1950er-Jahre
- Lisp wurde auch in „Hardcore“-Umgebungen wie dem NASA Jet Propulsion Lab eingesetzt
- COBOL fehlt in Blows Vortrag, spielt aber als Hochsprache, die Banken und Finanzinfrastruktur trägt, bis heute eine wichtige Rolle für das heutige Zivilisationsniveau
Ken Thompsons „Unix in drei Wochen“
- Dass Ken Thompson in drei Wochen einen Assembler, einen Editor und einen grundlegenden Kernel schrieb, ist als herausragende Leistung zu bewerten
- Allerdings ist unklar, wie robust die Software zu diesem Zeitpunkt war, wie nutzerfreundlich sie war und welche Funktionen sie hatte
- Die Arbeitsbedingungen damals und die heutiger Entwickler unterscheiden sich erheblich
- Dokumentation, Code-Reviews, Daily Standups, Backlog-Pflege, User Stories, Unit-Tests, Kundenanforderungen, A/B-Tests, Commit-Messages und unternehmensweite Coding-Standards gehören heute zur Entwicklung dazu
- Auch ein ablenkungsreiches Open Office und die individuelle Arbeitsumgebung der Bell Labs können sehr verschieden sein
- Ein einzelnes Beispiel Thompson beweist nicht, dass frühere Programmierer insgesamt produktiver waren
- Thompson arbeitete auch an Multics mit, das für Verzögerungen bekannt war
- Auch große Projekte wie IBM OS/360 verzögerten sich lange; Frederick P. Brooks schrieb auf Grundlage solcher Erfahrungen 1975 „The Mythical Man-month“
Software-Fortschritt und Nutzererwartungen
- Computer sind insgesamt robuster geworden als vor Jahrzehnten, und Programmierer sind meiner Ansicht nach mindestens so produktiv wie früher
- In manchen Fällen ist der Einstieg allerdings komplexer geworden, was die anfängliche Produktivität senken kann
- Moderne Nutzer wollen nicht RPN lernen, um einfache Rechenaufgaben zu erledigen, oder troff-Direktiven schreiben, um einen Flyer zu erstellen
- Bequeme Interfaces und fortgeschrittene Funktionen erhöhen unabhängig von Abstraktion Komplexität und Entwicklungszeit
- Ein Fall, in dem ein altes Amiga OS beim Kopieren von Dateien abstürzte und eine Festplattenpartition beschädigte, zeigt, dass frühere Systeme nicht zwangsläufig stabiler waren
- Moderne Home-Computer-Betriebssysteme besitzen Speicherschutz und Journaling-Dateisysteme, wodurch dasselbe Problem weit seltener auftritt
- Auch Windows 10 Home hat Mängel, enthält aber solche Fortschritte
Behauptungen nach dem Muster „früher konnte man das einfach“
-
Programme kopieren und ausführen
- Ein Programm von einem Computer auf einen anderen zu kopieren und dort auszuführen, ist bei gleicher Zielarchitektur und gleichen Kompilierbedingungen weiterhin möglich
- Es gibt ein Beispiel eines statisch gelinkten Go-Binaries von
slack-term, das auf Raspberry Pis lief - Die Zeit, in der eigenständige Programme allgemein üblich waren, reicht allerdings bis in die Ära von C64 oder PC/XT zurück; auch Deluxe Paint IV auf dem Amiga war von mehreren Hilfsdateien und Third-Party-Funktionsbibliotheken abhängig
- Einige Amiga-Spiele nutzten Track-loaded-Disketten, die das Dateisystem umgingen und wie eine damalige Art Container funktionierten, hatten aber den Nachteil, Festplatteninstallation und Multitasking zu verhindern
-
Die Behauptung, Code laufe, solange nur die CPU gleich sei
- Dass Maschinencode auf derselben CPU ausgeführt werden kann, wenn man ihn in den Speicher legt und den Program Counter darauf zeigen lässt, ist theoretisch möglich
- Für praktische Aufgaben wie Grafikausgabe, Soundwiedergabe, Eingabeverarbeitung oder Schreiben auf Disk sind Hardwareunterschiede jedoch ein großes Problem
- Auch frühere Z80-basierte Heimcomputer hatten dieselbe CPU, aber unterschiedliche Peripherie, wodurch echte Portierung schwierig war
- Programme auf einer höheren Abstraktionsebene wie Basic ließen sich zwischen verschiedenen Maschinen oft leichter portieren
- Mit Apples Einführung einer ARM-basierten Desktop-Linie kann die Abhängigkeit von Abstraktionen statt direktem Bare-Metal-Zugriff den Aufwand für die Portierung auf eine neue CPU verringern
-
Betriebssysteme und Hardwarezugriff
- Ein Betriebssystem nimmt der CPU nicht nur Fähigkeiten weg, sondern fügt Fähigkeiten wie Dateisysteme, Networking und Multitasking hinzu
- Nutzer wie Twitch-Streamer, die gleichzeitig Spiele und andere Programme ausführen müssen, brauchen Multitasking, das Hardware-Ressourcen kontrolliert und vorhersehbar aufteilt
- Manche Software für Amiga und Atari hielt sich nicht an die von den Herstellern bereitgestellten Spezifikationen und Abstraktionen, sondern griff direkt auf Hardware und Speicher zu; deshalb brach sie schon bei kleinen Upgrades wie mehr Speicher oder einer Festplatte
- Software, die gemäß Spezifikation und Abstraktion geschrieben war, konnte auch nach Hardwareänderungen weiter verkauft werden
-
Grafik, unsignierte Programme, LSP
- Pixel auf den Bildschirm zu zeichnen ist in vielen Sprachen weiterhin möglich; auch Mode 13h wurde über das VGA BIOS angesprochen, also eine frühe Hardware-Abstraktionsschicht
- Code, der von bestimmter VGA-Hardware abhing, war nicht portabel; Grafikprogramme, die Windows-Abstraktionen nutzten, konnten dagegen in sehr unterschiedlichen Umgebungen von Hercules bis True-Color-XGA laufen
- Auch das Ausführen unsignierter Programme ist möglich; als Beispiel wird genannt, WordGrinder selbst zu kompilieren und zu nutzen
- Einige von Blows Beschwerden betreffen weniger Abstraktion als vielmehr das Problem, dass Hardware- und Softwareanbieter Systeme abschließen und Nutzerrechte einschränken
- Beim Language Server Protocol stimme ich Blow im Großen und Ganzen zu, doch LSP löst mehr Probleme als nur „auf eine Methode klicken und zur Definition springen“
Spiele, Performance und Multitasking
- Unter modernen Produktivitäts-Apps gibt es viele Fälle von Performanceproblemen und erheblichem Input-Lag
- Ein Teil der Ursache ist Abstraktion, das größere Problem sind jedoch schlechter Code und die Wahl unpassender Werkzeuge für die jeweilige Aufgabe
- Selbst Programme auf derselben Plattform und mit demselben UI-Toolkit können sich auf derselben Maschine in der gefühlten Performance stark unterscheiden
- Das von Blow genannte Problem, dass ein Spiel nach Alt-Tab die Auflösung nicht korrekt wiederherstellt, ist eine schlechte Erfahrung und sollte verbessert werden
- Frühere DOS-Spiele waren jedoch einfacher, weil sie keine Rücksicht auf andere Prozesse nehmen mussten
- Um Doom unter Windows 3.1 zu spielen, musste man seine Arbeit speichern, Programme schließen, Windows beenden und dann das Spiel starten
- Auch Amiga-Spiele booteten oft von Diskette, übernahmen die Maschine vollständig und kehrten nicht sauber zum OS zurück
- Heutiges Gaming-Multitasking ist nicht perfekt, aber meiner Einschätzung nach besser als früher
Wissensverlust und Veränderungsgeschwindigkeit
- Blow sieht Wissen wie das Sprite-Management in Unity als Ersatz für tiefes Verständnis durch bloßes Sammelwissen
- Ich stimme zu, dass sich moderne Software und Hardware oft so schnell verändern, dass es schwer ist, sinnvoll Schritt zu halten
- Das ist jedoch eher ein Problem von Konsistenz über die Zeit und von Software-Distributionsmodellen als von Abstraktion selbst
- Ein Rhythmus, in dem alle vier Wochen etwas ausgeliefert wird, kann es Nutzern erschweren, eine stabile Erfahrung zu bekommen
- Wenn sich UIs häufig ändern, müssen Nutzer statt ihrer eigentlichen Arbeit ständig mit Details einer sich wandelnden Oberfläche kämpfen
Komplexität ist ein menschengemachtes Problem
- Blow argumentiert, Komplexität könne reduziert werden, wenn man sich dafür entscheide, und man bilde sich nur ein, durch zusätzliche Abstraktion Zeit zu sparen
- Das richtige Framework für den richtigen Zweck kann Webentwicklern stark helfen
- Zugleich bin ich skeptisch gegenüber dem Versuch, vom Textverarbeiten bis zu Spielen alles im Browser zu erledigen, oder gegenüber der Haltung, bei jedem neuen Framework sofort umzusteigen
- Software-Komplexität ist nicht nur ein Problem der Programmierer, sondern entsteht auch durch Markt- und Organisationsumfelder
- Unternehmenspolitik, sinnlose Meetings, schwer verständliche Zeiterfassungssoftware, extern gesetzte Deadlines, anspruchsvolle Kundenanforderungen, merkwürdige Managemententscheidungen, Aufwandsschätzungen für abstrakte Anforderungen und Debugging von Legacy-Code beeinflussen die Entscheidungen von Entwicklern
- Komplexität ist menschengemacht; reduziert man die Komplexität am Arbeitsplatz, kann langfristig auch die Software-Komplexität sinken
Junge Entwickler und die Fähigkeit, Engines zu bauen
- Blows Behauptung, junge Spieleentwickler hätten nie selbst eine Engine geschrieben und könnten diese Fähigkeit bald kollektiv vergessen, ähnelt einem Slippery-Slope-Argument
- Die meisten Menschen mit C64, Amiga oder 286-PC wurden keine Low-Level-Entwickler, und viele wurden überhaupt keine Programmierer
- Abstraktion und vorgefertigte Game-Engines ermöglichen kreatives Arbeiten, ohne Low-Level-Speicherverwaltung, Pointer oder Algorithmen beherrschen zu müssen
- Kinder wollen heute etwas bauen, das den AAA-Spielen aus dem Laden ähnelt, und die Erwartungen an moderne Spiele sind viel höher als zu Zeiten von C64 oder Amiga
- Wege zum Erwerb von Low-Level-Fähigkeiten existieren weiterhin
- Linux zieht über die Open-Source-Community junge Entwickler an und weckt Interesse an Systemsprachen wie Rust, C und C++
- dwm ist ein Window Manager, der durch Bearbeiten von C-Quellcode konfiguriert wird
- Es gibt junge Entwickler, die C und Z80-Assembler verwenden, Menschen, die Linux-Distributionen von Grund auf bauen, Leute, die eigene Hardware herstellen, und C-Entwickler, die Forschungsbetriebssysteme auf moderner Hardware betreiben
- Informatik- und Elektrotechnikstudiengänge lehren weiterhin Grundlagen wie C, Assembler und Compilerbau
- Der Zugang zu Programmierwerkzeugen, Literatur, Lernvideos und Materialien wie MIT OpenCourseWare ist günstiger und besser als früher
Abschließende Einschätzung: größere Probleme als Abstraktion
- Blows Fazit ähnelt einem auf Technologie übertragenen Survivalismus; die Analogie, dass man bei einem Stromausfall Menschen braucht, die Feuer machen können, ist nachvollziehbar
- Die Gesellschaft hängt von der Fähigkeit ab, manche Programme nahezu dauerhaft ausführen zu können
- Scheitern könnte gravierende Folgen wie einen Kollaps der Weltwirtschaft oder ein Versagen nationaler Gesundheitssysteme haben
- Da historische und aktuelle Aufzeichnungen zunehmend digital gespeichert werden, müssen sie auch künftig zugänglich bleiben
- Komplexität ist fragil, und Abstraktion kann schädliches Unwissen erzeugen; ein einfaches Blog braucht kein shadow DOM zum Rendern, und ein IRC-Client mit Bildern muss nicht in einer Browser-Hülle laufen
- Doch auch künstlicher permanenter Churn ist eine große Ursache von Verwundbarkeit
- „Agile“ Entwicklung soll eigentlich verhindern, dass Unfertiges und Ungetestetes ausgeliefert wird, führt in der Praxis aber oft zu einer endlosen Reihe unfertiger Releases
- Werbung, Tracker und Telemetriesysteme funktionieren faktisch wie Backdoors by design und erhöhen Verwundbarkeit und Unsicherheit
- Die größeren Probleme der digitalen Welt sind Privatsphäre und Freiheit
- Dass wir nicht mehr direkt mit Hardware interagieren können, liegt womöglich nicht daran, dass wir Abstraktion gewählt haben, sondern daran, dass immer mehr nur noch geschlossene und fernsteuerbare Plattformen übrig bleiben
1 Kommentare
Meinungen auf Hacker News
Ich unterrichte an der Montana State einen Systemkurs, der von Transistoren bis zu realen Computersystemen reicht, und zu Beginn des Kurses gibt es auch Studierende, die nicht richtig wissen, was ein Dateisystem ist.
Blow liegt bei einigen Details falsch, aber ich denke, dass man für Studierende technischer Fächer ernsthaft darüber nachdenken sollte, schon ab der Highschool eine Ausbildung im Stil von NAND-to-Tetris anzubieten.
Wir verwenden „alte“ Modelle wie den Little Man Computer oder einfache visuelle MIPS-Emulatoren; sie sind zwar nicht realistisch, vermitteln aber mit einer Komplexität, die normale Menschen verstehen können, ein Gefühl dafür, woher wir kommen.
Wenn ich mir heute empfohlene Lehrbücher zu 64-Bit-Architekturen ansehe, muss ich einfach lachen; Technologie bis zu ihren Wurzeln zurückzuverfolgen, ist ein schwieriges Problem.
Das Problem ist, dass mobile Betriebssysteme und Softwarefirmen Nutzerdaten möglichst zu einem eingezäunten Garten innerhalb der App machen wollen.
Selbst wenn man bereits mit Dateien arbeitet, zwingen sie einen dazu, bestehende Daten in ihren eigenen Speicher zu „importieren“, und geänderte Versionen muss man dann als neue Kopie manuell „exportieren“ oder „teilen“.
Ich mache gerade meinen Master in Wirtschaftsingenieurwesen an der Montana State und habe täglich mit Doktoranden zu tun, die nicht einmal einfache partielle Ableitungen beherrschen.
Letztes Semester gab es in einem Mathematikkurs auf 400er-Niveau sogar jemanden, der nicht wusste, wie man zwei Matrizen addiert.
Dass ein Informatikstudent im vierten Jahr kein Dateisystem kennt, ist auch seltsam, wirkt aber im Vergleich zu den absurden Dingen, die ich hier gesehen habe, fast harmlos.
Die Atmosphäre ist ganz anders als damals, als ich in den 2000ern zum ersten Mal an der Uni war, und das ist deprimierend; für den Arbeitsmarkt im nächsten Frühjahr bin ich dadurch aber eher zuversichtlich.
Entgegen dem Namen ist Informatik keine Wissenschaft über den Computer selbst; Computer sind zwar ein unverzichtbares Werkzeug, aber im Kern geht es um Abstraktionen von Domänen, Sprachmodellierung und deren Anwendung.
So wie Astronomen ein Teleskop nur so weit beherrschen müssen, wie es nötig ist, müssen Informatiker Computer nur so weit beherrschen, wie es nötig ist.
Den Computer ins Zentrum des Universums zu stellen und ihn zum Ausgangspunkt der Informatik zu machen, ist ein großer Fehler und historisch auch eine Quelle vieler Verwirrung.
Selbst „Low-Level“-Programmierung ist letztlich Abstraktion und Sprache; man verwendet lediglich die Sprache eines Rechengeräts, um die Abstraktion der betrachteten Domäne zu simulieren.
In meiner Freizeit dekompiliere ich MIPS-Assembly; kleine Funktionen kann ich sogar ohne weitere Tools von Hand wieder in den entsprechenden C-Code zurückführen.
Aber sie wird nicht verwässert. Weil es Unterricht, Bücher und Computer gibt, müssen wir Lehrkräfte nicht als Barden bezeichnen.
Am Ende ist das hier nur ein weiterer Blogpost über einen Blogpost, und ich weiß nicht, wie „wichtig“ diese Blogger sind, aber es riecht nach Bloggen um des Bloggens willen.
Wenn ein älterer Webentwickler Abstraktion kritisiert, zielt er auf React-Entwickler; wenn ein Python-Entwickler sie kritisiert, zielt er auf ältere Webentwickler; und wenn ein C++-Anwendungsentwickler sie kritisiert, zielt er auf Python-Entwickler.
Firmwareentwickler zielen auf Anwendungsentwickler, Elektroingenieure auf Firmwareentwickler.
Es ist schon eine bemerkenswerte Haltung, die Grenze der übermäßigen Abstraktion genau auf der Höhe des eigenen Wissens zu ziehen und alles danach als „tötet die Zivilisation“ zu bezeichnen.
Es gibt viele gute Punkte, und da ich den Vortrag ebenfalls gesehen habe, halte ich Kritik für wichtig.
Allerdings hat Blow recht, wenn er sagt, man könne „nicht einfach Pixel auf den Bildschirm zeichnen“.
Ich arbeite bei einem mittelgroßen Spieleunternehmen als Game-Engine-Programmierer, und es wird sehr schwierig, Leute einzustellen, die mit Grafikcode umgehen können.
APIs der Generation von DX12 haben die Anforderungen an Programmierer im Vergleich zur Vorgängergeneration DX11 enorm erhöht, und mit dieser API überhaupt etwas zu machen, ist schon eine große Aufgabe.
Microsoft hat einmal eingeräumt, dass es extrem schwierig sei, DX12 ohne vorherige Erfahrung mit Grafik-APIs zu lernen; inzwischen finde ich dieses Zitat in der Dokumentation aber nicht mehr.
Der Einwand „solche APIs sind für Entwickler gedacht, die Grafikkarten an ihre Grenzen bringen und sehr Low-Level-Optimierungen vornehmen wollen“ stimmt teilweise, aber inzwischen sind sie Branchenstandard, und Menschen ohne Vorerfahrung kann man sie kaum noch beibringen.
Wenn sich nichts ändert, wird der Pool einstellbarer Fachkräfte weiter schrumpfen.
Beim Erstellen von Softwareanwendungen ist selbst das Zeichnen eines einzelnen Buttons auf dem Bildschirm so schwierig geworden, dass die meisten einfach eine Progressive Web App verwenden, die 100-mal langsamer ist, als es die mögliche Leistung hergeben würde.
Ich frage mich, ob im Jahr 2025 wirklich Java Swing und Qt das Beste für GUI-Anwendungen sind.
Es gibt große Konzepte, die alles zusammenhalten, aber in der Dokumentation werden sie kaum angedeutet; man lernt sie nur, wenn man an Schulungen teilnimmt oder mit jemandem spricht, der sie bereits kennt.
Ich finde, dass Dinge wie serverseitiges JavaScript und React die Websoftware-Entwicklung gemessen an dem, was sie tatsächlich leisten, wirklich durcheinandergebracht haben.
Unter den Kindern von heute gibt es welche, die nicht einmal wissen, dass das, was im Browser gerendert wird, HTML ist. Sie glauben, React selbst werde vom Browser gerendert.
Außerdem hat der CEO von Vercel den absolut idiotischen Satz gesagt, React sei der Linux-Kernel der Entwicklung.
https://news.ycombinator.com/item?id=42824720
Ich bin lange genug dabei, um mich an die Zeiten von vanilla js, jQuery, Knockout und Angular 1 zu erinnern, aber grundlegende Verwirrung gab es auch damals immer.
React, manchmal sogar nur JSX, lässt sich durchaus vernünftig einsetzen.
Ich gebe eher den durch Venture Capital getriebenen Tools wie Vercel, Next, Apollo und Prisma sowie den Webentwicklungs-Influencern die Schuld, die dafür bezahlt werden, das Web mit Müll zu füllen.
Wenn man darüber nachdenkt, ist jeder Teil der Softwareentwicklung aufgebläht worden, von Notion-Boards bis hin zu fragwürdigen Datenbankentscheidungen.
Aber als jemand, der auch ohne Bibliotheken gut arbeiten kann, möchte ich hinzufügen, dass das DOM eine der schlechtesten APIs ist, die die Menschheit je erfunden hat, und dass „reaktive Programmierung“ dem alten Modell überlegen ist.
NextJS hat jahrelange Verbesserungen bei Tools zurückgedreht und ist deutlich langsamer als Vite.
Bei statisch gebautem NextJS lädt eine Seite ohne jegliche Interaktion 100 KB JavaScript herunter, nur um nichts zu tun.
Facebook versucht, etwas mit einem „Compiler“ für React zu lösen, das man im Grunde einfach dadurch beheben könnte, dass Komponenten nicht unnötig neu gerendert werden.
Im Vergleich zu Preact, das fast ein direkter Ersatz ist, ist React riesig und zeigt, wie wenig Facebook sich darum schert.
HTML ist ein Serialisierungsformat, und der Browser nutzt es, um im Speicher ein DOM aufzubauen.
React serialisiert nichts zu HTML, sondern rendert direkt ins DOM.
Dass das trotz seiner Falschheit viele Upvotes bekommen hat, zeigt gut, dass dieser Thread den Charakter eines „alten Mannes, der seine Faust gegen die Wolken schüttelt“ hat.
Nach meinem Verständnis ist HTML die Eingabe für den Browser, der sie in ein DOM umwandelt, worauf dann Zeichnen auf dem Bildschirm und Eingabeverarbeitung folgen.
Dieser Unterschied ist wichtig: React und virtuelle-DOM-JavaScript-Bibliotheken erzeugen kein HTML, sondern DOM-Manipulationsbefehle in JavaScript.
An Blows Kritik gibt es viele gute Punkte, aber ich finde, er übersieht, dass viele Rückschritte nicht aus generationenübergreifendem Abdriften oder Informationsentropie entstehen, sondern aus offenkundiger Böswilligkeit der Leute, die Entscheidungen treffen.
Blow trifft beim Thema Entwicklung oft wirklich hervorragende Punkte, liegt aber auch oft völlig daneben.
Er hat viel erreicht und hat Ideen, denen zuzuhören sich lohnt, aber es gibt auch viel Unsinn, der ununterscheidbar daneben präsentiert wird.
Die Sache mit dem Zusammenbruch der Zivilisation empfand ich stark als einen solchen Unsinn, und obwohl ich sie mir zweimal angehört habe, habe ich sie größtenteils ignoriert.
Ich bin dankbar, dass der Originalbeitrag eine grundsätzlichere Gegenrede liefert.
Casey Muratori imitiert Blow, bekommt meiner Ansicht nach aber nicht einmal die guten Teile richtig hin.
Muratori hat das Spiel, das er vor 10 Jahren begonnen hat, ebenfalls nicht fertiggestellt.
Mit modernen Game-Engines hingegen, sogar mit Dingen wie Raylib, kann man selbst bei einem Wochenend-Game-Jam ziemlich ordentliche Ergebnisse erzielen, und ein Sokoban-Spiel wie das von Blow ließe sich, besonders mit einem Team von etwa 10 Leuten, wohl in ungefähr 6 Monaten bauen.
Ich habe mir einige seiner Inhalte angesehen, und bei Themen, mit denen ich vertraut bin, wirkte er demütig, aber mit klaren Meinungen; außerdem finde ich, dass er bei Handmade Hero hervorragende Arbeit geleistet hat.
Wie lange Jira braucht, um ein Ticket anzuzeigen, wie lange Slack zum Wechseln eines Chatraums braucht, oder dass VSCode nicht mit normaler Tippgeschwindigkeit mithalten kann, ist wirklich verrückt.
Er scheint breite kritische Aussagen in den Raum zu werfen und dann wieder zu verschwinden, um nichts zu tun.
Man kann schwer behaupten, er habe Großartiges geleistet; ich finde, er hat ordentliche Arbeit gemacht.
Er hat nur zwei Spiele veröffentlicht, und die sind eher Puzzles als Spiele. Wenn man sie einmal beendet hat, gibt es kaum einen Grund, sie noch einmal zu spielen.
Braid ist okay, und The Witness ist einfach wie Flow.
Danach arbeitet er seit 10 Jahren an einer Programmiersprache, veröffentlicht sie aber nicht, weil sie „noch nicht fertig“ sei.
Seit er mit Glück Geld verdient hat, scheint er sich für weitaus talentierter zu halten, als er tatsächlich ist.
In der modernen Softwarelandschaft gibt es zweifellos viele Probleme, und übermäßige Abstraktion halte ich ebenfalls für eines davon.
Aber das entgegengesetzte Extrem ist auch schlecht, und es gibt eine Tendenz, die Vergangenheit zu sehr zu romantisieren.
Abstürze und Neustarts waren ebenfalls ein Problem, Systeme wie der Amiga hatten Kompatibilitätsprobleme zwischen Hardwareversionen, und selbst Systeme, die stark auf Kompatibilität setzten, waren nicht frei von Inkompatibilitäten.
Selbst unter Windows 11, dem instabilsten modernen System, ist mein Computer deutlich stabiler als jeder Rechner, den ich vor 2010 benutzt habe, und er kann sogar Software für Windows 95 ausführen.
Ein Computer, den man im Alltag nutzen kann, ist besser als einer, bei dem das nicht der Fall ist.
Nicht jede Vereinfachung ist eine Abstraktion, und nicht jede Abstraktion ist eine Vereinfachung.
Aber oft entstehen Abstraktionen aus dem Streben nach Vereinfachung.
Ich glaube nicht, dass Abstraktion Software oder die Zivilisation tötet, aber schlechte Abstraktionen, die mit kurzfristiger Vereinfachung begründet werden, verringern Flexibilität, Agilität und Zugänglichkeit.
Wenn man sich syntaktischen Zucker in fast jeder Sprache ansieht, kommt irgendwann der Punkt, an dem die lokale Vereinfachung, die man in genau dieser Nuance gewinnt, die gestiegene Komplexität des gesamten Werkzeugs nicht mehr rechtfertigt.
Dass Menschen in Sprachen mit viel Syntax Fehler machen, liegt nicht an einem einzelnen bestimmten Element, sondern daran, dass schon die Nutzung des Werkzeugs, um komplexe Probleme gut zu lösen, schwieriger wird.
Die zusätzliche Komplexität, die async und Coroutines in Kotlin meiner Erfahrung nach beim Umgang mit „threadähnlichem“ Code erzeugen, ist etwas völlig anderes als die Art, wie Elixir/Erlang dieselbe Art von Problem behandelt.
Beide bieten Abstraktionen und Vereinfachungen für das alte Problem paralleler und asynchroner Berechnung, aber Ersteres multipliziert Einfachheit über mehrere Schichten hinweg und erzeugt so wieder etwas Komplexes, während Letzteres eher eine wirklich einfache Abstraktion ist, die einfach funktioniert.
Der Autor scheint einer jüngeren Generation anzugehören und deshalb Blows Punkt verpasst zu haben, ohne ihn zu verstehen.
Ironischerweise wirkt der Text selbst wie ein Beispiel für das, wovon Blow sprach.
Es ist ähnlich, als würde man sagen, Figma ruiniere die Designwelt in beispiellosem Ausmaß, indem es Figmas eigene schlechte UX, UI und Produktmanagement-Praktiken normalisiert, und daraufhin reagieren junge Designer verwirrt, weil doch alles in Ordnung sei.
Dieses Wissen hat man, weil man in diesem Umfeld aufgewachsen ist; sie sind es nicht, und Dinge, die Kultur und Erfahrung betreffen, lassen sich auch nicht leicht irgendwo lernen.
Solche Ad-hominem-Angriffe tragen nichts zur Diskussion bei.
Entgegen der Aussage „Die Behauptung, Software mache Fortschritte, ist offensichtlich falsch“ nutze ich meine geliebten Amiga-Computer auch heute noch häufig.
Vor ein paar Wochen kopierte ich Dateien auf eine Amiga-Festplatte, als der Rechner plötzlich abstürzte – nicht, weil ich etwas falsch gemacht hatte, sondern weil alte Heimcomputer-Betriebssysteme nicht besonders stabil waren.
Dadurch wurde die Festplattenpartition beschädigt, das Betriebssystem konnte das Dateisystem nicht erneut validieren, und am Ende blieb mir nur, die Partition neu zu formatieren.
Von Design verstehe ich nicht besonders viel, aber ich kann erkennen, dass die Behauptung über Figma genauso völlig falsch ist wie Blows Behauptungen.
Das spricht die Nostalgie. Benutzeroberflächen waren schon immer voller Murks, und Software ebenso – wie alles andere auch.
Man erinnert sich nur an die Stärken der besten Beispiele der Vergangenheit und vergisst den ganzen Müll sowie selbst die Fehlschläge der gut gestalteten Dinge.
Das Problem sind Abstraktionen, die nicht gründlich durchdacht wurden.
Viele Abstraktionen wirken erkennbar wie ein erster Entwurf oder erster Versuch, werden aber wegen des Geschwindigkeitskults und der Arroganz der Tech-Branche veröffentlicht, bevor sie mehrfach überarbeitet wurden.
Sobald solche Abstraktionen Teil eines beliebten Projekts werden, kopieren andere sie aus Nachahmungstrieb unter dem verschwommenen Banner der „Best Practices“.
Wiederholt man diesen Prozess 10 bis 20 Jahre lang, entsteht ein riesiges Durcheinander.
Noch schlimmer ist, dass in einer durch Technologie paradoxerweise übersozialisierten Gesellschaft der soziale Konsens, nicht als „Betrüger“ entlarvt werden zu wollen, unausgereifte Lösungen immer weiter verbreitet.
Ich mag diesen Vortrag von Jonathan Blow und sehe ihn mir mindestens einmal im Jahr wieder an. Er sagt meiner Ansicht nach nichts Kontroverses; viele Entwickler werden wütend oder fühlen sich ertappt, weil sie insgeheim wissen, dass sie weder so gut wie möglich ausliefern noch die jüngere Generation richtig anleiten.
Wir sind bei einer Kultur angekommen, in der die Suche nach Neuem alltäglich ist und manchmal sogar gefeiert wird.
Früher waren ausreichend geprüfte Lösungen der kulturelle Maßstab; heute ist das Neue der Maßstab, unabhängig davon, ob es tatsächlich gut ist.
Man kann die Details von Blows Argumentation endlos auseinandernehmen, aber die Belege liegen überall offen vor uns.
Und über einen ausreichend langen Zeitraum kann das zum Zusammenbruch der Zivilisation führen; angesichts der Menge an kaputten Dingen in der Welt kann man auch sagen, dass es bereits geschieht.
Es ist bedauerlich, dass man eine fehlerhafte These so ausführlich zerlegen muss.
Ein reiner Empiriker ist der Realität genauso entrückt wie ein reiner Theoretiker, und Blow konstruiert Argumente, weil sie zu seiner eigenen Erfahrung passen, wählt nur Beispiele aus, die zu seinen Beschwerden passen, und erhebt Ausnahmen zur Regel.