Escrevo código mais ou menos da mesma maneira que há dez anos: faço edições no meu editor de texto, mudo para um terminal e executo um comando para compilar e executar. Olho o resultado e volto para o meu editor. Se não tenho certeza, adiciono impressões de rastreamento ou reinicio em um depurador. Se uma exceção derruba meu programa, eu corrijo e reinicio.

Invejo o que os programadores de Lisp fazem. O desenvolvimento em Lisp acontece digitando código diretamente no repl para adicionar, remover e substituir partes do sistema vivo em execução. Um programador de Lisp não precisa "alternar" porque já está dentro do processo do seu programa. Eles nunca "compilam e executam" porque o código já está rodando, e editam por troca a quente. Eles não reiniciam em um depurador porque podem inspecionar qualquer coisa. Eles não reiniciam em exceções porque o sistema de condições permite retomar de qualquer lugar.

Uma consequência é que no início de um projeto Lisp, pode não haver código-fonte; a definição em evolução existe apenas na imagem de memória. Isso é como as pessoas tratam bancos de dados relacionais no início—o esquema existe apenas no banco de dados em execução. Eventualmente, é despejado em um arquivo sob controle de versão.

Não sou desenvolvedor Lisp, então continuarei com inveja. Mas percebi que não tentei chegar mais perto. Em Haskell, há vitórias parciais: o sistema de tipos reduz exceções, e o servidor de linguagem Haskell (hls) com Eglot do Emacs dá melhor introspecção. ghcid observa mudanças e recompila rapidamente.