Die Ernüchterung über Software

 (tonsky.me)
5 Punkte von GN⁺ 2023-10-24 | 2 Kommentare | Auf WhatsApp teilen
  • Moderne Software gibt den Fortschritt der Hardware nicht in Form von Effizienz, Einfachheit und Reife zurück, sondern normalisiert Ineffizienz unter der Annahme, dass „Computer schnell genug sind“
  • Selbst grundlegende Aufgaben wie Web-Scrolling, das Öffnen einer E-Mail in Google Inbox in 13 Sekunden, ein 30-minütiges Windows-10-Update oder Eingabeverzögerungen im Texteditor fühlen sich langsamer an als erwartet
  • Ein Android-System mit 6 GB, Windows 10 mit 4 GB, Google Keyboard mit 150 MB sowie Beispiele wie Electron-Apps und Slack zeigen, dass die Aufblähung von Apps und Plattformen zu Kosten bei Leistung, Komplexität und Zuverlässigkeit führt
  • Wie bei Updates von OS, Apps und Browsern oder dem Wegfall der 32-Bit-App-Unterstützung in iOS 11 kann Software, die einmal gut funktionierte, mit der Zeit langsamer werden oder kaputtgehen
  • Um bessere Software zu bauen, müssen Ingenieure die Leistung, Struktur und Grenzen der von ihnen gebauten Systeme verstehen und mit weniger Ressourcen schnelle und vorhersehbare Ergebnisse liefern

Software, die Leistung verschwendet

  • Moderne Software wird oft so akzeptiert, als sei es in Ordnung, wenn sie nur mit 1 % oder 0,01 % der möglichen Leistung läuft
  • Während Autos, Gebäude und Flugzeuge sich physikalischen Grenzen oder optimalen Formen annähern, rechtfertigt Software Ineffizienz mit dem Satz: „Computer sind schnell genug“
  • Das Sprichwort „Die Zeit des Programmierers ist teurer als die Zeit des Computers“ kann die Realität verschleiern, dass Computerzeit in nie dagewesenem Ausmaß verschwendet wird
  • Ein Tweet, in dem ein täglich ausgeführtes Python-Programm in Rust neu geschrieben und von 1,5 Sekunden auf 0,06 Sekunden verkürzt wurde, aber die investierten 6 Stunden sich erst nach mehr als 41 Jahren auszahlen würden, wird als repräsentatives Beispiel in der Effizienzdiskussion verwendet

Unerträglich langsame Grunderfahrung

  • Moderne tragbare Computer sind tausendfach leistungsfähiger als die Rechner aus der Zeit der Mondlandung, dennoch ist es selbst auf einem aktuellen MacBook Pro schwer, Webseiten mit 60 fps flüssig zu scrollen
  • Das von Google entwickelte Inbox benötigt in Google Chrome 13 Sekunden, um eine einzelne E-Mail zu öffnen
    • Statt Inhalte anzuzeigen, animiert es leere weiße Kästen, was eher wie ein Kompromiss wirkt, der an die Leistungsgrenzen von Webseiten angepasst ist
    • Selbst zu einer Zeit, in der 120-Hz-Displays Mainstream sind, gilt schon 60 Hz beim Anzeigen einer einzelnen Antwort in einer Web-Community nicht als stabil
  • Ein Windows-10-Update dauert 30 Minuten; in derselben Zeit könnte man eine SSD mehrfach formatieren, einen neuen Build herunterladen und installieren
  • Moderne Texteditoren haben mehr Eingabeverzögerung als das 42 Jahre alte Emacs
    • Es wird kritisiert, dass selbst eine Aufgabe, bei der pro Tastendruck nur ein kleines rechteckiges Gebiet aktualisiert werden muss, nicht innerhalb von 16 ms erledigt wird
    • 3D-Spiele rendern in denselben 16 ms den gesamten Bildschirm, verarbeiten Eingaben, berechnen die Welt und verwalten Ressourcen
  • Schnellere Hardware wird nicht für bessere Software genutzt, sondern dafür, Software auszuführen, die dieselbe Arbeit langsamer erledigt

Aufgeblähte Apps und Plattformen

  • Web-Apps können schon durch das Blockieren von Werbung 10-mal schneller werden, und AMP ist weniger eine neue Technologie als vielmehr eine naheliegende Lösung, überflüssige Teile zu entfernen
  • Ein Android-System belegt selbst ohne Apps 6 GB, Windows 95 hatte 30 MB und Windows 10 hat 4 GB
    • Windows 10 ist 133-mal größer als Windows 95, bietet aber aus dieser Sicht keine grundlegend anderen Basisfunktionen
    • Android ist sogar 1,5-mal größer als Windows 10
  • Google Keyboard belegt typischerweise 150 MB, die Google-App 350 MB und Google Play Services 300 MB
    • Kritisiert wird dies mit der Frage, ob Google Keyboard, eine App, die etwa dreißig Tasten auf den Bildschirm zeichnet, wirklich fünfmal komplexer sein müsse als das gesamte Windows 95
    • Google Play Services lassen sich selbst dann nicht entfernen, wenn man sie nicht nutzt
  • Die Situation, dass nach der Installation der Standard-Apps nur noch etwa 1 GB Speicherplatz für Fotos bleibt, wird dem früheren Zeitalter gegenübergestellt, als OS, Apps und Daten gemeinsam auf Disketten gespeichert wurden
  • Eine auf Electron basierende Todo-App kann sogar Xbox-360-Controller-Treiber, 3D-Grafik-Rendering, Musikwiedergabe und Webcam-Aufnahmefunktionen enthalten
  • Slack ist im Grunde eine App für Chat und einen einfachen Texteditor, wird aber wegen Ladezeit und Speicherverbrauch als schwergewichtige App eingestuft
  • Je größer Apps werden, desto mehr wachsen Kontrollverlust, Kosten der Komplexität, Leistungsverluste und Zuverlässigkeitsschulden; übermäßig schwere Apps dürfen nicht als normal akzeptiert werden

