A la lliçó anterior vam acabar amb una pregunta oberta: si el processador només entén uns i zeros, com hem arribat a poder escriure print("Hola") i que funcioni? La resposta és una història de gairebé dos segles en què cada generació de programadors va construir una eina per no haver de patir el que va patir l'anterior.

Aquesta lliçó no és una llista de dates per memoritzar. És un recorregut amb propòsit: per cada fita ens preguntarem quin problema concret existia abans i què es va poder fer després que abans era impossible o insuportable. Entendre aquesta cadena té una utilitat molt pràctica: gairebé totes les decisions estranyes que trobaràs en els llenguatges moderns —per què Python indenta, per què existeixen les funcions, per què ningú no fa servir goto— són cicatrius de batalles concretes. Qui coneix la batalla entén la cicatriu.

Al final veurem la idea que unifica tot el recorregut, i que és l'única cosa que realment cal endur-se d'aquí.

1. Abans dels ordinadors: Jacquard i Ada Lovelace
2. Màquines electromecàniques i el primer «bug»
3. Llenguatge màquina i assemblador: parlar amb el processador
4. Els primers llenguatges d'alt nivell: FORTRAN, COBOL i LISP
5. La programació estructurada i la fi del goto
6. L'orientació a objectes: Smalltalk, C++ i Java
7. Llenguatges dinàmics i el web: Python, JavaScript i PHP
8. L'era actual: mòbil, núvol, open source i assistents d'IA
9. Taula cronològica i línia temporal
10. La idea clau: capes d'abstracció
11. Errors comuns i consells
12. Exercicis
13. Conclusió

La programació és anterior a l'ordinador. Això sorprèn, però és literal.

El teler de Jacquard (1804). Joseph-Marie Jacquard va construir a Lió un teler que teixia dibuixos complexos seguint les instruccions d'una sèrie de targetes perforades. On hi havia forat passava una agulla; on no, no passava. Canviant les targetes es canviava el dibuix, sense tocar la màquina.

Aquí hi ha, ja complet, el concepte fonamental de la informàtica: una mateixa màquina fa coses diferents segons les instruccions que se li donin, i aquestes instruccions són dades separades de la màquina. Un ordinador és exactament això, amb electrònica en lloc d'agulles.

• Problema que va resoldre: per canviar el dibuix d'un teixit calia reconfigurar físicament el teler, una feina de dies per a artesans molt especialitzats.
• Què va habilitar: la producció de teixits amb patrons complexos a escala industrial, i la idea de programa com una cosa intercanviable.

Ada Lovelace (1843). Charles Babbage va dissenyar la màquina analítica, un enginy mecànic de propòsit general que no es va arribar a construir mai. Ada Lovelace, matemàtica, va traduir un article sobre ella i hi va afegir unes notes pròpies que ocupaven el triple que l'original. A la cèlebre «Nota G» va descriure un procediment pas a pas perquè la màquina calculés els nombres de Bernoulli, incloent-hi la repetició d'operacions: el que avui en diríem un bucle.

Per això se la considera la primera programadora. Però la seva aportació més profunda va ser conceptual: va ser la primera persona a escriure que la màquina podria manipular qualsevol cosa que es pogués representar amb símbols, no només nombres —va esmentar explícitament la possibilitat de compondre música. És a dir, va veure que la informàtica no era una branca del càlcul, sinó una cosa molt més general. Es trigaria un segle a donar-li la raó.

Entre 1930 i 1950 arriben les primeres màquines de càlcul que realment funcionen: relés electromecànics primer, vàlvules de buit després. Noms com el Harvard Mark I, l'ENIAC o el Z3 de Konrad Zuse.

Programar aquestes màquines era una feina física. A l'ENIAC, canviar de programa significava recol·locar cables i interruptors durant dies. No hi havia codi: hi havia topologia. L'equip que feia aquesta feina estava format en gran part per dones matemàtiques —Kay McNulty, Betty Jennings, Marlyn Meltzer i altres— la tasca de les quals es va considerar durant dècades treball tècnic auxiliar i no programació.

D'aquesta època ve una anècdota que ha donat nom a mig ofici. El 1947, l'equip de Grace Hopper a Harvard va localitzar una fallada del Mark II i va descobrir que la causa era una arna atrapada entre els contactes d'un relé. La van enganxar al quadern d'incidències amb la nota «First actual case of bug being found». El terme bug per designar una fallada ja es feia servir abans en enginyeria, però aquesta és l'anècdota que el va fixar a la informàtica.

