En la lección anterior terminamos con una pregunta abierta: si el procesador solo entiende unos y ceros, ¿cómo hemos llegado a poder escribir print("Hola") y que funcione? La respuesta es una historia de casi dos siglos en la que cada generación de programadores construyó una herramienta para no tener que sufrir lo que sufrió la anterior.

Esta lección no es una lista de fechas que memorizar. Es un recorrido con propósito: por cada hito nos preguntaremos qué problema concreto existía antes y qué se pudo hacer después que antes era imposible o insoportable. Entender esa cadena tiene una utilidad muy práctica: casi todas las decisiones raras que encontrarás en los lenguajes modernos —por qué Python indenta, por qué existen las funciones, por qué nadie usa goto— son cicatrices de batallas concretas. Quien conoce la batalla entiende la cicatriz.

Al final veremos la idea que unifica todo el recorrido, y que es lo único que realmente hay que llevarse de aquí.

1. Antes de los ordenadores: Jacquard y Ada Lovelace
2. Máquinas electromecánicas y el primer «bug»
3. Lenguaje máquina y ensamblador: hablar con el procesador
4. Los primeros lenguajes de alto nivel: FORTRAN, COBOL y LISP
5. La programación estructurada y el fin del goto
6. La orientación a objetos: Smalltalk, C++ y Java
7. Lenguajes dinámicos y la web: Python, JavaScript y PHP
8. La era actual: móvil, nube, open source y asistentes de IA
9. Tabla cronológica y línea temporal
10. La idea clave: capas de abstracción
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

La programación es anterior al ordenador. Eso sorprende, pero es literal.

El telar de Jacquard (1804). Joseph-Marie Jacquard construyó en Lyon un telar que tejía dibujos complejos siguiendo las instrucciones de una serie de tarjetas perforadas. Donde había agujero pasaba una aguja; donde no, no pasaba. Cambiando las tarjetas se cambiaba el dibujo, sin tocar la máquina.

Ahí está, ya completo, el concepto fundamental de la informática: una misma máquina hace cosas distintas según las instrucciones que se le den, y esas instrucciones son datos separados de la máquina. Un ordenador es exactamente eso, con electrónica en lugar de agujas.

• Problema que resolvió: para cambiar el dibujo de un tejido había que reconfigurar físicamente el telar, un trabajo de días para artesanos muy especializados.
• Qué habilitó: la producción de tejidos con patrones complejos a escala industrial, y la idea de programa como algo intercambiable.

Ada Lovelace (1843). Charles Babbage diseñó la máquina analítica, un ingenio mecánico de propósito general que nunca llegó a construirse. Ada Lovelace, matemática, tradujo un artículo sobre ella y añadió unas notas propias que ocupaban el triple que el original. En la célebre «Nota G» describió un procedimiento paso a paso para que la máquina calculara los números de Bernoulli, incluyendo la repetición de operaciones: lo que hoy llamaríamos un bucle.

Por eso se la considera la primera programadora. Pero su aportación más profunda fue conceptual: fue la primera persona en escribir que la máquina podría manipular cualquier cosa que pudiera representarse con símbolos, no solo números —mencionó explícitamente la posibilidad de componer música. Es decir, vio que la informática no era una rama del cálculo, sino algo mucho más general. Tardaría un siglo en dársele la razón.

Entre 1930 y 1950 llegan las primeras máquinas de cálculo que realmente funcionan: relés electromecánicos primero, válvulas de vacío después. Nombres como el Harvard Mark I, el ENIAC o el Z3 de Konrad Zuse.

Programar esas máquinas era un trabajo físico. En el ENIAC, cambiar de programa significaba recolocar cables e interruptores durante días. No había código: había topología. El equipo que hacía ese trabajo estaba formado en gran parte por mujeres matemáticas —Kay McNulty, Betty Jennings, Marlyn Meltzer y otras— cuya labor se consideró durante décadas trabajo técnico auxiliar y no programación.

De esta época viene una anécdota que ha dado nombre a medio oficio. En 1947, el equipo de Grace Hopper en Harvard localizó un fallo del Mark II y descubrió que la causa era una polilla atrapada entre los contactos de un relé. La pegaron en el cuaderno de incidencias con la nota «First actual case of bug being found». El término bug para designar un fallo ya se usaba antes en ingeniería, pero esta es la anécdota que lo fijó en la informática.