Software, die mit der Zeit verfällt

  • Vor drei Jahren reichte ein Android-Handy mit 16 GB noch aus, doch in der Ära von Android 8.1 wurden Apps ohne besonderen Grund doppelt so groß und dadurch schwer nutzbar
  • Das iPhone 4s wurde mit iOS 5 vorgestellt, aber iOS 9 auszuführen ist mühsam, obwohl iOS 9 auch nicht grundsätzlich viel besser sei
  • iOS 11 stellte die Unterstützung für 32-Bit-Apps ein, sodass Apps ohne Entwickler oder ohne Updates möglicherweise nie wieder nutzbar sind
  • Es wird ein Tweet zitiert, nach dem DOS-Programme seit den 1980er Jahren auf vielen Computern ohne Änderungen laufen, während eine JavaScript-App schon durch das nächste Chrome-Update kaputtgehen kann
  • Selbst eine Webseite, die heute einwandfrei funktioniert, könnte in zehn Jahren in keinem Browser mehr richtig laufen
  • Man kauft ein neues Smartphone und ein neues MacBook, um am Ende dieselben Apps nur langsamer auszuführen — und dieser Zustand wiederholt sich ständig

Gesunkene Qualitätserwartungen

  • Wenn Webseiten Probleme machen, verlangen sie oft einfach, dass man neu lädt, statt die Ursache zu untersuchen
  • Web-Apps können selbst in kompatiblen Browsern „zufällige“ JavaScript-Fehler ausspucken
  • Kritisiert wird, dass Webseiten und SQL-Datenbankdesigns auf der Hoffnung beruhen, dass sich Daten nicht ändern, während man die gerenderte Webseite betrachtet
  • Funktionen für Zusammenarbeit bleiben oft auf dem Niveau von „best effort“ und enthalten alltägliche Szenarien, in denen Daten verloren gehen können
    • Dialoge wie „Welche Version möchten Sie behalten?“ bedeuten faktisch oft nur, auszuwählen, welches Arbeitsergebnis zerstört werden soll
  • Linux ist trotz eines Designs, das Prozesse willkürlich töten kann, das populärste Betriebssystem auf Servern
  • Beispiele wie Dell-Monitore, AirDrop und Bluetooth zeigen, dass Software in Geräten und komplexe Spezifikationen Erfahrungen erzeugen, die von periodischen Resets oder Glück abhängen
  • Um etwas zuverlässig Funktionierendes zu liefern, muss man das Gebaute von innen und außen verstehen; in übermäßig aufgeblasenen Systemen ist das jedoch schwierig

Verwirrung bei Programmierwerkzeugen und Entwicklungspraktiken

  • Selbst bei Grundelementen wie Paketverwaltung, Build-Systemen, Compilern, Sprachdesign und IDEs ist schnelle, effiziente und langlebige Reife schwer zu finden
  • Build-Systeme verfügen über alle Informationen zu Änderungen und verlangen dennoch regelmäßig, alles zu löschen und neu zu machen
    • Es gebe keinen Grund, warum sie nicht zuverlässig, vorhersehbar und reproduzierbar gemacht werden könnten
    • NPM habe jahrelang in einem Zustand verharrt, den man als „funktioniert manchmal“ beschreiben könne
    • Es wird ein Tweet zitiert, wonach rm -rf node_modules in der Node.js-/JavaScript-Entwicklung unvermeidlich wirke
  • Dass Compiler und Vor- oder Nachverarbeitung Minuten oder Stunden dauern dürfen, steht im Widerspruch zu der Aussage, die Zeit des Programmierers sei wichtig
  • Fälle, in denen Hadoop gewählt wird, obwohl es langsamer ist als die Ausführung auf einem einzelnen PC, zeigen, dass Programmierer nicht immer rationale Entscheidungen treffen
  • Maschinelles Lernen und „künstliche Intelligenz“ hätten Software in ein Zeitalter unzuverlässiger Vermutungen verschoben
    • Ein Tweet wird zitiert, nach dem Apps oder Dienste mit „künstlicher Intelligenz“ oder „Machine Learning“ als unzuverlässig, unvorhersehbar und schwer erklärbar zu lesen seien
  • Linux in einer VM zu betreiben und in der VM dann Docker zu verwenden, wird als Zeichen interpretiert, dass man nicht weiß, wie man Programme, Sprachen und Laufzeitumgebungen sauber aufräumt
    • Dass die einzelne ausführbare Datei von Go als zentraler Vorteil gilt, zeige eine Lage, in der es schon als Erfolg gilt, einfach kein totales Chaos zu sein
  • Abhängigkeiten lösen einfache Probleme als „komplette Paketlösung“, ziehen dabei aber Einführungskosten und weitere Abhängigkeiten nach sich
  • Es wird kritisiert, dass Programme kaum über Jahre ohne Neustart genutzt werden können, manchmal nicht einmal über Tage
    • Prozessneustarts, Datenbank-Restarts, Watchdogs, die Apps alle 20 Minuten neu starten, redundante Ressourcen und komprimierte Übertragung sind Wege, schnell weiterzumachen, statt Dinge zu reparieren
  • Solche Praktiken seien keine Ingenieurskunst, sondern faules Programmieren; Ingenieurskunst bedeute, Leistung, Struktur und Grenzen des Gebauten tief zu verstehen

