Pensamiento computacional no es «pensar en binario». Es una forma de partir un problema hasta que cada pieza se puede encargar sin negociar el sentido. En 1º de Bachillerato el bloque C del Decreto 40/2022 pide diseñar e implementar programas: sintaxis, estructuras, depuración, multimedia e interactividad. Nada de eso arranca en la llave del lenguaje. Arranca en el algoritmo, que es anterior al JavaScript, al sketch y al Python de la Raspberry Pi.
El problema del departamento es concreto: si en el patio meteorológico hay poca luz, el grupo de la Semana de la Ciencia no debe salir y alguien tiene que enterarse sin depender de que una persona mire al cielo. El algoritmo es la solución general, válida para cualquier lectura y no solo para «hoy está nublado». El programa es ese algoritmo escrito en un lenguaje que un intérprete o un compilador puede ejecutar. Si el algoritmo está mal, el programa correcto solo automatiza el error.
Descomponer es la primera maniobra. Aquí salen tres piezas y no conviene fundirlas. La entrada es lo que el sistema recibe y no decide: la lectura de luz y, si hace falta, el estado de un pulsador. El proceso es la regla: comparar con el umbral 500. La salida es el efecto observable: un mensaje o un LED en alto o en bajo. En la página de este curso la salida es un dibujo. En una UNO sería el pin digital 13. En una Pi, el GPIO 18 en numeración BCM. El algoritmo es el mismo; cambia el aparato que obedece.
Tiene que terminar. Un algoritmo que dice «sigue mirando el cielo» no es un algoritmo: es un deseo, y en un bucle se convierte en un programa que no devuelve el control. Tiene que estar definido: «si está oscuro» no le sirve a una máquina hasta que «oscuro» es una comparación con un número acordado. Y tiene que estar ordenado: leer la luz después de decidir el LED es decidir con un dato que aún no existe. Esas tres propiedades se comprueban leyendo los pasos en voz alta, antes de abrir el editor.
La abstracción es quedarse con lo que cambia el resultado y tirar el resto. Para el avisador importan la lectura y el umbral. No importan el color de la puerta del gimnasio ni el nombre de quien anota. Si metes esos datos en el programa, no lo haces más inteligente: lo haces más frágil. El patrón, en cambio, sí se reutiliza: la misma comparación servirá mañana para la temperatura del aula, cambiando el sensor y el umbral, no la forma del algoritmo.
El pseudocódigo de esta lección no es JavaScript ni C++. Es una convención del aula: una orden por línea, si / si no / fin, escribe para la salida, lee para la entrada. El laboratorio lo interpreta aquí mismo, sin enviarlo a un servidor. JavaScript, en el navegador, también lo interpreta un programa que ya está en tu ordenador: el motor del navegador. Un sketch de Arduino no se interpreta en la placa línea a línea como esta página. El IDE lo compila: lo traduce a código de máquina del microcontrolador y eso es lo que se graba. Compilar y interpretar resuelven el mismo problema (pasar de un texto a una ejecución) en momentos distintos. El fallo de sintaxis detiene las dos rutas. El fallo de lógica, no.
En un sketch, setup se ejecuta una vez: ahí se declaran los pines de salida, como el 13 para el LED. loop se ejecuta sin parar: leer, comparar, escribir el pin. Ese bucle infinito es deliberado en un controlador que vive enchufado. En un algoritmo de papel, el mismo bucle solo es aceptable si cada vuelta tiene una condición de salida o si el aparato está pensado para no terminar nunca, como la alarma del patio durante la tarde del acto. Conviene escribir esa decisión. Si no, «se me ha quedado colgado» y «está vigilando» se confunden.
Esta lección no pide todavía un juego ni un objeto. Pide que el avisador quepa en pocos pasos y que seas capaz de señalar cuál es entrada, cuál es proceso y cuál es salida. El interruptor de la página es la salida simulada: ON es HIGH, OFF es LOW. Cuando más adelante el programa encienda el LED solo, el gesto de la mano tiene que coincidir con lo que diría la traza. Si no coincide, no se toca el dibujo para «arreglarlo»: se revisa la condición.
Algoritmo. Secuencia finita, ordenada y definida de pasos. No es todavía un archivo.
Programa. Algoritmo escrito en un lenguaje. Aquí, pseudocódigo y, en paralelo, un sketch.
Entrada. Dato que llega de fuera: sensor o pulsador. El programa no lo inventa.
Proceso. La regla. En este hilo, comparar la luz con 500.
Salida. Efecto comprobable: texto o pin en HIGH o LOW.
Pseudocódigo. Lenguaje de aula, una orden por línea. Lo ejecuta el laboratorio, no la placa.
Intérprete. Ejecuta el texto mientras lo lee. El navegador interpreta JavaScript.
Compilador. Traduce todo el programa antes de ejecutarlo. El IDE de Arduino compila el sketch.
setup. Bloque que corre una vez al arrancar la placa. Sitio de pinMode.
loop. Bloque que se repite. Sitio de la lectura y del digitalWrite.
«Mientras haya gente en el patio, mira el cielo». No hay lectura numérica ni paso final. Se reescribe: leer luz, comparar con 500, escribir el pin, y repetir solo si el acto sigue, con esa condición escrita.
El paso 1 enciende el LED y el paso 2 lee el sensor. La primera decisión usa un valor viejo o ninguno. Se invierte el orden. En el sketch, analogRead va antes de digitalWrite dentro de loop.
El programa dice si (oscuro). Nadie puede trazar «oscuro» el jueves y el viernes con el mismo resultado. Se sustituye por luz < 500 y el 500 se nombra: es un acuerdo del departamento, no una constante de la naturaleza.
Cada caso es una entrega del avisador del patio del IES Duero (Aranda de Duero). Lee la situación antes de la decisión.
Situación. En el cuaderno hay un solo párrafo: «el LED se enciende cuando toca».
No conviene. Empezar por el color del LED en la página web del acto.
Decisión. Escribir tres líneas tituladas entrada, proceso y salida, y solo después el pseudocódigo.
Por qué: Un párrafo que dice «el LED se enciende cuando toca» diseña la salida antes de la regla. El dibujo manda y la condición se retuerce para que el dibujo quede bonito. Hacen falta tres líneas separadas: qué entra, qué se compara y qué efecto se ve.
Situación. Dos personas del grupo usan 400 y 600 sin decirlo.
No conviene. Dejar el número que «queda mejor» en el ensayo de las 17:30.
Decisión. Acordar 500, escribirlo una sola vez y citarlo en la memoria.
Por qué: Si una persona usa 400 y otra 600, la misma luz da dos resultados y ya no es un algoritmo definido. Dos umbrales son dos algoritmos. El número se acuerda, se escribe una vez y se usa en el ensayo de las 17:30, no el que «queda mejor».
Situación. El sketch se queda en loop y alguien cree que se ha bloqueado.
No conviene. Añadir un delay enorme para «que se vea» y dar el ejercicio por terminado.
Decisión. Explicar que loop no tiene fin porque la vigilancia no tiene fin, y anotar el periodo de lectura.
Por qué: Que el sketch se quede en loop no significa que se haya bloqueado: es la vigilancia del avisador, que no debe parar. Esconderlo con una pausa enorme solo dificulta la traza. Se explica que loop no tiene fin a propósito, y se distingue de un cuelgue.
Situación. El grupo quiere entregar una foto de una Pi encendida y no hay Pi en el aula.
No conviene. Inventar que el navegador escribió en el GPIO real.
Decisión. Entregar la traza y el interruptor simulado, y decir que HIGH sería led.on() en GPIO 18.
Por qué: Inventar que el navegador escribió en el GPIO real enseña un programa que no se puede repetir, porque en el aula no hay Pi. La simulación, declarada, sí se puede repetir: la traza y el interruptor. HIGH sería led.on() en el GPIO 18 si hubiera placa; aquí no la hay.
El problema no cambia: si la luz del patio del IES Duero baja de 500, hay que avisar. Cambia quién ejecuta. El pseudocódigo lo ejecuta el laboratorio de esta página. El sketch lo compilaría el IDE de Arduino hacia la UNO. El fragmento de Python lo ejecutaría una Raspberry Pi con gpiozero, si hubiera placa. Aquí no hay placa.
Una orden por línea. lee luz, en el laboratorio, fija la entrada simulada en 420.
lee luz
let umbral = 500
si luz < umbral
escribe "HIGH"
si no
escribe "LOW"
finsetup prepara el pin 13. loop lee A0 y escribe HIGH o LOW. Esto no se graba desde la página: es el paralelo del algoritmo.
const int LED = 13; // paralelo didáctico del GPIO 18
const int LDR = A0; // fotorresistencia, entrada analógica
const int UMBRAL = 500;
void setup() {
pinMode(LED, OUTPUT); // la salida se prepara una vez
}
void loop() {
int luz = analogRead(LDR); // entrada
if (luz < UMBRAL) { // proceso
digitalWrite(LED, HIGH); // salida
} else {
digitalWrite(LED, LOW);
}
}LED(18) usa numeración BCM. La Pi trabaja a 3,3 V. El 5 V de la UNO no se lleva a un GPIO. En esta página led.on() no se ejecuta: lo representa el interruptor.
from gpiozero import LED
led = LED(18) # numeración BCM, 3,3 V
UMBRAL = 500
def leer_luz_simulada():
return 420 # en el aula real, aquí iría el sensor
luz = leer_luz_simulada()
if luz < UMBRAL:
led.on() # HIGH
else:
led.off() # LOW
| Hora | luz | Pieza | Proceso | Salida |
|---|---|---|---|---|
| 17:30 | 420 | entrada | comparar con 500 | HIGH |
| 17:32 | 510 | entrada | comparar con 500 | LOW |
| 17:35 | 390 | entrada | comparar con 500 | HIGH |
| 17:41 | 600 | entrada | comparar con 500 | LOW |
| 17:48 | 500 | entrada | comparar con 500 | LOW |
| 18:02 | 250 | entrada | comparar con 500 | HIGH |
| 18:15 | 880 | entrada | comparar con 500 | LOW |
| 18:27 | 499 | entrada | comparar con 500 | HIGH |
A las 17:48 la luz es 500. 500 < 500 es falso, así que la salida es LOW. Cambiar esa decisión es cambiar el algoritmo, no «ajustar el dibujo». A las 18:27, 499 sí enciende: un dígito de diferencia es una traza distinta, no un empate.
Conviene probar el algoritmo con tres entradas extremas antes de darlo por bueno: luz 0 (sensor tapado o desconectado, según el montaje), luz 500 (el empate) y luz 1023 (el techo de un analogRead de 10 bits en la UNO). Si los tres casos no tienen una frase cada uno en el cuaderno, el algoritmo solo se ha ensayado con el tiempo que hacía el día del ensayo.
La descomposición también sirve para repartir el grupo. Una persona escribe la entrada, otra la condición, otra la frase que verá el público. El programa final es la suma, pero nadie necesita saber todavía cómo se declara una función. Ese reparto es pensamiento computacional aunque el archivo tenga doce líneas.
Cuando el mismo avisador pase a la lección 30, el propósito será lúdico y habrá una cesta y una puntuación. El algoritmo de debajo no se tira: comparar con el umbral sigue siendo el proceso. Si el juego no sabe decir cuál es su entrada, no es un programa del bloque C: es un dibujo que se mueve.
| Criterio | Aún no | En proceso | Conseguido | Notable |
|---|---|---|---|---|
| Descomposición | Un párrafo único | Nombra el LED y poco más | Separa entrada, proceso y salida | Justifica qué dato sobra |
| Definición | «Si está oscuro» | Hay un número sin unidad ni acuerdo | Umbral 500 explícito | Discute el caso igual al umbral |
| Orden | La salida va antes | El orden se entiende a medias | Leer, comparar, escribir | Lo mismo en sketch y en pseudocódigo |
| Fin | No se sabe si acaba | Hay un bucle mudo | Se explica loop o el fin | Distingue vigilancia de cuelgue |
| Honestidad del pin | Dice que encendió la Pi | No nombra el pin | GPIO 18 y D13, simulado | Recuerda 3,3 V frente a 5 V |
Un algoritmo cabe en entrada, proceso y salida, termina o justifica su bucle, y no depende de adivinar «oscuro». El programa vendrá después. El LED de la página solo demuestra la salida.
Abre cada pregunta, responde en el cuaderno y después mira la solución. El párrafo «Por qué» es la parte que se estudia.
Respuesta. Porque «oscuro» no es una operación definida y no se dice qué se lee ni cuándo se para.
Por qué: Una máquina no comparte el contexto del patio. Hasta que oscuro es luz < 500, dos personas pueden ejecutar pasos distintos con la misma frase y las dos creer que han seguido el algoritmo.
Respuesta. Prepara el pin de salida, pinMode del 13, una sola vez al arrancar.
Por qué: Volver a configurar el pin en cada vuelta no cambia la lógica del avisador y mezcla preparación con vigilancia. Separarlos es lo que hace legible el programa cuando el jueves falla solo la lectura.
Respuesta. Esta página interpreta el texto al pulsarlo. El sketch se compila en el IDE y en la placa ya no está el texto, está el código traducido.
Por qué: Por eso un error de sintaxis en el IDE ni siquiera llega a la placa, y un error de sintaxis aquí ni siquiera dibuja un estado nuevo. Un error de lógica, en los dos sitios, sí llega a ejecutarse: el LED se enciende cuando no toca y no hay mensaje de error.
En la vida real
Escribes y dibujas aquí mismo: no hay salto a otro módulo. La misma herramienta, a pantalla completa, está en l23-pensamiento-computacional-y-algoritmos.html y en el marco (útil si el navegador permite file:// en iframes).
Escribe en el laboratorio el pseudocódigo del avisador con un umbral que hayas elegido y justificado en una frase del cuaderno. Tiene que haber una entrada, una comparación y una salida HIGH o LOW. Mueve el interruptor, ejecuta otra vez con lee pulsador y anota qué valor entra. Una buena entrega explica el caso en el que la luz es exactamente el umbral, y no afirma que la página haya encendido una placa.
reto_id: bach1-tic-L23