Grace Hopper hizo algo mucho más importante que encontrar una polilla: defendió, contra la opinión mayoritaria de su época, que se podía escribir programas en algo parecido al inglés y que otro programa los tradujera automáticamente. Le dijeron que los ordenadores no entendían inglés. Construyó el primer compilador en 1952 y siguió adelante.

• Problema que resolvió: programar exigía manipular la máquina físicamente y conocer su electrónica.
• Qué habilitó: la idea de que la traducción del lenguaje humano al lenguaje de la máquina puede automatizarse. Es la puerta a todo lo que viene después.

Con los ordenadores de programa almacenado, el programa deja de ser cableado y pasa a ser datos en memoria: secuencias binarias que el procesador lee y ejecuta. Es el lenguaje máquina que vimos en la lección anterior.

Escribir directamente en binario es tan penoso como suena. La primera abstracción, casi inmediata, fue el lenguaje ensamblador: dar un nombre corto y memorizable a cada instrucción del procesador.

En lugar de escribir esto:

...se escribe esto:

Un programa llamado ensamblador hace la conversión, que es prácticamente uno a uno: cada línea de ensamblador equivale a una instrucción máquina.

La mejora es enorme en legibilidad, pero las limitaciones siguen ahí:

• El ensamblador es distinto para cada familia de procesadores. Un programa escrito para uno no funciona en otro: hay que reescribirlo entero.

• Sigue obligando a pensar como la máquina —registros, direcciones de memoria— y no como el problema.

• Una operación que mentalmente es una línea («calcula la media de estos números») son decenas de instrucciones.

• Problema que resolvió: la ilegibilidad absoluta del binario.

• Qué no resolvió: la portabilidad entre máquinas y la distancia entre el problema y el código.

Los años cincuenta traen el salto decisivo: lenguajes en los que se escribe la idea, no la instrucción del procesador. Aparecen tres, muy distintos entre sí, y los tres siguen vivos de alguna forma.

FORTRAN (1957), de John Backus en IBM. Pensado para cálculo científico y de ingeniería. Su propuesta era permitir escribir fórmulas matemáticas casi tal cual:

Nadie creía que un traductor automático pudiera generar código tan eficiente como el de un buen programador de ensamblador. FORTRAN demostró que sí, y ese fue su verdadero triunfo: convenció a la industria de que los lenguajes de alto nivel eran viables en serio.

• Problema que resolvió: los científicos perdían meses traduciendo fórmulas a ensamblador en lugar de investigar.

COBOL (1959), con Grace Hopper entre sus impulsoras. Orientado a la gestión empresarial: nóminas, facturación, banca. Su apuesta fue una sintaxis verbosa, parecida al inglés, legible por personas no técnicas:

Se rieron de esa verbosidad durante décadas. Sesenta y cinco años después, buena parte de los sistemas bancarios y de seguros del mundo siguen ejecutando COBOL, y encontrar quien lo mantenga es un problema real de la industria.

• Problema que resolvió: las empresas necesitaban procesar grandes volúmenes de datos administrativos con programas que alguien pudiera leer y auditar años después.

LISP (1958), de John McCarthy. Nacido en el ámbito de la inteligencia artificial, con una idea radical: el programa y los datos tienen la misma forma, listas. Eso permite que un programa manipule programas.

LISP introdujo o popularizó ideas que hoy están en todas partes: recursión, funciones que reciben otras funciones, gestión automática de memoria. Es el abuelo del paradigma funcional que veremos, en su versión moderna, en la lección Funciones como valores.

• Problema que resolvió: expresar cómputos simbólicos y estructuras de datos flexibles, imposibles de encajar en el molde numérico de FORTRAN.

Los años sesenta traen un problema nuevo y desagradable. Los programas ya son grandes, y se han vuelto imposibles de entender.

La causa principal era la instrucción goto, que salta a cualquier punto del programa. Usada sin disciplina produce lo que se bautizó como código espagueti: para saber cómo se llega a una línea hay que rastrear saltos por todo el fichero, y cualquier cambio rompe algo tres pantallas más abajo.

En 1968, Edsger Dijkstra publicó una carta con el título «Go To Statement Considered Harmful» que encendió el debate del que salió la programación estructurada. Su tesis: cualquier programa puede escribirse combinando solo tres estructuras.

• Secuencia: una instrucción tras otra.
• Selección: elegir entre caminos según una condición (si...entonces).
• Iteración: repetir mientras se cumpla algo (bucles).

