Nach einer sehr deutlichen Einordnung der Aufnahmezeit kommen wir im Wesentlichen zu den Unterschieden zwischen x86 und ARM. Natürlich wird auch geklärt, was das ist. Gegen Ende gibt es noch ein paar Meinungen und Weissagungen zum Thema KI.

Rückbezug STP011: grundsätzliche Beschreibung von Maschinensprache

heutzutage relevante ISA

Warum ist die Wahl der ISA wichtig?

Was steht in einem Maschinencode-Befehl drin?

Abwägungen zwischen Energieeffizienz (ARM) und Performance (x86)

Beim letzten Mal war zuviel Buch für zu wenig Zeit übrig. Daher nun die Fortsetzung mit zwar gelegentlich etwas angestaubten, im Großen und Ganzen aber sinnvollen, Vorschlägen zur Organisation von Softwareentwicklung.

Brooks beschreibt als Leitmotiv die Kathedrale von Reims, die von acht Generationen von Baumeistern errichtet wurde, aber trotzdem eine beachtliche gestalterische Kohärenz aufweist, da die nachfolgenden Generationen das ursprüngliche Design ungewöhnlich stark respektieren: "Das Ergebnis verkündet nicht nur die Herrlichkeit Gottes, sondern auch seine Macht, gefallene Menschen von ihrem Stolz zu befreien."

Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?

Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?

Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?

in diesem Dialog zwischen Architekt und Erbauer stellen sich viele Ideen des Architekten als unpraktikabel heraus und werden verworfen... bis zum nächsten Mal

der vorgeschlagene Lösungsansatz ist leider etwas antiquiert: "Eine Disziplin, die dem Architekten die Augen öffnen wird, ist es, jeder kleinen Funktion einen Wert zuzuweisen: Fähigkeit X ist nicht mehr wert als M Bytes Speicher und N Mikrosekunden pro Aufruf. Diese Werte dienen als Richtschnur für die ersten Entscheidungen und während der Implementierung als Leitfaden und Warnung an alle."

Wie stellt eine Gruppe von 10 Architekten sicher, dass ihre Entwürfe von 1000 Mitarbeitenden berücksichtigt und von allen Benutzern verstanden werden?

Qualitäten guter Dokumentation

Wie erarbeitet man Designs? Vorschlag von Brooks:

noch eine kleine Anmerkung am Rande: auch Kurzabsprachen am Telefon sollten dokumentiert werden :)

Woran können Projekte scheitern?

Wie sollen Teams kommunizieren? Neben direkten Gesprächen z.B. via Telefon und Gruppengesprächen z.B. in Meetings wird ein Arbeitsbuch vorgeschlagen.

D. L. Parnas von der Carnegie-Mellon-Universität hat eine noch radikalere Lösung vorgeschlagen. Seine These lautet, dass ein Programmierer am effektivsten ist, wenn er von den Details der Konstruktion von Systemteilen, die nicht seine eigenen sind, abgeschirmt wird, anstatt ihnen ausgesetzt zu sein. Dies setzt voraus, dass alle Schnittstellen vollständig und genau definiert sind. Dies ist zwar ein solider Entwurf, aber in der Abhängigkeit von seiner perfekten Ausführung ist eine Katastrophe vorprogrammiert. Ein gutes Informationssystem deckt Schnittstellenfehler auf und regt zu deren Korrektur an.

Xyrill stimmt voll und ganz zu: sorgfältiges Gegenlesen der Meeting-Minutes der benachbarten Teams ist zwar extrem zeitaufwändig, verhindert aber regelmäßig katastrophale Design-Entscheidungen

Organisationsstruktur: Brooks hält eine baumförmige Organisationsstruktur für unausweichlich (mehrere Vorgesetzte für einen Angestellten = Chaos) und schaut darauf, was jedes Team haben sollte

Option 1: Produzent und Architekt sind dieselbe Person

Option 2: Produzent als Chef, Architekt als seine rechte Hand

