¿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.

Los dos personajes aparecen en un artículo de Bret Victor (de quien ya les hablé en otro Post), donde se condena la frase del primero y se enaltecen las ideas del segundo. No voy a hablar mucho de lo que Bret Victor dice, pero sí lo menciono porque su artículo fue el desencadentante de esta discusión conmigo mismo que me llevó a agregar cosas en PSeInt, repensar mejor la frase de Perlis, y leer el genial libro de Papert, entre otras.

Una placa en algún lugar de Carnegie Mellon muestra una selección (no muy buena a mi gusto) de sus frases, 

imagen tomada de http://www.cs.iastate.edu/~jia/album/2007/album-cmu.html

La frase de Perlis básicamente dice que para programar que hay que ser capaz de entender no solo el programa, sino también cómo funciona la máquina que lo ejecutará. Hay que entender qué va a pasar con ese programa y cómo lo va a procesar la computadora. Entonces, se puede pensar también que hay que conocer (o al menos ser conciente de) qué tareas realizará un compilador o intérprete con el código que le demos, qué hace detrás el sistema operativo, cuál es la arquitectura de la computadora, y muchos otros detalles que posibilitan y condicionan el funcionamiento de ese programa. Bret Victor dice que una persona no es una máquina y por ende no debería pensar como tal. La mayoría de los lenguajes de programación nos obligan a ello y por eso él acusa a la frase de atentar contra el desarrollo de la programación, y plantea que la programación debería cambiar para convertirse en algo más natural, más fácil de entender para las personas.

Papert empieza su libro diciendo (resumiendo mucho mucho), si estamos en Estados Unidos y le intentamos enseñar Francés a niños pequeños muy probablemente no lo logremos y concluyamos que el Francés es demasiado difícil para los niños. Pero en Francia los niños aprenden Francés naturalmente desde muy pequeños sin que los obliguen a estudiar. Claro, hay una obvia diferencia de contexto. Entonces él propone que para que los niños aprendan matemáticas de la buena (la forma de pensar, no a hacer operaciones mecánicas), deberían vivir en Mathland (algo así como "Matematicalandia", o "La tierra de las matemáticas") y sugiere que la computadora puede crear virtualmente ese mundo (tal vez no les permita vivir en Mathland, pero sí ir de vacaciones allí, según sus palabras). Así, con LOGO, no buscaba enseñarle a programar a los chicos, sino entusiasmarlos para que aprendan, a su modo y a su tiempo, casi sin darse cuenta, bases de matemática, lógica, geometría y aprendan sobre ellos mismos (de sus propias formas de pensar y resolver problemas). Este aprendizaje tiene mil bondades que describe en el libro, pero hay algo de LOGO que no había notado: no es casual que tenga una tortuga. Él podría haber creado un lenguaje simple (estilo pseudocódigo) para hacer mil cosas, pero eligió dibujar, porque a los niños les entusiasmaría, y con una tortuga, porque es una metáfora muy fuerte. Sí, la tortuga responde al poder de la metáfora, y este es un aspecto que Bret Victor rescata especialmente.

Imagen del libro "The Children's Machine" de Papert, versión digital tomada de http://www.bfoit.org

Siempre pensé que era solo por lo simpática que resultaba, y por lo lento que iban aquellas computadoras. Pero lo lindo de la tortuga, es en realidad que el niño puede imaginarse él en el lugar de la tortuga muy fácilmente, y pensar cómo se movería él mismo (que ya sabe caminar y se mueve sin problemas por ejemplo por su casa). O puede asociarlo a cualquier cosa conocida, como pueden ser también un auto o un bote. Una cosa que avanza y/o gira para ir de un lugar a otro. Así, para resolver el problema de cómo dibujar algo con la tortuga en la computadora, es natural para el niño pensar cómo lo haría él y escribirlo casi literalmente. Así aprenden de forma natural no solo cómo dibujar, sino una forma valiosa de resolver problemas. De hecho, Papert proponía primero mostrarles a los chicos el concepto con una tortuga robótica con un lapiz real moviéndose por una gran hoja en el piso, para que luego la asocien con el triangulito que mostraba LOGO en pantalla en aquella época (la "tortuga de luz"). Hoy en día hay metáforas por todos lados (carpeta, escritorio, ventana, archivo, navegador, ¿acaso no son todas metáforas?, de esto también hablaba el ensayo de Neal Stephenson que recomendé en otro post), algunas que ayudan, algunas que atrasan, otras insípidas. Pero esta de la tortuga es una particularmente muy bien pensada y fundamentada. Y aquí, el programador (el niño) se convierte naturalmente y por "decisión de diseño" en la máquina (la tortuga).

