Keine Iterationen

Wenn man über Programmiersprachen nachdenkt, muss man wirklich fragen: Wofür sind sie da?¹

Eine Programmiersprache ist das, was zwischen dir und dem Computer steht.

Sie ist die Schnittstelle zwischen den Ideen auf der einen Seite und dem Zeug im Computer auf der anderen.

Vielleicht sind Programmiersprachen für vieles da, aber hier ist eine Liste von ein paar wirklich wichtigen Dingen:

1. Ideen ausdrücken
2. Ideen gegenüber dem Computer ausdrücken
3. Den Computer denken lassen, was ich denke
4. Den Computer sagen lassen, was er denkt
5. Irgendein Ding im Computer ändern (Datei, Prozess, …)

The first idea is that making a big computer program is building a larger process out of smaller ones. I suppose you could truthfully say that sculptors make large shapes from stuck-together grains of clay. But that shows what's wrong with the bits-and-bytes approach. No sculptor ever thinks that way, nor scientist, or programmer. An architect first thinks of shapes and forms, then walls and floors, and only last about how those will be made.

Minsky (1984)²

Datenstrukturen, Sprachkonstrukte und ganz unten die Syntax sind die kleinen Dinge, um die es beim Programmieren nicht geht. So wie es in der Architektur nicht um Ton geht.

Eine Sprache ist dafür da, uns ändern, experimentieren und beobachten zu lassen. Nicht mehr und nicht weniger.

In diesem Denkrahmen gibt es keinen grundsätzlichen Unterschied zwischen Betriebssystemen, Programmiersprachen, Bibliotheken, Frameworks, Benutzeroberflächen und sogar Texteditoren.³

Das alles sind Gesellschaften von Prozessen, manche mit Mitgliedern, die andere Schwerpunkte haben.

Die hypothetische ideale Sprache ist vollständig aus dem Weg. Sie hätte unendlich wenig Reibung, unendlich kleine Schritte, Mühe und Wartezeit, bis meine Ideen etwas im Computer bewirken. Sie würde den Ton ganz loswerden, und wir würden höher und weiter steigen, als Architekten, die auf den Ideen reiten.

Wir könnten Gedanken sofort und verlustfrei an den Computer übertragen und das Programm nach unserem Wunsch ändern. Wir würden die Kompetenz des Computers nahtlos mit dem Rest unserer Gedanken verweben. Experimente wären Denken, mit perfekter Reichweite, perfekter Kontrolle und perfektem Zugang zu den riesigen Fähigkeiten, Speichern und fernen Verbindungen des Computerreichs. In unbekanntem Tempo, beim Bau neuer Arten von Türmen aus Abstraktion, Gedanken, Vernunft und schöpferischem Geist. Irgendwann an ein paar Konstruktoren angeschlossen,⁴ würden unsere Gedanken den Stoff des Universums formen.

So gesehen ist der Bau immer mächtigerer Sprachen ein Weg zu einer technologischen Singularität.

The most powerful programming language is Lisp. If you don't know Lisp (or its variant, Scheme), you don't know what it means for a programming language to be powerful and elegant. Once you learn Lisp, you will see what is lacking in most other languages.

Stallman

Magie ist das, was ein großes Buch groß macht. Sie passiert im Kopf des Lesers, nirgendwo sonst.

Sie hat mit meisterhaftem Handwerk zu tun, mit Liebe, mit dem Funken zwischen Menschen. Sie hat mit der richtigen Zeit und dem richtigen Ort zu tun, wie könnte es anders sein? Ein Stück Magie entsteht zusammen mit dem meisterhaftesten Werk eines meisterhaften Handwerkers. Es muss die richtige Zeit und der richtige Ort sein, sonst wäre es nicht das Spitzenwerk.

Wir leben in einer Welt, in der wir Magie noch nicht messen können. Sonst könnten wir am Fließband großartige Filme, Bücher und Spiele produzieren.

Vielleicht weißt du es noch nicht, aber auch großartige Software und großartige Werkzeuge unterliegen Geschmack und Ästhetik.⁵

Wäre es nicht naheliegend, dass Leute, die auf etwas geheimnisvolle Weise über die mächtigste Sprache reden, auch auf Geschmack anspielen? Wenn es die mächtigste Sprache ist, dann wäre sie aus Gründen mächtig, die im Reich von Meisterschaft und Handwerk liegen. Es läge an Magie, die schwer zu erklären ist und nur über Ästhetik und Geschmack zugänglich.