Option 3: Architekt als Chef, Produzent als seine rechte Hand

Es gibt noch acht weitere Kapitel, die wir irgendwann™ mal besprechen werden.

Diesmal vieleicht doch eher aus Interesse denn aus Resignation. Wieder geht's um Holz. Allerdings noch nicht so weit, wie Xyrill sich das zuerst vorgestellt hatte.

Rückbezug STP072: Programmierung besteht aus Algorithmen und Datenstrukturen, Holzbau besteht aus Materialien (siehe STP053) und Fertigungstechniken (diesmal)

Schritt 1: Auftrennen

Schritt 2: Abrichten

Schritt 3: Aushobeln

Exkurs Fügen:

Schritt 4: Verleimen

Schritt 5: nochmal Aushobeln

Schritt 6: nochmal Winkelkante

Schritt 7: Formatzuschnitt

Auch heute geht es mit Rost und Kaffee weiter, allerdings mit grundsätzlicheren Datentypen. ttimeless wird von besonders winzigen Datentypen überrascht und Xyrill formuliert Gedanken darüber, warum Struktur das Handeln bestimmen sollte.

Rückbezug STP071: anhand von JSON haben wir die sichtbaren Datentypen besprochen

Einwurf Kombinatorik: Wieviele mögliche Werte haben die vorgenannten Typen (sofern nicht unendlich)? (wir schreiben K(T) für die Kardinalität des Typs T)

Listen wirken sich auf die Kardinalität also wie eine Potenzierung aus

Produkttypen: Gesamttyp P enthält je einen Wert von Typ T_1, T_2, ..., T_N, somit K(P) = K(T_1) * K(T_2) * ... * K(T_N)

Summentypen: Gesamttyp S enthält entweder einen Wert vom Typ T_1 oder T_2 oder ... oder T_N, somit K(P) = K(T_1) + K(T_2) + ... + K(T_N)

sehr kleine Spezialfälle: Gibt es Datentypen, die kleiner als bool sind?

Abendgedanken: Warum das ganze Gerede über Datentypen?

Offenbar gibt es unterschiedliche Ergebnisse, wenn verschiedene Datentypen für die gleichen Dinge verwendet werden. Wir fangen heute mal damit an, zu verstehen, welche Datentypen es denn überhaupt gibt. Außerdem geht es scheinbar um Kaffee und Rost.

JSON: ein populäres Format für die Serialisierung von Daten

atomare Datentypen: einzelne Werte (C++ nennt sie "Plain Old Data" (POD), Perl nennt sie "Skalare")

Listen: ein abgeleiteter Datentyp

assoziative Datenfelder: ein anderer abgeleiteter Datentyp

Damit ist alles beschrieben, was JSON kann, doch es gibt so viel mehr! Beispiele für abgeleitete Datentypen:

im Gespräch erwähnt

Manche Dinge geben keine ganze Folge her. Dies ist der Versuch, ein paar davon zusammenzufassen: Wie definiert sich ein Geek? Bringt es etwas, den Computer aus und wieder einzuschalten? Und rechnet es sich vielleicht in umgekehrtem Polnisch besser?

Talk Nr. 1: Geek Code

Talk Nr. 2: Ist was dran an "try turning it off and on again"? Ja! Hierzu eine Kurzeinführung in Kombinatorik:

Talk Nr. 3: Umgekehrte polnische Notation

Wer hat sich nicht schon einmal über schlechte Benutzeroberflächen geärgert? Aber wer wiederum hat sich Gedanken gemacht, warum diese Oberflächen so sind, wie sie sind, oder wie das Ganze überhaupt zustande kommt?

Rückbezug zu STP008 (2D-Grafik) und STP010 (3D-Grafik): dort besprochen die grundsätzliche Methodik zum Zeichnen mit Pixeln, aber wer zeichnet hier eigentlich?

Thema heute: Wie baut man als Anwendungsprogramm seine GUI zusammen?