Con esas tres piezas y funciones para agrupar código, el goto deja de ser necesario. ALGOL (1958-1968) fue el laboratorio de estas ideas y el antepasado sintáctico de casi todo lo que vino después. Pascal (1970) las llevó a la enseñanza. C (1972), de Dennis Ritchie en los Bell Labs, las combinó con acceso de bajo nivel al hardware y se convirtió en el lenguaje con el que se escribieron Unix, Linux, Windows y, más tarde, el propio intérprete de Python.

• Problema que resolvió: programas de miles de líneas que nadie —ni su autor— podía seguir ni modificar sin romperlos.
• Herencia directa: las estructuras de control que estudiarás en el módulo 3 y las funciones del módulo 4 son exactamente esto.

La programación estructurada organizó el flujo del programa. Quedaba sin resolver otra cosa: organizar los datos y su relación con el código que los manipula.

En un programa estructurado grande, los datos están por un lado (variables sueltas) y las funciones por otro. Nada impide que una función toque datos que no le corresponden, y cuando el programa crece nadie sabe qué parte modifica qué.

La programación orientada a objetos propone empaquetar juntos los datos y las operaciones que actúan sobre ellos. Un objeto «tarea» contiene su título, su responsable y su prioridad, y también sabe cómo marcarse como completada.

• Simula 67 (Noruega) introdujo las clases y los objetos para simulaciones.

• Smalltalk (Xerox PARC, años 70) llevó la idea al extremo: todo es un objeto que se comunica con otros mediante mensajes. También fue cuna de la interfaz gráfica con ventanas y ratón.

• C++ (1983, Bjarne Stroustrup) añadió objetos a C sin renunciar al rendimiento. Con él se escribió una generación entera de software de escritorio y videojuegos.

• Java (1995, Sun Microsystems) apostó por «escribe una vez, ejecuta en cualquier parte»: el código se compila a un formato intermedio llamado bytecode que ejecuta una máquina virtual presente en cada sistema. Ese mecanismo lo veremos en detalle en la próxima lección. Java se convirtió en el estándar del software empresarial.

• Problema que resolvió: en programas grandes, mantener juntos los datos y el código que los usa, y poder reutilizar componentes sin copiarlos.

• Dónde lo verás: el módulo 7 construye TareaFácil con clases y objetos.

Los años noventa cambian las prioridades. Con máquinas cada vez más rápidas, el recurso escaso deja de ser el ciclo de procesador y pasa a ser el tiempo de la persona que programa. Y aparece internet, que exige construir y publicar cosas muy rápido.

Nacen así los lenguajes dinámicos: más flexibles, sin necesidad de declarar el tipo de cada dato, interpretados, con mucho resuelto de fábrica.

• Python (1991, Guido van Rossum). Diseñado explícitamente para ser legible. Obliga a indentar el código, prohíbe la mayoría de florituras y sigue el principio de que debería haber una forma obvia de hacer cada cosa. Empezó como lenguaje de scripts y hoy domina la ciencia de datos, la automatización y la inteligencia artificial.
• JavaScript (1995, Brendan Eich, en diez días). Creado para dar interactividad a las páginas web dentro del navegador. Contra todo pronóstico —y pese a un diseño inicial lleno de rarezas— se convirtió en el lenguaje más usado del mundo y hoy corre también en servidores.
• PHP (1995). Pensado para generar páginas web en el servidor. Sostuvo el crecimiento de la web de los 2000; WordPress, que mueve una parte enorme de los sitios del mundo, está escrito en PHP.

Compara el precio de mostrar un texto en pantalla en tres épocas:

Las tres hacen lo mismo. La diferencia no es de potencia, es de cuánta máquina tiene que tener en la cabeza quien escribe.

• Problema que resolvió: el coste en tiempo humano de escribir y mantener software, y la necesidad de iterar rápido en la web.

Los últimos veinte años no traen una revolución de lenguajes equivalente a las anteriores, pero sí cambian radicalmente el contexto en que se programa.