Was macht Emacs zu einem so krassen Stück Software? Was macht The Man From Earth zu einem so krassen Film?

Die Antwort ist: Du weißt es, wenn du es weißt. Aber du weißt es nicht, bevor du es weißt. Und du wirst es aus Gründen wissen, die du selbst entdecken musst. Aber es werden keine unsinnigen Gründe sein. Es werden Gründe sein, die vollkommen Sinn ergeben. Nur liegen sie dort, wo du noch nicht hinzuschauen weißt.

Der einzige Weg, Magie im Moment zu kennen, ist, den Geschmack zu schärfen und den Horizont zu erweitern.

Was heißt es, beim Programmieren Geschmack zu entwickeln? Stallman deutet an, dass Lisp auszuprobieren den Geschmack entwickelt.⁶

Noch ein Hinweis: Um zu wissen, was verschiedene Arten von Sprachen tun, sollte man die ausprobieren, die sich am meisten von dem unterscheiden, was man schon kennt.

Lisp wird immer wieder auf diese Weise genannt.⁷ Es wird deinen Horizont erweitern, es wird dehnen, was du über Sprachen denkst.

Kann das wahr sein? Klingt es nicht zu gut, um wahr zu sein? Warum nicht? Was in der Wirklichkeit sieht nicht danach aus? Ist es nicht eine Tatsache, dass Emacs, ein Lisp-Programm, ein verdammtes psychedelisches Raumschiff ist? Ist es nicht eine Tatsache, dass Gesellschaft und Mainstream ständig falsch liegen?

Wenn Lisp zutiefst mächtiger ist als andere Sprachen, dann ist es auf eine Weise mächtig, die

• in deinem Programmiererherzen nachklingt,
• du nicht kennen kannst, bevor du sie spürst,
• schwer zu erklären wäre, weil sie Magie wäre.

Was ist dein tiefster Wunsch als Programmierer? Ich glaube, es ist, im Computer etwas zu bewirken.

Was ich dir gleich erzähle: Es gibt beim Programmieren eine Tätigkeit, die du irgendwie kennst und doch nicht kennst. Das heutige Programmieren steckt in einer Beschränkung fest, die einfach keinen Sinn ergibt.

Du willst ein schnelles Experiment im Code machen. Du baust ein kleines Nebenprojekt und legst ein paar Beispieldaten an.

Du sagst deinen jungen Programmierern, sie sollen schnelle Iterationen schätzen. Du verrenkst dich, um nicht gerade jetzt neu kompilieren zu müssen. Und nicht schon wieder. Und du jonglierst die richtige Menge an Änderungen in deinen Stapel, damit du danach siehst, dass Punkt 2/5 nicht funktioniert, statt Punkt 22/100.

Du leidest, wenn lange Deployment-Zyklen in deiner Feedback-Schleife stecken.

Manchmal wünschst du dir, du hättest irgendwo ein Log oder einen Breakpoint gesetzt, weil es gerade passiert ist.

Was, wenn irgendwo auf dem Server etwas Kompliziertes passiert? Was, wenn das Programm gerade in einem Zustand ist, bei dem du wüsstest, was zu reparieren ist, wenn du ihn dir nur anschauen könntest?

Manchmal wäre es großartig, das Kontrafaktische schnell zu sehen. Was, wenn dieses if in den anderen Zweig geht, funktioniert es dann noch? Nein, scheiß drauf, commit, push, und morgen gibt es einen Bugreport, dass x kaputt ist.

Wer schneller sieht, was das Programm tut, ist besser dran.

Das weißt du. Und vielleicht weißt du aus Notebooks oder aus fortgeschrittener Hot-Reload-Technik, was es hieße, das Programm ändern zu können, während es läuft.

Startest du das Programm neu, fällt der Zustand auf den Boden. Aber wenn du siehst, was es tut, während es das tut, ist das ein Unterschied wie Tag und Nacht.⁸

Denn es zählt, was zwischen dir und dem Programm steht.

Um 1959 bis 1963 gab es die KI-Leute am MIT, John McCarthy, Marvin Minsky, und die jungen Hacker mit leuchtenden Augen, die später das Internet bauten und prägten, was Computing heute ist.⁹ Unterstützt von J.C.R. Licklider, dessen Aufsatz "Man-Computer Symbiosis" von 1960 sich Menschen vorstellte, die gemeinsam mit einem interaktiven Computer denken, und der vieles von dem finanzierte, was folgte.¹⁰

