lunes, 12 de agosto de 2013

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?

10 comentarios:

  1. Muy buen aporte de tu parte Pseint me sirvió como base para aprender a programar en mi Bachiller,
    sigue así ¡

    ResponderEliminar
  2. Está bueno que el usuario elija la interfase que mas le convenga

    ResponderEliminar
  3. Una idea fuera de punto, crear una plantilla o programa dentro de pseint o externo para agregar un script que convertir de pseint a otros lenguajes, por que modificar los archivos actuales es para expertos

    por ejemplo

    [si] [entonces] ... entonces el usuario escribe los códigos de conversión
    [IF] [THEN]

    Gracias

    ResponderEliminar
    Respuestas
    1. Ya me han preguntado más de una vez. El problema es que no siempre es tan sencillo como reemplazar si-entonces por if-then. Hay cuestiones de sintaxis que varían mucho (por ejemplo el for en c/c++), hay que tener en cuenta el tipado de las variables y adivinar cosas que pseint no pide, ver el tema de los operadores (como el [], que no es lo mismo por ejemplo en c/c++ cuando hay más de una dimensión), la lectura (poco que ver cin>> y cin.getline con leer), etc. De todas formas esa parte del código está un poco más prolija en las últimas versiones, y lo más útil para mi sería que me envíen ejemplos de cómo sería en otros lenguajes quienes dominen esos lenguajes. Ahora se me ocurre que con buenos ejemplos me llevaría poco tiempo agregar más lenguajes, y estaría bueno en algún momento armar una batería de ejemplos para organizar esto y publicar un post con los detalles para quien le interese colaborar (ya sea con ejemplos, o directamente con código). Gracias por disparar esta idea, cuando tenga tiempo voy a empezar a escribir al respecto.

      Eliminar
  4. puede ser primero crear un subforo para tal propósito

    Gracias

    ResponderEliminar
  5. Es una excelente herramienta para dar los primeros en la programación, en nuestra institución la usamos desde hace 6 años. Una recomendación, al menos para nosotros, sería ideal que los bucles repetir y mientras también tengan sus variantes, es decir, la condición al inicio o al final del bucle cada uno.
    Saludos cordiales

    ResponderEliminar
    Respuestas
    1. Mientras y Repetir son sus respectivas variantes, ambas repetitivas con condiciones arbitrarias, pero una al principio, la otra al final. La opcional que agregué hace un tiempo y puede tener que ver con su idea, pero que por ahi muchos no notaron que se agregó es "Repetir .... Mientras Que ...", en lugar de "Repetir .... Hasta Que ...".

      Eliminar
  6. Como declaro mis variables en el pseint, cadena, numero, fecha, imagen y logico

    ResponderEliminar
  7. En esta pagina se encuentra una recopilación de videos, archivos con ejercicios resueltos en pseudocodigo Pseint de Internet. Se las recomiendo si tienen alguna duda con un algoritmos en la ultima sección dejan el comentario y se lo ayudan a resolver.

    http://logicacomputacional8.jimdo.com/

    ResponderEliminar
  8. nesesito ayuda para la materia programacion, alguien me ase el favor de eyudarme es qe no quiero rendirla a fin de año por que es dificil gracias

    ResponderEliminar