Casi todo el mundo ha usado un programa hoy: una alarma que suena, un mensaje que llega, un recibo que se calcula solo. Muy poca gente, en cambio, ha visto de cerca qué es exactamente un programa y por qué una máquina que no entiende nada es capaz de hacer algo útil. Esta lección responde a esa pregunta desde el principio, sin dar por supuesto ningún conocimiento previo. Al terminarla sabrás qué es una instrucción, qué diferencia hay entre el código que escribe una persona y el que ejecuta el procesador, y por qué existen los compiladores y los intérpretes.

Es la lección más importante del curso, aunque parezca la más sencilla. Programar no consiste en memorizar palabras raras: consiste en traducir una intención humana a instrucciones inequívocas. Si esa idea queda bien asentada, todo lo demás —variables, bucles, funciones, objetos— son detalles de forma. Si no queda asentada, el resto del curso se convierte en copiar símbolos sin entenderlos.

Además, aquí conocerás el caso que nos acompañará de principio a fin: Estudio Alba y su gestor de tareas TareaFácil. Todo lo que aprendamos lo aplicaremos a ese proyecto, módulo a módulo, hasta tener un programa completo.

1. Programar es traducir una intención a instrucciones
2. Instrucción, programa y código fuente
3. Hardware y software en una frase
4. Del código fuente a la ejecución: código máquina
5. Compilador frente a intérprete
6. Para qué sirve programar: automatización, resolución de problemas y escala
7. El caso del curso: Estudio Alba y su problema
8. Qué debería hacer TareaFácil
9. Primer contacto con Python: el saludo del programa
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Imagina que le pides a un compañero de trabajo: «prepara la sala para la reunión». Lo entenderá. Sabe qué es una sala, qué significa preparar y deducirá lo que falta: sillas, proyector, agua. Ha rellenado por su cuenta un montón de huecos que tú no has explicado.

Un ordenador no rellena huecos. Un ordenador hace exactamente lo que se le dice, en el orden en que se le dice, sin interpretar la intención. Si le pides que prepare la sala, no hará nada: no sabe qué es preparar. Hay que decírselo así:

1. Cuenta cuántas personas vienen.
2. Coloca ese número de sillas alrededor de la mesa.
3. Si hay presentación, enciende el proyector.
4. Pon una botella de agua por cada dos personas.

Eso, y no otra cosa, es programar: descomponer una intención humana en pasos tan precisos que una máquina que no entiende nada pueda ejecutarlos y producir el resultado esperado.

De esa definición salen las dos habilidades reales del oficio:

• Pensar con precisión: detectar los huecos que un humano rellenaría solo y taparlos. ¿Qué pasa si no viene nadie? ¿Y si vienen treinta y solo hay diez sillas?
• Expresar ese pensamiento en un lenguaje que la máquina acepte. Esta parte es la más visible —es «escribir código»— pero es la menos difícil de las dos.

Mucha gente cree que no puede programar porque no se le da bien la parte técnica. Casi siempre ocurre lo contrario: la sintaxis se aprende en semanas, y lo que cuesta años afinar es la precisión al pensar.

Conviene desmontar cuanto antes la idea de que el ordenador «sabe». No sabe nada. Sus dos virtudes son:

• Velocidad: ejecuta miles de millones de operaciones elementales por segundo.
• Obediencia literal: repite la misma instrucción un millón de veces sin cansarse, sin distraerse y sin corregirte.

Esa obediencia literal es un arma de doble filo. Si tu instrucción es correcta, la ejecutará perfectamente un millón de veces. Si es incorrecta, se equivocará perfectamente un millón de veces.

Vamos a fijar tres términos que usaremos durante todo el curso.

• Una instrucción es una orden elemental que la máquina puede ejecutar: sumar dos números, guardar un valor, mostrar un texto en pantalla, comparar dos cantidades.
• Un programa es un conjunto ordenado de instrucciones que, ejecutadas, resuelven una tarea concreta.
• El código fuente es el texto que escribe la persona programadora, en un lenguaje de programación, y que expresa ese programa de forma legible para humanos.

El código fuente se guarda en ficheros de texto normal y corriente. Un fichero de Python es un fichero de texto con extensión .py: se puede abrir con cualquier editor y leerlo. No tiene nada mágico dentro.

Para lo que necesitamos ahora basta con una distinción muy corta:

• El hardware es la parte física: procesador, memoria, disco, pantalla, teclado.
• El software es el conjunto de instrucciones que le dicen al hardware qué hacer.

