"No me acuerdo" (a.k.a. "estudié por catálogo").

"No me acuerdo" es, en el 95% de los casos, una de las peores respuestas que me pueden dar mis alumnos. Y tiene que ver con la forma de encarar el estudio y un problema muy recurrente que vemos en las carreras de ingeniería: lo que voy a llamar "estudiar por catálogo".

¿Qué estuve haciendo el 2020?

Como para sacudir un poco el polvo que se acumuló en este blog arranco tarde el año con un post más relacionado a la docencia que a los proyectos de software que le dieron origen. Pero esta vez escribo mirando hacia atrás. Digamos que este 2020 que al fin terminó fue cuanto menos "complicado", y todo lo que pasó derivó en un silencio de radio para este blog, y en casi nulas actualizaciones para esos proyectos.

La docencia, el paso del tiempo y el sentido común

Como todos los años, cuando están por empezar las clases, paso por una etapa de introspección durante la preparación de ese primer contacto con los nuevos ingresantes. Ya llevo casi 15 años "enseñando". Y ya he pasado también más de 15 "aprendiendo", la mayoría de ellos formalmente entre las carreras de grado y posgrado. ¿Quiere decir esto que soy un gran docente? ¿Que la tengo reee-clara en esto de la educación? Terminantemente NO! Hacerlo muchas veces no implica hacerlo bien si no hay mejora entre una y otra vez, si se repiten todos los años los mismos errores.

Reviviendo una vieja funcionalidad de ZinjaI

En algunos prácticos de computación gráfica les damos a los alumnos programas que implementan algo visto en teoría para que experimenten: a) cambiar cosas, predecir el resultado y validar la predicción; b) pensar un resultado, deducir qué hay que cambiar, y validar la deducción; o c) si todavía no pueden predecir ni deducir nada, cambiar al azar y observar para desarrollar una primer intuición de qué hace cada cosa. Entonces, quiero programas donde sea fácil y rápido cambiar cosas.

Podemos empezar por decir que para cambiar el estudiante debe modificar el código, pero eso puede hacer que el loop de retroalimentación sea lento y tedioso. El plan B es programar alguna interfaz; pero como usamos bibliotecas muy simples (como FreeGLUT), no hay widgets o similares. Las alternativas parecen ser: a) programar controles propios, pero entonces es más código accesorio para ensuciar el ejemplo; b) usar mejores bibliotecas, pero entonces agregamos otra dependencia. Pues bien, ZinjaI viene al rescate con una tercera opción.

Solo se que se muy poco

Hace ya más de 13 años que "doy clases" en la universidad. Empecé como ayudante cuando era alumno y de a poco creo que fui creciendo. Hasta ahora formalmente siempre era JTP/ayudante de otros titulares. Este año, cuando empiece "Computación Gráfica", será la 1era vez que estaré como máximo responsable de una materia.

Estoy en la cátedra desde hace varias cursadas, y el titular anterior nos daba muchísima participación, así que podría decir que estoy preparado. Además, él había pensado y repensado mucho el armado de la materia, no era solo seguir un libro, así que parto de una muy buena base como para lograr un dictado más que decente. Peeeero....

El arte de nombrar (parte 2)

En la primera parte hice comentarios mayormente prácticos sobre problemas y sugerencias a la hora de dar nombres a variables, clases, funciones, etc. Ahora vengo a completar las ideas con otro punto de vista, pensando más en la elección de las palabras que en la forma de escribirlas o abreviarlas.

Estas reflexiones tienen dos orígenes: por un lado la introducción del clásico libro de patrones de diseño de "la Pandilla de 4", por el otro una mini-frustración personal que me agarra a veces dando clases.

Dedicado a ustedes, nuestros futuros pioneros...

Cucarachas Racing es un blog sobre programación, software libre y cosas técnicas, pero también se desliza cada tanto algún post diferente, a veces relacionado a la docencia o a la educación... como este.

