Programación interactiva

Una de las cosas que mas me gustan de programar en Lisp es que encuentro facil mantener la concentración cuando lo hago. Creo que esto se debe en buena parte a la programación interactiva que facilitan los ambientes de desarrollo en lisp. La programación interactiva consiste en ir modificando un programa poco a poco mientras éste se encuentra activo. Es decir, el termino de programación interactiva no tiene que ver con el estilo en el queesta escrito un programa sino con el proceso de escritura del código. Veamos esto un poco mas en detalle.

Teclado symbolics

En ambientes no interactivos los programadores trabajan intercalando dos tipos de actividades bien separadas: la edición y la ejecución. La programación es entonces una secuencia de sesiones de edición de código y de sesiones de ejecución (y a veces también de fases de compilación). Al terminar una sesión de edición, se lanza el programa y se observan los efectos sobre el comportamiento del programa. Una vez se ha observado el programa en ejecución, se interrumpe el programa para empezar una nueva sesión de edición. Cada actividad esta claramente delimitada e implica un tipo de gestos distinto. El cambio entre una actividad y otra implica un cambio de contexto mental que se convierte en un esfuerzo adicional. El programador tiende entonces a programar en sesiones de edición largas para evitar el tener que cambiar frecuentemente de actividad.

En ambientes interactivos, el programa todo el tiempo esta en ejecución y el programador modifica su comportamiento haciendo un pequeño cambio a la vez. El programador trabaja en micro-sesiones de edición tras las cuales observa inmediatamente el resultado de la edición. La sensación del programador es que las dos actividades, modificar el programa y observar el resultado de las modificaciones, se funden en una sola actividad.

Los programadores de common lisp suelen usar el editor de texto Emacs junto a Slime, una adaptación que permite programar interactivamente. Una sesión de trabajo consiste habitualmente en:

  1. Cargar el sistema en el que se va a trabajar, a partir del editor;
  2. Escribir nuevas funciones o modificar las existentes y hacer que el sistema en ejecución use estas nuevas definiciones tan pronto se van escribiendo;
  3. Probar constantemente estas nuevas funciones ejecutando fragmentos de código, que luego pueden deshecharse.

Como se puede ver, el programador “lanza” el sistema al inicio de una sesión de trabajo y no lo detiene sino cuando termina de trabajar.

En java se puede lograr un cierto nivel de interactividad usando un buen ambiente de desarrollo integrado, por ejemplo Eclipse, en el que un programa puede facilmente ejecutarse en modo “debug” y modificar las clases “en caliente” sin tener que detener la ejecución. Aún así, en java muchas veces es necesario detener la ejecución del programa, por ejemplo cuando se cambia el nombre de un método.

Turbo C

Aparte del ambiente de desarrollo, el lenguaje en si mismo influye en que tan interactivamente se pueda programar. Por ejemplo, muchas veces en java, para poder usar una cierta librería, es necesario crear sub-clases. Crear una clase implica una sesión de tecleo relativamente larga, que destruye la fluidez de la programación interactiva.

Uno de los ambientes menos interactivos en los que he trabajado lo sufrí desarrollando una cierta aplicación en java que solo podia ejecutarse en un servidor de aplicaciones instalado en otra máquina. Cada vez que modificaba el código y queria probar mis cambios, debia detener la aplicación, subir el programa usando una interfaz web y relanzarlo. Para una persona como yo, a la que le cuesta concentrarse, mantener la cabeza en lo que estaba haciendo era una odisea en esas condiciones.

Creo que la academia debería interesarse al tema del placer en la programación. Por que puede ser mas placentero programar de una cierta manera que otra y cómo se refleja el placer del programador sobre el resultado final.