Grace Hopper va fer una cosa molt més important que trobar una arna: va defensar, contra l'opinió majoritària de la seva època, que es podien escriure programes en alguna cosa semblant a l'anglès i que un altre programa els traduís automàticament. Li van dir que els ordinadors no entenien anglès. Va construir el primer compilador el 1952 i va tirar endavant.

• Problema que va resoldre: programar exigia manipular la màquina físicament i conèixer-ne l'electrònica.
• Què va habilitar: la idea que la traducció del llenguatge humà al llenguatge de la màquina es pot automatitzar. És la porta a tot el que ve després.

Amb els ordinadors de programa emmagatzemat, el programa deixa de ser cablejat i passa a ser dades a la memòria: seqüències binàries que el processador llegeix i executa. És el llenguatge màquina que vam veure a la lliçó anterior.

Escriure directament en binari és tan penós com sona. La primera abstracció, gairebé immediata, va ser el llenguatge assemblador: donar un nom curt i memoritzable a cada instrucció del processador.

En lloc d'escriure això:

...s'escriu això:

Un programa anomenat assemblador fa la conversió, que és pràcticament un a un: cada línia d'assemblador equival a una instrucció màquina.

La millora és enorme en llegibilitat, però les limitacions continuen sent-hi:

• L'assemblador és diferent per a cada família de processadors. Un programa escrit per a un no funciona en un altre: cal reescriure'l sencer.

• Continua obligant a pensar com la màquina —registres, adreces de memòria— i no com el problema.