El boom de la Programación Funcional (parte 1/3)

Desde hace relativamente pocos años, el paradigma de la programación funcional ha tomado un nuevo auge, hasta el punto en que hoy en día podríamos considerarlo como una especie de "trending topic" en el mundillo de la programación en general. Podría decir que los conceptos esenciales son más viejos que la programación misma. Pero, para alguien como yo, que tuve toda mi formación inicial en lenguajes estructurados y procedurales, que luego pasé a la "moderna" orientación a objetos, y que desde hace años C++ es mi herramienta de trabajo en el día a día, esto es nuevo. Es algo que empezó a hacerme ruido con la estandarización de C++11, y que por lo que veo, gracias al auge del paralelismo, llegó para quedarse.

Hay muchos programadores sueltos que han tenido una formación similar a la mía, y que aún no descubren lo enriquecedor que es el mundo de la programación funcional. A esos colegas les estoy escribiendo. Por que si bien, es muy probable que yo nunca use de verdad un lenguaje realmente funcional, las ideas que me va implantando el aprender sobre este paradigma sí repercuten en mi forma de pensar los problemas y analizar las implementaciones. Creo que todo informático debería tener una formación básica en programación funcional, con el solo objetivo de abrirle la cabeza a otra forma de analizar un programa y de entender la programación.

SFINAE: Magia con templates en C++ (parte 3)

Finalmente llegamos a la última parte. Ya introduje en la parte 1 qué es eso de sfinae, y en la parte 2 cómo usarlo para consultar en tiempo de compilación la existencia de algo. La idea era poder plantear ejercicios de programación autocalificables; es decir, que validen solos si son correctos o no al ejecutarse. Para ello nos falta acomodar un poco el resultado de la parte 2 para que sea más cómodo de usar. Primero vamos a definir una macro para declarar con una linea la clase que hace la prueba de existencia de algo. Luego vamos a definir otra macro para declarar con una linea una función que solo se ejecuta si se pasa una prueba. Con todo eso, podemos plantear un ejercicio como el siguiente:

El programador es un pequeño Dios

Empieza una vez más el cursado en "mi" Universidad, y como docente de una de las comisiones de teoría de la materia "Fundamentos de Programación"  tengo la enorme responsabilidad de presentarles la programación por primera vez a muchos jóvenes ingresantes. Es una oportunidad única para que empiecen motivados y con el pie derecho, para que lo vean como algo atrapante y divertido, y no como una materia más. Y es en este contexto, donde cada año al preparar esos primeros 15 minutos de la primer clase, divago sobre la naturaleza de la programación, como lo voy a hacer en este post. Pero antes de seguir leyendo, estén advertidos de que será una ensalada de cosas muy subjetivas relacionadas de formas cuestionables.

Miles de artículos se han escrito debatiendo acerca de la naturaleza de la programación, ¿arte o ciencia? Si me preguntan a mi, es ambas cosas, pero primero digo arte, porque lo de ciencia lo doy por obvio, mientras que lo de arte es lo más discutido. De todas, formas, no es esta pregunta el eje de este post, sino que pretendo volcar en algunas lineas una visión general y motivadora de la parte que más disfruto de esta maravillosa actividad, la visión que me gustaría transmitir a mis alumnos y compañeros para alentarlos a disfrutar de los desafíos como yo lo hice cuando estaba aprendiendo, y como lo sigo haciendo en la mayoría de los casos.

Exportar un pseudocódigo a un lenguaje real

Desde hace muchísimo tiempo, PSeInt tiene la opción para exportar un pseudocódigo a C++. Es decir, para generar un código C++ que haga exactamente lo mismo que hace un algoritmo en pseudocódigo al ejecutarse en PSeInt. No siempre es posible, pero en general se puede obtener una buena aproximación. El objetivo de esta funcionalidad es bastante dudoso. Definitivamente no está pensado para que generen a través de PSeInt programas reales (es decir, para no tener que aprender un lenguaje real, sino hacerlo acá y convertirlo). Está pensado para servir como ayuda cuando el estudiante empieza a aprender un lenguaje real, luego de haber adquirido lo básico mediante el pseudocódigo. Para generar una sintonía entre lo que ya conoce y lo que está aprendiendo.

