Algoritmos en clase: lo que enseña un ascensor
¿Cómo enseñar programación por bloques, algoritmos sencillos y depuración cuando no sabes programar y Scratch te resulta complejo? Es la pregunta que muchos docentes se hacen al llegar al apartado de pensamiento computacional en su programación de aula. El currículo lo nombra con frases precisas pero impronunciables ("interpretación, modificación y creación de algoritmos sencillos: secuencias de pasos ordenados, esquemas, simulaciones, programación por bloques"), y no dice cómo. Quien busca en internet acaba en Scratch, una herramienta excelente pero con decenas de bloques, eventos, sprites y escenarios donde la primera media hora se va en aprender la interfaz.
La respuesta corta: no hace falta empezar por ahí. Lo que el currículo busca es una experiencia donde el alumno construya una secuencia de pasos, la ejecute, vea el resultado y la modifique cuando algo falle. Cualquier entorno que permita esas cuatro fases cumple. Un simulador con tres botones cumple, y a veces mejor que una herramienta con doscientos.
Las cuatro cosas que de verdad importan
Si se mira despacio lo que se pide a niños de tercer ciclo de Primaria y primer ciclo de la ESO, no son siete cosas distintas; son cuatro:
- Secuencia ordenada de pasos. Una lista de instrucciones que se ejecutan una detrás de otra.
- Programación por bloques. Construir esa lista visualmente, no escribiéndola.
- Simulación. Ejecutar el programa y ver qué pasa.
- Depuración. Encontrar el error cuando algo no funciona, modificar y volver a probar.
Si lo que se hace en clase cubre las cuatro, se está enseñando lo que la ley quiere que se enseñe. Lo demás (qué herramienta concreta, qué lenguaje, qué plataforma) es decisión del docente. Lo mismo que cuando hablamos de algoritmos en la vida cotidiana: un algoritmo no es código, es una receta clara.
¿Por qué Scratch no siempre es el mejor punto de partida?
Scratch es una herramienta excelente y nadie la cuestiona seriamente. El problema aparece cuando se usa como puerta de entrada con niños que no han programado nunca: la primera media hora se va en aprender la interfaz. Hay decenas de bloques disponibles, categorías de eventos, sprites, escenarios. Para un alumno que viene de cero, esa abundancia es ruido.
Y aquí pasa una cosa interesante: en pensamiento computacional, menos bloques enseñan más. Cuando solo tienes tres piezas, te obliga a pensar cómo combinarlas. Cuando tienes doscientas, te obliga a buscar la que resuelve el problema entero. La primera situación entrena el pensamiento; la segunda entrena el manejo de software.
Ese principio (pocos átomos, muchas combinaciones) es el que diferencia un buen ejercicio de pensamiento computacional de una clase de informática aplicada. Es el mismo principio del juego Programar un ratón sin pantalla, donde el alumno tiene cuatro flechas y un queso que alcanzar. Y es exactamente el principio que pone en práctica un simulador de ascensor.
¿Cómo cubre un ascensor las cuatro cosas?
Imagina un ascensor con seis plantas y varios pasajeros esperando en plantas distintas. El alumno tiene tres bloques que puede usar tantas veces como quiera:
- ▲ Subir una planta.
- ▼ Bajar una planta.
- ⇆ Abrir las puertas (recoger a los pasajeros que estén ahí, dejar a los que iban a esta planta).
Cada bloque cuesta un turno. Su trabajo es construir la secuencia que recoja a todo el mundo. Cuando termina, pulsa Play y ve qué pasa. Si algo falla, vuelve a empezar.
Secuencia ordenada de pasos
La secuencia construida es literalmente eso: una lista de pasos que el ascensor obedece. Si el alumno pulsa "subir, subir, abrir" y en la primera planta había un pasajero, el ascensor habrá subido dos plantas sin recogerlo y abrirá las puertas vacío en la segunda. El alumno ve el resultado de cada paso, en pantalla, en el orden en el que sucede. No hay magia ni inteligencia oculta detrás.
Programación por bloques
Los tres botones son bloques en el sentido pedagógico del término. Se pulsan y van apareciendo como chips de colores en una caja debajo. Se ejecutan en orden. No hay sintaxis, no hay teclado, no hay errores de tipeo. La capa cognitiva es solo la lógica del problema, no la interfaz que la rodea.
Simulación
Cuando el alumno pulsa Play, la cabina sube y baja en pantalla, los pasajeros suben y bajan con sus pequeños contadores de espera, las puertas se abren cuando toca. Es una simulación de un sistema controlado por código, en tiempo real, ante los ojos del alumno. La distancia entre lo que pidió y lo que pasa es inmediata.
Depuración
Aquí es donde se separa el aprendizaje real del entretenimiento. La primera versión del programa de cualquier alumno fallará. Faltará un "abrir" en una planta, sobrará uno en otra vacía, el ascensor se quedará a una planta del último pasajero. Las estadísticas finales lo dirán: "queda 1 sin terminar", "espera máxima 18 turnos". El alumno tiene que mirar su propia secuencia, identificar el paso erróneo y arreglarlo. Es la actitud de la que ya hablamos en el error es la pregunta, no la respuesta: el bug no es un fracaso, es la pista que te dice por dónde seguir.
¿Cuándo está bien hecho un programa?
Una de las cosas más útiles del simulador es que no ofrece una sola métrica al cerrar la partida, ofrece varias. Hay un contador de tiempo total (cuántos turnos has gastado), pero también la espera mínima, mediana y máxima de los pasajeros.
Esto abre una conversación que no es trivial: dos alumnos pueden resolver el mismo nivel en el mismo número de turnos pero con esperas máximas muy distintas. ¿Cuál es mejor?
La respuesta no es única. Depende de qué consideres mejor. Si lo que importa es la velocidad total, una solución gana. Si lo que importa es que nadie tenga que esperar demasiado, gana otra. Esa pregunta no es teórica, sale natural delante del juego cuando dos parejas comparan sus programas.
En el modo «Con destino», cada pasajero lleva un bocadillo con la planta a la que quiere ir, y hay que recogerlo y dejarlo allí. Aquí el alumno tiene que pensar en dos fases (recogida y entrega) y darse cuenta de que el orden importa. Aparece, sin necesidad de nombrarla, la idea de planificación.
Para una sesión de aula
Una propuesta breve, sin convertirla en ficha:
- Veinte minutos en pareja por nivel del modo «Recoger», empezando por el nivel 2 o 3. Suficiente para que la mecánica se asiente.
- Una segunda sesión con «Con destino» cuando construir-ejecutar-depurar ya se haga sin mirar al profesor.
- Una conversación abierta comparando dos programas distintos. Mismo nivel, dos parejas, dos secuencias. ¿Por qué una tarda menos? ¿Por qué la otra tiene la mediana más baja? Aquí entra el pensamiento algorítmico de verdad.
Lo importante en esa conversación es resistir la tentación de dar la respuesta. Si el docente resuelve el problema, el alumno deja de pensar. La depuración como actitud se entrena dejando que el alumno se equivoque, vea el error y lo arregle por su cuenta.
Pruébalo
Es gratuito, sin registro, sin descargas. Funciona en cualquier navegador. Está pensado para que un docente pueda abrirlo un lunes a las nueve y empezar a usarlo en clase ese mismo día, sin curso previo. Y para que un padre o madre que ha visto al hijo aburrido un rato pueda enseñárselo en el sofá un sábado por la mañana.
Si lo usas con un grupo y descubres algo que merece la pena, cuéntalo. Estos ratos cortos delante de un problema bien planteado son lo que entrena el pensamiento computacional de verdad, mucho más que cualquier lista de objetivos memorizada.