• Una operació que mentalment és una línia («calcula la mitjana d'aquests nombres») són desenes d'instruccions.

• Problema que va resoldre: la il·legibilitat absoluta del binari.

• Què no va resoldre: la portabilitat entre màquines i la distància entre el problema i el codi.

Els anys cinquanta porten el salt decisiu: llenguatges en què s'escriu la idea, no la instrucció del processador. N'apareixen tres, molt diferents entre si, i tots tres continuen vius d'alguna manera.

FORTRAN (1957), de John Backus a IBM. Pensat per al càlcul científic i d'enginyeria. La seva proposta era permetre escriure fórmules matemàtiques gairebé tal qual:

Ningú no creia que un traductor automàtic pogués generar codi tan eficient com el d'un bon programador d'assemblador. FORTRAN va demostrar que sí, i aquest va ser el seu veritable triomf: va convèncer la indústria que els llenguatges d'alt nivell eren viables de debò.

• Problema que va resoldre: els científics perdien mesos traduint fórmules a assemblador en lloc d'investigar.

COBOL (1959), amb Grace Hopper entre les impulsores. Orientat a la gestió empresarial: nòmines, facturació, banca. La seva aposta va ser una sintaxi verbosa, semblant a l'anglès, llegible per persones no tècniques:

Es van riure d'aquesta verbositat durant dècades. Seixanta-cinc anys després, bona part dels sistemes bancaris i d'assegurances del món continuen executant COBOL, i trobar qui el mantingui és un problema real de la indústria.

• Problema que va resoldre: les empreses necessitaven processar grans volums de dades administratives amb programes que algú pogués llegir i auditar anys després.

LISP (1958), de John McCarthy. Nascut en l'àmbit de la intel·ligència artificial, amb una idea radical: el programa i les dades tenen la mateixa forma, llistes. Això permet que un programa manipuli programes.

LISP va introduir o popularitzar idees que avui són a tot arreu: recursivitat, funcions que reben altres funcions, gestió automàtica de memòria. És l'avi del paradigma funcional que veurem, en la seva versió moderna, a la lliçó Funcions com a valors.

• Problema que va resoldre: expressar càlculs simbòlics i estructures de dades flexibles, impossibles d'encaixar en el motlle numèric de FORTRAN.

Els anys seixanta porten un problema nou i desagradable. Els programes ja són grans, i s'han tornat impossibles d'entendre.

La causa principal era la instrucció goto, que salta a qualsevol punt del programa. Feta servir sense disciplina produeix el que es va batejar com a codi espagueti: per saber com s'arriba a una línia cal rastrejar salts per tot el fitxer, i qualsevol canvi trenca alguna cosa tres pantalles més avall.

El 1968, Edsger Dijkstra va publicar una carta amb el títol «Go To Statement Considered Harmful» que va encendre el debat del qual va sortir la programació estructurada. La seva tesi: qualsevol programa es pot escriure combinant només tres estructures.

• Seqüència: una instrucció rere l'altra.
• Selecció: triar entre camins segons una condició (si...aleshores).
• Iteració: repetir mentre es compleixi alguna cosa (bucles).

Amb aquestes tres peces i funcions per agrupar codi, el goto deixa de ser necessari. ALGOL (1958-1968) va ser el laboratori d'aquestes idees i l'avantpassat sintàctic de gairebé tot el que va venir després. Pascal (1970) les va portar a l'ensenyament. C (1972), de Dennis Ritchie als Bell Labs, les va combinar amb accés de baix nivell al maquinari i es va convertir en el llenguatge amb què es van escriure Unix, Linux, Windows i, més tard, el mateix intèrpret de Python.

• Problema que va resoldre: programes de milers de línies que ningú —ni el seu autor— podia seguir ni modificar sense trencar-los.
• Herència directa: les estructures de control que estudiaràs al mòdul 3 i les funcions del mòdul 4 són exactament això.

La programació estructurada va organitzar el flux del programa. Quedava sense resoldre una altra cosa: organitzar les dades i la seva relació amb el codi que les manipula.

En un programa estructurat gran, les dades són per una banda (variables soltes) i les funcions per l'altra. Res no impedeix que una funció toqui dades que no li corresponen, i quan el programa creix ningú no sap quina part modifica què.

La programació orientada a objectes proposa empaquetar juntes les dades i les operacions que hi actuen. Un objecte «tasca» conté el seu títol, el seu responsable i la seva prioritat, i també sap com marcar-se com a completada.

• Simula 67 (Noruega) va introduir les classes i els objectes per a simulacions.

• Smalltalk (Xerox PARC, anys 70) va portar la idea a l'extrem: tot és un objecte que es comunica amb els altres mitjançant missatges. També va ser bressol de la interfície gràfica amb finestres i ratolí.

• C++ (1983, Bjarne Stroustrup) va afegir objectes a C sense renunciar al rendiment. Amb ell es va escriure una generació sencera de programari d'escriptori i videojocs.

• Java (1995, Sun Microsystems) va apostar per «escriu una vegada, executa a qualsevol lloc»: el codi es compila a un format intermedi anomenat bytecode que executa una màquina virtual present a cada sistema. Aquest mecanisme el veurem en detall a la lliçó següent. Java es va convertir en l'estàndard del programari empresarial.

• Problema que va resoldre: en programes grans, mantenir juntes les dades i el codi que les fa servir, i poder reutilitzar components sense copiar-los.

• On ho veuràs: el mòdul 7 construeix TascaFàcil amb classes i objectes.

Els anys noranta canvien les prioritats. Amb màquines cada vegada més ràpides, el recurs escàs deixa de ser el cicle de processador i passa a ser el temps de la persona que programa. I apareix internet, que exigeix construir i publicar coses molt de pressa.

Neixen així els llenguatges dinàmics: més flexibles, sense necessitat de declarar el tipus de cada dada, interpretats, amb molta cosa resolta de fàbrica.

• Python (1991, Guido van Rossum). Dissenyat explícitament per ser llegible. Obliga a indentar el codi, prohibeix la majoria de floritures i segueix el principi que hauria d'haver-hi una manera òbvia de fer cada cosa. Va començar com a llenguatge de scripts i avui domina la ciència de dades, l'automatització i la intel·ligència artificial.
• JavaScript (1995, Brendan Eich, en deu dies). Creat per donar interactivitat a les pàgines web dins del navegador. Contra tot pronòstic —i malgrat un disseny inicial ple de raresses— es va convertir en el llenguatge més utilitzat del món i avui també corre en servidors.
• PHP (1995). Pensat per generar pàgines web al servidor. Va sostenir el creixement del web dels 2000; WordPress, que mou una part enorme dels llocs del món, està escrit en PHP.

Compara el preu de mostrar un text per pantalla en tres èpoques:

Tots tres fan el mateix. La diferència no és de potència, és de quanta màquina ha de tenir al cap qui escriu.

• Problema que va resoldre: el cost en temps humà d'escriure i mantenir programari, i la necessitat d'iterar ràpid al web.

Els últims vint anys no porten una revolució de llenguatges equivalent a les anteriors, però sí que canvien radicalment el context en què es programa.

• Mòbil (2007 endavant). L'iPhone i Android creen un mercat nou. Apareixen Swift (Apple, 2014) i Kotlin (2011, oficial a Android des del 2017), llenguatges moderns que corregeixen errors de disseny heretats d'Objective-C i Java.
• El núvol. El codi deixa d'executar-se en «un ordinador» i passa a executar-se en infraestructura llogada i elàstica. Això torna crítiques habilitats que abans eren d'administració de sistemes: desplegament, contenidors, escalat.
• Open source. El codi obert passa de curiositat militant a base de la indústria: Linux, Python, PostgreSQL, Git. Avui és normal que un projecte comercial es recolzi en centenars de biblioteques escrites per desconeguts i regalades.
• Nous llenguatges amb obsessions concretes. Go (2009) prioritza la simplicitat i la concurrència; Rust (2010) elimina per disseny tota una família d'errors de memòria sense renunciar al rendiment.
• Assistents d'IA (2021 endavant). Eines capaces de generar codi a partir d'una descripció en llenguatge natural. Canvien la part mecànica de l'ofici: escriure el codi estàndard és cada vegada més barat.

Sobre aquest últim punt convé una nota sense fum, perquè afecta directament el motiu pel qual estàs fent aquest curs. Un assistent escriu codi plausible amb molta facilitat. El que no pot fer per tu és:

• Decidir què cal construir. La Marta no sap formular el seu problema en termes precisos; aquesta feina és la de l'apartat 8 de la lliçó anterior, i és humana.
• Verificar que el que s'ha generat és correcte. Per saber si un programa fa el que ha de fer cal entendre'l.
• Diagnosticar quan falla. Acceptar codi que no comprens significa quedar-te sense recursos en el moment en què deixi de funcionar.

Dit d'una altra manera: la IA ha apujat el llistó de la part mecànica i ha fet més valuosos els fonaments, no menys. És exactament el que ha passat a cada capa d'abstracció anterior.

Si et quedes amb una sola frase d'aquesta lliçó, que sigui aquesta: cada capa d'abstracció existeix perquè qui programa pensi en el problema i no en la màquina.

Mira el recorregut complet amb aquesta lent:

Cap capa no va eliminar la feina: la va desplaçar cap amunt, cap al problema. El programador de 1955 es preguntava com moure un valor entre registres. El de 2026 es pregunta si la Marta hauria de poder reassignar una tasca ja completada. És exactament la mateixa professió, resolent preguntes cada vegada més properes a la persona que té el problema.

Una conseqüència pràctica: no necessites conèixer totes les capes inferiors per treballar en la de dalt, però saber que existeixen et salva quan alguna cosa es comporta de manera inesperada. No hi ha màgia sota print("Hola"). Hi ha història.

Memoritzar dates en lloc d'entendre transicions. Ningú no et preguntarà l'any de COBOL. El que sí que importa és poder explicar per què va aparèixer: les empreses necessitaven processar dades administratives amb codi auditable. La data és una etiqueta; el problema resolt és el contingut.

Creure que el que és antic està mort. COBOL mou transaccions bancàries avui. C és sota Linux, Windows i l'intèrpret de Python que faràs servir demà. FORTRAN continua en càlcul científic. En programari, «vell» sol significar «provat durant quaranta anys».

Creure que el que és nou substitueix l'anterior. Gairebé mai no passa: s'acumula. L'orientació a objectes no va eliminar la programació estructurada, la va incorporar; en Python faràs servir les dues alhora i ni t'adonaràs del canvi.

Pensar que la història és un adorn. Quan al mòdul 3 llegeixis que cal evitar els bucles amb salts estranys, o al mòdul 8 que el codi ha de ser llegible per una altra persona, estaràs aplicant conclusions de debats concrets que pots datar. Saber-ho converteix una regla arbitrària en una decisió raonada.

Consell: quan aprenguis una construcció nova, pregunta't «què calia fer abans que això existís?». Gairebé sempre la resposta és «alguna cosa molt més pesada i propensa a errors», i és aquí on la construcció pren sentit.

Relaciona cada avenç amb el problema que va venir a resoldre, i explica en una o dues frases què passava abans:

Estudi Alba vol mostrar per pantalla el missatge Estudi Alba - TascaFacil. Descriu, sense escriure codi real, què hauria de fer un programador per aconseguir-ho en tres moments històrics: (a) programant l'ENIAC el 1946, (b) en assemblador el 1960, (c) en Python avui. Indica en cada cas quins coneixements necessitava tenir i quant de temps aproximat li portaria.

Per a cada situació, digues quina capa d'abstracció està treballant per tu i què hauries de fer manualment si no existís:

1. Escrius print("Hola") i no et preocupes de en quina posició de la pantalla es dibuixa cada lletra.
2. Crees una llista de tasques i no reserves memòria per a ella ni l'alliberes en acabar.
3. El teu programa funciona igual al portàtil del Luis (Windows) i al de la Nuria (macOS).
4. Fas servir una biblioteca per llegir un fitxer CSV en lloc d'interpretar comes i cometes tu mateix.

Solució 1.

• a) Assemblador → 2. Abans calia escriure seqüències binàries a mà, comptant bits i consultant taules de codis d'operació. Un error d'un sol bit produïa una fallada impossible de localitzar llegint el programa.
• b) FORTRAN → 4. Abans, un físic que volgués calcular una trajectòria havia de traduir cada fórmula a desenes d'instruccions de màquina, amb la qual cosa passava més temps fent de traductor que de físic.
• c) Programació estructurada → 1. Amb goto sense disciplina, saber com s'arribava a una línia exigia rastrejar salts per tot el fitxer; qualsevol modificació trencava comportaments llunyans.
• d) Orientació a objectes → 3. En un programa de cent mil línies, amb variables globals i funcions soltes, era impossible saber quina part del codi modificava quina dada.

