J'écris du code à peu près de la même manière qu'il y a dix ans : je fais des modifications dans mon éditeur de texte, je passe à un terminal, et j'exécute une commande pour compiler et exécuter. Je regarde le résultat, puis je reviens à mon éditeur. Si je ne suis pas sûr, j'ajoute des impressions de trace ou je redémarre dans un débogueur. Si une exception fait planter mon programme, je le corrige et je redémarre.

J'envie ce que font les programmeurs Lisp. Le développement Lisp se fait en tapant du code directement dans le repl pour ajouter, supprimer et remplacer des parties du système vivant en cours d'exécution. Un programmeur Lisp n'a pas besoin de "basculer" car il est déjà à l'intérieur du processus de son programme. Il ne "compile et exécute" jamais car le code est déjà en cours d'exécution, et il édite par échange à chaud. Il ne redémarre pas dans un débogueur car il peut inspecter n'importe quoi. Il ne redémarre pas sur les exceptions car le système de conditions permet de reprendre de n'importe où.

Une conséquence est qu'au début d'un projet Lisp, il peut ne pas y avoir de code source ; la définition en évolution n'existe que dans l'image mémoire. C'est comme la façon dont les gens traitent les bases de données relationnelles au début—le schéma n'existe que dans la base de données en cours d'exécution. Finalement, il est vidé dans un fichier sous contrôle de version.

Je ne suis pas un développeur Lisp, donc je resterai envieux. Mais j'ai réalisé que je n'ai pas essayé de me rapprocher. En Haskell, il y a des gains partiels : le système de types réduit les exceptions, et le serveur de langage Haskell (hls) avec Eglot d'Emacs donne une meilleure introspection. ghcid surveille les changements et recompile rapidement.