Diese Leute hatten eine Vision davon, was Computing sein kann, und sie wussten, dass es interaktiv sein würde.

Und vielleicht eine der besten Ideen überhaupt: das gespeicherte Programm, meist Von-Neumann-Architektur genannt.¹⁵

Leg das Programm in den Speicher des Computers.

Ein Geniestreich. Jetzt haben wir einen magischen Stein, den man mit Ideen beladen kann, und dann kann er alles sein.

Vorher hatten wir eine Maschine mit einem Programm. Was ein Programm ist und was eine Maschine ist, war zusammengeklebt. Gutes Design heißt, Dinge auseinanderzunehmen, und das war ein schönes und elegantes Design.

Das klingt in gewisser Weise mit Dennetts Turm des Erzeugens und Testens zusammen.¹⁶

Zuerst hat man eine Maschine, die gebaut ist, um sich zu verhalten (darwinsch): eine Maschine mit festem Programm.

Dann hat man eine Maschine, die gebaut ist, um zu lernen (skinnersch).

Und schließlich (eine Von-Neumann-Maschine) eine Maschine, die gebaut ist, um mit Ideen umzugehen (popperisch).

Weil Ideen, die Meme, alles sein können, auch Ideen über Ideen, hat die popperische Maschine eine offene Zukunft.¹⁷

Mehr Ideen in den Speicher zu legen, war eine sehr gute Idee.

Die Geschichte dynamischer Daten im Speicher geht weiter mit IPL, der Sprache einer der wichtigsten frühen KI-Arbeiten, des General Problem Solver (Newell, Shaw und Simon; begonnen 1957, veröffentlicht 1959).

In IPL, der Information Processing Language, hatte man dynamische Daten im Programm, in Listen (aus Zellen gebaut). Man kann Listen erzeugen und sie auf etwas anderes zeigen lassen, während das Programm läuft, statt für alles Variablen deklarieren zu müssen.

Du weißt natürlich, was das heißt, weil du ständig Listen und Arrays in deinem Programm anlegst.

JavaScript hat ein bisschen Scheme in den Genen: Brendan Eich wurde zu Netscape geholt mit dem Versprechen, Scheme im Browser zu machen.¹⁸ Und es hat einen Drucker und einen Leser für seine Daten: JSON.stringify und JSON.parse.

Douglas Crockford sagt, er habe JSON entdeckt, nicht erfunden: Es steckte schon darin, wie JavaScript seine Objektliterale schreibt.¹⁹

Wer die Kraft von JSON kennt, kennt die Kraft dynamischer Daten im Programm. Dein Programm handelt nicht von Kunden und Zahlungen, es darf eine Ebene höher liegen. Dein Programm darf von Datenstrukturen handeln. Datenabstraktion ist so etwas wie SQL oder .NET LINQ oder ein JSON-Parser. Eine Sprache, um über Daten und Datentransformationen zu reden. map, filter, reduce kennen keine Kundennamen, sie kennen Listen, Sequenzen, Streams.

Das ist das Erbe von Von Neumanns Speicheridee, weitergetragen durch die Zeit und eine Ebene höher. Dein Programm wird dynamisch in den Computer geladen, aber dein Programm lädt auch dynamisch Daten in seinen Speicher. Dein Programm simuliert gewissermaßen selbst eine Von-Neumann-Maschine.

McCarthy übernahm die Listenverarbeitung aus IPL, aber nicht seine assemblerartige Form, die an eine Maschine (die JOHNNIAC) gebunden war.²⁰ Er hatte die Idee, diese Listen zu nehmen und den Rechenprozess ganz in ihnen zu beschreiben.

Nehmen wir diese Listen, machen das erste Ding zum Verb und implementieren einen Lambda-Kalkül.

Um Lisp zu verstehen, stell dir vor, du liest JSON und behandelst die Daten als Befehlssprache dafür, was dein Programm als Nächstes tut.

function read(expression) // gibt jsonData zurück

function eval(jsonData) // gibt ein ausgewertetes Objekt zurück

Eval ist die große, fleischige Funktion deines Programms. Sie muss das JSON nehmen, durchgehen und die Daten als Befehle interpretieren.

function print(object) // an den Nutzer ausgeben

