Ein mürrischer Entwickler probiert einen Language Server
A curmudgeon tries a language server
Ein erfahrener Haskell-Entwickler, der seit zehn Jahren Code auf dieselbe Art schreibt, entdeckt die Vorteile von Language Servern und automatisiertem Neuladen. Mit Tools wie Haskell Language Server, ghcid und foreign-store nähert er sich dem Workflow von Lisp-Programmierern an, die direkt im laufenden Prozess arbeiten. Er beschreibt die Einrichtung mit Emacs, Nix und direnv und zeigt an einem Spielzeugprojekt, wie er Tests beim Speichern automatisch ausführt und den Programmzustand erhält – ein Schritt in Richtung interaktiver Entwicklung, ohne den Editor zu verlassen.
Ein Lisp-Programmierer muss nicht zu etwas anderem wechseln, weil er bereits in seinem Programmprozess ist.
- dieggsy
Als Common-Lisp-Entwickler kommt mir die Einleitung über Lisp ziemlich (?) wahr vor. Ich würde sagen, in meiner Erfahrung kompilieren und führen wir Code tatsächlich aus, wir können das nur inkrementell und mit weniger Kontextwechsel tun, wegen des beschriebenen Workflows. Aber oft gibt es tatsächlich getrennte Kompilier- und Ausführungsschritte, nur eben nicht auf der Ebene des gesamten Programms (sagen wir, eine Funktion kompilieren und sie oder eine aufrufende Funktion ausführen). Und so oft es als Stärke vorgeführt wird, das Neudefinieren von Code während der tatsächlichen Ausführung ist gar nicht so üblich, denke ich. Ja, es wird manchmal gemacht, aber viele Programme passen von vornherein nicht wirklich in dieses Paradigma. Es kann gut funktionieren, z.B. für einige Spiele oder langlebige Server. Was das Arbeiten in einem Image ohne Quellcode betrifft: Das scheint mir eine schreckliche Idee zu sein. Man könnte das für triviale Einmal-Experimente tun, aber im Allgemeinen profitiert man davon, seinen Code früh aufzuschreiben und zu organisieren. Ich weiß nicht einmal von einem besonders einfachen oder sauberen Weg, Quellcode aus einem Image wie beschrieben herauszuschreiben. Es wäre möglich, aber alle Wege, die mir einfallen, klingen eher nach Ärger oder Chaos als nach etwas Nützlichem. Könnte einfach meine Erfahrung sein oder ich verpasse irgendein nettes Feature eines kommerziellen Lisps oder so.
- cassepipe
Nicht genau dasselbe, aber für C/C++-Programmierer da draußen erwähnenswert: gdb kann tatsächlich als eine Art "billige" Live-Umgebung für C und C++ fungieren. Wenn man an einem Breakpoint angehalten hat, kann man C/C++-Ausdrücke auswerten, den Zustand ändern, Funktionen aufrufen und mit `compile code` neuen C/C++-Code im Kontext des laufenden Prozesses kompilieren und ausführen:
(gdb) set variable state->counter = 42
(gdb) call recompute_state(state)
(gdb) compile code
> printf("counter = %d\n", state->counter);
> do_something(state);
> end
Das ergibt eine überraschend schöne "REPL, die an ein laufendes C-Programm angeschlossen ist"-Erfahrung. Man kann im Heap stochern, Variablen ändern, bestehenden Code aufrufen und kleine Stücke neuen Codes injizieren, ohne den Prozess neu zu starten. Ein Anwendungsfall, an den ich mich gerne erinnere, war das Implementieren verschiedener Baumstrukturen und das Hinzufügen einer `print_dot`-Funktion, die den Baum im .dot-Format ausgab, und wann immer ich die Funktion aus gdb heraus aufrief, zeichnete das xdot-Fenster mit einem aktualisierten Baumgraphen neu. Ich weiß, es ist nicht wirklich dasselbe wie ein Lisp-Image, wo der injizierte Code persistent wird, aber es ist trotzdem schön zu haben. P.S.: Wenn du gdbs TUI zum ersten Mal ausprobierst und dein Programm noch voller print-Anweisungen ist, kannst du den Bildschirm nach einer printf-Ausgabe mit Strg+L oder dem refresh-Befehl entwirren.
- PaulHoule
Gott, dieser image-basierte Programmieransatz war noch nie Mainstream, weil er ein schreckliches Durcheinander erzeugt. Schau dir die Albtraum-Notebooks an, die man von Datenwissenschaftlern bekommt, die in Python arbeiten und ihre Antworten in einem Notebook festhalten wollen, das sie Leuten zeigen können, und nicht erkennen, dass sie Code und Daten in der Versionskontrolle trennen müssen und ein Skript haben müssen, das man jedes Mal von oben bis unten ausführen kann, wenn sie ihre Fähigkeiten auf Räder stellen wollen.
- ux266478
Um ehrlich zu sein, angesichts der strukturellen Zerstörung, die man durch GHC bekommt, klingt image-basierte Entwicklung nach einer wirklich schlechten Idee. Haskell ist eine so seltsame und unintuitive Sprache aus systemischer Perspektive, weil es fast so ist, als wäre man darauf beschränkt, Makros für eine Sprache zu schreiben, die man nie direkt sieht oder mit der man interagiert. Die Transformation von deinem Quellcode zu dem, was der Compiler ausspuckt, kann hochgradig nicht-lokal und unvorhersehbar sein, noch bevor man Dinge wie benutzerdefinierte Umschreiberegeln einführt. Für mich ist der kluge Weg, mit Haskell zu arbeiten, das genaue Gegenteil von Iteration. Arbeite es auf Papier aus, verfeinere es, finde die algebraischen Regeln dafür, verfeinere es noch mehr, und beginne dann Code zu schreiben, sobald du genau weißt, was du tust. Ich denke, der Versuchung nachzugeben und einfach anzufangen, Code zu schreiben, führt zu undurchsichtigem Typ-Spaghetti. Das ist nur mein Gefühl dazu.
- airza
Ich habe aus diesem Beitrag viele interessante Fakten über Haskell und Lisp gelernt. Diese Fakten lassen mich schreiend davonlaufen wollen, eine von beiden für die Softwareentwicklung zu verwenden. Meine Zeit mit Haskell hat mich zu einem besseren Programmierer gemacht, und ich wette, dass LLMs einige der Dokumentationen verständlicher gemacht haben, aber...