El hardware sin software es un objeto caro que se calienta. El software sin hardware es un texto. Programar consiste en escribir software; el hardware lo pone el ordenador.

Aquí aparece la primera pieza que sorprende a quien empieza. El procesador no entiende Python. Tampoco entiende Java, ni C, ni ningún lenguaje pensado para humanos. El procesador solo entiende código máquina: secuencias de números binarios (unos y ceros) que representan operaciones muy elementales.

Un fragmento de código máquina, escrito tal cual, tiene este aspecto:

Nadie escribe software moderno así, por razones evidentes: es ilegible, específico de cada modelo de procesador y prácticamente imposible de corregir. Por eso se inventaron los lenguajes de programación de alto nivel, que permiten escribir esto:

...y dejar que otro programa se encargue de convertirlo en las secuencias binarias correspondientes. Ese «otro programa» es un traductor, y hay dos familias: los compiladores y los intérpretes.

Ambos resuelven el mismo problema —pasar del código fuente a algo que el procesador ejecute— pero con estrategias distintas.

• Un compilador traduce todo el código fuente de una vez, antes de ejecutarlo, y produce un fichero ejecutable en código máquina. Luego ese ejecutable se lanza cuando se quiera, sin volver a traducir. Es el modelo de C o de Rust.
• Un intérprete lee el código fuente y lo va ejecutando sobre la marcha, instrucción a instrucción, sin generar un ejecutable independiente. Es el modelo de Python.

Este es el recorrido de ambos casos:

Las consecuencias prácticas para quien aprende son estas:

Para aprender, un lenguaje interpretado es cómodo: escribes una línea, la ejecutas y ves el resultado en dos segundos. Ese ciclo corto es oro cuando estás empezando, y es una de las razones por las que este curso usa Python. La comparación completa entre lenguajes, con sus máquinas virtuales y sus casos intermedios, la veremos en la lección Lenguajes de programación.

Hay tres motivos por los que a una organización le compensa que alguien programe.

Automatización. Cualquier tarea repetitiva y con reglas claras puede pasar de hacerse a mano a hacerse sola. Renombrar 400 ficheros, enviar el mismo aviso a 50 clientes, comprobar cada mañana si un servidor responde. El ordenador no se aburre y no se salta el fichero 217.

Resolución de problemas. Programar obliga a definir el problema con precisión, y muchas veces esa definición es ya media solución. Al escribir el programa descubres reglas que nadie había explicitado: ¿qué pasa si dos tareas tienen la misma prioridad? ¿Puede una tarea no tener responsable? Esas preguntas mejoran el proceso aunque el programa no llegue a escribirse.

Escala. Un procedimiento manual que funciona con 10 elementos suele romperse con 10.000. Un programa correcto trata 10.000 elementos con el mismo esfuerzo humano que 10: el coste está en escribirlo una vez, no en ejecutarlo muchas.

Fíjate en la segunda fila: que un programa se equivoque siempre igual es una ventaja, no un defecto. Un error reproducible se puede localizar y arreglar. Un error humano aleatorio, no.

Estudio Alba es un pequeño estudio de diseño gráfico ficticio. Lo forman tres personas:

• Marta, coordinadora. Reparte el trabajo y habla con los clientes.
• Luis, diseñador. Se ocupa sobre todo de identidad visual.
• Nuria, diseñadora. Lleva maquetación y materiales impresos.

Su forma actual de organizarse es esta: Marta apunta cada encargo en una nota de papel y la deja sobre la mesa de quien corresponda. Funcionó bien el primer año. Ahora no:

• Las notas se pierden. Un encargo de un cliente desapareció bajo un montón de pruebas de color y se entregó con nueve días de retraso.
• Nadie sabe qué tiene el otro. Marta pregunta en voz alta «¿tú cómo vas?» varias veces al día e interrumpe el trabajo de todos.
• No hay prioridades explícitas. Todas las notas parecen igual de urgentes porque están escritas en el mismo papel amarillo.
• No queda historial. Cuando un cliente pregunta qué se hizo en marzo, nadie puede responder.

Marta ha decidido que quiere un programa que resuelva esto. No quiere una herramienta comercial cara y llena de opciones que no usarán: quiere algo pequeño, propio y exactamente adaptado a cómo trabajan. Ese programa se llamará TareaFácil y es lo que vamos a construir a lo largo del curso.

Fíjate en un detalle importante: el problema de Estudio Alba no es un problema informático. Es un problema de organización. La programación es solo la herramienta con la que lo vamos a atacar. Esto es lo normal en el mundo real: el software casi nunca es un fin, es un medio.