Solució 2.

(a) ENIAC, 1946. No existeix el concepte de «mostrar text»: la sortida són targetes perforades o llums. Caldria representar cada caràcter numèricament i configurar físicament la màquina —cables i interruptors— per produir aquesta sortida. Coneixements: electrònica de la màquina concreta, matemàtiques, representació numèrica. Temps: dies, i ocupant l'ordinador sencer.

(b) Assemblador, 1960. S'escriu una seqüència d'instruccions que carrega l'adreça del text en un registre, invoca la rutina del sistema per escriure al dispositiu de sortida i controla el resultat. El text cal definir-lo caràcter a caràcter. Coneixements: joc d'instruccions d'aquell processador concret, convenis de crida al sistema. Temps: entre mitja hora i unes hores, i no serveix en una altra màquina.

(c) Python, avui. Una línia: print("Estudi Alba - TascaFacil"). Coneixements: saber que print existeix i com s'escriuen les cometes. Temps: segons.

La conclusió no és que avui siguem més llestos, sinó que la feina d'aquelles dècades està incorporada a les eines que fem servir.

Solució 3.

1. El llenguatge d'alt nivell i les biblioteques del sistema. Sense ells hauries de calcular posicions a la pantalla o enviar cada caràcter al dispositiu de sortida amb crides al sistema operatiu.
2. La gestió automàtica de memòria (el recol·lector d'escombraries de Python). Sense ella hauries de reservar memòria explícitament i alliberar-la en acabar; oblidar-ho provoca fuites de memòria, i alliberar de més provoca caigudes.
3. L'intèrpret i la biblioteca estàndard de Python, que amaguen les diferències entre sistemes operatius. Sense això caldria compilar i probablement reescriure parts del programa per a cada sistema, com passava als vuitanta.
4. L'ecosistema de biblioteques open source. Sense ell hauries d'escriure tu l'anàlisi del format CSV, incloent-hi casos molestos com comes dins de cometes o salts de línia en un camp.

La història de la programació és una sola idea repetida: cada generació va construir una capa per deixar de pensar en la màquina i pensar més en el problema. De les targetes de Jacquard al primer algorisme d'Ada Lovelace; del cablejat de l'ENIAC al compilador de Grace Hopper; del binari a l'assemblador i d'aquí a FORTRAN, COBOL i LISP; del codi espagueti a la programació estructurada; de les funcions soltes als objectes; i d'aquí als llenguatges dinàmics, el web, el núvol i els assistents actuals. Cap capa no va eliminar la feina: la va empènyer cap amunt, més a prop de les persones que tenen el problema —més a prop de la Marta i les seves notes de paper perdudes.

Aquest recorregut explica també per què avui no existeix un llenguatge de programació, sinó centenars, cadascun arrossegant les decisions de l'època i l'àmbit en què va néixer. Un llenguatge pensat per calcular trajectòries no s'assembla a un pensat per a nòmines, ni a un pensat per al navegador. I en algun moment cal triar-ne un.

A la lliçó següent, Llenguatges de programació, veurem com es classifiquen aquests centenars de llenguatges —per nivell d'abstracció, per forma d'execució, per tipatge i per paradigma—, compararem els més utilitzats avui en una taula pràctica i establirem criteris per triar l'adequat en cada cas. Acabarem justificant per què Python és l'elecció correcta per a aquest curs i per a TascaFàcil.