El único motivo por el cual se convierte a C++ y no a otro lenguaje es porque C++ es el lenguaje que domino bien, en el cual me siento cómodo, y del cual creo conocer lo suficiente como para decidir cómo conviene hacer las traducciones. Pero muchos docentes que utilizan PSeInt para comenzar, luego pasan a otros lenguajes, y me gustaría que PSeInt también pudiera exportar a muchos de esos otros. En este post voy a contar un poco cómo espero lograrlo, solicitando la colaboración de los docentes (o usuarios en general) que tengan gran conocimiento de esos otros lenguajes para proporcionar ejemplos, y voy a hablar también de los problemas y desafíos que esta traducción supone.

Sobre la Programación Orientada a Objetos

Me crié (hablando de programación) con Basic, y con uno de los viejos, donde había que ponerle a todo números de lineas y no teníamos subs. Eso hizo que mi forma de pensar un código fuera fuertemente "estructurada". Más tarde, alguien me sugirió QBasic como una forma de hacer lo mismo que hacía en Basic (el mismo código) pero con un editor más bonito. Explorando qué más tenía QBasic encontré las subs (funciones o subrutinas) y eso me hizo un poco más modular. Cuando pasé a VisualBasic, mi forma de pensar no cambió. La poca y bizarra orientación a objetos de los primeros VB pasó totalmente desapercibida para mí, y sólo incorporé el concepto de evento.

Con ese background (que llevó varios años y estaba bien acentado), entré a la universidad y me dispararon directamente con la Programación Orientación a Objetos (POO) y bastante de C++. Además, era el primer año que la materia se daba en C++; los docentes eran muy buenos programadores con Pascal/Delphi, y tuvieron que aprender C++ solo para actualizar la materia. Todo esto y más hicieron que la orientación a objetos parezca algo forzada. Y si bien no la cuestioné de entrada, tampoco la entendí ni aproveché tanto en mis primeros proyectos. Solo para la parte visual parecía realmente tener sentido.

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.

Algunos porqués del pseudocódigo

Tengo una eterna discusión (en el buen sentido de la palabra) con varios usuarios de PSeInt acerca de hasta dónde debe llegar este lenguaje. Me han sugerido agregar la posibilidad de leer y escribir archivos, de declarar estructuras o pseudo-clases, de usar tipos de datos más específicos, escribir las palabras claves en inglés, agregar operadores como el de desplazamiento de bits, o hasta en algún caso incorporar una instrucción para enviar y recibir datos por el puerto serie (¿?). El dilema es el de siempre, ¿cuánto de pseudo y cuánto de código? Pareciera que mucho de pseudo significa que no se parece casi nada a un lenguaje real y que tiene en principio poca potencia (digamos que muchas cosas no se pueden hacer); mientras que mucho de código pareciera implicar que será fácil pasar luego a un lenguaje real (será más parecido), y que tal vez se puedan hacer cosas bastante complejas.

¿Ser o no ser una tortuga?

Alan Perlis fue un pionero que se dedicó a las ciencias de la computación, especializándose en el estudio de lenguajes de programación (no en programar con ellos, sino en discutir sus diseños y fundamentos), lo cual incluso le valió el primer premio Turing (podríamos decir el Nobel de la informática). Entre las muchas cosas que escribió, hay una frase muy popular en el mundo de la programación que es la siguiente: "To understand a program you must become both the machine and the program". Podría traducirse como "para entender un programa de computadora tenés que convertirte en los dos, el programa y la computadora". Es una frase muy interesante que siempre acepté como válida (según mi experiencia) y jamás se me ocurrió cuestionar.