Antes de escribir nada, conviene poner por escrito qué esperamos del programa. Esto se llama definir los requisitos y es el paso que más gente se salta, con resultados predecibles.

Después de hablar con Marta, Luis y Nuria, la lista queda así:

Cada tarea de TareaFácil tendrá, por tanto, cinco datos:

• Título: una frase corta. Ejemplo: «Diseñar logotipo para Panadería Solé».
• Descripción: el detalle. Ejemplo: «Tres propuestas en blanco y negro, formato vectorial».
• Responsable: Marta, Luis o Nuria.
• Prioridad: alta, media o baja.
• Estado: pendiente o completada.

No vamos a implementar nada de esto todavía. Guardar datos entre ejecuciones (R6), por ejemplo, es cosa de la lección Guardar datos en archivos, al final del módulo 5. Lo que sí conviene es tener la lista delante: cada módulo del curso irá tachando requisitos.

Ya podemos escribir nuestra primera línea de código real. Va a ser modesta —mostrar un texto en pantalla— pero es un programa completo y funcional.

En Python, la instrucción para mostrar algo en pantalla es print:

Desmenucemos esa línea, porque cada símbolo cuenta:

• print es el nombre de la instrucción. Significa «muestra en pantalla». Se escribe en minúsculas: Print o PRINT darían error, porque Python distingue mayúsculas de minúsculas.
• Los paréntesis ( y ) encierran aquello que queremos mostrar. Siempre tienen que estar los dos, uno de apertura y otro de cierre.
• Las comillas " marcan el principio y el final de un texto. Todo lo que va entre comillas se muestra tal cual, sin que Python intente interpretarlo. También tienen que estar las dos.

Si ejecutamos ese fichero, en la pantalla aparece exactamente:

Ni comillas, ni paréntesis, ni la palabra print. Solo el texto. Las comillas le dicen a Python dónde empieza y acaba el texto, pero no forman parte de él.

Un programa puede tener varias instrucciones, una por línea, y se ejecutan en orden, de arriba abajo. Esto es una pantalla de bienvenida completa para TareaFácil:

Y esto es lo que sale por pantalla:

Tres observaciones sobre este ejemplo:

1. El orden importa. Si movieras la primera línea al final, la línea de = aparecería abajo. Python no reordena nada por su cuenta.
2. Los espacios dentro de las comillas se respetan. Por eso " TareaFacil v0.1" aparece indentado: esos dos espacios están dentro del texto.
3. print("") con comillas vacías muestra una línea en blanco. Es la forma habitual de separar bloques visualmente.

Ese es, literalmente, un programa. Hace poco, pero es un programa completo: tiene instrucciones, un orden y un resultado observable. Cómo escribirlo en un fichero y ejecutarlo en tu propio ordenador lo verás en la lección Entornos de desarrollo.

Creer que hay que saber matemáticas avanzadas. Para la inmensa mayoría del software profesional basta con sumar, restar, comparar y razonar con lógica. Lo que sí hace falta es tolerancia a la frustración: pasarás mucho tiempo con programas que no funcionan, y eso es normal, no una señal de que no vales.

