Estoy suscrito al canal de YouTube del amigo Carlos en el que enseña a programar y se me ha ocurrido recordar que en el tiempo que llevo programando he intentado pensar en alguna manera de introducir los conceptos de programación y, a día de hoy, no he conseguido ninguna respuesta que me satisfaga. Ojo, no digo, ni de lejos, que Carlos lo haga mal o que no explique adecuadamente los conceptos de los que habla, que lo hace y muy bien. Pero digo que yo no he encontrado una forma razonablemente adecuada para introducir ciertos conceptos básicos de programación … o sí, pero no se utilizarlos.

El tema está en que me dio por recordar cómo aprendí a programar (aunque creo que nunca aprendo lo suficiente, de ahí que me guste escuchar a los que quieren enseñar programación, porque sé que siempre se me olvida algo). Iba a comentárselo a Carlos en un comentario, pero como creo que me va a salir un tocho, prefiero desarrollarlo tranquilamente en este humilde (y mínimamente renovado) blog.

La primera vez que arranqué MI ordenador (un SVI-328), copié un programa del manual que hacía que un melón-píxel de una pantalla de 320 x 200 se desplazara en diagonal como si fuera bajando unas escaleras. Ahí explotó mi mente para descubrir que con mi imaginación y sus circuitos, juntos podíamos hacer lo que quisiéramos.

El caso es que aprendí a programar en Basic, más concretamente en la versión que montó Microsoft para los pre-MSX y MSX. Luego fui a la Universidad y ya entraron en juego otros lenguajes más estructurados y ciertas metodologías y conceptos de los que solo había pillado de rebote en forma de prueba y error. El aprendizaje es un no parar hasta estos días, y espero que dure mucho más.

¿Y cómo aprendí? ¿Cómo solté el lastre de las incorreccciones que, alertaban, grababa el Basic en nuestro ADN? ¿Cómo puedo enseñar a otros programación?

Este aspecto es el que me frustra. He intentado observar (y ejecutar) cursos y sitios especializados en la Web, como codeacademy y los veo demasiado prácticos y reducidos al lenguaje que se está enseñando. Cierto es que aprendí así, pero me faltan esos conceptos que aprendí en modo prueba y error, que posiblemente me costaran asimilar más de lo que recuerdo, y que son básicos para programar.

Los libros con los que aprendí bastante a programar usaban los ejemplos típicos de matemáticas (factoriales, mínimo común múltiplo, etc.), de cadenas (palíndromos), de vectores (ordenar), de gestión de datos (agenda de contactos)… todo bastante potente pero con el inconveniente -a mi modo de ver- de que no consigue relacionar los problemas que se solucionan; si he intentado enseñar a alguien a programar con esto, me ha dado la impresión de que dejaba algo por el camino, y no sé decir muy bien qué.

Otra forma de enseñanza que he intentado ha sido mediante los juegos de programación (que no programación de juegos); es decir, juegos donde debes programar el comportamiento de los elementos del juego, como robots que se lanzan a una arena para pelear entre ellos, o un equipo de fútbol que debe jugar contra otro. Pero, claro, en este tipo de juegos priman los algoritmos de inteligencia artificial (aunque se reduzcan a conjuntos ilimitados de condiciones) y donde los estudiantes avanzados tienen unas ventajas absurdas sobre los primerizos. Así pues, tampoco es la forma correcta de enseñar a programar, aunque sea divertida.

Existen también videojuegos que parten de una base de programación para ofrecer un concepto de puzzle, y aunque no se pueden considerar como juegos de programación puros y duros, sí te dan una idea sobre el razonamiento lógico de la computación, y estos me gustan más que los anteriores, la verdad. ¿Ejemplos? Para mí, el mejor es Human Resources Machine, que básicamente te enseña a programar ensamblador.

Otro muy bueno para pillar conceptos de programación es el Spacechem, que además añade a la ecuación un poco de química.

El último que me ha gustado, aunque para el principiante le puede echar para atrás el aspecto y su aparente complejidad, es el TIS-100.

Entonces, ¿qué usar? Sinceramente, no lo sé. Nunca lo he sabido, y a veces esto me ha desesperado. No es nada fácil enseñar conceptos de programación, a pesar de que veo mucha gente, cada vez más, que dice que es imprescindible aprender a programar, mientras salen a diario plataformas que te prometen enseñarte lo básico para que empieces a programar tus propias páginas web o juegos.