• Móvil (2007 en adelante). El iPhone y Android crean un mercado nuevo. Aparecen Swift (Apple, 2014) y Kotlin (2011, oficial en Android desde 2017), lenguajes modernos que corrigen errores de diseño heredados de Objective-C y Java.
• La nube. El código deja de ejecutarse en «un ordenador» y pasa a ejecutarse en infraestructura alquilada y elástica. Eso vuelve críticas habilidades que antes eran de administración de sistemas: despliegue, contenedores, escalado.
• Open source. El código abierto pasa de curiosidad militante a base de la industria: Linux, Python, PostgreSQL, Git. Hoy es normal que un proyecto comercial se apoye en cientos de bibliotecas escritas por desconocidos y regaladas.
• Nuevos lenguajes con obsesiones concretas. Go (2009) prioriza la simplicidad y la concurrencia; Rust (2010) elimina por diseño toda una familia de errores de memoria sin renunciar al rendimiento.
• Asistentes de IA (2021 en adelante). Herramientas capaces de generar código a partir de una descripción en lenguaje natural. Cambian la parte mecánica del oficio: escribir el código estándar es cada vez más barato.

Sobre esto último conviene una nota sin humo, porque afecta directamente a por qué estás haciendo este curso. Un asistente escribe código plausible con mucha facilidad. Lo que no puede hacer por ti es:

• Decidir qué hay que construir. Marta no sabe formular su problema en términos precisos; ese trabajo es el del apartado 8 de la lección anterior, y es humano.
• Verificar que lo generado es correcto. Para saber si un programa hace lo que debe hay que entenderlo.
• Diagnosticar cuando falla. Aceptar código que no comprendes significa quedarte sin recursos en el momento en que deje de funcionar.

Dicho de otro modo: la IA ha subido el listón de la parte mecánica y ha hecho más valiosos los fundamentos, no menos. Es exactamente lo que ha pasado en cada capa de abstracción anterior.

Si te quedas con una sola frase de esta lección, que sea esta: cada capa de abstracción existe para que quien programa piense en el problema y no en la máquina.

Mira el recorrido completo con esa lente:

Ninguna capa eliminó el trabajo: lo desplazó hacia arriba, hacia el problema. El programador de 1955 se preguntaba cómo mover un valor entre registros. El de 2026 se pregunta si Marta debería poder reasignar una tarea ya completada. Es exactamente la misma profesión, resolviendo preguntas cada vez más cercanas a la persona que tiene el problema.

Una consecuencia práctica: no necesitas conocer todas las capas inferiores para trabajar en la de arriba, pero saber que existen te salva cuando algo se comporta de forma inesperada. No hay magia debajo de print("Hola"). Hay historia.

Memorizar fechas en lugar de entender transiciones. Nadie te va a preguntar el año de COBOL. Lo que sí importa es poder explicar por qué apareció: las empresas necesitaban procesar datos administrativos con código auditable. La fecha es una etiqueta; el problema resuelto es el contenido.

Creer que lo antiguo está muerto. COBOL mueve transacciones bancarias hoy. C está bajo Linux, Windows y el intérprete de Python que usarás mañana. FORTRAN sigue en cálculo científico. En software, «viejo» suele significar «probado durante cuarenta años».

Creer que lo nuevo sustituye a lo anterior. Casi nunca ocurre: se acumula. La orientación a objetos no eliminó la programación estructurada, la incorporó; en Python usarás las dos a la vez y ni te darás cuenta del cambio.

Pensar que la historia es adorno. Cuando en el módulo 3 leas que hay que evitar los bucles con saltos raros, o en el módulo 8 que el código debe ser legible por otra persona, estarás aplicando conclusiones de debates concretos que puedes datar. Saberlo convierte una regla arbitraria en una decisión razonada.

Consejo: cuando aprendas una construcción nueva, pregúntate «¿qué había que hacer antes de que esto existiera?». Casi siempre la respuesta es «algo mucho más pesado y propenso a errores», y ahí es donde la construcción cobra sentido.

Relaciona cada avance con el problema que vino a resolver, y explica en una o dos frases qué pasaba antes:

Estudio Alba quiere mostrar por pantalla el mensaje Estudio Alba - TareaFacil. Describe, sin escribir código real, qué tendría que hacer un programador para conseguirlo en tres momentos históricos: (a) programando el ENIAC en 1946, (b) en ensamblador en 1960, (c) en Python hoy. Indica en cada caso qué conocimientos necesitaba tener y cuánto tiempo aproximado le llevaría.

Para cada situación, di qué capa de abstracción está trabajando por ti y qué tendrías que hacer manualmente si no existiera:

1. Escribes print("Hola") y no te preocupas de en qué posición de la pantalla se dibuja cada letra.
2. Creas una lista de tareas y no reservas memoria para ella ni la liberas al terminar.
3. Tu programa funciona igual en el portátil de Luis (Windows) y en el de Nuria (macOS).
4. Usas una biblioteca para leer un fichero CSV en lugar de interpretar comas y comillas tú mismo.

Solución 1.

• a) Ensamblador → 2. Antes había que escribir secuencias binarias a mano, contando bits y consultando tablas de códigos de operación. Un error de un solo bit producía un fallo imposible de localizar leyendo el programa.
• b) FORTRAN → 4. Antes, un físico que quisiera calcular una trayectoria debía traducir cada fórmula a decenas de instrucciones de máquina, con lo que pasaba más tiempo haciendo de traductor que de físico.
• c) Programación estructurada → 1. Con goto sin disciplina, saber cómo se llegaba a una línea exigía rastrear saltos por todo el fichero; cualquier modificación rompía comportamientos lejanos.
• d) Orientación a objetos → 3. En un programa de cien mil líneas, con variables globales y funciones sueltas, era imposible saber qué parte del código modificaba qué dato.

Solución 2.

(a) ENIAC, 1946. No existe el concepto de «mostrar texto»: la salida son tarjetas perforadas o luces. Habría que representar cada carácter numéricamente y configurar físicamente la máquina —cables e interruptores— para producir esa salida. Conocimientos: electrónica de la máquina concreta, matemáticas, representación numérica. Tiempo: días, y ocupando el ordenador entero.

(b) Ensamblador, 1960. Se escribe una secuencia de instrucciones que carga la dirección del texto en un registro, invoca la rutina del sistema para escribir en el dispositivo de salida y controla el resultado. El texto hay que definirlo carácter a carácter. Conocimientos: juego de instrucciones de ese procesador concreto, convenios de llamada al sistema. Tiempo: entre media hora y unas horas, y no sirve en otra máquina.

(c) Python, hoy. Una línea: print("Estudio Alba - TareaFacil"). Conocimientos: saber que print existe y cómo se escriben las comillas. Tiempo: segundos.

La conclusión no es que hoy seamos más listos, sino que el trabajo de aquellas décadas está incorporado en las herramientas que usamos.

Solución 3.

1. El lenguaje de alto nivel y las bibliotecas del sistema. Sin ellos tendrías que calcular posiciones en pantalla o enviar cada carácter al dispositivo de salida con llamadas al sistema operativo.
2. La gestión automática de memoria (el recolector de basura de Python). Sin ella tendrías que reservar memoria explícitamente y liberarla al terminar; olvidarlo provoca fugas de memoria, y liberar de más provoca caídas.
3. El intérprete y la biblioteca estándar de Python, que ocultan las diferencias entre sistemas operativos. Sin eso habría que compilar y probablemente reescribir partes del programa para cada sistema, como pasaba en los ochenta.
4. El ecosistema de bibliotecas open source. Sin él tendrías que escribir tú el análisis del formato CSV, incluyendo casos molestos como comas dentro de comillas o saltos de línea en un campo.

La historia de la programación es una sola idea repetida: cada generación construyó una capa para dejar de pensar en la máquina y pensar más en el problema. De las tarjetas de Jacquard al primer algoritmo de Ada Lovelace; del cableado del ENIAC al compilador de Grace Hopper; del binario al ensamblador y de ahí a FORTRAN, COBOL y LISP; del código espagueti a la programación estructurada; de las funciones sueltas a los objetos; y de ahí a los lenguajes dinámicos, la web, la nube y los asistentes actuales. Ninguna capa eliminó el trabajo: lo empujó hacia arriba, más cerca de las personas que tienen el problema —más cerca de Marta y sus notas de papel perdidas.

Ese recorrido explica también por qué hoy no existe un lenguaje de programación, sino cientos, cada uno arrastrando las decisiones de la época y el ámbito en que nació. Un lenguaje pensado para calcular trayectorias no se parece a uno pensado para nóminas, ni a uno pensado para el navegador. Y en algún momento hay que elegir uno.

En la siguiente lección, Lenguajes de programación, veremos cómo se clasifican esos cientos de lenguajes —por nivel de abstracción, por forma de ejecución, por tipado y por paradigma—, compararemos los más usados hoy en una tabla práctica y estableceremos criterios para elegir el adecuado en cada caso. Terminaremos justificando por qué Python es la elección correcta para este curso y para TareaFácil.