Un cascarrabias prueba un servidor de lenguaje
A curmudgeon tries a language server
El autor, un programador escéptico, explora cómo acercar su flujo de trabajo en Haskell al desarrollo interactivo de Lisp. Combina el servidor de lenguaje Haskell (hls) con ghcid y la biblioteca foreign-store para recompilar y reiniciar la aplicación automáticamente sin perder estado, mientras escribe pruebas como experimentos. Describe la configuración con Emacs, Eglot y Nix, incluyendo los obstáculos encontrados, y logra un ciclo de desarrollo que nunca abandona el editor, aunque reconoce que no es exactamente la experiencia Lisp.
Nunca abandonamos nuestro editor.
- dieggsy
Como desarrollador de Common Lisp, la introducción sobre Lisp me parece en su mayoría(?) cierta.
Diría que en mi experiencia sí "compilamos y ejecutamos" código, pero podemos hacerlo de forma incremental y con menos cambio de contexto debido al flujo de trabajo descrito. Pero a menudo hay pasos separados de compilación y ejecución, solo que no a nivel de todo el programa (por ejemplo, compilar una función y ejecutarla o una función que la llama).
Y a pesar de lo a menudo que se muestra como una fortaleza, redefinir código durante la ejecución real no es tan común, creo. Sí, a veces se hace, pero muchos programas no encajan realmente en ese paradigma en primer lugar. Puede funcionar bien para, por ejemplo, algunos juegos o servidores de larga duración.
En cuanto a trabajar en una imagen sin código fuente: esto parece una idea terrible. Podrías hacerlo para experimentos triviales y únicos, pero en general te beneficias de escribir y organizar tu código desde el principio. Ni siquiera sé de una manera particularmente fácil o limpia de extraer código fuente de una imagen como se describe. Se podría hacer, pero todas las formas que se me ocurren suenan más a un dolor o desorden que otra cosa. Podría ser solo mi experiencia o me estoy perdiendo alguna característica interesante de un Lisp comercial o algo así.
- cassepipe
No exactamente lo mismo, pero vale la pena mencionarlo para los programadores de C/C++: gdb puede funcionar como una especie de "entorno en vivo" barato para C y C++.
Cuando te detienes en un punto de interrupción, puedes evaluar expresiones de C/C++, modificar el estado, llamar funciones y, con compile code, hacer que GDB compile y ejecute nuevo código C/C++ en el contexto del proceso en ejecución:
(gdb) set variable state->counter = 42
(gdb) call recompute_state(state)
(gdb) compile code
> printf("counter = %d\n", state->counter);
> do_something(state);
> end
Eso proporciona una experiencia sorprendentemente agradable de "REPL adjunto a un programa C en ejecución". Puedes tocar el montón, cambiar variables, llamar al código existente e inyectar pequeños fragmentos de nuevo código sin reiniciar el proceso.
Un caso de uso que recuerdo con cariño fue implementar diferentes estructuras de árbol y añadir una función print_dot que imprimiera el árbol en formato .dot y cada vez que llamaba a la función desde gdb, la ventana de xdot se redibujaba con un gráfico de árbol actualizado.
Sé que no es realmente lo mismo que una imagen de Lisp donde el código inyectado se vuelve persistente, pero es bueno tenerlo.
PD: Si estás probando el tui de gdb por primera vez y tu programa todavía está lleno de sentencias printf, puedes limpiar la pantalla después de una salida de printf con Ctrl+L o el comando refresh.
- PaulHoule
Dios, ese enfoque de programación basado en imágenes nunca ha sido mainstream porque crea un desastre terrible.
Mira la pesadilla de los notebooks que obtienes de los científicos de datos que trabajan en Python, donde quieren tener sus respuestas horneadas en un notebook que puedan mostrar a la gente y no se dan cuenta de que necesitan separar código y datos en el control de versiones y tener un script que puedas ejecutar de arriba a abajo cada vez si quieren poner sus habilidades sobre ruedas.
- ux266478
Para ser honesto, dado el grado de obliteración estructural que obtienes de GHC, el desarrollo basado en imágenes suena como una idea realmente mala. Haskell es un lenguaje tan extraño e intuitivo de entender desde una perspectiva de sistemas, porque es casi como si estuvieras restringido a escribir macros para un lenguaje que nunca ves o con el que interactúas directamente. La transformación de tu código fuente a lo que el compilador escupe puede ser altamente no local e impredecible, incluso antes de introducir cosas como reglas de reescritura personalizadas.
Para mí, creo que la forma inteligente de trabajar con Haskell es exactamente lo opuesto a la iteración. Trabájalo en papel, refínalo, encuentra las reglas algebraicas para ello, refínalo un poco más, y luego empieza a escribir código una vez que sepas exactamente lo que estás haciendo. Creo que ceder a la tentación de Simplemente Empezar a Escribir Código es cómo terminas con espaguetis de tipos opacos. Esos son solo mis sentimientos al respecto.
- airza
He aprendido muchos datos interesantes sobre Haskell y Lisp de esta publicación. Esos datos me hacen querer salir corriendo de intentar usar cualquiera de ellos para desarrollar software. Mi tiempo con Haskell me hizo un mejor programador y apuesto a que los LLMs hicieron que parte de la documentación fuera más inteligible, pero...