¿Quien es quien? Hoy: ZinjaI

Siguiendo con las presentaciones, toca hablar de ZinjaI (aclaración: la ultima letra es una i, pero en mayúsculas, no una L como parece con muchas fuentes, y lo pronuncio zinyai, por su significado: "ZinjaI is not just another IDE"). ZinjaI es actualmente un IDE (entorno de desarrollo integrado) para programar en C/C++, que debería ser útil tanto para principiantes como para programadores avanzados. Pero originalmente, no iba a ser así.

Todo empezó por un programa de becas que tienen en mi facultad para que alumnos de grado se inicien en investigación. El alumno se presenta con un director y un plan de trabajo para dedicarle algunas horas a la semana durante año y medio a algun proyecto de investigación o relacionado. A cambio recibe, entre otras cosas, una formación básica, una primer experiencia, y un punto más en su CV.  En un momento de mi carrera, el docente titular de las primeras materias de programación, aprovechando lo que ya tenía encaminado con las primeras versiones de PSeInt me ofreció aplicar para una de estas becas, para formalizar ese desarrollo y continuarlo.

Como la parte más importante (el intérprete en sí) de PSeInt ya estaba desarrollada, me puse a pensar qué otra herramienta nueva podría ser de utilidad en el aula. Dado que en nuestra carrera, luego de pseudocódigo pasamos a utilizar C++, lo lógico era pensar en una herramienta para empezar a trabajar con C++. 
En ese momento utilizaban por razones históricas mayormente los IDEs de Borland (Builder 4 y 6, que estaban desactualizados y hasta desmantenidos). Yo por mi parte, sugería utilizar MinGW Developer Studio (uno muy muy básico con una apariencia inspirada en las primeras versiones de Visual C) porque me parecía mucho más simple que los grandes IDEs libres como DevCpp, Code::Blocks, Anjuta, KDevelop, etc., y tenía lo básico que consideraba necesario, además de ser liviano y gratuito. Hacer un nuevo IDE solo por hacerlo, con tantos dando vuelta no era necesariamente la mejor idea, había que incorporar algún elemento distintivo que lo justifique. Y ahí es cuando conocí DDD (Data Display Debugger), una interfaz gráfica para el depurador gdb muy muy potente y con representaciones visuales. DDD es tan potente que se torna complicado para alguien que no está muy familiarizado con gdb, y consideremos que los alumnos que recién empiezan no están familiarizados ni con gdb, ni con el concepto de depuración, ni con C++, apenas si acaban de enganchar los fundamentos del pseudocódigo. Entonces la propuesta era hacer un entorno bien simple en el que el alumno pudiera visualizar gráficamente los datos y ver paso a paso como funciona su programa, como se organizan las cosas en memoria, etc, para entender mejor los algoritmos o sus errores.

Así que quería una especie de depurador gráfico, simple e intuitivo, que cualquiera pudiera entender por su cuenta. Pero para que todo sea simple, el alumno tenía que poder escribir su código directamente ahí, para que el depurador lo compile y ejecute como debe. Entonces el depurador incluiría un pequeño editor, que a su vez llamaría al compilador, etc., y de pronto tenemos más de medio IDE. Por otro lado, más tarde encontré limitaciones en gdb que me hicieron abandonar al menos temporalmente algunas de las ideas originales, por lo que el producto final se transformó cada vez más en un IDE más o menos estándar, pero adaptado para estudiantes, antes que un depurador gráfico. El adaptado para estudiantes implica que su interfaz está en castellano, que para hacer un programa no hace falta crear un proyecto o ni siquiera guardar el archivo, que las opciones básicas que necesita están a mano y no está superpoblado de otras opciones que solo confunden, algunas funcionalidades más particulares como la posibilidad de compartir el código que el docente está desarrollando en su notebook y que los alumnos ven proyectado en una clase directamente desde el IDE para que ellos lo reciban a través de la red, que oculta las diferencias entre plataformas, que simplifica un poco los mensajes de error que arroja gcc, etc.

