- Bei der Überarbeitung des Multics-Dateisystems bei Honeywell Cambridge übernahm André Bensoussan den zentralen Teilsystembereich, den VTOC manager, und betreute ihn von der Konzeption bis zu den Tests
- Dieses Modul musste Dateibeschreibungsinformationen zwischen Festplatte und Speicher bewegen und zudem den Pufferpool sowie den Festplattenspeicher verwalten, also war es praktisch eher ein kleiner Virtual-Memory-Manager
- André programmierte nicht direkt am Terminal, sondern feilte mit dem Bleistift an Diagrammen und Code und versuchte, eine symmetrische Architektur zu schaffen, die zugleich Zustandsinformationen aufnehmen konnte
- Nach der Eingabe des endgültigen Manuskripts traten beim ersten Kompilieren nur drei Tippfehler auf, und auch der an das System gebundene Lauf funktionierte beim ersten Versuch
- Der später entdeckte einzige Bug entstand nur deshalb, weil Tom Van Vleck die Aufrufreihenfolge der Fehlerbehandlungsprozedur falsch angegeben hatte, sodass die Fertigstellungsqualität des Programms selbst außerordentlich hoch war
Arbeit am Multics-VTOC-manager
- André Bensoussan arbeitete zusammen mit Tom Van Vleck bei Honeywell Cambridge am Betriebssystem Multics
- Für die umfangreiche Überarbeitung des Dateisystems wurde ein Teilsystem namens VTOC manager benötigt
- Dateibeschreibungsinformationen zwischen Festplatte und Speicher verschieben
- gemeinsamen Speicher-Pufferpool verwalten
- Festplattenspeicher für Dateiinformationen verwalten
- Wegen dieser Aufgaben musste der VTOC manager wie ein kleiner Virtual-Memory-Manager arbeiten
- André übernahm Entwurf, Implementierung und Tests dieses Moduls
Ein mit dem Bleistift vollendetes Programm
- André setzte sich zunächst an den Schreibtisch und zeichnete viele Diagramme
- Er wollte eine Form, die alle Zustandsinformationen aufnehmen und zugleich ansprechend und symmetrisch sein sollte
- In seinem Umfeld machte man sich wegen des Zeitplans schon Sorgen darüber, dass sich das Schreiben des Codes verzögerte
- Auch das Codieren selbst erfolgte nicht am Terminal, sondern mit dem Bleistift
- Er lehnte Hilfe beim Tippen ab
- Er schrieb Teile neu, übertrug sie, radierte, korrigierte und erstellte so das endgültige Manuskript
- Nachdem das vollständige Bleistiftmanuskript in das Terminal eingegeben worden war, scheiterte die erste Kompilierung, doch nach der Korrektur von drei Tippfehlern war die Kompilierung erfolgreich
- Nach dem Binden an das System lief es beim ersten Versuch, und der VTOC manager funktionierte danach dauerhaft perfekt
- Der einzige entdeckte Bug entstand, weil Tom Van Vleck auf Andrés Frage zur Aufrufreihenfolge der Fehlerbehandlungsprozedur ohne Prüfung eine Vermutung als Antwort gab
- Als dieser Fehlerpfad erstmals durchlaufen wurde, kam es zu einem Absturz
- Abgesehen davon gab es kein Problem im Programm
1 Kommentare
Hacker-News-Meinungen
Der Hauptgrund, warum er das schaffen konnte, war meiner Ansicht nach, dass die Anforderungen sehr klar definiert waren.
Ein großer Grund dafür, dass heutige Software fehleranfällig und langsam ist: Niemand weiß wirklich, was eigentlich gebaut wird, oder falls doch, ändert es sich wegen „Agile“ ständig.
Gib Entwicklern eine klare API und gut definierte Kriterien, und die meisten schreiben Code, der sehr gut funktioniert.
Anforderungen sind nicht, Listen und Tickets auf einem Kanban-Board auszubreiten, sondern die Domain dessen, was gebaut werden soll, tatsächlich zu lernen.
Man kann auch etwas in einem Bereich bauen, den man nicht versteht, aber das Ergebnis wird leicht Müll; wenn man den Prozess, diesen Müll zu schreiben, als Entwurf versteht, um die Domain-Aufgaben und mögliche Lösungen zu lernen, ist das in Ordnung.
Für Qualität gibt es keine Abkürzung.
Als Stakeholder sollte man für die Personen, die die Anwendung bauen, erreichbar sein und sicherstellen, dass sie die Domain verstehen. Das geht auch, ohne sie ständig zu belästigen.
Vor Hochstaplern, die nur Buzzwords aneinanderreihen, sollte man sich hüten.
Als Designer und Programmierer sollte man sicherstellen, dass Stakeholder und Domain-Experten aktiv und engagiert sind. Andernfalls wird es so schwierig wie Zähneziehen, Anforderungen und Verständnis aus ihnen herauszubekommen.
Manche Stakeholder wollen das Problem vielleicht nicht einmal lösen, wollten eigentlich eine völlig andere Richtung oder sind aus politischen Gründen beleidigt. Kaum etwas bringt ein Projekt so zuverlässig zum Sinken wie faule oder gleichgültige Stakeholder.
Stakeholder wissen nicht, was sie wollen, verlangen aber trotzdem scheinbar willkürlich zusätzliche Funktionen oder große Änderungen.
Es werden unzählige Sonderbehandlungen nötig, weil man mit diesem Tool Dinge erzwingen will, für die es nicht gedacht ist.
Designer entwerfen häufig Lösungen, die mit den benötigten Funktionen, dem Verhalten bestehender Systeme und den Anforderungen der Stakeholder kollidieren, und die Teams, die die einzelnen Systemteile entwickeln, arbeiten in Silos, ohne richtig zu kommunizieren.
Schlecht konzipierte „Agile“-Prozesse versuchen, auf Basis fragwürdiger Schätzpunkte alles in einen bestimmten Zeitraum zu pressen.
Am Ende führen diese Probleme dazu, dass das System nicht wie beabsichtigt funktioniert oder zu einem Bug-Haufen wird.
Wenn die Anforderungen klar sind und sich nicht ändern, die Projektbeteiligten gut kommunizieren und man den Prozess vollständig kontrollieren kann, funktioniert es. Der Fall im Originaltext sieht ebenfalls danach aus.
Ich arbeite überwiegend in Großunternehmen, und 90–99 % der eingehenden Arbeit entsprechen dem Durchschnittsfall.
Aber es gibt unzählige unicornartige Sonderfälle, die einmal in drei Jahren auftreten, und zwar ungefähr dann, wenn Mond- und Sonnenfinsternis gleichzeitig stattfinden und Hexen im Wald Zaubersprüche murmeln.
Weil man solche Fälle nicht manuell behandeln darf, sondern sie in Code implementieren muss, entstehen Bugs, und es gibt deutlich mehr Code zu prüfen und zu warten.
Von Wartung fangen wir lieber gar nicht erst an. Das ist ein wunder Punkt.
Anforderungen ändern sich immer. Das ist wie eine Naturgewalt; es gibt keine Welt, in der alle von Anfang an wissen, was gebaut werden soll, eine vollständig spezifizierte API bekommen und sich dann nur noch in eine Höhle zurückziehen müssen, um sie zu implementieren.
Die Realität funktioniert nie so, und wenn man solche Bedingungen braucht, ist Software Engineering nicht der richtige Beruf.
Ohne Benutzer wäre meine Software perfekt ;)
Ich habe einmal mit jemandem gearbeitet, der aus der Sowjetunion geflohen war. Er sagte, sowjetische Programmierer seien deshalb so gut gewesen, weil der Zugang zu Computern extrem eingeschränkt war.
Wenn man mit Bleistift und Papier programmieren muss, möchte man, dass es beim ersten Lauf funktioniert.
Zufällig arbeiteten wir bei Honeywell.
War das also eine gute Ausbildungsmethode oder eher ein guter Filter, um weniger motivierte Leute auszusortieren?
An der Schule konnten wir während des Unterrichts keine Computer benutzen, also waren wir daran gewöhnt, auf Papier zu programmieren und sogar zu debuggen.
Als ich nach Hause kam, tippte ich es ein und führte es aus; ich war neugierig, ob ich die Multics-Anekdote nachstellen könnte, die ich früher gelesen hatte.
Die erste Kompilierung schlug fehl, aber nachdem ich einen Variablennamen korrigiert hatte, lief es perfekt.
Ich erinnere mich, dass für einige Jahre in der Editieren→Kompilieren→Ausgabe-Schleife Listing-Ausdrucke viel besser waren als Terminals, weil es schwer war, Code effizient anzusehen, zu navigieren und zu korrigieren.
Mit besseren visuellen Editoren, größeren Terminals sowie schnellerem Kompilieren und Ausführen wurde es schließlich besser.
Als Analogie: Es war ähnlich wie bei frühen Feuerwaffen. Der Übergang vom Langbogen war ineffizient wegen nassem Schießpulver, unzuverlässiger Steinschlosszündung und der Notwendigkeit, alles in den Lauf zu stopfen.
In einem früheren HN-Thread zu diesem Text gibt es einen guten Kommentar des Accounts jrd259, der mit André zusammengearbeitet hatte: https://news.ycombinator.com/item?id=18415231
Es geht darum, wie wichtig ein großer Schreibtisch und ein privater Arbeitsbereich ohne Benachrichtigungen sind.
Mir fallen zwei Situationen in meinem Leben ein, in denen ich auf Papier programmiert habe
Die erste war, als ich etwa 10 bis 12 Jahre alt war. Ich war bei meinen Großeltern, wo es weder Computer noch Smartphones gab, aber eine mechanische Schreibmaschine, bei der man per Schalter zwischen schwarzer und roter Farbe wechseln konnte
Mein wichtigstes Hobby war damals Turbo Pascal, also schrieb ich auf der Schreibmaschine ein Pascal-Programm, das ich später zu Hause in den PC eingeben und ausführen wollte
Da ich eine Woche bei meinen Großeltern war, hatte ich genug Zeit, gründlich nachzudenken, von Hand zu debuggen und fehlerhafte Stellen noch einmal abzutippen
Die zweite Situation betrifft die von mir entwickelte esoterische Programmiersprache Ziim (https://esolangs.org/wiki/Ziim) und die Funktion zur binären Addition auf dieser Seite
Diese Funktion war riesig, komplex und fehlerhaft. Weil ich sie im Interpreter ausgeführt hatte, wusste ich, dass es einen Bug gab, aber nicht, wo das Problem lag oder wie ich es beheben sollte
Zufällig musste ich eine etwa sechsstündige Fernbusfahrt machen, eine perfekte Gelegenheit zum Debuggen
Ich übertrug die Ziim-Additionsfunktion mit Bleistift auf kariertes Papier und führte sie im Bus Schritt für Schritt von Hand aus. Ich konnte den Bug finden und beheben, musste aber die gesamte Anordnung der Funktion neu machen
Die Lektion scheint zu sein: Wenn man die Fähigkeit, den einfachen Weg zu gehen, absichtlich einschränkt, kann das manchmal zu gut durchdachtem Code führen
Trotzdem mache ich das normalerweise nicht so. Ich arbeite auch einfach mit groben Snippets und iteriere oder gehe im Debugger Zeile für Zeile durch. Vielleicht sollte ich das noch einmal überdenken
Wenn man aber alles auf Papier macht, unterscheidet es sich am Ende kaum noch davon, direkt am Computer zu arbeiten. Man schreibt alles auf und verliert diese Abstraktion und Sorgfalt
Als ich anfing, war das das Ende der Ära der „Großrechner“
Früher waren „Programmierer“ meist eher Datenerfasser, und oft waren es Frauen
Die Leute, die Software schrieben, saßen in von Zigarettenrauch erfüllten Büros und schrieben Programme auf Papier
Rechenzeit war teuer und knapp. Wenn während der Ausführung ein Bug auftrat, hatte man keine Chance, ihn zu beheben, bis man wieder Zeit für die Dateneingabe und erneut CPU-Laufzeit reserviert hatte
Das förderte den Ansatz, zweimal zu messen und einmal zu schneiden
Die meiste Software war damals im Vergleich zu dem, was wir heute als selbstverständlich ansehen, recht bescheiden, was das erleichterte. Außerdem waren Ein- und Ausgabe von Software extrem eingeschränkt, der Begriff UI existierte nicht einmal, und der Anschluss von Peripheriegeräten war eine große Sache
Heutzutage arbeitet man bei Software oft nach dem Motto: „an die Wand werfen und sehen, was kleben bleibt“. Es ist einfacher, halbfertigen Code zu schreiben und ihn in der IDE zu debuggen
Meine Softwareentwicklung ist eher iterativ, und ich habe hier darüber geschrieben: https://littlegreenviper.com/miscellany/evolutionary-design-...
Ich erinnere mich an eine Uni-Aufgabe, bei der wir einen einfachen Betriebssystemkernel schreiben mussten
Ich kannte C kaum und wusste über Kernel auch nicht mehr als die Theorie, musste aber ein paar Hundert Zeilen C-Code für die Aufgabenverwaltung schreiben
Ich dachte, wenn dieses Programm nicht funktioniert, gibt es wegen des parallelen Codes kaum eine Möglichkeit zum Debuggen, und die Bugs würden sich als undurchschaubare Race Conditions zeigen
Ich durchdachte das gesamte System und verbrachte mehrere Tage damit, viele kleine, unabhängige Funktionen sehr gründlich zu planen und zu schreiben
Dann kompilierte und startete ich es, und nachdem ich den unvermeidlichen Kompilierfehler wegen eines „fehlenden Semikolons“ behoben hatte, funktionierte es beim ersten Lauf
Jedes Mal, wenn eine beeindruckende Leistung gepostet wird, suchen die Kommentare im Allgemeinen nach Fehlern. Damit sollte Schluss sein
Sie entwerfen keinen Virtual-Memory-Manager für ein neues Betriebssystem, sondern sind nur Zahnräder in einer Maschine, die SQL-Abfragen in HTML verwandelt, um Kindern und alten Menschen Werbung zu zeigen
Da kann man nur zynisch und verbittert werden
Eigentlich sollten wir das nicht. Genau darum sollte es in einer Diskussion gehen
Das stimmt bis zu einem gewissen Grad, aber die bessere Frage, die die Sache positiv wendet, lautet: Wie können wir in heutigen Unternehmensumgebungen einen Zustand erreichen, in dem ähnliche Leistungen möglich sind?
Das ist meistens so, wenn ich solche Reaktionen sehe. Das Sieb der Nutzer-Moderation braucht nur ein wenig Zeit, um die besseren Kommentare nach oben zu bringen
Wenn diese Person sich der Herausforderung hätte stellen müssen, die ich erlebt habe, wäre sie daran zerbrochen
Software war damals deutlich kleiner.
Heutzutage sind die meisten Projekte schon dann im Megabyte-Bereich, wenn sie nur wenig größer als ein Spielzeugprogramm sind, und sie als einzelne Datei „herunterzuschreiben“ ist unmöglich.
Das ist größer und komplexer als das, woran die meisten heute arbeiten. Vieles, was heute gemacht wird, ist eher aufgeblasener Glue Code, der Dinge wie CRUD/REST zusammenklebt.
Es mag weniger Codezeilen haben als ein gesamtes Projekt, ist aber größer als die Einheiten, mit denen Leute typischerweise umgehen. Außerdem ist auch das nur ein Teil des gesamten Betriebssystem-Codes.
Das ist der komplette „Manager zur Verwaltung von Datei-Beschreibungsinformationen“. Er musste Dateiinformationen zwischen Festplatte und Speicher transportieren, einen Shared-Memory-Buffer-Pool verwalten und auch den Plattenspeicher für diese Informationen verwalten.
Man sollte heutige Programmierer einmal bitten, heute etwas mit denselben Anforderungen und derselben Semantik in der Sprache ihrer Wahl zu schreiben.
Die meisten würden sich schon beim Versuch, es sich vorzustellen, verirren. Ganz zu schweigen davon, es auf Papier zu schreiben, einzutippen und zum Laufen zu bringen.
Ein kleiner Teil davon sind URLs zu Elektronikbauteilen, aber fast 90 % sind einfach englischer Text. Weitere 10 % sind Zitate aus Texten anderer Leute, Webseiten, Hersteller-Application-Notes, Büchern usw.
Es ist eine einzelne Datei und wird vermutlich nicht nur für den Rest dieses Jahres, sondern dauerhaft eine einzelne Datei bleiben. Wenn es im selben Tempo weitergeht, werden daraus 12 Megabyte. Das ist keineswegs unmöglich.
Wer interessiert ist, kann
git clonehttp://canonical.org/~kragen/sw/leatherdrink.git ausführen.Derzeit ist die avr-Toolchain mit eingecheckt, daher sind es fast 200 Megabyte, und es gibt auch Fotos, Videos, Schaltpläne und Ähnliches.
Bei einer Programmiersprache wäre der monatliche Zuwachs in Bytes geringer, aber wahrscheinlich nur um etwa den Faktor fünf.
Der von André Bensoussan geschriebene Code ist hier: https://multicians.org/vtoc_man.html
Als ich mich an den Schreibtisch setzte, um mit der Arbeit anzufangen und eine aufgeschobene Aufgabe endlich zu erledigen, schweiften meine Gedanken natürlich ab, und ich wollte auf reddit oder HN Nachrichten checken.
Ich öffnete HN, und die erste Überschrift war diese:
„Man kann es schaffen“
Das hat mich motiviert.
PS: Den Artikel habe ich natürlich auch gelesen :)
„Wie hat André das ohne irgendein Werkzeug außer einem Bleistift gemacht?“
Als ich mit 14 auf die Highschool kam, schrieben wir im Programmierunterricht den Großteil des Codes auf Papier.
Ich war ein armes Kind in einem armen Land und hatte nicht nur zu Hause keinen PC; auch die wenigen „Computer“ im Computerraum der Schule waren ZX-Spectrum-Klone, auf denen die damals verwendete Programmiersprache Turbo Pascal nicht lief.