- Gerald Sussman sagt, dass er seit 1962 durch frühe Computing-Umgebungen wie IBM 7094, PDP-6, Mac Hack 6 und Maxima hindurch an der Freude am Programmieren selbst festgehalten hat
- Programmieren ist nicht das mechanische Übertragen einer Spezifikation in Code, sondern eher abstraktes Engineering-Design, bei dem unter unvollständigen Zielen mögliche Spezifikationen und Implementierungen gemeinsam gefunden werden
- Mit einem nebeneinandergestellten Blick auf die eval/apply-Struktur von Lisp und das Zusammenspiel der Maxwell-Gleichungen versteht er Programmieren als kreative Tätigkeit, die wie Physik, Mathematik oder Philosophie tiefe konzeptionelle Probleme behandelt
- Bugs sind nicht bloßes Scheitern, sondern Lerngelegenheiten, die entstehen, wenn endliche Menschen Probleme mit vereinfachten Plänen lösen, und Teil einer „Problemlösung durch das Debuggen eines fast richtigen Plans“
- Automatische Differentiation, die Erweiterung generischer Operationen in Scheme und die Erfahrung, klassische Mechanik als ausführbare Programme auszudrücken, zeigen, dass Programmieren andere Disziplinen klarer machen kann; vollständig wird der Spaß erst, wenn man dies als free/libre software teilt
Entwurf und Erkundung jenseits des Codings
- Sussman nutzte seit 1962 als Highschool-Schüler Computer und kam im Columbia Science Honors Program mit Computing in Kontakt
- Frühe Computer waren Maschinen wie die IBM-7094-Familie, kosteten Millionen Dollar, konnten nur 2^15 Wörter zu 36 Bit adressieren und liefen mit einem Zyklus von etwa 2 Mikrosekunden
- Nach seinem Eintritt am MIT arbeitete er mit Computern wie dem DEC PDP-6, dessen System 2^18 Wörter zu 36 Bit adressieren konnte
- Großer Speicher wurde für frühe symbolische Manipulationssysteme wie Maxima benötigt
- Das MIT bestellte bei Fabritek einen großen Speicher; die Fertigung dauerte ein Jahr, und aktenkundig kostete er etwa 380.000 Dollar
- Weil dieser Speicher damals außergewöhnlich groß war, bekam er nach dem Wal den Namen Moby
- Er war an Künstlicher Intelligenz, dem Entwurf neuer Computer, der Erfindung von Programmiersprachen, numerischen Simulationen in der Himmelsmechanik und dem Schreiben großer symbolischer Systeme beteiligt, doch im Kern stand stets seine Liebe zum Programmieren
- Programmieren ist keine mechanische Arbeit, bei der eine wohldefinierte Spezifikation in ausführbaren Code übersetzt wird
- Gute Spezifikationen kommen meist nicht von oben herab
- Erst nachdem man erkundet hat, was sich implementieren lässt, schreibt man eine Spezifikation, die zu dem passt, was tatsächlich erreichbar ist
- Deshalb ist Programmieren eine gemeinsame Erkundung, bei der man auf ein teilweise definiertes Ziel hin mögliche Spezifikationen und Implementierungen zusammen findet
- Anders als physisches Engineering wird Programmieren weniger durch materielle Beschränkungen wie Toleranzen, Schnittkrümmungen oder Widerstandsfehler begrenzt als durch die Fähigkeit, Gedanken zu organisieren
- Programmierer wählen Darstellungen, Algorithmen und Abstraktionsebenen und arbeiten mit einer riesigen virtuellen Maschine
Programmieren als kreative Kunst
- Um das Gefühl des Programmierens zu erklären, zitiert Sussman einen Text, in dem Edgar Allan Poe beschreibt, wie er „The Raven“ schrieb
- Poe sagt, das Werk sei nicht durch Zufall oder Intuition entstanden, sondern Schritt für Schritt wie ein mathematisches Problem vollendet worden, und legt einen komplexen Prozess aus Auswahl, Streichung, Einfügung und Überarbeitung offen
- Dieser Prozess kommt dem tatsächlichen Gefühl des Programmierens näher als die Vorstellung, eine Spezifikation in Code zu verwandeln
- Programmieren steht kreativen Künsten wie Architektur, Musik, Mathematik und theoretischer Physik näher
- Mathematik ist eine Tätigkeit, bei der man schöne Theoreme erfindet
- Theoretische Physik ist eine Tätigkeit, bei der man Erklärungen für die physische Welt erfindet
- Auch beim Programmieren geht es darum, Ideen und Strukturen zu erfinden und zu verfeinern
Die Struktur hinter eval/apply und den Maxwell-Gleichungen
- Die Erfahrung, im ersten Jahr am MIT Lisp 1.5 und den eval/apply-Interpreter zu lernen, war für Sussman ein Wendepunkt
- eval nimmt einen Ausdruck und eine Umgebung, wertet Operator und Operanden aus und erzeugt so Prozedur und Argumente; apply nimmt Prozedur und Argumente, bindet die Argumente an formale Parameter und kehrt dann zur Auswertung des Rumpfs zurück
- Sussman sieht in dieser Struktur ein Muster, das für alle Computersprachen und auch für die Funktionsweise von Computern selbst gilt
- Zur gleichen Zeit beeindruckte ihn im Elektromagnetismusunterricht noch etwas anderes stark
- Maxwell fügte zur Auflösung des Widerspruchs zwischen Ladungserhaltung und bestehenden Gleichungen den Term des Verschiebungsstroms hinzu
- Daraus ergab sich die Gleichung elektromagnetischer Wellen und die Verbindung, dass Licht eine elektromagnetische Welle ist
- Zwischen dem Zusammenspiel von eval/apply und der Struktur der Maxwell-Gleichungen, in denen elektrisches und magnetisches Feld gegenseitig Veränderungen hervorrufen, besteht eine tiefe Analogie
- Diese Analogie hängt auch mit den Beziehungen dualer Variablen wie Ort und Impuls oder Energie und Zeit zusammen
- Beim Programmieren begegnet man alltäglich philosophischen Fragen
- Wie der Name
Chicagoin einem Programm auf die reale Stadt verweist, ist nicht trivial - Ob zwei Objekte identisch sind, zeigt sich daran, ob sich beim Verändern des einen auch das andere ändert; Mutation ist also mit der Frage der Identität verbunden
- In rein funktionalen Programmen gibt es keine Mutation, daher muss Identität anders verstanden werden
- Innerhalb zitierter Ausdrücke kann das Prinzip scheitern, dass „Gleiches durch Gleiches ersetzt werden kann“
- Aussagen wie „Alle Raben sind schwarz“ machen, wie bei Hempels Raven Paradox, die Bedeutung von Evidenz schwierig
- Wie der Name
Umgang mit Bugs
- Sussman betrachtet Bugs nicht als beschämendes Scheitern, sondern als Lerngelegenheit
- Mit guten Werkzeugen kann Debugging wie ein Abenteuer Spaß machen, und Bugs sollten Namen haben, etwa fencepost error oder reader-writer bug
- Bugs sind auch das Ergebnis mächtiger Entwurfsstrategien
- Menschen können nicht alles auf einmal bedenken und machen deshalb Pläne
- Pläne verlangen Vereinfachung, und Vereinfachung erzeugt ausgelassene Teile
- So entstehen Bugs, und Debugging wird zum Prozess, einen fast richtigen Plan in die gewünschte Richtung zu korrigieren
- Sussman nennt diesen Ansatz „Problemlösung durch das Debuggen eines fast richtigen Plans“
- Das Beispiel des Entwurfs elektrischer Filter zeigt diese Strategie
- Um einen Filter mit einem Verhalten zwischen 30 Hz und 3 kHz zu bauen, faktorisiert man die Systemfunktion
- Mit Widerständen und Kondensatoren baut man die nötigen Teilschaltungen auf
- Doch jede Teilschaltung beruht auf der Annahme „es fließt kein Ausgangsstrom“, sodass beim Zusammenschalten ein loading bug entsteht
- Ein Verstärker-Patch kann dieses Problem in manchen Situationen lösen
- Nicht alle Bugs machen Spaß
- Sussman kritisiert C und C++ als voller Fallstricke
- Dass wegen Speicherverwaltungsbugs oft ein neuer Kernel nötig wird, verbindet er ebenfalls mit in C geschriebenem Code
- Auch in Python führt er mangelnde Konsistenz an:
{}ist ein Dictionary, aber{1}ein Set, und ein Tuple wird nicht durch Klammern, sondern durch ein Komma definiert
Automatische Differentiation und ausführbare Physik
- 1992 hielt sich Sussman bei der Gruppe von Kip Thorne am Caltech auf, lernte Allgemeine Relativitätstheorie und nutzte Programme als Medium zur Speicherung von Wissen
- Gemeinsam mit Dan, einem Entwickler von Floating-Point-Chips bei Hewlett-Packard, dachte er über Ableitungen von Funktionen nach und entdeckte forward-mode automatic differentiation unabhängig neu
- Ziel war ein Ansatz, der weder symbolische Differentiation durch Einsicht in das Innere einer Funktion noch numerische Approximation war
- Der Kern war die chain rule
- Wenn man Zahlen zu differential objects mit einem endlichen und einem infinitesimalen Teil erweitert, funktioniert die chain rule bei Funktionskomposition automatisch
- Weil er Scheme verwendete, konnte er primitive arithmetische Operatoren passend für differential objects neu definieren, und Sussman implementierte dies in einer nächtlichen „hack attack“
- Danach trugen mehrere Personen dazu bei, Ableitungen höherer Funktionen, mehrfache Ableitungen und die dynamische Erweiterung primitiver Scheme-Operationen zu verfeinern
- Abelson half dabei, die korrekte Theorie mehrfacher Ableitungen auszuarbeiten
- Jeff Siskind, Barak Pearlmutter und Alexey Radul debuggteten subtile Bugs bei Ableitungen höherer Funktionen
- Hansen entwickelte eine Methode, primitive Operationen in Scheme effizient dynamisch zu erweitern
- Diese Arbeit führte zum System Scmutils, das er zusammen mit Jack Wisdom nutzte, um klassische Mechanik und Differentialgeometrie zu lehren und zu erforschen
- Das Buch von Sussman und Wisdom, Structure and Interpretation of Classical Mechanics, war ein Versuch, das Verständnis der klassischen Mechanik durch Rechenmethoden zu klären
- Die traditionelle Notation der Lagrange-Gleichungen ist ohne kulturelles Vorwissen mehrdeutig und auch aus Sicht der Typen von Funktionen problematisch
- Schreibt man sie in funktionaler Notation und als Scheme-Code, werden mathematische Ideen zu klaren, ausführbaren Programmen
- Am Beispiel des harmonischen Oszillators werden die korrekten Bewegungsgleichungen und die Beziehung zur Kreisfrequenz aus Masse, Federkonstante und Position berechnet
Spaß wird erst vollständig, wenn man teilt
- Sussman fasst die Freude am Programmieren in mehreren Strängen zusammen
- die Freude, tiefe Analogien zwischen verschiedenen Welten zu entdecken
- die Freude, Problemen zu begegnen, über die Philosophen lange nachgedacht haben
- die Freude an der Jagd nach Bugs
- die Freude, gute Ideen und Abstraktionen zu finden
- die Freude, andere Disziplinen mit Programmen klarer zu machen
- Der Spaß am Programmieren wird vollständig, wenn man die Arbeit mit anderen teilt, und er empfiehlt die Nutzung und Entwicklung von free/libre software
- Sussman bedauert, dass die Aufnahme über Zoom erfolgen musste, und sagt, er wolle Software, die man lesen, verändern und erneut teilen kann
- Für freie Software und Softwarefreiheit verweist er auf GNUs Philosophie freier Software und bittet um Mitwirkung und Spenden an die Free Software Foundation
1 Kommentare
Hacker-News-Kommentare
Dieser Teil hat mir wirklich gefallen: „Man schreibt Programme als eine Art, sich an etwas zu erinnern. Meine Erinnerung sind die Programme, die ich geschrieben habe. Wenn man Dinge wie Mathematik, Physik oder Biologie lernt und Programme schreibt, die sie ausdrücken, dann sind sie auch später beim Lesen nicht mehrdeutig und leicht zu verstehen; so speichert man gewissermaßen Wissen.“
https://www.infoq.com/presentations/Expression-of-Ideas/
Sie liegt thematisch sehr nah an dem obigen Zitat und behandelt, wie Programmieren hilft, Gegenstände wie Mathematik und Physik tiefer zu verstehen.
Zum Beispiel hilft die Wirkungsweise von Schmerzmitteln dabei, Keylogger oder Man-in-the-Middle-Angriffe zu verstehen, und wenn man sich die „Grammatikprüfung“ der DNA während der Mitose ansieht, kann man einiges über Kompilierung im Allgemeinen lernen.
Wenn ein Welpe alles verschluckt, was er sieht, liefert er dem Immunsystem gewissermaßen genügend Testdaten über die Umgebung; das ähnelt auch Machine Learning, und viele Konzepte der Cybersicherheit lassen sich ebenfalls über Biologie verstehen.
Da ich eher in Bildern denke, fiel es mir schwer, Mathematik wirklich zu verstehen; Coding ermöglichte mir, Bilder und Beziehungen im Kopf aufzubauen.
Ich hatte Glück, das als Kind zu entdecken; ohne das hätte ich mich wohl verirrt.
Probleme, Entscheidungen, Gründe, die zugrunde liegenden Fakten und die geprüften Alternativen sind alles Wissen, und jeder in eine Programmiersprache eingegebene Befehl ist ebenfalls eine Entscheidung.
Softwaredesign kann lange genug bestehen, dass frühere Entscheidungen und ihr Kontext vergessen werden, und es kann lange genug andauern, dass Menschen gehen, Wissen verschwindet und neue Leute hinzukommen, denen dieses Wissen fehlt.
Den Computer dazu zu bringen, den Quellcode zu verstehen, ist nicht der schwierige Teil; schwieriger ist es, anderen Menschen verständlich zu machen, was erreicht wurde, damit sie besser und schneller arbeiten können.
Wenn Kopf und Gedächtnis nicht ausreichen, muss man mithilfe von Techniken wie Schreiben, Drucken und Software größere Wissenspakete erinnern und organisieren.
Das größte Problem in der Mathematik war für mich, dass ich weder darauf vertrauen konnte, keine Fehler zu machen, noch darauf, Fehler zu entdecken.
Ein Compiler oder Interpreter bringt mich dazu, sie zu bemerken.
Vor einiger Zeit habe ich im Keller der NYU zusammen mit etwa 20 Doktoranden der Neurowissenschaften einen Vortrag von Sussman gehört.
Er sprach schon über dieses Thema, lange bevor Interpretierbarkeit von KI in Mode kam.
Ich stellte eine Frage, und er merkte sofort, dass ein Elektrotechniker im Raum war; er ging zur Tafel daneben und zeigte, dass man aus ersten Prinzipien heraus verstehen kann, wie ein Operationsverstärker funktioniert.
Dieser Mensch hatte enorme Energie und Intelligenz, und er hat definitiv einen tiefen Eindruck hinterlassen.
Ich habe das Video noch nicht gesehen, aber mir fiel sofort das Zitat von Alan J. Perlis ein, das Sussman und Abelson in der Widmung von SICP verwenden.
Darin geht es darum, dass es in der Informatik sehr wichtig ist, den Spaß am Computing zu bewahren, und dass es in den Anfangstagen wirklich Spaß gemacht hat.
Kunden kamen gelegentlich zu Schaden, und man begann, ihre Beschwerden ernst zu nehmen; zugleich geht es um die Sichtweise, dass wir nicht dafür verantwortlich sind, diese Maschinen erfolgreich, fehlerfrei und perfekt zu nutzen.
Vielmehr tragen wir die Verantwortung, die Maschinen voranzutreiben, sie in neue Richtungen zu schicken und den Spaß zu erhalten; im Kern steht der Wunsch, dass die Informatik ihren Sinn für Spaß nicht verliert und wir uns nicht wie Missionare oder Bibelverkäufer aufführen.
Man soll nicht glauben, der Schlüssel zu erfolgreichem Computing liege ausschließlich in unseren Händen; was wir in der Hand halten, sei vielmehr Intelligenz – also die Fähigkeit, in der Maschine mehr zu sehen als bei der ersten Begegnung und sie größer zu machen.
Für den Rest von uns, der meist Programme zum Bohnendrehen baut, ist es aus Sicht der Leute, die das Gehalt zahlen, viel wichtiger, nicht eine einzige Bohne zu verlieren, als wie viel Spaß wir haben oder wie sehr wir die Möglichkeiten erweitern.
Also kein Bug, sondern ein kleines Spaßpaket /s
Ein besserer Titel wäre eher: „Akademische Informatik macht Spaß, oder sollte Spaß machen.“
Im Kern geht es darum, dass das Entdecken von Analogien, philosophisches Nachdenken, Debugging, gute Ideen und das Gewinnen von Klarheit alles Spaß macht; das ist aber vor allem der Luxus von Professoren, die für solche Tätigkeiten bezahlt werden, und scheint – abgesehen von der streitbaren Freude am Debugging – nicht besonders gut in die Welt von „der Kunde will das bis Ende der Woche“ zu passen.
Den Großteil von „Programmierung“ sollte man wahrscheinlich eher wie Schweißen als Fach einer Berufsschule betrachten.
Die Entwicklung neuer Schweißtechniken ist durchaus ein Forschungsthema auf Graduiertenniveau, aber die meisten Schweißer und Programmierer arbeiten mit gut bekannten Werkzeugen und vergleichsweise einfachen Systemen.
Berufsschüler wollen vielleicht keine Zeit darauf verschwenden, MIT/GNU Scheme zu lernen, das sie im Berufsleben nie wieder verwenden werden; für akademische Studierende kann es dagegen lohnend sein, ähnlich wie für Linguistikstudierende, die lernen, Linear B zu lesen und zu schreiben.
Jede Tätigkeit kann Spaß machen, aber am Ende wirkten sich Bedingungen wie die Kompetenz und emotionale Stabilität von Kollegen und Managern, Gestaltung und Sicherheit des Arbeitsplatzes, existenzsichernde Bezahlung und die Frage, ob eine Organisation schlampige Arbeit durchgehen lässt, stärker aus; das gilt ebenso für andere Fachberufe wie die Programmierung industrieller Steuerungssysteme.
Du würdest feststellen, dass neugierige, nachdenkliche und gebildete Menschen – ob autodidaktisch oder nicht – in jedem Beruf bessere Arbeit leisten als solche, die das nicht sind.
Als ich vor langer Zeit als Schweißer arbeitete, waren die klugen, motivierten und neugierigen Leute ebenfalls besser als diejenigen, die einfach nur ihre Zeit absaßen.
Daher stimme ich zu, dass Programmierung dem Schweißen ähnelt, aber auf eine andere Weise, als du es gemeint hast.
SICP hat meine Art, über Code, Abstraktion und Modularität nachzudenken, völlig verändert, während meine Kolleginnen und Kollegen neben mir in Pascal oder C herumhackten.
Mit Lisp/Scheme konnte ich ein mentales Modell des Problems aufbauen, während die anderen die Abstraktion im Kopf leisten und sie dann in Sprachen umsetzen mussten, die Low-Level-Konzentration verlangten.
Deshalb bin ich ewig dankbar, SICP so früh begegnet zu sein.
Je nachdem, in welcher Sprache man programmiert, kann es mehr Spaß machen oder sich angenehmer anfühlen.
Mit C++ werde ich mich vermutlich nie wirklich wohlfühlen.
Es ist schön, die Sichtweise eines der Autoren von SICP auf Programmierung zu hören, und auch die Anekdoten in den ersten Minuten sind gut.
Als ich sagte, dass ich es unbedingt brauche, weil ich Sussman am nächsten Tag treffe, rief ein Mitarbeiter beim Harvard co-op an; dort gab es noch ein Exemplar, also nahm ich ein Uber zum Harvard-Buchladen und kaufte SICP.
Am nächsten Tag ging ich in Sussmans Büro am MIT, und zufällig war auch Abelson dort und gerade im Begriff zu gehen, sodass beide mein SICP signierten.
Sussman fügte hinzu: „Wenn du 15 Minuten früher gekommen wärst, hätte meine Frau auch unterschrieben!“ Bis dahin wusste ich nicht, dass seine Frau die Korrektorin von SICP gewesen war.
Es gibt auch ein großartiges Foto von mir mit diesen beiden Zauberern und dem gerade signierten violetten Buch.
Ich möchte dieses Video unbedingt bald sehen.
Ich habe SICP noch nicht wirklich gründlich durchgearbeitet, aber das Buch ausgeliehen und beim Renovieren des Hauses die Vorlesungen gehört.
Das Sussman-Zitat aus der SICP-Vorlesung über das Verstehen komplexer Dinge baue ich oft in Vorträge über Architektur ein; es ist immer die Folie, bei der alle hektisch mitschreiben.
Ehrlich gesagt habe ich Programmieren jahrelang geliebt, und eine Zeit lang war es auch mein wichtigstes Hobby.
Ich habe neue Sprachen oder Software ausprobiert, Programmierbücher gelesen und mich in verschiedenen Chats wie libera/freenode herumgetrieben.
Aber als ich Freelancer wurde und mich darauf konzentrierte, in kleineren Kontexten schnell brauchbaren Code zu liefern, ließ diese Leidenschaft nach.
Für mich als Engineer ist das insgesamt vielleicht eine gute Sache, aber im Arbeitsalltag sind viel Spaß und Lernen verschwunden.
Freelancing und Consulting bedeuten meist, Probleme zu lösen, fast wie Problem-Shooting: Probleme so schnell wie möglich aus dem Weg zu räumen, und Eleganz ist keine Voraussetzung.
Wenn man ein Builder sein möchte, der Werkzeuge erschafft, passiert das im Freelancing vermutlich selten; ein Wechsel in eine Consultant-Rolle könnte das eher ermöglichen.
Consulting verstehe ich als eher langfristige Beziehung, daher wäre das als nächster Schritt eine Überlegung wert.