Die Softwarekrise

 (wryl.tech)
1 Punkte von GN⁺ 2024-07-07 | 1 Kommentare | Auf WhatsApp teilen
  • Der auf der NATO Software Engineering Conference 1968 geprägte Begriff „software crisis“ wird heute seltener verwendet, doch die Belastungen durch Softwarekomplexität und Abstraktion bestehen weiter
  • Edsger Dijkstra sah in seiner Turing-Award-Rede 1972, dass Hardwareleistung und Komplexität rasant gewachsen waren, während organisierte Methoden zu deren Beherrschung nicht Schritt hielten
  • Die Kommerzialisierung des Personal Computing und schnelle Release-Zyklen führten dazu, dass Nutzer größere Kapazitäten wollten, bevor sie ihre Werkzeuge ausreichend beherrschten; „abstract it away“ wurde zur Standardreaktion
  • Verschachtelte Abstraktionsschichten verursachen Performance-Kosten und verzerrte mentale Modelle und erschweren den Zugriff auf grundlegende Maschinenfunktionen wie Grafik und Sound
  • Die Lösung liegt nicht in der Rückkehr zu den eingeschränkten Plattformen der Vergangenheit, sondern darin, Abstraktionsschichten zu reduzieren und Informationen zwischen den Schichten zu bewahren, um den Nutzern von Werkzeugen die Kontrolle zurückzugeben

Die Problemwahrnehmung von 1968 ist noch nicht erledigt

  • Auf der ersten NATO Software Engineering Conference 1968 wurde der Begriff „software crisis“ geprägt
    • Diese Konferenzen gehörten zu den frühen Versuchen, Praktiken für die Programmierung automatischer Rechenmaschinen zu ordnen und zu systematisieren
    • Am 16. Juli 1969 startete die Apollo-11-Mission, und im Oktober desselben Jahres fand die letzte NATO Software Engineering Conference statt
  • Edsger Dijkstra sah in seiner Turing-Award-Rede 1972 die Ursache der Krise in leistungsfähiger gewordenen Maschinen und dem Fehlen organisierter Methoden, mit ihnen umzugehen
    • Er äußerte sinngemäß: Als es keine Maschinen gab, war Programmieren kein Problem; als es ein paar schwache Computer gab, war es ein kleines Problem; und als riesige Computer entstanden, wurde auch Programmieren zu einem riesigen Problem
  • In der heutigen Programmierpraxis taucht der Ausdruck „software crisis“ nicht mehr häufig auf
    • Durch die Entwicklung neuer Sprachen und organisatorischer Methoden sowie den zeitlichen Abstand zu früheren Problemen konnte in der Branche eine gewisse Erleichterung entstehen, man habe das Problem ein Stück weit gelöst
    • Doch diese Erleichterung bleibt eher ein Zustand von Niederlage und Akzeptanz als echter Komfort

Abstraktion entfernt Nutzer von der Kontrolle

  • Die Entwicklung des frühen Computing und angrenzender Bereiche fand in Maschinen und Umgebungen statt, in denen der Aufbau eines Turms der Abstraktionen direkte Kosten verursachte
    • Wenn Einschränkungen nicht umgangen werden konnten, folgte ein Wachstumszyklus aus Hardware-Upgrades
    • In der Praxis entstand der Wunsch nach größerer Kapazität, bevor die aktuellen Einschränkungen ausreichend verstanden waren
  • Nach der Kommerzialisierung des Personal Computing warteten die Unternehmen, die Geräte verkauften, nicht darauf, dass Nutzer ihre Produkte vollständig beherrschten, und die Wachstumszyklen beschleunigten sich weiter
    • Zusammen mit schnellen Hardware-Release-Zyklen wurde „abstract it away“ zur Grundhaltung
    • Wenn unerwünschte Details in eine kontrollierbare Struktur verschoben werden, gewinnt man ein gewisses Maß an Unabhängigkeit, bezahlt aber mit Performance-Kosten
  • Mehrere Schichten von Abstraktion und Information Hiding verlagern das Problem des Softwarebaus auf höhere Ebenen
    • Diese Schichten werden in die Software integriert, die zur Computernutzung nötig ist, und in die Software, die das Leben steuert
    • Die breitere Softwareindustrie hat Release-Zyklen und den Einfluss von Kapital beschleunigt, während der leicht zugängliche Spielraum für einzelne Entwickler kleiner wurde
  • Die Softwarekrise ist nicht nur ein Problem der Entwickler, sondern betrifft auch Softwarenutzer
    • Nutzer haben außerhalb der von den Autoren zugelassenen Funktionen kaum Kontrolle
    • Dabei gerät aus dem Blick, dass sowohl das Erstellen als auch das Nutzen von Software menschliche Tätigkeiten sind

Der Weg führt nicht zurück in die Vergangenheit, sondern zu flacheren Schichten

  • Die vorgeschlagene Lösung besteht nicht darin, zu stärker eingeschränkten Plattformen zurückzukehren
    • Die zulässige Anzahl der Abstraktionsschichten sollte begrenzt werden
    • Informationen müssen zwischen den Schichten erhalten bleiben
    • Programmiermodelle, Benutzeroberflächen und die zugrunde liegende Hardware sollten flach und kombinierbar sein
    • Bewegungen wie Handmade, Permacomputing und Retrocomputing-Communities tragen dazu bei, das Bewusstsein für die Softwarekrise zu schärfen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-07
