Mejor interfaz para los errores en PSeInt

Siempre digo que aprender a programar involucra aprender dos o tres grandes cosas: en un primer escalón los fundamentos (la lógica), luego el lenguaje, y tal vez un poco más abajo las herramientas (el compilador y el IDE). No es fácil aprender todo al mismo tiempo, y creo que sin dudas los fundamentos son lo primero y más importante, son la parte más universal y duradera de este conocimiento. Por eso siempre planteo que para enseñar a programar debemos primero sentar buenas bases en este aspecto tratando de que los otros dos no "molesten" demasiado. Para evitar que el lenguaje "moleste" es que utilizamos el pseudocódigo. Para evitar que la herramienta "moleste" es que, o bien no utilizamos ninguna (pseudocódigo solo en papel como le gustaba a Dijkstra), o bien propongo PSeInt. Es decir, el pseudocódigo debe ser natural y flexible para que los errores que consuman el tiempo sean los de lógica, y la interfaz intuitiva y rápida para que tampoco desvíe la atención, de forma que todo esto se vuelva invisible.

La interfaz de PSeInt arrastra varias decisiones de diseño tomadas por razones "históricas" a veces, técnicas otras, o hasta simplemente por no pensarlas demasiado. En los últimos años he intentado pensarlas más y con un sentido didáctico, pero arrastrando la inercia inicial. Un punto importante y ejemplificador de esto que hablo es la forma en que se muestran los errores de un algoritmo dentro del editor. En este artículo cuento los porqués de algunos cambios que estoy probando para la próxima versión, y los invito a dejar sus opiniones.

Vamos a empezar explicando cómo se llegó a lo que era hasta hoy este aspecto de la interfaz de PSeInt. La tarea escribir código se desarrolla en la mayoría de los casos de la siguiente forma:  paso 1:escribir código, paso 2:compilar/intentar interpretar: paso 3:si hay errores volver al paso 1, sino ejecutar... Lo importante aquí es que escribir es un paso, y compilar/intentar interpretar es otro, y es en ese otro donde recién se marcan los errores de aquel primero. Esto es así por las herramientas que se han utilizado históricamente (y se siguen utilizando en muchísimos casos). En un nivel básico, se utiliza primero un editor de texto para escribir el código, y luego un compilador/intérprete para analizarlo. Al compilador/intérprete no le interesa demasiado en general cuál es o qué hace el editor. Y es tarea del IDE integrar ambos y hacer que parezcan que trabajan juntos. Pero siguen siendo herramientas separadas. Entonces lo mejor que puede hacer el IDE es invocar al compilador de forma transparente y mostrar los resultados manera más o menos prolija. Por eso, la mayoría de los IDEs despliega un panel en la parte inferior con los resultados, a lo sumo coloreados, organizados en árbol, o hasta reacomodados o levemente reformateados en el mejor de los casos (como en ZinjaI ;). Y este es el modelo que seguí en PSeInt hasta hace muy poco, porque también funcionaba en partes como explicaba antes, con un editor por un lado y un intérprete independiente por otro. El proyecto no era en sus principios tan ambicioso, por lo que empecé copiando el modelo que conocía y le puse casi todas las fichas al intérprete y muy pocas a la interfaz. A cualquier programador que ha usado uno o más IDEs clásicos (o que a programado con un editor de texto genérico y una consola) esto le parecerá natural y adecuado. Pero los usuarios de PSeInt todavía no son programadores, de hecho casi garantizado que todo lo contrario, aún apenas están empezando ese camino. Entonces, ese modelo de interfaz con un panel con la lista de errores tan "natural" para quienes conocen como funcionan estas herramientas, no tiene porqué serlo para el estudiante, y ahí es cuando me pregunto ¿qué alternativa mejor tengo?

Interfaz clásica, con el panel de errores en la parte inferior. Hay que intentar ejecutar 

para que se actualice y seleccionarlos para ver sus descripciones detalladas.

Algunas mejoras sobre la base de la misma interfaz fueron por ejemplo el panel con los comandos para insertar las plantillas, o el de ayuda rápida que muestra las descripciones más detalladas de los errores. Estas no requerían nada especial del intérprete y podían sencillamente extender al modelo de trabajo anterior. En algún punto quise marcar los errores en tiempo real, mientras se escribe, sin esperar a la ejecución, y eso sí implicó modificar el intérprete y establecer un canal de comunicación ad-hoc entre ambas partes (intérprete y editor). Y esas creo que fueron buenas mejoras, pero esta segunda forma de marcar errores, si bien no colisiona con la original, tampoco colabora, sino que es independiente, puede que ni siquiera muestren los mismos errores, y eso es algo que a mi gusto hacía ruido. Debería haber una forma unificada para reducir los elementos de la interfaz y facilitar su aprendizaje. La idea es entonces es deshacerme del mecanismo original y mejorar el nuevo para cubrir todos los casos. Entre las mejoras, está la integración del panel de ayuda rápida, que antes respondía solo al panel de resultados, pero ahora se sincroniza con los errores en tiempo real, mostrando siempre la descripción del error en donde esté el cursor de texto cuando el panel está visible. Por otro lado, agregué algunas marcas rojas en el margen para hacer más evidente cuales son las líneas con errores, ya que no va a estar el panel inferior con la lista y de paso pueden usarse para llevar el cursor a los errores y desplegar la ayuda rápida en un solo click.

 

Interfaz propuesta. En todo momento se marcan los errores sobre el pseudocódigo y

 se muestra la descripción detallada debajo con solo colocar el cursor sobre ellos. 

Ahora, al intentar ejecutar, exportar, o realizar cualquier acción que requiera la verificación de sintaxis, los resultados se muestran de la misma forma que los de la verificación en tiempo real (de hecho, normalmente coincidirán y la única diferencia será el despliegue de la descripción detallada si no estaba ya visible). ¿Qué pierdo respecto al panel original? La lista de errores (ahora hay que elegirlos de a uno para ver los mensajes), y la presentación de los errores en tiempo de ejecución. Pero ambas cosas se pueden presentar dentro del mismo panel de ayuda rápida y listo. Entonces me deshago de un panel completo, simplificando la interfaz, tanto para el usuario como para mi al programarla. Así que en la próxima versión, por defecto ya no se utilizará para nada el panel de resultados, sino que todo se marcará sobre el pseudocódigo y con la ayuda del panel de ayuda rápida, que ya estaba antes. Un elemento menos, misma funcionalidad.

 Interfaz propuesta. Al intentar ejecutar la lista de errores se muestra en el mismo panel.

En algún caso, algún usuario querrá el panel, para ir acostumbrándose mejor a lo que sigue después, o para practicar sin tanta ayuda (en muchos cursos el examen será en papel). Para estos casos, pueden desactivar la verificación de sintaxis en tiempo real y esto hará que vuelva al modo clásico. Pero en general, creo que la mayoría de los usuarios no va a extrañarlo, ¿ustedes que opinan? ¿cual es la forma más natural de presentar los errores?