Ich schreibe Code ungefähr so wie vor zehn Jahren: Ich mache Änderungen in meinem Texteditor, wechsle zu einem Terminal und führe einen Befehl zum Kompilieren und Ausführen aus. Ich schaue mir das Ergebnis an und wechsle dann zurück zu meinem Editor. Wenn ich unsicher bin, füge ich Trace-Ausgaben hinzu oder starte in einem Debugger neu. Wenn eine Ausnahme mein Programm zum Absturz bringt, behebe ich sie und starte neu.

Ich beneide, was Lisp-Programmierer tun. Lisp-Entwicklung erfolgt, indem man Code direkt in das REPL eingibt, um Teile des lebenden, laufenden Systems hinzuzufügen, zu entfernen und zu ersetzen. Ein Lisp-Programmierer muss nicht "umschalten", weil er sich bereits im Prozess seines Programms befindet. Er "kompiliert und führt" nie aus, weil der Code bereits läuft, und er bearbeitet durch Hot-Swapping. Er startet nicht in einem Debugger neu, weil er alles inspizieren kann. Er startet nicht bei Ausnahmen neu, weil das Bedingungssystem es erlaubt, von überall fortzufahren.

Eine Konsequenz ist, dass es zu Beginn eines Lisp-Projekts möglicherweise keinen Quellcode gibt; die sich entwickelnde Definition existiert nur im Speicherabbild. Das ist so, wie Menschen relationale Datenbanken am Anfang behandeln—das Schema existiert nur in der laufenden Datenbank. Schließlich wird es in eine Datei unter Versionskontrolle ausgegeben.

Ich bin kein Lisp-Entwickler, also werde ich neidisch bleiben. Aber mir ist klar geworden, dass ich nicht versucht habe, näher heranzukommen. In Haskell gibt es Teilerfolge: Das Typsystem reduziert Ausnahmen, und der Haskell-Sprachserver (hls) mit Eglot von Emacs bietet bessere Introspektion. ghcid überwacht Änderungen und kompiliert schnell neu.