Aufgetürmte Komplexität und Gleichgültigkeit des Marktes

  • Heutige Software ist ein Zustand, in dem auf Code, der gerade so funktioniert, wieder Code gestapelt wird, der ebenfalls gerade so funktioniert; alles wächst weiter, wird komplexer, und die Chancen auf Veränderung schwinden
  • Ein gesundes Ökosystem braucht gelegentlich einen Rückschritt, bevor es wieder vorangeht, doch seit 25 Jahren habe man keinen neuen OS-Kernel gesehen, und inzwischen sei alles zu komplex geworden, um es neu zu schreiben
  • Auch bei Browsern sei es wegen Edge Cases und historischer Altlasten schwer, eine Layout-Engine von Grund auf neu zu schreiben
  • Der heutige Fortschritt wirkt, als würde man zur Lösung von Monolith-Problemen Microservices einführen, zur Lösung von Microservices-Problemen Docker und zur Lösung von Docker-Problemen Kubernetes — also immer mehr Brennstoff ins Feuer gießen
  • Es wird ein Tweet zitiert, wonach man von XML-basierter deklarativer Konfiguration zu YAML-basierter Microservices-Konfiguration gewechselt sei, XML aber wenigstens noch ein Schema hatte
  • Nutzer können am Ende nur akzeptieren, was Ingenieure liefern, und haben selbst bei 350-MB-Android-Apps, ruckelndem Scrollen oder „Wenn es nicht funktioniert, starten Sie neu“ kaum Alternativen
  • Wenn konkurrierende Produkte ebenfalls langsam, groß und qualitativ schwach sind, entsteht kaum Wettbewerbsdruck
    • Produkte, die zeitweise Spannung erzeugen — etwa iPhone/iOS gegenüber anderen Smartphones oder Chrome gegenüber anderen Browsern — halten aus dieser Sicht nicht lange an
  • Die Aufgabe von Ingenieuren sollte sein zu zeigen, was auf modernen Computern bei Leistung, Zuverlässigkeit, Qualität und Verfügbarkeit möglich ist

Dennoch sichtbare Alternativen

  • Martin Thompsons LMAX Disruptor, SBE und Aeron werden als beeindruckende, einfache und effiziente Beispiele genannt
  • Raph Leviens Xi editor wird als mit den richtigen Prinzipien im Hinterkopf gebaut bewertet
  • Jonathan Blow entwickelte für sein Spiel eine eigene Sprache und kann auf seinem Laptop 500.000 Zeilen Code in 1 Sekunde vollständig neu kompilieren
    • Das Ergebnis ist ein vollständiger Neu-Compile, kein inkrementeller Build und keine Zwischen-Cache-Lösung
  • Zum Schreiben schneller Programme brauche es weder Genie noch Magie; man müsse nur vermeiden, auf einem gigantischen Müllhaufen aus trendigen Toolchains zu bauen

Forderungen für bessere Software

  • Software Engineering darf nicht im aktuellen Zustand verharren, sondern muss besser werden; es gibt keinen Grund, immer wieder dasselbe nur langsamer und größer zu bauen
  • Die heutige Entwicklung ähnelt weniger Fortschritt als einem Zustand, in dem auf brüchigen Werkzeugen gerade so die Geschäftsziele erfüllt werden
  • Es wird kritisiert, dass man sich durch lokale Optimierung an Aufblähung und Ineffizienz gewöhnt habe
  • Ingenieure können und sollten mit besseren Werkzeugen bessere Apps mit um ein Vielfaches weniger Ressourcen schnell, vorhersehbar und zuverlässig bauen
  • Um zuverlässige, vorhersehbare und hochwertige Produkte zu liefern, muss man vollständig verstehen, was man warum tut; die Ausrede „So ist es eben gegeben“ ist nicht akzeptabel

Verwandte Beiträge

2 Kommentare

 
xguru 2023-10-24

Für diesen Text gibt es bereits seit Längerem eine koreanische Übersetzung, sehen Sie sich also bitte diese an.

https://tonsky.me/blog/disenchantment/ko/

Ich habe den Link direkt durch den Übersetzungslink ersetzt.
 