Como esto era, a mis ojos, un desarrollo más que una investigación, planteamos la investigación como excusa para el desarrollo. Propusimos investigar el impacto que este tipo de herramientas tiene en los alumnos y cómo mejorarlo, comparando los resultados académicos en dos cursos similares, uno que utilice el software y otro que no. Cuando llegó el momento de evaluar esto, el desarrollo de ZinjaI estaba todavía verde así que no se pudo sacar grandes conclusiones, pero respecto al pseudocódigo, resumiendo mucho, observamos que servía para mejorar el rendimiento del alumno que estaba en el límite entre aprobar y desaprobar la materia, pero que no tenía impacto alguno sobre el alumno que la promocionaba con notas altas.

Las limitaciones de gdb no son específicamente problemas de gdb, sino más bien características del diseño C++. Hay una una idea que heredo desde PSeInt y es que si voy a hacer algo que el alumno va a usar para intentar entender, tengo que hacerlo bien o no hacerlo, porque si mi programa lo hace mal (y no avisa), estoy contribuyendo a confundir al alumno, a que lo aprenda mal como lo hace mi programa, o al menos a generarle dudas sobre algo que estaba bien y que le harán perder tiempo (está claro que en la realidad no logro respetar esta idea al 100%, pero intento). Por ejemplo, cuando en DDD inspecciono un puntero, aparece en el área de dibujo un cuadradito con la dirección de memoria. Cuando hago doble click sobre el puntero, aparece otro cuadradito con el contenido al cual apunta, y una flecha del primero hacia el segundo, similar a lo que un docente dibuja en el pizarrón cuando lo explica en clases. Pero si tengo dos punteros que apuntan a la misma dirección y hago doble click sobre los dos, por cada uno aparece un nuevo cuadradito con el contenido apuntado, en lugar que apuntar los dos al mismo (o al menos así era cuando lo probé). Esto confunde, porque los dos cuadraditos nuevos deberían ser uno, ya que ese contenido no está dos veces en memoria, y no puedo modificar un dato apuntado sin alterar el otro. Corregir esto implica llevar un registro de todas las direcciones de todas las variables involucradas para detectar cuando deben ser las mismas. No solo podría ser lento, sino que en algunos casos rebuscados no encontré como pedirle a gdb la dirección que necesito para saber si alguien le está apuntando. Otro ejemplo sería el uso de arreglos dinámicos, no hay una forma fácil y no intrusiva de saber cuantos elementos tiene un arreglo generado con new inspeccionando la memoria. Esta información está en memoria (sino el programa no podría destruir los elementos al hacer el delete []), pero de una forma que es dependiente de cada compilador, de cada sistema operativo, de las opciones de compilación en sí mismas, y por lo tanto, difícil de encontrar y poco fiable (peor aún con malloc). Por esto, lo que iba a ser un depurador gráfico con olor a IDE, terminó siendo un IDE con un depurador no tan gráfico (pero sí con algunas pocas representaciones más piolas que las estándar, como las de tablas), sólo que haciendo énfasis en la I de IDE para adaptarla a las necesidades del aula y distinguirla de las demás.

Siguiendo con la historia de ZinjaI, como era un IDE que yo había hecho, que conocía al detalle, y que podía modificar a gusto, comencé a usarlo para mis trabajos reales, para proyectos más serios que un ejercicio en una clase de práctica. Y a medida que lo iba usando cada vez más, iba necesitando agregarle cosas, siempre tratando de no perturbar la sencillez inicial, pero ganando en potencia con cada nueva versión. Finalmente, tengo un IDE que se presenta como básico y simple (o al menos eso pretendo), pero que permite armar grandes proyectos, interactuar con herramientas externas, manejar configuraciones complejas, depurar aprovechando casi toda la potencia de gdb, etc. Hoy en día sigue siendo una cuenta pendiente mejorar aún más la interfaz para la depuración, algo que es a mi criterio increíblemente útil como herramienta didáctica, pero que muchísimos alumnos (aún alumnos avanzados y hasta docentes a veces) desconocen y en consecuencia no valoran.