Al enseñar a programar en los lenguajes actuales, o en pseudocódigos como el de PSeInt tenemos que forzar esa (no)metáfora. Tenemos que obligar explícitamente al alumno a pensar en cómo se interpreta un algoritmo para evitar que caiga en la trampa del ensayo y error, y para que aprenda esa forma de pensar que buscamos que aprenda, para que logre esa abstracción que ya no es para nada natural. Bret Victor cuestiona esto, y no estoy de acuerdo en ese punto. Propone algunos ejemplos muy atractivos e inteligentes de alternativas. Pero no podemos infantilizar de esa forma la programación real. Los verdaderos problemas, los desafiantes e interesantes, no admiten ese traspaso de forma genérica. Por lo que ahora sé, ni siquiera Papert buscaba enseñar directamente programación. Y alguien tiene que hacer el trabajo "sucio", ya que no veo un cambio de paradigma en la dirección pedagógica como algo que vaya a autosustentarse (que los nuevos lenguajes y entornos más "humanos" permitan crear las nuevas herramientas en todo nivel, compiladores, sistemas operativos, etc). Es algo que no va a cambiar a menos que cambie la esencia misma de las máquinas, cosa que no va a pasar en nuestras vidas (quien sabe qué pasará cuando llegue la computación cuántica por ejemplo, pero no va en esa dirección). Entonces, veo la capacidad de convertirse en el interprete como algo no solo deseable, sino fundamental en un buen programador.

Uno de mis certificados más valiosos. De alguna forma, allí empezó todo.

 
De todas maneras, es algo que puede adquirirse gradualmente con el tiempo. Las ideas de Bret Victor siguen siendo fabulosas a nivel didáctico como lo fueron las de Papert plasmadas en LOGO (ambos critican prácticas actuales que tienen su origen en razones históricas, y cuyos fundamentos han caducado con el tiempo). Permitirán que los programadores se entusiasmen a más temprana edad, que vayan descubriendo su camino de a poco y gradualmente, y que cuando lleguen a ser capaces de convertirse en "la máquina", sientan el sustento y la confianza que les dá el haber recorrido ese camino previo. Por ejemplo, Papert sabe que los niños no van a interpretar como ángulos en grados los números que indican cuanto debe girar la tortuga (los de avanzar pueden asimilarse a pasos y ser más naturales), sino que van a experimentar, ahí sí con ensayo y error. Pero de a poco, con el uso, a medida que su forma de pensar madure y sus conocimientos se vayan formalizando entenderán mejor esos secretos aprendidos a pura práctica, y notarán que estarán poniéndole nombres a cosas que tal vez ya sabían. De alguna forma fue lo que me pasó con la programación cuando llegué a la facultad y por eso simpatizo tanto con su idea: aprendí a programar mucho antes, solo porque era divertido, a pura práctica, con muchos ejemplos y casi sin sustento teórico, y adquirí así las bases, la capacidad de abstracción y otras cualidades importantes sin saberlo y a mi ritmo. Mis códigos eran horribles, pero andaban. En la facultad le puse nombre a esas cosas y comencé a construir sobre ellas. Así el proceso fué gradual y sólido. Esto lleva tiempo, y por eso es importante tener una motivación propia, antes de la obligación, y allí lo de Bret también es fantástico. Pero cuando vamos a lo serio, si llegamos al otro lado y nos toca ser los que generen esas posibilidades, la frase de Perlis no pierde ni un bit de vigencia.