GN⁺ 2023-10-24
Meinungen auf Hacker News

  • Kleinerer, saubererer, weniger fehleranfälliger, sichererer, schnellerer und langlebigerer Code ist natürlich möglich. Wenn wir das schon in den Anfangstagen des Informationszeitalters geschafft haben, gibt es keinen Grund, warum wir es heute mit Jahrzehnten an Erfahrung und mächtigen Werkzeugen nicht schaffen sollten.
    Der Grund, warum wir es nicht tun, ist, dass damit kein Geld zu verdienen ist – tatsächlich ist eher das Gegenteil der Fall. VC-finanzierte Startups müssen zuerst auf den Markt, um zu überleben, und auch in reifen Organisationen sind Kosten und Aufblähung kein Problem, sondern funktionieren fast wie ein Feature, das das Prestige von Managern erhöht. Am Ende werden die Kosten an die Kunden weitergereicht.
    Dass die „unerbittlichen Marktkräfte“ diese Verschwendung nicht korrigieren, liegt wohl daran, dass eine bessere Codebasis zwar irgendwann den Schlüssel zum Königreich bekommen könnte, das reale Wettbewerbsumfeld aber zu anfällig für Pathologien und Moden ist.

    • Kagi hat keine VC-Finanzierung erhalten, aber trotzdem suboptimalen Code, viele Bugs und hier und da merkwürdige Performance-Probleme. Aus Sicht von jemandem, der Softwareentwicklung kennt, ist das unabhängig von Finanzierungsquelle oder Unternehmensgröße schwer zu vermeiden; ich sehe es als Funktion von Softwarekomplexität, verfügbaren Ressourcen und Anreizen.
      Was man allerdings leichter tun kann als VC-finanzierte Unternehmen, ist, Zeit für Refactoring und den Abbau technischer Schulden einzuplanen. Tatsächlich treten wir gerade 45 Tage lang bei der Entwicklung neuer Funktionen kräftig auf die Bremse und kümmern uns um wichtige technische Probleme. Wenn man erwartet, nächstes Jahr übernommen zu werden, ist es schwer, solche Investitionen zu tätigen, und technische Schulden werden zum Problem anderer Leute.
      Solange ein Produkt weiterentwickelt wird, entstehen ständig neue Bugs und Probleme. „Perfekter Code“ ist nur in einem geschlossenen Kontext möglich, in dem keine neuen Funktionen mehr hinzugefügt werden.
    • Die Aussage „Damit ist kein Geld zu verdienen. Tatsächlich ist es das Gegenteil“ ist es wert, wiederholt zu werden. Das ist die Krankheit, die Software verschlungen hat, und sie macht moderne Software zur schlechtestmöglichen Version ihrer selbst.
      Ich denke, das VC-Investmentmodell hat die Branche dorthin getrieben. Startups bekommen Millionen von Dollar und müssen schnell genug Geld verdienen, um die Investoren zufriedenzustellen; also müssen sie so schnell wie möglich Geld aus der App pressen. Arbeit, an der keine ROI-Kennzahl hängt, interessiert niemanden.
    • Ich glaube nicht, dass frühere Software sicherer war. Computernutzer waren nur naiver und vertrauensseliger. Als mehr Maschinen ans Netz gingen, haben wir viel gelernt.
      Im Grunde gab es offenen Zugriff, keine Passwörter oder kurze Passwörter, unsichere Passwortspeicherung, alles im Klartext, ignorierte Eingabebereinigung, Dinge wie telnet.
      Darin liegt ein weiterer Grund, warum Software aufgeblähter geworden ist. Wir haben begonnen, Interaktionen und Risiken zu sehen, und wenn man sie einmal sieht, kann man nicht mehr so tun, als hätte man sie nicht gesehen. Die Randfälle, die behandelt werden müssen, werden nicht weniger, sondern mehr, und auch die zu unterstützende Hardware wird vielfältiger.
      Der Prozess, performanten Code zu schreiben, kann verbessert werden, aber gleichzeitig steigt die Messlatte schneller, als wir sie erreichen. Interessant ist auch, dass wir uns jetzt wieder langsam in Richtung passwortloser Systeme bewegen.
    • Ich stimme zu, dass die Anreize nicht passen. Es gibt Industriebereiche, in denen Performance und Korrektheit echten Wert haben. Wenn man wie der Autor Software-Handwerkskunst wichtig findet, ist der Wechsel in solche Bereiche der beste Weg, die Arbeit zu genießen.
    • Vereinfacht gesagt veröffentlicht man nicht Code, sondern Funktionen. Man veröffentlicht keine automatische Dependency Injection, eleganten Abstraktionen oder schicken Compiler-Tricks, sondern neue Funktionen, für die Kunden bezahlen.
      Eine hohe Unit-Test-Abdeckung, die Refactoring schmerzhaft macht, behindert oft die Veröffentlichung von Funktionen – und meiner Meinung nach deutlich häufiger, als Test-Driven-Development-Fanatiker zugeben wollen. Viele „Best Practices“ der Branche sind eher unrealistische Dogmen, die von Leuten in Unternehmen entwickelt wurden, die Product-Market-Fit bereits gefunden haben und bei denen das Geld von selbst hereinkommt.

  • Ich habe noch einen HP MS200 All-in-One, der gerade noch benutzbar ist. Ich habe ihn 2017 günstig auf einem Garagenverkauf gekauft, und mit Linux konnte er, sobald Chrome geladen war, im Web-Client von Skype Vollbild-Videoanrufe oder YouTube im Vollbild abspielen.
    Kürzlich habe ich ihn wiederbekommen und vor der Einrichtung als Kindercomputer FC38 und das aktuelle Chrome installiert; danach wurden YouTube-Videos zur Diashow. Egal, welche Einstellungen ich änderte, es half nichts. Als ich den RAM von 2 GB auf 3 GB erhöhte, war er wieder auf dem Niveau von vor sechs Jahren: 720p-Wiedergabe im Vollbild.
    Für dieselbe Aufgabe braucht man also 1,5-mal so viel Speicher, 1 GB mehr. Ich weiß auch, dass 16 GB als Minimum gelten, aber selbst auf dieser miesen Maschine zeigt Chrome, obwohl es fast nur ein im Leerlauf befindlicher Webbrowser ist, einen Speicher-Footprint von etwa 30 GB an. Das meiste davon werden per mmap eingebundene Dateien sein, aber trotzdem: 30 GB.

    • YouTube ist ein gutes Beispiel für Performance-Unterschiede. Die Videoqualität ist dank moderner Codecs gestiegen, aber alte oder billige Maschinen haben keine aktuelle GPU und müssen in Software dekodieren, manchmal sogar per JavaScript, was extrem verschwenderisch ist, aber auf allen Maschinen funktioniert.
      Umgekehrt sind auf den meisten Geräten längere Akkulaufzeit, niedrigere Temperaturen sowie geringerer RAM- und Speicherbedarf klare Verbesserungen. YouTube könnte alte Encodings zusätzlich auf seinen Servern behalten, aber wenn die meisten Nutzer mit modernen Geräten zugreifen, wäre das Platzverschwendung.
      Der größte Teil des gestiegenen RAM-Verbrauchs von Chrome stammt aus der Weiterentwicklung der Sandbox-Architektur. Gemeinsamer Speicher und Prozessräume können für Sandbox-Escape-Angriffe genutzt werden, daher wurde mehr Isolation hinzugefügt; außerdem ist es ein großer Faktor, dass Chrome für jeden Tab und jede Erweiterung einen neuen unabhängigen Prozess startet.
      Heutzutage haben auch Adblocker großen Einfluss. Da das Web schlechter geworden ist, sind wirksame Adblocker schwieriger zu bauen und benötigen mehr Ressourcen. Langsame Software ist nicht einfach langsamer geworden, um Menschen zu ärgern; oft ist sie das Ergebnis davon, gefährliche Hacks durch gute Implementierungen zu ersetzen und geänderte Anforderungen zu erfüllen. FLV reicht längst nicht mehr aus, und auch h264 wird es schwer haben, in fünf Jahren noch lange durchzuhalten, wenn h265 und AV1 weiter verbreitet sind.
    • Webbrowser sind faktisch zu eigenen Betriebssystemen geworden. Das „moderne Web“ hat zu viele Funktionen, und oft wird dieselbe Funktion auf fünf oder sechs konkurrierende Arten implementiert. Selbst auf moderner Hardware kann allein Textrendering eine erhebliche Last sein.
      Moderne Toolchains konzentrieren sich auf „das Rad nicht neu erfinden“, aber wenn jede Abhängigkeit eine andere Version des Rads gewählt hat, zieht man schon mit ein paar Abhängigkeiten sechs Implementierungen derselben Low-Level-Funktion herein.
    • Jedes Mal, wenn ich ein neues Linux installiere, gebe ich der Standard-UI eine Chance, kehre am Ende aber doch zu MATE zurück. Auf dieser alten Maschine reagierte Gnome Shell allerdings ziemlich knackig, es gab einen App Store und auch Chrome.
      Installiert war allerdings Flatpak, und es fühlte sich aufgebläht an. Zum Glück lässt sich Chrome noch direkt nativ als RPM installieren und nutzt tatsächlich die Shared Libraries des OS.
    • Ich erinnere mich noch an die Zeit, als man unter Linux/X11 8 MB brauchte, um einen grafischen Webbrowser laufen zu lassen. Vermutlich war es Netscape Navigator; 8 MB reichten, und mit 16 MB war es etwas komfortabler.

  • Dieser Text berührt nicht einmal den Kernschmerz: Bugs. Fast jede Software fühlt sich an, als wäre sie so verbuggt wie nur möglich. Jedes Mal, wenn ich Software auf einem ungewöhnlichen Pfad oder in einem nicht normalen Ablauf benutzen muss, bekomme ich Angst – und fast immer scheitert es.
    Vor Kurzem habe ich beim Verkauf meines Autos an Carvana nur mit Mühe zwischen Chrome und Firefox hin und her gewechselt, bis es endlich klappte. In Chrome warf der Assistent zum Hochladen von Bildern eine JS-Exception; dieser Teil funktionierte wie durch ein Wunder nur in Firefox, aber der Rest der Website hatte so viele Probleme, dass offensichtlich war, dass Firefox kaum getestet worden war.
    Noch schlimmer ist, dass nichttechnische Nutzer, wenn sie auf Bugs stoßen, denken, sie hätten etwas falsch gemacht. Selbst wenn Software aufgebläht und langsam ist: Wenn sie stabil und robust wäre, würde ich das inzwischen bereitwillig akzeptieren.

    • Einerseits ist es unglaublich, dass das, was wir heute haben, überhaupt so gut funktioniert. Jede Schicht wirkt, als wäre sie mit Panzertape und Kaugummi zusammengehalten, und trotzdem läuft sie tatsächlich. Was die Menschheit geschafft hat, erstaunt mich jeden Tag.
      Andererseits sehe ich ständig, wie verbuggt alles ist, und ich weiß nicht, ob es tatsächlich mehr Bugs geworden sind oder ob ich, je älter ich werde und je mehr ich die Interna kenne, einfach weniger Geduld für Softwareentwicklung nach Großkonzern-Art habe. Ich ärgere mich über den imaginären Product Owner, der sagt: „Feature X muss sofort raus“, obwohl offensichtliche UX-Bugs leicht zu finden wären.
    • Seit ich Jonathan Blows Vortrag „The End of the World“ gesehen habe und darauf achte, fällt mir auf, wie erstaunlich viele miserable Software-Erfahrungen wir im Alltag einfach hinnehmen.
      Ich verstehe Argumente wie Kosten, Opportunitätskosten und Pragmatismus und stimme ihnen teilweise zu, aber manchmal lässt sich das Gefühl kaum abschütteln, dass wir einfach akzeptiert haben, in einer halb fertig gebauten Welt zu leben.
    • Als ich Teenager war und das MacBook Air der ersten Generation herauskam, fand ein Freund heraus, dass man ein Demo-Gerät im Laden zuverlässig zum Absturz bringen konnte, indem man einfach die Apps im Dock schnell hintereinander öffnete. Ein paar Sekunden Klicken, und die Maschine stürzte ab und startete neu.
      Ich glaube nicht, dass es heute besser ist. Wenn kleine Kinder ein Smartphone oder einen Laptop in die Hand bekommen, können sie moderne Geräte ziemlich zuverlässig zum Hängen, Einfrieren und Abstürzen bringen, indem sie nur Tasten zu schnell oder in unerwarteter Reihenfolge drücken. Sie machen physisch nichts kaputt – und trotzdem ist das der Zustand moderner Technik.
      Ich verstehe, warum es nicht behoben wurde. Die Leute haben sich daran gewöhnt, dass gelegentlich ein Neustart nötig ist; in solchen Fällen ist es leicht, dem Kind die Schuld zu geben, und ein Neustart löst das Problem. Trotzdem hätte ich gehofft, dass Betriebssysteme über ihren Lebenszyklus hinweg inzwischen besser geworden wären.
    • https://danluu.com/everything-is-broken/
    • Ich glaube nicht, dass Software heute viel verbuggter ist als früher. Wer Ende der 90er und Anfang der 2000er Windows-Rechner supportet hat, weiß das.

  • In meinem Text über C habe ich es nicht erwähnt, aber einer der Hauptgründe, warum ich C verwende, ist, dass es schwer ist, damit Software aufzublähen. Man kann Funktionen hinzufügen, aber es ist nicht leicht, dass eine einzelne Funktion gleich 100 KB zur ausführbaren Datei hinzufügt.
    Ich bin derzeit nicht angestellt, nutze aber für „Arbeit“ eine leistungsstarke Maschine. Trotzdem verwende ich statt einer IDE Neovim und tmux, statt einer gewöhnlichen Linux-Distribution ein stark angepasstes Gentoo und statt systemd OpenRC; außerdem nutze ich statt einer vollständigen Desktop-Umgebung den Tiling-Window-Manager Qtile.
    Ich halte die Maschine schlank, sodass direkt nach dem Booten und Einloggen nur 40 Prozesse laufen. Im Moment betreibe ich wirklich Software-Engineering. Ich versuche, die Probleme von C effektiv abzumildern und die Software gleichzeitig klein und schnell zu halten, und hoffe, darauf eines Tages ein Geschäft aufbauen zu können.
    Ich werde wohl sehen, ob es noch einen Markt für schlanke, flinke Software gibt.
    https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
    https://gavinhoward.com/2020/12/my-development-environment-a...
    https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
    https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

    • Eine interessante Sichtweise. Ich bin alt genug, um mich an Zeiten zu erinnern, in denen die Sprache C im Vergleich zu direkt geschriebenem Assembler als aufgebläht galt.
      Programme wie WordPerfect, Lotus 123, MS-DOS 1.0 und SubLogic Flight Simulator vor der Übernahme durch Microsoft wurden in den 1980ern in Assembler geschrieben. Branchenbeobachter sahen damals, dass Microsoft bei MS Word und MS Excel schneller neue Funktionen iterierte und schneller auf andere Architekturen portierte als WordPerfect und Lotus 123, weil diese Programme in „aufgeblähtem“ C geschrieben waren. Die Konkurrenten blieben zu lange bei Assembler.
      Bei persönlicher Software sehe ich denselben Trade-off. Wenn man statt schlankerem C/C++ ein höheres und „aufgeblähteres“ C#/Python verwendet, kann man bestimmte Aufgaben viel schneller erledigen. Ich bin in C++ geübter und bevorzuge kleine ausführbare Dateien, aber wenn C# die gewünschte Arbeit schneller fertig bekommt, wird dieser Vorteil bedeutungslos. Auch ich bin Teil des Problems aufgeblähter Software.
    • Ich sehe „echtes Engineering“ darin, solche Entscheidungen auf einem Spektrum von Trade-offs zu verorten und ein Projekt passend zu den Einschränkungen der Ersteller und der Nutzer zu positionieren. Das Ergebnis kann an einem Extrem liegen, aber das bedeutet nicht, dass Menschen, die wegen anderer Einschränkungen an einer anderen Stelle landen, kein „echtes Engineering“ betreiben.
      „Ich werde die stärkste und leichteste Brücke der Welt bauen“ ist etwas Wunderbares; „ich werde eine Brücke bauen, die leicht genug und stark genug ist, zu Kosten, die der Kunde tragen kann“ ist Engineering.
    • Es hieß, dass eine einzelne Funktion kaum 100 KB zur ausführbaren Datei hinzufügt; mit Unicode-Unterstützung sieht das anders aus.
    • Ich würde gern mehr darüber hören, was mit „die Probleme von C effektiv abmildern“ gemeint ist. Geht es darum, die Probleme der Sprache selbst zu lösen, einen neuen C-Dialekt zu verwenden, Ökosystemprobleme wie die Schwierigkeiten beim statischen Linken von glibc, oder um etwas ganz anderes?
    • Mit „Ich habe schon einmal ein C++-Jobangebot abgelehnt“ kann ich mich identifizieren.

  • Ich habe etwas mehr als die Hälfte gelesen und dann aufgehört, aber die zentrale These schien zu sein, dass Software schnell sein müsse; an eine Rechtfertigung dieser Philosophie erinnere ich mich außer der Andeutung „das ist einfach wahr“ nicht. Der Einwand, dass es Fälle gibt, in denen Effizienzgewinne die Zeitkosten der Effizienzjagd niemals aufwiegen, wurde zwar anerkannt, aber die Argumentation wurde nicht wirklich aufgegriffen
    Ein weiteres zentrales Merkmal des Textes war das Cherry-Picking von Daten und die übermäßige Vereinfachung des Bereichs. Mehrfach wird emotional gefragt: „Was zum Teufel macht Software eigentlich mit all dieser Zeit und diesem Speicherplatz?“, aber es wird nicht ernsthaft versucht, diese Frage zu beantworten; stattdessen wird die Tatsache, dass keine Antwort gegeben wird, wie ein Beleg für eine falsche Antwort benutzt. Teilweise werden auch mehrere Softwareprodukte ohne Funktionsgleichheit so verglichen, als unterschieden sie sich nur in der Performance
    Über die sozialen, ökologischen und geschäftlichen Kosten von Ineffizienz und über effizientere Software ließe sich viel sagen, aber auch der Punkt ist diskussionswürdig, dass moderne Software Menschen, die sonst überhaupt nichts bauen könnten, ermöglicht, etwas „Schlechtes“ zu bauen, das sie brauchen. So wie Bauingenieure etwas auswählen, das „stark genug“ ist, zielen moderne Entwickler oft auf etwas ab, das „schnell genug“ ist
    Es gibt reichlich Stoff für eine gute Debatte, aber dieser Text blieb bei emotionaler Empörung stehen und setzte sich nicht wirklich mit Vernunft und Argumenten auseinander. In einigen Behauptungen steckt Wahrheit, aber der Text selbst hat meiner Meinung nach deutlich gemacht, dass er gar nicht diskutieren will

    • Aus Nutzersicht stimmt es, dass Software schnell sein muss. Man muss nur überlegen, ob dieser Kommentar auf einem iPhone 4 oder einem iPhone 14 geschrieben wurde, und ob die Workstation ein Pentium mit 4 GB RAM ist
      Auch das Netzwerk ist wahrscheinlich kein 2G mit ein paar kbit/s, sondern 5G oder Glasfaser mit Hunderten Mbit/s. Am Ende sprechen Taten lauter als Worte, und wenn die Gesellschaft als Ganzes dem Axiom „schnellere Software“ folgt, kann man es als Tatsache akzeptieren
      Besonders, weil es ein Axiom aus derselben Ecke ist wie die Behauptung „Entwicklerzeit ist wertvoller“; der Unterschied liegt nur darin, wessen Zeit man spart
    • Wenn Code auf einem teuren M1 Mac ein paar Sekunden braucht, muss ein ziemlich großer Anteil potenzieller Nutzer möglicherweise Minuten warten. Nichttechnische Nutzer wissen oft nicht, dass sich die Performance auch ohne den Kauf neuer Hardware stark verbessern ließe, und nehmen solche Absurditäten deshalb einfach hin
      Wenn Entwickler nicht auch auf Low-End-Geräten testen, bekommen sie dieses Problem überhaupt nicht mit. Das eigentliche Problem ist weniger technischer Natur als die Haltung mancher Entwickler, defensiv zu werden und erst einmal zu diskutieren, wenn sie mit der unbequemen Wahrheit konfrontiert werden, dass ihr Code zu langsam ist. Man sollte sich mit dem Produktmanager zusammensetzen, Zeit für Profiling und Optimierung einplanen und prüfen, wie sich Performance-Probleme entschärfen lassen, ohne alles von Grund auf neu zu bauen
    • Mir gefiel die emotionale Empörung. Manchmal verschleiern Daten nur die Wahrheit, die man bereits kennt. Man braucht keine Daten, die einem sagen, dass man sein Bestes geben sollte, um die beste Software zu bauen; dieser Text erinnert einen daran
    • Bei „moderne Software ermöglicht es Menschen, etwas Schlechtes zu bauen“ ist mir nicht klar, was genau an moderner Software besonders sein soll. Unklar ist auch, nach welchem Maßstab etwas als modern gilt
      BASIC und SQL hatten schon vor langer Zeit den Zweck, Menschen zu ermöglichen, etwas „Schlechtes“ zu bauen, und dasselbe gilt für Fortran und viele inzwischen verschwundene Sprachen und Technologien
      Python oder Java sind wohlwollend betrachtet konservativ; wenn man an die Fortschritte bei Programmiersprachen in den 70ern denkt, müsste man sie eigentlich anachronistisch nennen. J oder Prolog sind konzeptionell viel weiter als Rust oder Go, wurden aber früher entwickelt. Ob C in seiner von C89 bis C23 akkumulierten Form eine moderne Sprache ist, ob nur C23 modern ist, oder ob es zwischen C89 und C23 wirklich einen großen Unterschied gibt, ist ebenfalls unklar
      Wenn es nicht um den Entstehungszeitpunkt oder einen imaginären Evolutionsbaum geht, frage ich mich, ob es eine andere Möglichkeit gibt, Modernität zu definieren
    • Ich denke, der Autor hat seine eigene Frage in dem frühen Absatz beantwortet: „Nur bei Software ist es in Ordnung, wenn Programme mit 1 % oder 0,01 % der möglichen Performance laufen. Offenbar finden das alle in Ordnung.“ Wenn alle es in Ordnung finden, kann man es dabei belassen

  • Das ist eine alte Beschwerde. Viele Bequemlichkeiten, die wir als selbstverständlich ansehen, haben Kosten, und diese Kosten summieren sich beträchtlich. Ein 4K-Bildschirm hat 17-mal so viele Pixel wie 800x600 und verwendet 32-Bit-Farbe, wodurch die Rohgröße von Grafiken für moderne Displays etwa 68-mal größer wird
    Früher reichten statische Bilder aus, heute sind hochwertige Animationen mit hoher Bildrate Standard. Arial Unicode ist eine 15 MB große Schriftart und hätte wohl nicht einmal in den Arbeitsspeicher der meisten Computer gepasst, auf denen Windows 95 lief
    Rechtschreibprüfung überall ist selbstverständlich geworden, und solche Dinge summieren sich. Trotzdem machen sie Computer deutlich angenehmer. Ich vermisse weder 16-Farben-Videomodi noch die Zeit, in der man ohne extrem nervige Workarounds nicht zwei nicht-englische Sprachen gleichzeitig verwenden konnte

    • Selbst unter denselben 4K- und Unicode-Beschränkungen gibt es Apps, die um mehrere Größenordnungen effizienter sind; allein dadurch lässt es sich also nicht erklären
    • Es stimmt, dass es Kosten gibt, aber diese Kosten sind nicht immer ihren Preis wert. Ich will einen 4K-Bildschirm und bin bereit, den Preis für diese Pixel zu zahlen
      Aber Animationen, deren einziger Zweck darin besteht, Wartezeiten weniger langweilig erscheinen zu lassen, will ich nicht. Unicode ist die Kosten ebenfalls wert
      Trotzdem sollte man Glyphen wie 1981 innerhalb einstelliger Millisekunden auf den Bildschirm zeichnen können. Es gibt mehr Pixel und mehr Glyphen, aber es ist möglich; es hat nur keine Priorität
    • Ich verstehe, dass alle Ausgaben deutlich mehr Ressourcen fressen, aber es braucht eine Erklärung dafür, warum Software trotz 100-mal mehr Rechenressourcen immer noch schmerzhaft langsam ist
      Das ist so ähnlich, als würde man 100.000 Dollar für einen Performance-BMW bezahlen und der Ingenieur sagt, 0–60 mph dauere 30 Sekunden, und der Nutzer müsse das akzeptieren, weil er kein Performance-Experte ist

  • In meiner aktuellen Organisation habe ich einen ähnlichen Verlauf gesehen. Am Anfang, als das Team klein war, waren Details wichtig. Es durfte nicht langsam sein, Animationen mussten flüssig laufen, Scrollgeschwindigkeit und Ladezeiten waren wichtig, und man wollte das effizienteste Produkt bauen, um die Effizienz der Nutzer zu erhöhen.
    Als das Team wuchs, verschob sich der Wert hin zur Steigerung der Entwicklereffizienz. Mehr Abstraktionen, Schichten und Frameworks kamen hinzu, und der Kompromiss, einen Entwicklertag zu sparen, dafür aber insgesamt Millionen Sekunden der Nutzer zu verbrauchen, wurde akzeptiert.
    Der Unterschied liegt in der Sichtbarkeit. Das Management kann die Kosten auf Entwicklungsseite sehen, aber nicht den Nutzen von etwas schnellerer Ausführungszeit, besserem Caching oder flüssigerem Scrollen. Weil das nicht gemessen wird. Wenn eine Organisation an den Punkt kommt, an dem sie sich nur noch um messbare Zahlen kümmert, wirkt diese Entwicklung natürlich.

    • Man muss nur abwarten, welche verheerenden Auswirkungen LLMs in den nächsten Jahren auf Codequalität und Performance haben werden. Die neue Welle von Programmierern sind „GPT-Flüsterer“, die selbst in der IDE die meiste Zeit am Chatbot hängen und ihn für sich programmieren lassen.
      Natürlich nur, bis AI den Punkt erreicht, an dem sie alles reparieren kann, was wir schlecht geschrieben haben, oder was AI schlecht geschrieben hat, und sogar die sehr ineffiziente AI selbst, wie es der Originalbeitrag vorhersagt.
    • Es geht nicht nur um Messbarkeit, sondern auch um Profitabilität. Kapitalismus bringt keine effizienten Produkte hervor, sondern effiziente Produktion. Denn er interessiert sich nur dafür, aus dem Produktionssystem Gewinn zu ziehen.
      Autos wurden erst nach einem externen Ölschock optimiert, und selbst das sehr ungleichmäßig. Tatsächlich sind ineffiziente Produkte oft profitabler, weil Kunden sie häufiger ersetzen müssen. Ein mieses iPhone-Kabel, das nach einem Jahr aufreißt, ermöglicht es Apple, wieder und wieder Ersatz in Rechnung zu stellen. Weiße Ware geht häufiger kaputt, wird aber billiger hergestellt und erhöht so den Gewinn pro Einheit. Entscheidend ist nicht die Nutzungseffizienz nach dem Verkauf, sondern die Produktionseffizienz.
      In Software funktioniert Kapitalismus so, dass neue Automatisierung möglichst schnell herausgeschleudert wird und die Verbraucher die Energie- und Zeitverschwendung tragen. Die Produktionskette wird immer stärker standardisiert und optimiert, sodass React-Entwickler oder Kubernetes-Administratoren wie Lagerarbeiter austauschbar werden, mit entsprechendem Lohndruck. Ein Teil der Automatisierung ist fast selbstrechtfertigend, so wie man Buchhaltungsbegriffe verkompliziert, um einen Beruf zu legitimieren; beim Rest geht es um Gewinn.

  • Alles hat Kosten. Wenn die Rechenkosten oder die schlechtere User Experience groß genug sind, optimiert man auf Effizienz. ML-Modelle sind ein Beispiel. In anderen Fällen optimiert man nicht, weil Endnutzer das nicht wollen, wenn sie dafür weniger Funktionen akzeptieren müssten.
    Autos haben früher ebenfalls viel Sprit verbraucht, aber wegen Kraftstoffkosten und Umweltbedenken wollten Kunden schließlich etwas anderes, und das änderte sich. Viele Ingenieure vergessen, dass sie dafür bezahlt werden, Produkte für Kunden zu bauen.
    Außerdem scheint der Autor des Originalbeitrags nie darauf gewartet zu haben, dass ein alter Windows- oder Linux-Rechner vollständig hochfährt. Moderne Versionen booten viel schneller, weil Kunden das wollten. Telefone sind rund um die Uhr eingeschaltet, daher interessiert es Kunden nicht, wenn der Bootvorgang alle paar Monate einmal lange dauert.

    • Die Bootzeiten sind immer noch schrecklich. Besonders auf aktuellen AM5/DDR5-Systemen.
      Mein BIOS braucht etwa 20 Sekunden für den POST, und angeblich ist das normal. Danach dauert der OS-Boot etwa 10 Sekunden.
    • Ich weiß nicht, wann Kunden je eine sinnvolle Wahlmöglichkeit oder ein Mittel hatten, ihre Präferenzen auszudrücken. Es war schon lange ein angebotsgetriebener Markt: Anbieter bauen, was sie bauen wollen, und Kunden kaufen, was auf dem Markt ist.
    • Auf den Schul-PCs dauerte es buchstäblich mehrere Minuten, WordPerfect zu starten.
    • „Ingenieure werden dafür bezahlt, Produkte für Kunden zu bauen“ stimmt bis zu einem gewissen Grad, aber Software ist in vielerlei Hinsicht zu einem zentralen Bestandteil des menschlichen Lebens geworden, ähnlich wie Strom oder medizinische Versorgung.
      Man könnte auch sagen, Ärzte oder Ingenieure würden dafür bezahlt, neue Medikamente oder neue Energiequellen zu entwickeln, aber weil diese Bereiche sensibel und wichtig sind, gibt es dort mehrere Ebenen staatlicher Kontrolle. Bei Software gibt es dieses Maß an Kontrolle noch nicht.
    • Teilweise richtig, aber wenn Unternehmen von der Größe von Google oder Apple die Richtung vorgeben, sollten sie nicht so tun, als würden sie dem Kundenwillen folgen wie kleine oder mittelgroße Unternehmen.
      Sie haben die Macht, die Umgebung selbst zu formen, und können dadurch das Ergebnis von „Kundenanforderungen“ stark umlenken.

  • Dieser Artikel stammt aus dem Jahr 2018, und es gab schon einige frühere Diskussionen dazu.
    https://news.ycombinator.com/item?id=18012334 (Sep 2018)
    https://news.ycombinator.com/item?id=21929709 (Jan 2020)
    https://news.ycombinator.com/item?id=31798580 (Jun 2022)

  • Ich stimme dem sehr zu. Als Entwickler ist es wichtig, sich daran zu erinnern, dass wir eine Wahl haben. Wir können nicht über alles entscheiden, aber wir können die weniger schlechte Alternative wählen.
    Man muss nicht unbedingt Node verwenden. Auch im .NET- oder JVM-Ökosystem kann man hervorragende, abwärtskompatible Software schreiben und erwarten, dass sie in zehn Jahren noch unverändert läuft.
    Man muss auch nicht zwingend Single-Page-Webseiten bauen. Altmodisches HTML, bei dem die Seite bei jedem Klick vollständig neu geladen wird, funktioniert gut und kann zu diesem Zeitpunkt sogar eine geringere Latenz haben.
    Man muss Desktop-Apps auch nicht zwingend mit Chromium bauen. Ein UI-Framework aufzusetzen macht etwas mehr Arbeit, aber die Qualität ist es wert. Man hat nicht immer die Entscheidungsgewalt, aber wenn man sie hat, sollte man aus schlechten Entscheidungen aussteigen.

    • Die heutige Denkweise, dass „alles eine SPA sein muss“, macht mich traurig. Ich verstehe, dass komplexe Apps wie GMail von einer SPA profitieren, aber an viel zu vielen Stellen wird auf Frontend-Komplexität bestanden, obwohl man dieselbe Funktion mit einfachem CSS/HTML und ein wenig jQuery in viel weniger Zeit und mit viel weniger Bugs bauen könnte.
    • Bei der Aussage, man könne im .NET-Ökosystem gut abwärtskompatible Software nutzen, muss ich husten. Die .NET-Core-Initiative hat wirklich viel Code kaputtgemacht, und Microsoft hat viele Bibliotheken eingestellt. Natürlich gab es dafür teilweise sehr gute Gründe, und viele alte .NET-Bibliotheken hatten ziemlich schlechte Designentscheidungen.