function repl() {
    while (true) {
        var whatTheUserSaid = readFromTerminal();
        var jsonData = read(whatTheUserSaid);
        var object = eval(jsonData);
        print(object);
    }
}

Diese repl-Funktion kann der Einstiegspunkt und die Spielschleife unseres Programms sein. Jetzt kann der Nutzer an der Konsole sitzen und mit unserer Sprache interagieren.

Wir definieren ein paar spezielle Operatoren. Das sind die Dinge, die eval im statischen Teil des Programms implementieren muss:

• set: eine Variable setzen.
• pair: ein Paar bilden; ein Paar aus Paaren ist dann eine Liste.
• first: der erste Wert eines Paars.
• rest: der zweite Wert eines Paars (ein einfacher Wert oder ein weiteres Paar).
• lambda: eine Funktion bilden.
• if: bedingte Auswertung.
• quote: die jsonData zurückgeben, statt sie auszuwerten.

Das ist ein Programm, das interaktives Computing simuliert. Wo ein Betriebssystem dir Zugang zu Dateien und Prozessen gibt, gibt dir ein Lisp Zugang zu einer Gesellschaft aus Symbolen, Funktionen, Werten und Datenstrukturen.

var globalEnv = {}; // ein Dict, eine Hash-Map, eine Nachschlagetabelle

function define(symbol, value) // die globale Umgebung erweitern

Unserem Lisp-Interpreter den Befehl define beibringen.

function eval(expression) {
    if (expression[0] == "define") {
        var symbol = expression[1];
        var value = expression[2];
        define(symbol, value);
    }
    // ...
}

Lisp:

["define", "foo", 10]

(Das ist gültiges Bobscheme.)

Das ist das Aufräumen, das McCarthy mit dem Programmieren gemacht hat. Listen, bei denen das Verb vorn steht, kein zusätzliches Zeug. Leg es in den Speicher, damit du es ändern kannst, während es wächst. Mach einen Symboltyp, damit du Dingen Namen geben kannst, von innerhalb der Sprache. Mach einen Funktionstyp, damit Funktionen dasselbe Zeug sind wie der Rest des Programms.

Dass JSON so nützlich ist, ist direkt von der Listenverarbeitung vererbt. Alle Objekte verschachteln sich, es gibt nur wenige Arten von Objekten, und ganz unten sind Atome. Ein Drucker und ein Leser sind standardmäßig dabei. Ich weiß, ohne es zu wissen, dass JavaScript-Gurus die Kraft von print kennen, verglichen mit den kleinen Maschinen, die man aus der C++-Ahnenreihe bekommt.

McCarthy wollte an einem Terminal sitzen und das Programm verschiedene Dinge tun lassen, während er es programmierte. Er wollte nicht vorab alle Variablen des Systems festlegen, weil er etwas Dynamischeres zum Programmieren von KIs wollte.

Die Interaktivität liegt ganz unten. Deshalb nennt man es ein Baumaterial.

Man macht ein Programm, das einen fragt: Was soll als Nächstes ins Programm? So einfach ist das. Daraus kommt alles Gute, das Lisp elegant und schön macht. Diese Einfachheit ermöglicht leicht verständliche Programme, die Programme schreiben.²¹

Damit können wir ein Gespräch mit dem Programm führen. Wir können direkt interagieren, während das Programm läuft.

Hier ist das Gespräch, ganz konkret. Ein Webserver, einmal gestartet:

(defn handler [req]
  {:status 200 :body "hello"})