Olvidar cerrar comillas o paréntesis. Es el error número uno de la primera semana. print("Hola) no funciona porque el texto nunca se cierra; print("Hola" tampoco, porque falta el paréntesis. Consejo: escribe siempre los dos símbolos seguidos —() y ""— y luego coloca el contenido en medio.

Escribir Print en vez de print. Python distingue mayúsculas de minúsculas: print, Print y PRINT son tres nombres distintos y solo el primero existe. Lo mismo pasará con los nombres que tú inventes más adelante.

Confundir «no entiendo el código» con «no entiendo el problema». Cuando te atasques, pregúntate primero si sabrías resolverlo a mano, con papel. Si la respuesta es no, el problema no es Python. Vuelve al enunciado antes de tocar el teclado.

Querer escribir el programa entero a la primera. Nadie lo hace. El software se construye por capas: algo mínimo que funcione, y encima otra cosa. TareaFácil empieza siendo ocho print y acabará siendo un programa completo, pero el camino son decenas de versiones intermedias.

Consejo de método: escribe el resultado esperado antes de ejecutar. Antes de lanzar un programa, apunta en un papel qué crees que va a salir por pantalla. Si acierta, has entendido. Si falla, acabas de descubrir un hueco en tu modelo mental, que es exactamente lo que buscabas.

Escribe, en español y en forma de lista numerada, las instrucciones que seguiría una máquina para preparar una taza de té. La máquina no sabe nada: no sabe qué es una taza, pero sí puede coger, verter, esperar y comprobar. Sé tan preciso que no quede ningún hueco por rellenar. Después, señala al menos dos huecos que un humano rellenaría solo y tú has tenido que explicitar.

Para cada situación, indica si describe un lenguaje compilado o uno interpretado, y justifica la respuesta en una frase:

1. Cambias una línea del programa y lo vuelves a lanzar de inmediato, sin ningún paso intermedio.
2. Entregas al cliente un único fichero ejecutable; el cliente no recibe tu código.
3. El programa se detiene con un error justo al llegar a la línea 80, tras haber ejecutado correctamente las 79 anteriores.
4. Antes de poder probar nada, esperas 40 segundos a que termine un proceso de traducción.

Escribe un programa Python usando solo print que muestre exactamente esto por pantalla:

Fíjate en la línea en blanco antes de la última línea: tiene que estar.

Solución 1.

Una versión suficientemente precisa sería:

1. Comprueba si hay agua en el hervidor. Si no hay, llena el hervidor con 250 ml de agua.
2. Enciende el hervidor.
3. Espera hasta que el agua alcance los 95 grados.
4. Coge una taza vacía y colócala sobre la encimera.
5. Coge una bolsita de té y déjala dentro de la taza.
6. Vierte el agua del hervidor en la taza hasta 1 cm por debajo del borde.
7. Espera 3 minutos.
8. Saca la bolsita de la taza y tírala a la basura.
9. Apaga el hervidor.

Huecos que un humano rellenaría solo y hemos tenido que explicitar:

• La cantidad de agua y la temperatura. Un humano entiende «agua caliente»; una máquina necesita 250 ml y 95 grados.
• El tiempo de reposo. «Deja reposar» no es una instrucción: 3 minutos sí lo es.
• Que la taza esté vacía y en su sitio. Nadie diría en voz alta «coge una taza vacía», pero la máquina podría coger una llena.
• Qué hacer con la bolsita al final. Si no lo dices, se queda dentro.

Bonus: falta una comprobación. ¿Y si no queda ninguna bolsita de té? Un programa robusto tendría que decidir qué hacer en ese caso. Esto se llama tratar los casos excepcionales y lo trabajaremos en el módulo 8.

Solución 2.

1. Interpretado. No hay paso de traducción previo: el intérprete lee el código y lo ejecuta en el momento.
2. Compilado. Se ha generado un ejecutable en código máquina, independiente del código fuente, y es lo único que se distribuye.
3. Interpretado. El error aparece al llegar a la línea 80, lo que indica que las líneas se van procesando durante la ejecución y no se revisaron todas antes.
4. Compilado. Esos 40 segundos son el compilador traduciendo todo el programa antes de que nada se ejecute.

Solución 3.

Puntos donde suele fallar:

• Olvidar el print("") de la línea en blanco. Sin él, las dos últimas líneas salen pegadas.
• Escribir print(### TareaFacil ###) sin comillas. Python intentaría interpretar esos símbolos como código y daría error: todo texto literal va entre comillas.
• Usar seis líneas de contenido pero en otro orden. Recuerda: se ejecutan de arriba abajo, exactamente como están escritas.

Programar es traducir una intención humana a instrucciones tan precisas que una máquina obediente y rápida, pero que no entiende nada, pueda ejecutarlas. Ese texto preciso es el código fuente; el procesador, en cambio, solo entiende código máquina, y entre ambos hay siempre un traductor: un compilador, que traduce todo de golpe antes de ejecutar, o un intérprete, que va leyendo y ejecutando sobre la marcha, como hace Python.

Programamos por tres razones: para automatizar lo repetitivo, para resolver problemas obligándonos a definirlos con precisión y para escalar, pagando el esfuerzo una vez y ejecutándolo muchas. Las tres se ven en el caso que nos acompañará todo el curso: Estudio Alba pierde notas de papel y necesita TareaFácil, cuyos seis requisitos ya tenemos por escrito. Y hemos escrito nuestro primer programa real: unos cuantos print que dibujan la pantalla de bienvenida.

Ahora bien, nada de esto apareció de golpe. Los lenguajes que hoy nos permiten escribir print("Hola") en lugar de secuencias de unos y ceros son el resultado de casi dos siglos de intentos, fracasos y buenas ideas acumuladas. En la siguiente lección, Historia de la programación, recorreremos ese camino: no como una lista de fechas, sino entendiendo qué problema concreto resolvió cada etapa y por qué el oficio es hoy como es.