9 Comments

  1. cavorite
    March 12, 2010 #

    Este es uno de mis temas favoritos y cada vez me convenzo más de que es *necesario* tener un ambiente interactivo para programar, ya sea un IDE, un REPL o un shell, lo que sea.

    Al igual que ud, yo me puedo concentrar más en lo que estoy haciendo si veo los resultados inmediatamente. Es muy aburrido tener que esperar, así sean solo unos segundos, para ver si las cosas funcionan como uno quería o si se pueden mejorar un poco más.

    Cuando hablé de esto en mi blog alguien me dijo que la programación interactiva era como programar utilizando la técnica de ensayo y error, y que esa era una pésima manera de escribir un programa. Supongo que el comentario quería señalar que al poder probar las cosas inmediatamente no se está entendiendo el problema antes de solucionarlo, como si uno estuviera programando ‘a las patadas’. No creo que eso sea cierto en todos los casos. Me parece que con la programación interactiva se pueden corregir errores, probar nuevas ideas y entender el problema mucho más rápido.

    Algún día dije en mi blog que mi entorno favorito eran los ‘cuadernos’ de Mathematica, en donde el programa y su resultado se mezclan en un solo documento que se actualiza a medida que uno hace cambios en el. La hoja de cálculo es otra de las interfaces que más me gusta: uno modifica un par de celdas y todos los demás valores se actualizan inmediatamente. No hay que compilar ni esperar nada, el programa está vivo. Es más, en estos días estuve pensando en utilizar Open Office Calc como un IDE de Python: en la hoja de cálculo uno tiene sus variables y las va modificando y en una sesión de un intérprete de Python uno modifica las funciones que se utilizan para mostrar otros valores.

    Me sorprende un poco que la programación interactiva no sea más popular, por decirlo de alguna forma. Sin embargo, me gusta que se tenga más en cuenta. Por ejemplo, leía en un blog que hay gente que está integrando Clojure, Hadoop y Slime para tener una experiencia similar a la del REPL con programas que procesan muchos datos. Algo así es lo que yo quiero tener cada vez que esté programando.

  2. juandiego
    March 12, 2010 #

    Eso que dicen se parece a mi forma de “programar”. generalmente hago PHP o Actionscript y ejecuto cada pocas líneas de código. No lo hago en realidad por un tema de concentración sino porque, como no soy programador, no me tengo confianza.

    Aparte de esto, bueno, no estoy tan seguro de que escribir php y dar F5 en el navegador califique como lo que ustedes llaman : programación interactiva”. Como quiera que sea, la lectura me hizo pensar en mi forma de realizar este tipo de tareas, cosa a la que muy poco tiempo le he dedicado.

  3. Alfabravo
    March 12, 2010 #

    PHP tiene esa gracia cuando se ajusta el entorno.

    Ahora mismo, la arquitectura base de las aplicaciones web que hacemos acá tiene esa gran ventaja… permite que se modifiquen XSLs y XSPs sin tener que mover el servidor de aplicaciones.

  4. Sergio
    March 12, 2010 #

    @cavorite:

    “Es muy aburrido tener que esperar, así sean solo unos segundos, para ver si las cosas funcionan como uno quería o si se pueden mejorar un poco más.”

    Si, totalmente de acuerdo. Es interesante que unos cuantos segundos puedan hacer la diferencia. De hecho yo diria que unos cuantos milisegundos pueden hacer la diferencia. (si uno piensa en interfaces graficas en general, incluso esperar unos cuantos milisegundos de mas para que un menu aparezca cuando uno hace click hacen que la aplicacion se sienta lenta)

    @juandiego:

    Yo diria que si tiene un buen nivel de interactividad, de hecho pensé mencionar HTML y PHP en mi post. En general programar una interfaz web asi es mucho mas interactivo que por ejemplo programar una GUI stand-alone, donde generalmente hay que reiniciar todo para ver los efectos de un cambio.

    @alfabravo:

    XSL me da escalofrios 😛

  5. cmart
    March 12, 2010 #

    Que interesante el problema que planteas en este post y el momento en que lo haces, pues en la actualidad hay una serie de iniciativas en el contexto de las artes electronicas que buscan la misma experiencia al programar.

    El Livecondig es una practica surgida recientemente en la que un programador va escribiendo una pieza de codigo y la va transformando en el mismo proceso de escritura. Este proceso se realiza generalmente en publico y la mayoria de los programas que se escriben en sesiones de Livecoding producen salidas visuales o sonoras.

    Uno de los ejemplos mas claros e importantes es Fluxus [1], un programa desarrollado precisamente para programar graficos en 3D y transformarlos a traves de la modificacion del programa en tiempo real. Precisamente Fluxus esta escrito en scheme, que si no estoy mal esta basado en lisp.

    Simon Yuill escribio hace poco un texto [2] en el que desarrolla y relaciona ideas provenientes de practicas artisticas como el performance y la imporvisacion en musica experimental con el livecoding. Interesante econtrar esas inquietudes por aca.

    [1]http://pawfal.org/fluxus

    [2] http://www.metamute.org/en/All-Problems-of-Notation-Will-be-Solved-by-the-Masses

  6. Nelson
    March 12, 2010 #

    Interesante el tema. Me gustaría probar eso algún día. Cuando programo trato de tener algo que corra lo más pronto posible. Compilo con mucha frecuencia, cada vez que hago un cambio. Por la costumbre de trabajar con cosas de bajo nivel la etapa de compilación ya es un hábito.

    Con respecto a tu experiencia con el “servidor de aplicaciones”, mi historia de horror más reciente tiene que ver con programar para un blackberry. Me tocaba usar un emulador en Java que había que reiniciar cada vez que hacía una prueba. Eso tomaba como 15 segundos (estimado).

    Y una vieja. En 1997 recuerdo que cuando programamos Dfd por ignorancia no usábamos compilación separada sino que era un solo programa que se compilaba siempre. Ya al final recuerdo que los tiempos de compilación pasaban del minuto.

  7. Nelson
    March 12, 2010 #

    Me faltó decir que el pantallazo de Turbo C me trae muchos recuerdos Usé el de Pascal también que era idéntico. Lo que más me gustaba era el modo “paso a paso”.

  8. Manuel Cerón
    March 13, 2010 #

    Me gusta la programación interactiva. Aunque en la mayoría de los programas que escribo me cuesta trabajo imaginar cómo programarlos de una forma interactiva. Mi flujo de trabajo sigue siendo mayoritariamente edicion-ejecución.

    Yo uso la programación interactiva para probar pequeñas cosas, para acordarme de cómo hacer algo en el lenguaje o para probar una funcionalidad específica de una API.

    A veces también lo uso en programas más grandes. Un ejemplo es seleccionar un trozo de código y darle “Ejecutar en consola” y luego probar pequeñas cosas ahí. Otro ejemplo es poner un breakpoint en algún pedazo de un programa y luego probar cosillas en la consola.

    Hay una cosa que me molesta de probar las cosas en vivo y en directo y es que uno tiende a desechar lo que probó. Por ejemplo, en el caso que menciona @cavorite de usar OpenOffice como IDE, uno puede probar su función con ciertos valores en las celdas y luego cambiar los valores y probar otra cosa. El problema es que lo primero que probó se perdió. Algo que estoy tratando de aprender a las malas es a no dejar perder las pruebas que hago. Hacer pruebas que sean repetibles automáticamente. Por supuesto esos malos hábitos igual los cometo programando de forma no interactiva. Es sólo que a veces pienso que se es más susceptible en el entorno interactivo.

    Por cierto, @cavorite, dale una mirada a Reinteract: http://people.gnome.org/~otaylor/reinteract-demo.html

  9. j.
    March 13, 2010 #

    Yo programo con mi montblanc.

Leave a Reply

Powered by WordPress. Designed by Woo Themes