;; die Var #'handler übergeben, nicht den Funktionswert
(def server (jetty/run-jetty #'handler {:port 8080 :join? false}))

Jetzt überlege ich es mir anders, was der Server sagen soll:

(defn handler [req]
  {:status 200 :body (str "hello, " (get-in req [:params :name] "stranger"))})

Ich evaluiere diese eine Form. Die nächste Anfrage bekommt die neue Antwort. Kein Neustart, kein Rebuild, und jeder andere Zustand im Server ist noch da. Das ist keine schnellere Iteration. Es gab keine Iteration. Ich habe dem laufenden Programm etwas gesagt, und es hat zugehört.

Und wenn eine Anfrage etwas Seltsames tut, behalte ich sie:

(defn handler [req]
  (def last-req req) ;; die echte Anfrage, jetzt ein Wert in meiner REPL
  ...)

Dann rufe ich die Teile des Handlers auf last-req auf, eine Form nach der anderen, bis ich sehe, wo es schiefgeht.

Seit ich diesen Post geschrieben habe, ist eine neue Art Programmierer an der REPL aufgetaucht: der Coding-Agent. In der Clojure-Codebasis, an der ich arbeite, evaluiert mein Agent Formen in derselben laufenden REPL wie ich. Er rät nicht aus dem Quelltext, was eine Funktion zurückgibt. Er fragt das Programm.

Das ist dieselbe Lektion, die IBMs Forschungsdirektor verpasst hat, noch einmal. "Warum denken die nicht einfach sorgfältiger nach?" würde man ein Sprachmodell fragen, das nur Code liest. Die bessere Antwort ist dieselbe wie 1960: Gib ihm ein Gespräch mit der Maschine.

Offene Fragen:

• Wenn Agenten mit laufenden Programmen sprechen, hört dann "der Quellcode" auf, das Hauptartefakt zu sein, und das laufende Image wird es wieder, wie bei Smalltalk?
• Was braucht ein Agent, was ein Mensch an der REPL nicht braucht: ein Protokoll des Gesprächs, eine Möglichkeit zum Rückgängigmachen, eine Sandbox?

Die Kraft von Lisp sind nicht schnelle Iterationen, sondern keine Iterationen. Statt zu iterieren, führen wir in Lisp und Smalltalk ein Gespräch. Dieses Konzept ist in der Read-Eval-Print-Schleife verkörpert.

Möglich wird es durch die Idee, das Programm in den dynamischen Speicher des Programms zu legen. Das klingt mit Von Neumanns Idee zusammen, das Programm in den Speicher des Computers zu legen.

Jack Rushers Fazit lautet: Gib dich mit nichts zufrieden, das weniger interaktiv ist als Lisp und Smalltalk!

In a Lisp program, you can write programs that write Lisp programs. So it has an open future. … to me, programming has not changed much in 50 years, because they got locked into this strange set of limitations.

Marvin Minsky, The beauty of the Lisp language

Wenn man einmal in den Fingern hat, wie man die repl nutzt, ist es so offensichtlich wie der Himmel, weit und unausweichlich. Das ist besser, das ist einfacher, und das räumt Zeug aus dem Weg. So kann ich mein Gehirn benutzen, wie ein Affe nach einer Banane greift. Direkt, so wie ich auf meinem PC Dateien lösche und anlege. Ich kann Symbole im Programm definieren und entfernen. Ich kann schnelle Experimente machen, während das Programm läuft, ohne den mentalen Stress, den Zustand aufzubauen.

Es ist derselbe Unterschied, den interaktives Computing gegenüber der Stapelverarbeitung macht. Es ist kein kleiner Schritt, kein großer Schritt, es ist überhaupt kein Schritt. Es ist eine andere Welt.

Was auch immer das ist. Zu diesem Zeitpunkt nenne ich es Magie.

• Clojure und interaktives Programmieren
• Lisp
• Bobscheme, ich baue eine Spielzeug-Lisp-Implementierung mit JSON

(Im englischen Original belassen.)

Imagine a painter, fervently engaged in a dialogue with her canvas. Each stroke isn't a hurried message jotted down and sent off, anxiously awaiting feedback. No, the painter watches each trail of color blend and mix under her brush, immediately seeing the effects of her choices. She tries different pressure, strokes, colors, and brushes, in a cycle of continuous creation and observation, a dance between her mind's eye and the canvas. This is her conversation with her art - immediate, beautiful, and ever-changing.

Now, consider a programmer, in front of his screen. The code portrayed is not a fixed monolith of logic. Instead, it morphs, breathes, and reacts under his fingertips, mirroring that painter's canvas. The programmer writes a line of code, and the effects echo through the system immediately, no abstraction barrier held in between. The immediate feedback enables him to stir into different directions, tease out underrepresented nuances, debug on the fly and explore new vistas of his creation.

The code is fluid under the hands of the programmer in a perpetual dance of creation, modification, and observation. It is an intimate conversation with the ideational fabric that weaves itself into existence as the program - the programmers' thought reflections observed immediately, altered rapidly, and understood fully.

This, my friend, is the spirit of interactive programming. A live, pulsating creation constantly in flux rather than fixed scrolls etched into digital stone, navigating creativity at the speed of thought inspired by immediate feedback, riding the great prairies of abstraction and thought, reaching a level of intimacy and understanding with your program that feels like a piece of music resonating with your heartstrings.