Programación Estructurada I: Introducción
- programación
Creo que una de las cosas que se me ha venido recurrentemente a la cabeza por mucho tiempo es que la forma de enseñar a programar no va de acuerdo con los tiempos. Si ves una guía creada en este año (2026), se ve muy similar a lo que era hace 10 años: se selecciona un lenguaje, se hace un primer programa («Hola, mundo»), se explican conceptos, y se repite, produciendo en cada iteración un nuevo programa que explica un concepto nuevo, hasta llegar al punto en el que el estudiante tiene conocimiento de un conjunto de conceptos para la creación y análisis de programas. Y esto suena, al menos por escrito, como un buen método, y por eso se ha mantenido por años, con el único cambio notorio siendo el uso más frecuente de lenguajes interpretados sobre lenguajes compilados.
Pero creo que esto está por cambiar. La llegada del vibe coding, o el arte de usar nuestras intenciones a través de IA para la generación de código, si bien ha sido una idea controversial, también ha sido refrescante: rompe primero con el precepto de que se tiene que usar un lenguaje de programación para la enseñanza de la habilidad, y trae con esto un cambio de enfoque de la implementación (bajo nivel) al diseño (alto nivel) para el desarrollo de software. Y es con este cambio que me surge la pregunta: ¿cómo se ve un curso así?
Principios de programación estructurada
Ok, no empezaremos con un «Hola, mundo»; en su lugar usaremos conceptos fundamentales (principios) de los cuales podremos derivar otros conceptos e ideas más complejas. Estos principios están definidos en lo que se conoce como el teorema del programa estructurado, el cual dice que cualquier programa computable puede crearse a partir de tres estructuras de control:
- secuencia: haz A, después B
- selección: si P, haz A; si no, haz B
- iteración: mientras P, repite A
Y es usando la composición, la idea de que una estructura puede ir dentro de otra, que se forman programas más complejos.
Debo hacer algunos puntos antes de continuar. Si bien es posible representar cualquier programa computable haciendo uso de estas estructuras, resulta poco práctico cuando el programa es complejo; para esos casos utilizaremos otras ideas, como la abstracción, que simplifican su diseño.
La abstracción consiste en darle nombre a un grupo de estructuras y tratarlo como una sola acción. Como cada estructura tiene una sola entrada y una sola salida, cualquier diagrama completo puede ocupar el lugar de una caja en otro diagrama más grande: «haz A» puede ser una instrucción sencilla o un programa entero. Así podemos diseñar de arriba hacia abajo, empezando por los pasos generales y resolviendo después el detalle de cada uno.
El segundo punto es que las estructuras de control solo representan el flujo del programa: el orden en que se hacen las cosas. La otra parte es el estado, la información que el programa guarda y va cambiando mientras se ejecuta.
Las dos partes se encuentran en los diagramas: las acciones (A, B, C) cambian el estado, y las preguntas (P, Q) lo consultan para decidir el camino. Un contador que sube de uno en uno hasta llegar a diez es un buen ejemplo: «suma uno al contador» es una acción que cambia el estado, y «¿el contador es menor que diez?» es una pregunta que lo lee. Niklaus Wirth lo resumió en el título de su libro de 1976: Algoritmos + Estructuras de datos = Programas.
De arriba hacia abajo y de abajo hacia arriba
Con la abstracción y el estado ya tenemos lo necesario para hablar de cómo se diseña un programa. Hay dos estrategias, y las dos se apoyan en la misma idea de que una estructura completa puede ocupar el lugar de una caja.
La primera es de arriba hacia abajo (top-down). Se empieza por el problema completo, escrito como unos cuantos pasos generales, y cada paso se va refinando en sus propias secuencias, selecciones e iteraciones, hasta que cada caja es tan sencilla que ya se puede escribir directamente. Wirth la llamó refinamiento paso a paso, en 1971. Es la estrategia de quien sabe lo que quiere y todavía no sabe cómo hacerlo.
La segunda es de abajo hacia arriba (bottom-up). Se empieza por piezas pequeñas que ya funcionan, como sumar, ordenar una lista o guardar un archivo, y se combinan en piezas más grandes, que a su vez se combinan en otras, hasta formar el programa. Es la estrategia de quien conoce bien sus herramientas y construye con ellas.
En la práctica se usan las dos al mismo tiempo: se diseña de arriba hacia abajo hasta encontrar piezas que ya existen, y esas piezas se construyen o se reutilizan de abajo hacia arriba. El punto donde se encuentran es justamente una caja con una sola entrada y una sola salida.
Recursión
Hay una última idea que sale de la abstracción. Si «haz A» puede ser un programa entero, también puede ser el mismo programa que lo contiene. A eso se le llama recursión: resolver un problema usando una versión más pequeña del mismo problema, hasta llegar a un caso tan sencillo que se resuelve directamente, el caso base.
Por ejemplo, para subir una escalera: si quedan escalones, sube uno y después sube la escalera que queda; si ya no quedan, llegaste. La escalera que queda es otra escalera, solo que más corta, y el caso base es el último escalón. La recursión tiene el mismo poder que la iteración: todo lo que se resuelve con una se puede resolver con la otra, con un poco de estado de por medio. Así que el teorema sigue en pie.
Para concluir, y como un ejemplo básico de recursión, aquí está un repaso más compacto de esta sesión:
- Estructuras: secuencia, selección e iteración, unidas por la composición, bastan para construir cualquier programa computable.
- Abstracción: un diagrama completo se puede nombrar y usar como una sola caja.
- Flujo: el orden en que se hacen las cosas, lo que describen las estructuras.
- Estado: la información que el programa guarda; las acciones la cambian y las preguntas la consultan.
- De arriba hacia abajo: se parte del problema completo y se refina paso a paso hasta llegar a cajas sencillas.
- De abajo hacia arriba: se parte de piezas que ya funcionan y se combinan en piezas más grandes.
- Recursión: un problema se resuelve con una versión más pequeña de sí mismo, hasta llegar al caso base, como este repaso.
Estas ideas no dependen de ningún lenguaje, y es ahí donde está mi respuesta a la pregunta del principio. Con el vibe coding, la IA se ha vuelto la pieza de abajo hacia arriba más grande que hemos tenido: le pedimos una caja y nos la regresa escrita en el lenguaje que queramos. Lo que queda en nuestras manos es el diseño: saber qué cajas pedir, en qué orden, qué preguntas deciden el camino, qué se repite y qué estado se guarda. Por eso creo que un curso de programación para estos tiempos debe empezar por los principios, antes de cualquier «Hola, mundo». Los lenguajes y las herramientas van a seguir cambiando; estos principios llevan sesenta años sirviendo, y hoy sirven más que nunca.
Dicen que para entender la recursión primero hay que entender la recursión. Si algo no quedó claro, ya sabes qué hacer: vuelve a leer esta sesión desde el principio. Y si el caso base nunca llega, la falla es mía, por no haberlo escrito.