Por otro lado, Seymour Papert es un matemático del MIT que investigó entre otras cosas sobre la enseñanza y el aprendizaje en niños, las ciencias de la computación y la inteligencia artificial. Como fruto de todo esto, surgió el lenguaje LOGO, el de la tortuga. Además, escribió muchas cosas, entre ellas un libro genial llamado "Mindstorm: children, computers and  powerful ideas", donde habla del aprendizaje de los niños, de la enseñanza de la matemática, de su esperanza de que el uso masivo de computadoras cambiaría todo eso, y de cómo el lenguaje de tortugas fue concebido para empezar a dar ese paso. Papert sin duda fue un adelantado.

Codificar y ejecutar, ¿serie o paralelo?

Se viene algo grande en PSeInt. Por suerte 2012 ha sido un año de muchos muchos avances, y parece que 2013 también va empezar con novedades. Había advertido que no iba a hacer nada nuevo por un buen tiempo, pero me topé con un concepto demasiado bueno como para andar esperando tanto. Navegando sin rumbo llegué a un post de un tal Bret Victor, un tipo que parece tener ideas más que interesantes sobre cómo deberían ser los entornos de programación (entre otras cosas) y cómo la gente debería aprender a programar. Gracias a ese artículo dí con este video. Si miran el video (que dura más de una hora, pero yo solo vi los primeros 20 minutos cuando me decidí a empezar todos estos cambios), van a entender de qué se trata. No estoy 100% de acuerdo en todo lo que propone, pero sí en su gran mayoría, al menos pensando a nivel didáctico que es lo que me ocupa en PSeInt. Y hay momentos de la charla realmente fantásticos, de esos que le abren a uno la cabeza y lo hacen ver las herramientas que tenía desde un punto de vista completamente nuevo.

El tipo plantea un entorno de desarrollo donde los pasos para programar no son primero codificar, luego ejecutar para ver que sale, y repetir; sino que propone codificar y ver qué sale en simultáneo. Es decir, a medida que el programador va codificando el programa, este se va ejecutando, y si a mitad de una ejecución cambia algo del código fuente, la ventana de ejecución refleja inmediatamente esos cambios. El video muestra otras cosas interesantes, pero esa idea tan simple y complicada a la vez fue la que más me impactó. Aquí les presento mi video, de solo 2 minutos, con algunas de estas ideas llevadas a PSeInt:

¿Hacia dónde debe ir el pseudolenguaje de PSeInt?

Escribo este post para abrir formalmente un debate con la comunidad de usuarios de PSeInt. Quiero pedir sus opiniones y hacer que sean partícipes del futuro de PSeInt, y entonces comienzo escribiendo esto para dejar claro mi punto de vista y mis objetivos como principal y único desarrollador de este proyecto. La motivación del debate reside en la necesidad de ampliar (o no) el pseudolenguaje que utilizo. Varios usuarios, en la mayoría docentes, me han pedido extender el pseudolenguaje para poder hacer tal o cual cosa. Por ejemplo: definir funciones/subprocesos, manejar cadenas, escribir y leer archivos, controlar mejor la salida por consola (ubicación, colores, etc). Por otro lado, algunos usuarios alumnos escriben preguntando ¿cómo hago tal cosa? que actualmente no se puede hacer, e indirectamente también están aportando una nueva idea. Entonces, tengo que decidir si el lenguaje va a crecer o no para permitir estas cosas, cuales debo permitir y cuales no, y sobre todo, de qué manera se integran. Para tomar esta decisión de la mejor forma y dejar contenta a la mayor cantidad de personas posibles es que quiero iniciar antes un debate. En primer lugar voy a describir mi visión del pseudocódigo, y debo advertir que será innegociable. A continuación, presentaré algunas de las posibles mejoras, mencionando los pros y contras que veo en ellas, como se relacionan con mi visión innegociable, y tratando de dejar abierto el camino para la futura discusión.