Sin embargo, hay un ejemplo que creo que me sirvió de mucho, de muchísimo, para aprender a programar, pero que pienso que está muy desfasado y que los jóvenes de hoy en día no entenderían; pero a mí me enseñó casi todo los conceptos que hoy utilizo.

Me refiero a las aventuras conversacionales; no gráficas: conversacionales. Es difícil explicar a la juventud, envuelta en juegos de gráficos alucinantes (no es una crítica a los nuevos juegos, yo los disfruto enormemente), este tipo de juegos.

Pero es que a nivel de programación, estos juegos lo tenían absolutamente todo:

  • Entrada de datos, vía teclado.

  • Tratamiento de cadenas: el jugador introducía una cadena y el programador debía validarla y tratarla, buscando una cierta organización (sujeto - verbo - complemento directo la mayoría de las veces). Principalmente este es el punto que no encuentras en el desarrollo actual de videojuegos.

  • Con la gestión de inventario aprendías el uso de vectores.

  • Con el mapa aprendías el uso de estructuras, vectores y gestión de estados y condiciones (paso a la siguiente habitación según a qué dirección me dirijo)

  • Grabación y lectura de datos para guardar y cargar la partida.

  • Variables para llevar el control de vidas, de objetos, etc.

  • Salida formateada de datos, a la pantalla de texto. Y eso incluye hacer cajas de asteriscos.

Y todo a un cierto peldaño de programación a bajo nivel; por ejemplo, en la escritura de la partida, debías grabar en el disco cada una de las variables de la estructura para luego recuperarlas en el mismo orden. No existía el concepto de serializable, había que hacerlo a mano.

Lo que quiero hacer ver es que el caso de las aventuras conversacionales es el único que conozco que me ha obligado a aprender muchos conceptos relacionados a partir de un ejemplo divertido y completo en su conjunto. Puede que me digáis, con razón, que esto se puede conseguir si enseñamos a programar en un determinado motor de juegos, pongamos Unity, pero yo no lo veo igual. Para empezar, en Unity tenemos muy asociado el tema de la visualización con el de programación de objetos, y precisamente veo que sobra eso: los objetos. Es fácil ver que en estos motores lo que prima es el conjunto de librerías de objetos ya creados que hacen que al final pierdas más tiempo en la documentación de las APIs que en la programación en sí misma. Con las aventuras conversacionales, más allá de las funciones de sistema básicas para recoger datos del teclado, mostrar cadenas en el monitor, o leer y escribir una secuencia de bytes, como programador lo tenías que hacer tú absolutamente todo. Para mí, esa es la clave: ¿cómo extraigo una subcadena? ¿cómo comparo verbos? ¿cómo actualizo la información que sale en pantalla? ¿cómo guardo la partida?

Otro asunto que siempre se olvida de enseñar, y que para mí refleja parte de la calidad de un programador, es la depuración. Y, ojo, aunque al final termines usando depuradores y programas de ayuda, creo que añadir los echo ‘aquí paso X’ te obliga a entender la traza más allá de lo que piensas. He visto a más de tres programadores que no encontraban un error porque pensaban que el código hacía lo que tenían en mente, en vez de seguir el código tal cual. Siempre digo: si quieres depurar, sé código; si no sabes depurar, no sabes programar; seguir el código “es muy sencillo”: el ordenador tan solo ejecuta lo que le dice el código, no hay más (vale, esto está muy simplificado, pero no me negaréis que en esencia no hay más). La búsqueda de errores no deja de ser una versión del juego del ratón y el gato, y hay que ir arrinconándolo hasta que aparezca. Si un programador no es capaz de seguir la traza, arrinconar el error y repararlo, mal vamos. Está claro que hoy en día, el error puede venir desde distintas capas: una librería con un cierto error, un problema del sistema operativo. Pero para eso puedes hacer tests que comprueben las salidas de las librerías (y no hace falta ninguna librería de tests, simplemente unos cuandos if-then).

Como resumen diré que nunca he sido capaz de enseñar programación, o al menos no al nivel que deseo, porque realmente no sé cómo debo enfocarlo; quizás le doy demasiadas vueltas y debería simplificar el tema, pero en las veces que lo he intentado nunca me he sentido satisfecho, porque creo que no enseño las bases necesarias que, aun hoy, tras más de treinta años de programación a mis espaldas, sigo aprendiendo de gente como Carlos.