Wie baut man so ein GUI-Toolkit? Retained Mode vs. Immediate Mode

Layoutstrategien: Wie werden Steuerelemente gegeneinander angeordnet?

Layoutstrategien bei Webseiten und Webapplikationen

zum Weiterhören: Pentaradio vom März 2024: "UI: Hui oder pfui?"

In dieser Episode wird ein lang gehegter Traum wahr. Xyrill hat ein Buch gelesen und spricht darüber. Obwohl es nicht sehr dick ist, ist es doch sehr gehaltvoll und so entscheiden wir uns kurz vor Ende der Sendung für eine spontane Planänderung.

„Die wichtigste Entscheidung, die ich je getroffen habe, war, die IBM-360-Serie von einem 6-Bit-Byte auf ein 8-Bit-Byte umzustellen und damit die Verwendung von Kleinbuchstaben zu ermöglichen. Diese Veränderung verbreitete sich überall.“

zum Buch: "Vom Mythos des Mann-Monats" ("The Mythical Man-Month") dokumentiert Brooks' Erfahrungen als Projekt-Manager in einem der frühen großen Software-Projekte

Hörempfehlung: Pentaradio vom Dezember 2022

Teergruben-Analogie: steckt ein Tier mit einem Bein in der Teergrube, kann es das Bein meist aus eigener Kraft herausziehen; alle Beine in der Teergrube sind hingegen meist ein Todesurteil

Programme können von Einzelpersonen oder Zweierteams erschaffen werden

vom Programm zum Programmprodukt: Generalisierung (Nützlichkeit für eine ganze Klasse von Situationen), Testabdeckung (siehe STP038), Dokumentation, fortlaufende Wartung -> heute sagt man "Produktisierung" dazu

vom Programm zum Programmsystem: Einbettung in ein Netzwerk anderer Programme mit konsistentem Stil und definierten Schnittstellen untereinander

Programmsystemprodukt: ein produktisiertes Programmsystem

Problem 1: Programmierer sind schlecht im Schätzen von Zeitaufwand

Problem 2: konventielle Planungsmethoden funktionieren nur, wenn "Personen und Monate austauschbar sind"

Problem 3: der Zeitplan wird durch die Bedürfnisse des Kunden bestimmt, nicht durch die Bedürfnisse der Programmierer

Problem 4: Was macht man, wenn dann das Kind in den Brunnen gefallen ist und man zu spät dran ist?

Beobachtung: sehr weite Spannbreite im Produktivitätsspektrum der Software-Entwickler; die besten sind 10x so produktiv wie die schlechtesten

Alternativvorschlag: Teamstruktur analog zu Operations-Teams in der Chirurgie

genaue Rollenverteilung in diesem Vorschlag

großer Fokus auf den unterstützenden Sekretärs- und Schreiberrollen, um den Chirurgen und Copilot von Schreibarbeiten zu entlasten

Skalierungsfrage ist hierdurch vereinfacht: ein Projekt mit 2000 Mitarbeitern kann damit in 200 Zehnerteams geteilt werden, sodass nur die 200 Chirurgen miteinander reden müssen

Endlich ist die Hardware geliefert und montiert; Zeit, der Elektronik Leben einzuhauchen. Was könnte da besser passen als die Linux-Distribution der Wahl.

Rückbezüge: STP065/066, Gamespodcast

Unterschiede zu Windows und macOS

Wie wählt man eine Distribution?

Auf dem Kongress gab es eine Postkarte.

Nachdem es sich als eine gute Entscheidung erwiesen hat, die ursprünglich geplante Episode zu teilen, geht es heute nun konkreter um die Auswahl der Komponenten und deren Montage in den Selbstbau-PC.

fortgesetzt aus STP065: Wie wählt man Komponenten so, dass alles zusammenpasst?

Webempfehlungen:

Wie baut man es zusammen?

weitere Empfehlungen