Meinungen auf Hacker News

  • Hallo, ich bin der Autor. Mir scheint es wichtig, einige Punkte klarzustellen, die in diesem Beitrag häufig missverstanden werden. Ich bin nicht gegen Abstraktion an sich, sondern dagegen, sie unbegrenzt anzuwenden.
    Die Lösung ist auch nicht, zu restriktiveren Plattformen zurückzukehren, und auch nicht die Forderung, Nutzer sollten „es eben aushalten und technischer werden“. Der Schlüssel zum Verständnis der Softwarekrise liegt in den Kurven von „Plattform-Kompetenz“ und „Wachstums-/Release-Zyklus“. In den vergangenen mehr als 40 Jahren haben sich diese Kurven, von einigen Bereichen abgesehen, auseinanderentwickelt. Wir haben das Problem nicht gelöst, als sie noch nahe beieinander lagen; der zweitbeste Zeitpunkt ist jetzt.
    Es gibt auch Reaktionen, die den Beitrag für Clickbait halten, aber es ist der erste Eintrag in meinem Log und enthält meine Gedanken zur Lage, in der ich mich als Entwickler befinde. Ähnliche Stimmungen sieht man in verschiedenen Formen in mehreren Communities, insbesondere auch in einigen gegenkulturell geprägten Communities. Ich möchte einen Teil der Problemlösung zeigen und plane deshalb auch einen Folgebeitrag nach dem Motto „Ich zeige, wie es geht“. Ich mache das allein, daher bitte ich um Zeit und Geduld.

    • Persönlich ist mir nicht ganz klar, wofür hier argumentiert wird. Ich stimme zu, dass es viele schlechte Abstraktionen gibt oder dass Probleme übermäßig abstrahiert werden können, aber ich halte das keineswegs für eine kontroverse Aussage.
      Solange Millionen Menschen Software entwickeln, lässt sich dieses Problem nicht vollständig beheben. Mit einem Teil von ihnen wird man zwangsläufig anderer Meinung sein, und nicht alle können so kompetent werden wie der Autor. Daher lese ich den Beitrag letztlich als Forderung, die Messlatte für „akzeptable Abstraktion“ höher zu legen als bisher.
      Große Worte sind einfach, aber wenn man sich konkret Bereiche ansieht, die man für „zu stark abstrahiert“ hält, wird man vermutlich bescheidener. Für solche „Überabstraktion“ gibt es in der Regel ziemlich gute Gründe, und auch die Ingenieure in diesen Bereichen empfinden die Abstraktionslage als unordentlich, halten sie aber für notwendig oder für unrealistisch zu beheben.
      Viele Software wird zum Beispiel dadurch gebaut, dass man gute Abstraktionen auf verbreitete Zwischenabstraktionen setzt. Kubernetes sitzt etwa auf Linux, Container-Runtimes und der klassischen Struktur aus Control Plane, Konfigurationsschicht und Data Plane. Man könnte all diese Logik auch direkt in einem neuen Betriebssystem implementieren, aber dann entstünden Kompatibilitätsprobleme für die Nutzer. Man könnte es bauen, hätte aber womöglich keine Nutzer, und müsste dann die schlechten Abstraktionen, die man vermeiden wollte, wieder implementieren. Außerdem wäre eine solche Lösung deutlich schwieriger umzusetzen. Ich mag das Kubernetes-Design nicht und würde dieses Problem gern lösen, aber für mich läuft es darauf hinaus, dass es zu schwierig oder zu teuer ist, es „richtig“ zu machen, sodass es sich nicht lohnt.
    • Man sollte an Clarkes drei Gesetze denken.
      1. Wenn ein angesehener, aber älterer Wissenschaftler sagt, dass etwas möglich ist, hat er mit ziemlicher Sicherheit recht; wenn er sagt, dass etwas unmöglich ist, liegt er sehr wahrscheinlich falsch.
      2. Der einzige Weg, die Grenzen des Möglichen zu entdecken, besteht darin, sich ein Stück über sie hinaus ins scheinbar Unmögliche zu wagen.
      3. Jede hinreichend fortgeschrittene Technologie ist von Magie nicht zu unterscheiden.
        Je nachdem, wann und mit welchem Hintergrund man in dieses Feld eingestiegen ist, ist es gut möglich, dass die Abstraktionen früherer Generationen bereits als akzeptierte Praxis gelten. Zum Beispiel wurde es irgendwann zu einer Selbstverständlichkeit, ein Betriebssystem mit einem allgemeinen Dateisystem zu verwenden.
        Das hier angesprochene Problem sehe ich eher in den Schwierigkeiten, die man heute beim Einstieg in dieses Feld hat. Wenn man davon ausgeht, dass man alle verwendeten Abstraktionen im Detail verstehen muss, um beitragen zu können, ist das erforderliche Vorwissen beträchtlich. Das kann überwältigend sein, aber es gibt auch den Weg, Abstraktionen zu akzeptieren, bis man sie tiefer verstehen kann.
        0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
    • Mir gefiel die Art, wie gezeigt wurde, dass sich das Problem durch die Geschichte zieht. Der Ausdruck „Softwarekrise“ passt auch deshalb, weil er auf den Punkt verweist, an dem diese Lage erstmals klar formuliert wurde.
      Allerdings halte ich den Grund dafür, dass sich diese Lage nicht ändert, klar für wirtschaftlich. Das heißt nicht, dass schlechte Software billiger wäre. Aber wenn man Abstriche macht, kann eine Person oder Organisation jetzt Kosten sparen, während die größeren Kosten später von der Organisation selbst, den Kunden oder der Gesellschaft insgesamt getragen werden. Deshalb gibt es starke Anreize für billige und schlechte Praktiken. Hinzu kommt, dass sich auf Software die Maßstäbe anderer Ingenieursdisziplinen nur schwer anwenden lassen, was es auch schwierig macht, Verträge oder Regulierungen zu schaffen, die Software nach bestimmten Standards oder mit bestimmter Qualität verlangen.
      Die einzige vorstellbare Lösung wäre wohl eine technologische Revolution, die es ermöglicht, mit derselben Technologie billigere und bessere Software zu bauen, während es zugleich unmöglich wird, billigere und schlechtere Software zu bauen.
    • Ich sehe darin weniger eine Softwarekrise als vielmehr einen Softwareüberfluss.
      Es gibt zu viel Software auf zu vielen Plattformen, und die Landschaft ist so fragmentiert, dass allgemeine Aussagen schwierig sind. Manche Projekte wackeln und brechen zusammen, während andere gut funktionieren.
      Es gibt auch nutzerfeindliche Software, aber das ist Absicht im Design. Dahinter stehen Zynismus und Gier. Nicht, weil Programmierer nicht wissen, was sie tun, sondern weil sie tun, was ihnen aufgetragen wird.
      Auch die Nutzer selbst fördern das. Selbst wenn man ihnen gute Software baut, interessiert es sie nicht; Nutzer verlangen andere Dinge als gute Software. Ein Nutzer, der gute Software will, wird zum Opfer von fünfzig Nutzern, die das nicht wollen. Software für den Massenmarkt ist inzwischen Popkultur.
    • Windows 3.1 und Word passten problemlos auf eine 40-MB-Festplatte, mit reichlich Platz übrig. Word lief mit 2 MB RAM und einem Single-Core-80386 mit 16 MHz, und moderne Mikrocontroller übertreffen das deutlich.
      Word war damals im Vergleich zur heutigen Version auch nicht besonders eingeschränkt. Heute brauchen Windows und Office jedoch schon allein, um zu laufen, 50–100 GB Speicherplatz. Was haben wir dafür bekommen, dass es um den Faktor 1000 gewachsen ist?
      Das ist völlig verrückt, aber wir nehmen es einfach hin. Moderne Systeme haben ungefähr 5000- bis 10000-mal mehr Festplatte, RAM und CPU, und Heim-Internet ist buchstäblich eine Million Mal schneller als frühe Modems.

  • Dieser Text setzt voraus, dass die Softwarekrise tatsächlich existiert oder ein ernstes Problem ist. Als Elemente der Krise werden Budgetüberschreitungen, Terminüberschreitungen, Ineffizienz, geringe Qualität, nicht erfüllte Anforderungen, nicht beherrschbare Projekte, schwer wartbarer Code und Nichtlieferung genannt.
    Wenn man hier aber das Wort „Software“ weglässt: Wie viele menschliche Tätigkeiten gibt es dann, die nicht mindestens eines dieser Probleme haben? Umgekehrt gibt es tatsächlich auch sehr viel ziemlich hervorragende Software. Wir wollen nur Misserfolge und Fehler sehen und ignorieren Erfolge, als wären sie eine selbstverständliche Baseline, selbst wenn sie immer besser werden.
    Wenn man den Einschaltknopf eines Computers drückt und bis zum Desktop gelangt, durchläuft man bereits Hunderte von Abstraktionen. Allein dieser Desktop ist das komplexeste Ding, mit dem wir im Lauf des Tages interagieren werden. Das passiert weltweit zig Milliarden Mal am Tag und funktioniert im Großen und Ganzen problemlos. Und das ist nur ein sehr kleines Beispiel.

    • Der Text erklärt nicht gut, worin die eigentliche Krise besteht. Komplexität an sich ist kein Problem, die zuvor aufgelisteten Punkte aber sind reale Probleme.
      Allerdings glaube ich, dass die eigentliche Motivation solcher Texte nicht diese Punkte sind, sondern das Gefühl, dass alles unbeherrschbar geworden ist. Als erfahrener Programmierer muss man dieses Gefühl der Überforderung mit dem, was zu tun ist, in Einklang bringen. Es hat gedauert, bis ich so weit war, aber ich halte das für wichtig. Es wird nie alles vollständig geordnet sein, und diese Tatsache muss man akzeptieren.
    • Software ist deshalb einzigartig, weil es keine physischen Beschränkungen gibt, die als natürliche Zwangskraft oder Filter für Qualität wirken. Eine Brücke muss auf einem gewissen Niveau Mindestanforderungen an strukturelle Integrität oder Materialqualität erfüllen, sonst stürzt sie unter ihrem eigenen Gewicht ein. Auch ein Gericht muss Mindestanforderungen an die Qualität der Zutaten und an die Kochtechnik überschreiten, damit es essbar ist.
      Bei Software gibt es, abgesehen von Performance- und Speicherbeschränkungen, kaum solche Grenzen. Und beides ist so großzügig bemessen, dass man endlos Müll darüberkleben und damit durchkommen kann. Wir alle hatten schon den Moment, in dem wir dachten oder sagten: „Wie läuft das überhaupt?“ Bis ein Nutzer eine falsche Randbedingung trifft, weiß man nicht, wie wackelig der darunterliegende Code ist.
      „Haben Sie versucht, es aus- und wieder einzuschalten?“ ist der Beleg dafür. Softwaresysteme geraten häufig in so subtile und unerklärlich schlechte Zustände, dass die einzige Lösung darin besteht, alles zu löschen und von vorn hochzufahren. Etwa wenn ein Handy nach einem Anruf weiter vibriert, bis der nächste Anruf oder die nächste SMS kommt, wenn in einer Web-App Teile nicht zu 100 % geladen werden und Optionen verschwinden, oder wenn Bluetooth-Pairing sprunghaft funktioniert.
    • Die meisten, vielleicht sogar alle der aufgelisteten Probleme lassen sich auf zwei Grundbegriffe zurückführen: Kommunikation und Verständnis.
      Kommunikation ist die Art, Verständnis zu verbreiten und dessen Mangel zu beheben, und Verständnis ist die Grundlage für Erfolg bei jeder Tätigkeit. Ohne Verständnis tritt eines oder mehrere der genannten Symptome auf. Sie können auch mit Verständnis auftreten, aber zumindest entsteht dann ein Weg zum Erfolg.
      Meiner Erfahrung nach sind die meisten Probleme in der Software-Engineering-Branche menschliche Probleme. Nicht die Technik, nicht die Technologie selbst und auch nicht die Prozesse. Deshalb sind Kommunikation und Verständnis für den Erfolg unerlässlich.
    • Zu „Wie viele menschliche Tätigkeiten haben mindestens eines dieser Probleme?“: Wollen Sie eine binäre Antwort, dass es in irgendeinem Bereich absolut nie vorkommt? Bei den meisten Projekten gilt es schon als schlecht gelaufen, wenn nur 1–2 davon auftreten; bei Software erklärt man es zum Sieg, wenn man nur 2 davon vermeiden kann.
    • Ich frage mich, was der Maßstab für „ziemlich hervorragende“ Software ist. Natürlich ist das subjektiv, aber die meisten Menschen würden die Software, die sie tatsächlich benutzen, wohl nicht hervorragend nennen.
    • Es stimmt, dass der Desktop die komplexeste Maschine ist, mit der man im Laufe des Tages interagiert – mit Ausnahme des Gehirns, das diesen Computer bedient, Signale aufnimmt und daraus Schlüsse zieht.

  • Wenn man sich die Laufbahnen der Führungskräfte in Engineering-Unternehmen oder Automobilkonzernen ansieht, erkennt man Stufen, in denen sie immer größere Verantwortung für die Konstruktion von Teilen, Komponenten und Produkten oder für den Betrieb von Produktionsanlagen übernommen haben. Auch CEOs betonen weiterhin technisches Wissen, und selbst nichttechnische Kräfte tun zumindest so
    Dagegen endet bei agiler Softwareentwicklung technische Kompetenz meist auf der untersten Ebene. In Scrum-Teams sitzen die Leute, die Software bauen, und das war’s. Scrum Master und viele Business Analysts haben wahrscheinlich nie viel programmiert, und der erste tatsächliche Vorgesetzte in der Hierarchie erledigt vor allem Sekretariats- und Verwaltungsarbeit und schaut sich kaum Code an
    Der Punkt ist nicht nur, dass Softwareentwicklung in Ticket-Größen stattfindet und es dadurch schwer wird, philosophisch darüber nachzudenken, wie viele Abstraktionsebenen man selbst baut und wartet. Softwareentwickler haben nicht einmal einen Platz am Entscheidungstisch. Sie werden vom Scrum Master betreut, gehen in Code-Reviews Kompromisse ein, stehen unter Druck, nicht über das Ticket hinauszudenken, und es gibt meist keinen Beförderungspfad, der technische Kompetenz in die Führungsebene trägt
    Deshalb dürfte eine Bewegung, die auf die „Softwarekrise“ aufmerksam machen will, wohl im Hobbybereich bleiben, den der Text am Ende mit Handmade, Permacomputing, Retro-Computing beschreibt. Ich denke, auch Hollywood trägt eine gewisse Verantwortung, weil es Software-/IT-Leute ständig demütigend darstellt, während Ärzte und Anwälte endlos Hauptrollen bekommen und komplexe Fachsprache zu interessanten Geschichten verknüpft wird. Ist das bei uns wirklich unmöglich? Vielleicht schafft demnächst eine KI fürs Drehbuchschreiben etwas

    • Ärzte und Anwälte lassen sich leichter in interessante Geschichten verwandeln, weil sie mit Menschen und alltäglichen Problemen zu tun haben. Es gibt nicht viele Werke mit Vertragsanwälten oder Radiologen als Hauptfiguren; meistens sind es Notärzte und Strafverteidiger
      Softwareentwicklung bedeutet, den ganzen Tag strikt mit Computern zu kommunizieren. Man löst gewöhnliche Aufgaben, die längst gelöst sind, in einer neuen Anwendung, oder befasst sich mit Problemen, die ohne technischen Hintergrund nicht einmal zu erfassen sind. Ich programmiere seit über 20 Jahren zum Spaß, aber die meiste Arbeit ist zum wahnsinnig werden langweilig. Ich versuche gar nicht erst, sie Nichtentwicklern zu erklären. Sie ist so uninteressant wie Buchhaltung, und viele Leute würden aus einer anderen Geschichte wohl nützlichere Informationen ziehen
    • Dieses Argument ist nachvollziehbar. Wäre ich ein Junior in der agilen Ära gewesen, wäre ich vielleicht nicht so schnell und so weit gewachsen wie heute
      Das Unternehmen, in dem ich gearbeitet habe und das am tiefsten in Agile versunken war, behandelte Juniors und Seniors wie austauschbare Zahnräder. Der einzige Unterschied war, dass Seniors pro Sprint mehr Punkte abarbeiten mussten. Es wurde aktiv unterbunden, über den Ticketumfang hinauszudenken, und die Atmosphäre war: Kopf runter und Mund halten
    • In Big Tech gibt es bis zu ziemlich hohen Ebenen viele technische Manager
      Allerdings gibt es zwei Probleme. Sie können nicht tief in Implementierungsdetails einsteigen, und sie sind an verzerrte Anreize gebunden, die das Erzeugen von Komplexität belohnen. Natürlich gibt es auch Leute, die sich dem widersetzen, aber solche Menschen werden eher selten befördert. Man wird nicht dafür belohnt, die Zahl der Leute unter sich zu reduzieren oder die eigene Rolle abzuschaffen
    • Das beschriebene Unglück fühlt sich zu einem erheblichen Teil selbst verschuldet an. Viele Entwickler „unter“ mir wurden völlig von Kundenanforderungen abgekoppelt und dazu gebracht, sich nur auf „interessante“ Entwicklungsprobleme zu konzentrieren
      Kurz gesagt: Der Grund, warum Entwickler von den tatsächlichen Anforderungen nur Einheiten in Ticket-Größe bearbeiten, ist, dass sie zu dumm sind. Sie können das Ganze nicht im Kopf behalten und verstehen es nicht. Klingt frustrierend? Ist es auch. Es ist wirklich schwer zu verstehen. Tut mir leid
    • Gegenbeispiel: Boeing

  • Dieser Text zeichnet Abstraktion als etwas Böses, aber sie ist ein unvermeidliches Werkzeug, wenn man von Menschen erstellte Software oberhalb eines gewissen Fähigkeitsniveaus bauen will
    Rich Hickey hat einmal sinngemäß gesagt: „Ein Anfänger im Jonglieren kann zwei oder drei Bälle handhaben, aber selbst der weltbeste Jongleur stößt vermutlich bei etwa neun an seine Grenze. Menschliche Fähigkeiten unterscheiden sich nicht um Größenordnungen, und man stößt schnell an die Decke.“ Um diese Grenze zu überwinden, bleibt einem nur Abstraktion
    Natürlich kann es in bestimmten Fällen schlechte Abstraktionen oder zu viele Abstraktionen geben, und ich denke, genau darüber ärgert sich der Autor. Aber diese Unterscheidung ist wichtig
    Der Teil „Heute ist es nicht mehr leicht, Software zu bauen, und nichts kommt mit einer Anleitung“ ist eindeutig falsch. Software zu erstellen ist einfacher als je zuvor, und die Dokumentation ist ebenfalls besser geworden

    • Was in diesem Vortrag hauptsächlich vorgeschlagen wurde, war weniger Abstraktion als Einfachheit, also Zerlegung
      Um ein komplexes Ganzes zu verstehen, braucht man nicht zwingend Indirektion. Um mit Komplexität umzugehen, muss man Verflochtenes entwirren, sodass die einzelnen Teile unabhängig verstanden werden können. Wenn man Komplexität durch Indirektion versteckt, entsteht Distanz zwischen uns und dem Gegenstand, über den wir nachdenken müssen
      Abstraktion ist gut für Nutzer. Denn sie müssen sich, ob Entwickler oder nicht, nicht um Details kümmern. Aber sie macht es uns nicht leichter, sie zu bauen

  • Entgegen der Aussage „Software zu bauen ist heute nicht mehr einfach“ ist es sehr einfach, wenn man die richtigen Tools für die richtige Aufgabe kennt. Nur werden Informationen über solche Tools unterdrückt, sodass man kaum davon hört
    Das technische Tool-Ökosystem, wie die meisten es sich vorstellen, unterscheidet sich stark von der Realität. Die meisten Tools, die wir kennen, sind furchtbar. Sie versuchen, wie Universallösungen zu wirken, sind in Wirklichkeit aber für kaum etwas besonders gut. Trotzdem sind sie die beliebtesten Tools. Wie der Text andeutet, liegt das meiner Ansicht nach am Einfluss des Kapitals
    Als Beispiel habe ich mit dem Tool, das ich derzeit nutze, ein Video aufgenommen, in dem ich eine relativ komplexe Marketplace-App mit Login, Zugriffskontrolle, Schema-Validierung und komplexen Filter-Views von Grund auf in 3 Stunden erstelle – nur im Browser, ohne irgendeine Software herunterzuladen, serverless. Die gesamte App besteht aus weniger als 700 Zeilen HTML-Markup und 12 Zeilen JavaScript. Sie hatte etwa 10 Aufrufe

    • Zur Klarstellung: Es ist nicht „das Tool, das ich derzeit nutze“, sondern ein Tool, das du selbst gebaut hast und das du jetzt ziemlich unverhohlen bewerben willst. 18 Dollar Monatsabo, keine Nutzer, und natürlich ist auch noch Kryptowährung dabei, getragen von Versprechen und Übertreibungen
      Abgesehen vom verschwörungstheoretischen Twist sind moderne Tools flexibler und einfacher zu benutzen als je zuvor. Sie haben Schwächen, aber das ist nichts im Vergleich zu dem, was Entwickler vor Jahrzehnten durchmachen mussten. Es gibt keine riesige Verschwörung, die dein Tool unterdrücken will
    • Web3 oder populäre Kryptowährungen sind nicht mein Gebiet. Ich mag Mathematik, deshalb mag ich unpopuläre Kryptografietechniken. Da das Video 3 Stunden lang ist, werde ich es mir nicht bis zum Ende ansehen. Ich habe bereits das Gefühl, dass es mir nichts geben wird, was ich heute, nächste Woche oder diesen Monat nutzen kann. Das ist nicht abwertend gemeint; 3 Stunden sind einfach lang
      Ich glaube stark an No-Code/Low-Code und an Tools, die überall laufen können. Allerdings kann es sein, dass ich damit etwas anderes meine, als du denkst. Jedenfalls erkenne ich an, dass du es gebaut hast
      Als ich anfing, das Video anzusehen, waren meine ersten Fragen: Was ist Codespaces? Wie sieht es mit Sicherheit aus? Wo läuft die fertige App? Kann ich sie auf meiner eigenen Hardware betreiben? Kann ich sie ohne Cloud-Zugriff betreiben? Welche Cloud ist es? Wird sie nächste Woche, nächsten Monat, nächstes Jahr, in 10 Jahren noch existieren? Natürlich sollte man sich an einem einzelnen Beispiel nicht zu sehr festbeißen
      Die No-Code/Low-Code-Situation lässt sich mit Desktop-Publishing vergleichen. Bei DTP gibt es keine CI/CD-Pipeline. Man drückt auf Drucken. Es ist eine vollständig integrierte Umgebung. Dagegen wirkt buchstäblich jede „Continuous Integration“-Umgebung, als würde sie sich selbst auffressen, weil sie so angestrengt herumschreit. Irgendwo gibt es sicher Tools für Farbseparation, Randeinstellungen, Font-Import, PostScript-Header-Bibliotheken oder LaTeX-Erzeugung, aber die meisten sehen oder nutzen sie nie. Irgendwo gibt es sicher auch Leute, die mit weit vielfältigeren Pigmenten als CMYK Mehrplatten-Drucke erstellen, die nur bei natürlichem Licht klar wirken, aber die meisten sehen nur miese Schnappschüsse auf dem Handy und erkennen darin keinen Sinn
      Das ist nicht nur ein Problem der Schaffenden. Verbraucher wissen nicht, was möglich ist, und sie haben auch keine Geräte, die die gesamte Bandbreite der Möglichkeiten sichtbar machen würden. Verbrauchergeräte untergraben diese Bandbreite aktiv – aus zahlreichen Gründen geschlossener Ökosysteme sowie aus gewöhnlicher Nachlässigkeit und Unwissenheit
      Vor ein paar Jahren bekam ich als Mietwagen einen Cadillac, und einen modernen Cadillac werde ich sicher nicht kaufen und nach Möglichkeit auch nicht fahren. Ich konnte die Scheibenwischer nicht steuern, und der Konsolenbildschirm zeigte mir mehrfach eine extrem auffällige Warnung an, ich würde nicht auf die Straße schauen. Vermutlich hat er nicht erkannt, dass ich eine Brille trage. Da ich mich auf einer unbekannten Straße in schnellem Verkehr befand, habe ich tatsächlich nicht auf den Bildschirm geschaut, sondern meinen Beifahrer gefragt: „Was zum Teufel sagt dieser blinkende Bildschirm da?“ Gut gemacht, Cadillac
    • Link bitte!

  • Flache und kombinierbare Strukturen erlebt jeder, der UNIX-Tools verwendet
    GUI bricht hier zusammen. GUIs sind buchstäblich Inseln, die nicht auf kombinierbare Weise miteinander kommunizieren
    Ich experimentiere mit einem Tool namens guish damit, GUI- und Shell-Pipeline-Ideen zu vermischen
    https://github.com/williamcotton/guish
    Ich frage mich, ob jemand ähnliche Tools oder kombinierbare GUI-Ansätze kennt

    • Das sind Projekte in einem ähnlichen Bereich
      https://hisham.hm/userland/
      https://arcan-fe.com/2021/04/12/introducing-pipeworld/
      http://conal.net/papers/Eros/
    • Ich denke, die Antwort auf kombinierbare GUIs ist die emacs-Architektur. emacs ist weder nur CLI noch nur GUI. Es ist eine großartige, wenn auch alte Kombination, in der beides nahtlos integriert ist
      Ich arbeite selbst an Ideen dazu, und oberflächlich sieht es Ihrem Ansatz ähnlich. Ich empfehle aber, sich anzusehen, wie das in emacs funktioniert. Ich habe Ihren Ansatz nicht im Detail betrachtet, aber er wirkt auf mich nicht besonders „kombinierbar“
      Falls Sie es noch nicht kennen, könnte auch das inspirierend sein: https://gtoolkit.com/ Eine Smalltalk-Umgebung, in der wie bei emacs buchstäblich alles programmierbar ist, nur eher in die entgegengesetzte Richtung. Die GUI ist nicht das Ergebnis von Befehlen, sondern die Sprache selbst
    • Genau. Es muss flach, breit und kombinierbar sein. Unsere Abstraktionen sollten das ebenfalls sein
      Das größere Problem ist jedoch nicht die GUI. GUI ist zwar auch ein Problem, aber da sie zwangsläufig ganz oben auf dem Abstraktions-Stack sitzt, setzen sich die Probleme nicht weiter kombiniert fort. Interessanterweise ist es ein so großes Problem, dass es dadurch fast keines mehr ist
      Der heutige riesige Elefant im Raum sind verteilte Systeme
    • Für Pipelines wie eine „Sonntagsfahrt“, also Aufgaben, die man ein paar Tage oder etwa eine Woche intensiv nutzt und dann monatelang liegen lässt, mag ich KNIME(https://www.knime.com/). Als Code-Ebene verwende ich Python/Pandas
    • Sieht ziemlich cool aus. Ich stimme zu, dass ein wichtiger Grund, warum ich Unix mag und als produktiv empfinde, darin liegt, dass es „flach und kombinierbar“ ist
      Allerdings waren GUIs schon lange eine Schwachstelle. Ich vermute, das liegt daran, dass bei der Frage, ob eine UI gut ist, viele „globale“ Überlegungen eine Rolle spielen und es daher keine modulare Eigenschaft ist
      Persönlich hätte ich gern mehr UI, aber mit erhaltener Automatisierung. Genau diese Eigenschaft, dass man das, was man in der Shell tippt, in eine Datei speichern, später erneut ausführen, ändern und wieder ausführen sowie Befehle kopieren und per E-Mail an Freunde schicken kann
      Zur Einordnung: Ich baue seit Jahren eine Shell von Grund auf und habe einen headless mode für GUIs. Es gibt auch echte Demos von anderen Leuten, aber derzeit arbeitet niemand daran
      Screenshots:
      https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
      https://www.oilshell.org/blog/tags.html?tag=headless#headles...
      Weitere Links gibt es hier - https://github.com/oilshell/oil/wiki/Interactive-Shell - darunter auch interessante inaktive Projekte wie Xiki
      Wenn Sie eine kompatible Shell brauchen, die vom Terminal getrennt ist, oder eine neue Shell dieser Art, melden Sie sich per E-Mail oder unter https://oilshell.zulipchat.com
      Im Grunde brauche ich jemanden, der das headless-Protokoll testet und mir Verbesserungsvorschläge gibt. Ich denke, man sollte eine Shell-GUI bauen, die ein Terminal „hat“, aber nicht das Terminal „selbst“ ist. Das scheint auch mit dem zusammenzuhängen, was Sie bauen
      Derzeit arbeite ich hauptsächlich an der neuen YSH-Sprache, würde die GUI-Arbeit aber gern wiederbeleben. Ich habe nicht viel Erfahrung als UI-Programmierer, daher wären andere Perspektiven hilfreich
      Und ich freue mich, dass ggplot enthalten ist, weil ich ggplot mag. Tatsächlich ist ggplot genau der Punkt, an dem ich mir immer gewünscht habe, es gäbe Grafik in der Shell

  • Der Satz am Ende „Es kann besser werden. Ich werde zeigen, wie“ wirkt einfach wie ein Clickbait-Einstieg

    • Das zentrale Kriterium für Clickbait ist, ob es reißerisch, täuschend oder absichtlich irreführend ist. Das scheint hier auf keines davon zuzutreffen. Es ist nur der letzte Satz eines Blogbeitrags
    • Das ist der erste und einzige Blogbeitrag auf dieser Website: https://wryl.tech/log/index.html
    • Ist das ein persönlicher Angriff? Oder stellen Sie es einfach als Tatsache hin, ohne nach der Stichhaltigkeit des Arguments zu fragen?

  • Die Aussage „Diese Modelle bilden die Realität nur sehr selten ab. Wenn sie es tun, ist das ein glücklicher Zufall, wenn nicht, eine Katastrophe“ entspricht nicht meiner Erfahrung
    Im Allgemeinen ist der Großteil der handelsüblichen Software nicht lebensgefährlich. Viele aufgeblähte, miserable Webapps können den ganzen Tag über unnötig viele Ressourcen verschlingen, hier und da unregelmäßige Bugs zeigen und trotzdem die vom Nutzer erwartete Aufgabe schlecht erfüllen. Das stimmt alles
    Aber sie ist nicht so lebensgefährlich wie Software, die Herzschrittmacher oder Weltraumraketen steuert. Die meiste Software darf chaotisch sein. Denn die meisten Projekte haben mit menschlichen Launen zu tun, und das Schlimmste mangelnder Qualität ist ein wenig Frust, nicht Elend oder Tod
    Außerdem arbeiten die meisten Softwareentwickler wohl weder unter einer Geldmotivation nach Silicon-Valley-Art, noch verdienen sie ihren Lebensunterhalt mit Projekten, die sie aus Leidenschaft bauen wollen. Der Großteil der Software, die auf den Markt kommt, entsteht durch extern vorgegebene, schlechte Anreizstrukturen. Was sollte man als Ergebnis eines solchen Prozesses anderes erwarten als Müll?

    • Ich stimme zu, dass die Risikostufe nicht passend wirkt, aber ich spreche von aller Software und berücksichtige auch, dass es sehr viele solcher Frustrationen gibt. Bei ein paar kleinen Rissen in der Treppe wäre es etwas anderes, aber im Durchschnitt fehlt eher die Hälfte der Stufen
      Ich hasse fehlende Stufen wirklich
      Wir sind sehr weit von der tatsächlichen Nutzung der Software entfernt, die wir bauen, und erleben nur kurze, verwertbare Signale, die den Entwicklungsprozess informieren. Solange man nicht mit einem neuen Nutzer den Körper tauschen kann, ist es schwer, den tatsächlichen Schmerz dieses „Todes durch tausend Schnitte“ richtig zu spüren
      Ich sehe Programmieren als Profession, und ich denke, wir haben die Macht, die Qualität von Software zu steuern. Es gibt nur Anreize, finanzieller Art oder nicht, die uns dazu bringen, wegzuschauen

  • Ich glaube nicht, dass es eine Softwarekrise gibt. Millionen Programmierer auf der ganzen Welt schreiben einigermaßen nützliche Programme, und fast alles, bis hin zum Toaster, führt Software hinreichend erfolgreich aus. Die Community hat auch Programme geschaffen, die für alle zugänglich sind, vom fünfjährigen Kind bis zu den Großeltern. Wo ist hier die Krise?
    Es gibt aber eine Projektmanagement-Krise. Sie ist nicht auf Software beschränkt, sondern ein Problem der Distanz zwischen den Leuten, die planen, und denen, die liefern. Und wir scheinen diese Kluft nicht schließen zu können. Agile, Scrum usw. sind Symptome dieser Kluft, in der „Gurus“ uns alle wie Idioten behandeln, und wir schaffen es ebenfalls nicht, etwas Besseres hervorzubringen
    Auch die Kommodifizierung der Softwareentwicklung trägt zu diesem Durcheinander bei. Wegen der niedrigen Einstiegshürde des Bereichs können Menschen aller Niveaus mit unterschiedlich hohem Erfolg mitmachen. Das ist keine Frage von gut oder schlecht, sondern das Wesen des Phänomens. Es ist nicht viel anders als in der Gastronomie, wo es sowohl Michelin-Sterne-Restaurants als auch MacDonalds gibt und beide ihre Kundschaft haben. Trotzdem spricht man nicht von einer Restaurantkrise

    • Das Toaster-Beispiel ist vielmehr ein Fall einer realen und konkreten Softwarekrise. Toaster führen schlechten Code aus. Schlechter Code, der nicht auf Resilienz oder Sicherheit ausgelegt ist, wird mit dem Internet verbunden
      Dadurch verkürzt sich die Lebensdauer des Toasters. Früher gab es vielleicht Toaster, die zehn Jahre hielten. Jetzt werden sie wegen schlechter Software und vielleicht erzwungener WLAN- oder Bluetooth-Verbindungen nach zwei Jahren zu Müll, wenn der Anbieter keine Updates mehr liefert. Vielleicht gab es überhaupt nie Updates. Die Krise ist nur nicht immer sichtbar, weil sie nicht direkt zu sehen ist oder wegen unseres heutigen Überkonsums und des endlosen Kaufs neuer Produkte
      Wenn der Toaster nach zwei Jahren ausfällt, halten wir das für in Ordnung und kümmern uns nicht darum oder wissen nicht, warum. Aber vielleicht war er Teil des Mirai-Botnetzes https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
      Wahrscheinlich nicht, weil Toaster einfachere Chips verwenden, aber wer weiß
    • Stützt die Aussage „sogar Toaster führen Software aus“ nicht eher die These des Autors, dass es zu viel Software gibt?
      Nebenbei: Mein Dualit-Toaster führt keine Software aus
    • Ist der Einstieg heute wirklich so leicht? Der Einstieg in moderne Softwareentwicklung fühlt sich derzeit sehr schwierig an. Man braucht sehr viel Wissen

  • Die Passage „Wir haben Wege entwickelt, verschachtelte Abstraktionsschichten aufzubauen und Informationen auf mehreren Ebenen zu verbergen. Wir haben das Problem, Software zu bauen, in ein Problem hoch aufragender Schichten verwandelt“ erinnert mich an leaky abstractions und den Turmbau zu Babel
    https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
    https://en.wikipedia.org/wiki/Tower_of_Babel
    https://en.wikipedia.org/wiki/Hierarchy
    https://en.wikipedia.org/wiki/Abstraction
    https://en.wikipedia.org/wiki/Abstraction_(computer_science)
    Es lohnt sich, sie miteinander zu vergleichen