Los ingenieros suelen encontrarse con el presente en su forma más comprimida: un framework, una API, un servicio en la nube, una tarjeta, un modelo, un protocolo. Todo parece estar disponible ahora mismo, como si la tecnología fuera solo una sucesión de actualizaciones. History of Computer Systems enseña lo contrario. El curso muestra que la informática es acumulativa, que los entornos técnicos están estratificados y que cada generación de herramientas se apoya en decisiones científicas, industriales y políticas anteriores.
01 Por qué la historia tiene lugar en una formación de ingeniería
En DSTI seguimos una convicción de larga data en la enseñanza científica y de ingeniería: las humanidades forman parte de la formación técnica. Un buen ingeniero no solo aplica un método; sabe situarlo, reconocer sus supuestos y ver el horizonte histórico del que proviene. La historia no diluye la formación técnica: le da profundidad.
Esto vale en especial para la informática, un campo que avanza rápido pero recuerda más de lo que admite. La superficie de moda cambia; las estructuras profundas se heredan: paradigmas de programación, ideas de sistemas operativos, modelos de bases de datos, arquitecturas de red y las instituciones que las estandarizan. Las secciones siguientes trazan de forma concreta algunas de esas herencias, porque la cuestión no es que la historia sea interesante, sino que es estructural.
02 Un día de trabajo está lleno de los años setenta
Dos ideas de una sola década siguen sosteniendo casi todo lo que toca un ingeniero de software. La primera es UNIX. Iniciado en Bell Labs hacia 1969 por Ken Thompson y reescrito en el nuevo lenguaje C de Dennis Ritchie a principios de los años setenta, fijó unas pocas decisiones de diseño de una durabilidad poco común: un único sistema de archivos jerárquico, el principio de que casi todo —dispositivos, procesos, configuración— puede tratarse como un archivo, y programas pequeños compuestos mediante pipes en lugar de una sola gran aplicación. Esas decisiones están hoy en todas partes. Linux heredó el modelo; la línea BSD corre dentro de macOS e iOS; Android se asienta sobre un núcleo Linux; y la mayoría de los servidores en la nube son de tipo UNIX. El estándar POSIX existe precisamente para que esta herencia siga siendo portable entre proveedores.
La segunda es el modelo relacional. En 1970 Edgar Codd, en IBM, sostuvo que los datos debían expresarse como relaciones y consultarse describiendo lo que se quiere en vez de navegar cómo están almacenados. Los sistemas que desplazó —bases de datos jerárquicas como el IMS de IBM, y bases de datos en red— obligaban a la aplicación a recorrer cadenas de punteros a mano. La idea de Codd tardó años y dos prototipos de investigación, System R de IBM e Ingres de Berkeley, en volverse práctica; SQL desciende del primero. Perduró porque sobrevivió a un cambio de generaciones de hardware sin cambiar las preguntas que se le hacen.
Lo «nuevo» suele ser una reorganización
El giro reciente es instructivo: el movimiento NoSQL de los años 2000 cambió las relaciones y la consistencia estricta por escalabilidad, y los sistemas NewSQL que siguieron volvieron a poner, sin ruido, la interfaz relacional sobre el almacenamiento distribuido. Buena parte de ese debate repitió compromisos que los contemporáneos de Codd ya habían nombrado. Reconocer la reorganización es una habilidad práctica, no solo histórica.
03 El mainframe nunca se fue
Es tentador archivar los mainframes en la historia. Son, en cambio, el lugar donde se elaboraron por primera vez varias ideas estructurales. El System/360 de IBM, anunciado en 1964, introdujo algo más importante que cualquier máquina aislada: una familia de computadoras que compartían una misma arquitectura —un mismo conjunto de instrucciones— con independencia de cómo se construyera cada modelo en hardware. Esa separación entre arquitectura e implementación es el contrato que todo conjunto de instrucciones moderno sigue honrando, de x86 a Arm y RISC-V, y por eso el software puede sobrevivir al chip en el que corrió por primera vez.
La virtualización, hoy sustrato de la computación en la nube, no la inventó la nube; IBM ya ejecutaba máquinas virtuales completas a principios de los años setenta. Los sistemas de tiempo compartido como el CTSS del MIT y Multics, en los años sesenta, ya permitían que muchos usuarios compartieran una misma máquina con aislamiento y planificación: el ancestro directo de la nube multiinquilino. Y COBOL, estandarizado en 1959, todavía mueve una parte importante del procesamiento bancario, de seguros y gubernamental esencial del mundo. Llamar «legacy» a ese código es exacto; tratarlo como inerte no lo es. Buena parte de lo que se vende como «cloud-native» es tiempo compartido y virtualización redescubiertos, con mejores herramientas y un modelo de facturación.
04 Las redes son acuerdos, no solo cables
Un protocolo parece un artefacto técnico. Históricamente también es institucional, y ambas cosas son difíciles de separar. La conmutación de paquetes —dividir la comunicación en paquetes enrutados de forma independiente— fue propuesta a comienzos y mediados de los años sesenta por Paul Baran en RAND, que quería una red capaz de sobrevivir a una destrucción parcial, y de forma independiente por Donald Davies en el National Physical Laboratory británico, que acuñó el término. ARPANET transportó sus primeros paquetes en 1969.
El paso decisivo llegó en 1974, cuando Vinton Cerf y Robert Kahn especificaron el protocolo que se convertiría en TCP/IP, y con el principio de extremo a extremo formulado por Saltzer, Reed y Clark en 1984: mantener la red simple y empujar la inteligencia hacia los extremos. Ese principio es una decisión de ingeniería con consecuencias políticas: explica en parte por qué internet siguió abierto a aplicaciones que sus diseñadores nunca imaginaron. También lo es la cultura que lo estandarizó: el lema de trabajo del IETF, «rough consensus and running code», y la serie abierta de RFC describen una manera particular de decidir quién puede definir una red interoperable. Depurar una conexión es trabajar dentro de decisiones de gobernanza tanto como de paquetes.
05 La IA es un debate largo, no una llegada repentina
Ningún campo se describe de forma más ahistórica que la inteligencia artificial, y ninguno lo sufre más. El nombre data del taller de Dartmouth de 1956, pero la conversación es más antigua: la Cibernética de Norbert Wiener apareció en 1948, y la estadística y la optimización son aún más antiguas. El patrón, desde entonces, ha sido cíclico, no lineal.
El perceptrón de Frank Rosenblatt (1958) generó gran optimismo; Perceptrons de Minsky y Papert (1969) explicitó sus límites y se asocia con el desplome de financiación que hoy llamamos el primer «invierno de la IA». Los métodos neuronales resurgieron cuando la retropropagación se popularizó en 1986, volvieron a decaer con el colapso de los sistemas expertos a finales de los años ochenta, y se impusieron de manera decisiva solo cuando hubo suficiente potencia de cálculo y datos etiquetados para hacer funcionar las redes profundas: el momento que suele datarse en el resultado de AlexNet en ImageNet en 2012. Los sistemas de hoy son la capa más reciente de esa secuencia de esperanza, decepción y acumulación.
06 La tecnología también es historia política: el caso francés
Como la ingeniería nunca está separada de las instituciones que la financian y la estandarizan, un mismo sistema puede tomar formas muy distintas en distintos Estados. Francia es un caso de estudio de una claridad poco común, y en parte por eso tiene lugar en este curso. Tras las restricciones estadounidenses a la exportación y la absorción de la firma francesa Bull por General Electric, Francia lanzó el Plan Calcul en 1966: un programa estatal para construir una industria informática soberana, que dio origen al fabricante CII y al instituto de investigación que se convertiría en INRIA.
Dos décadas más tarde, la red Minitel puso, desde principios de los años ochenta, una terminal en línea funcional en millones de hogares franceses: un directorio, servicios y un modelo de pago, años antes de la web de consumo. Es un ejemplo de manual de estrategia nacional que de verdad tuvo éxito y creó su propia forma posterior de dependencia. Leídos en conjunto, estos episodios enseñan lo que ningún diagrama de arquitectura puede: que quién financia una tecnología, quién la estandariza y qué estructuras industriales y administrativas la rodean moldean el resultado tanto como la ingeniería misma. Ese criterio importa de forma directa cuando los egresados trabajan luego en gobernanza de datos, diseño de plataformas, ciberseguridad o despliegue de IA.
07 Por qué este curso está en el BSc
El curso da a los estudiantes el mapa anterior y el hábito de usarlo: conectar una arquitectura actual con la generación de sistemas que la sostiene, entender por qué cierto legado sobrevive y ciertos estándares perduran, y leer una tecnología nueva preguntándose qué problema resolvió primero y de qué capa anterior sigue dependiendo. Complementa la programación, los sistemas, las matemáticas y la práctica de la ingeniería en lugar de competir con ellas: el objetivo es un ingeniero con memoria técnica además de destreza técnica, capaz de reconocer la moda sin volverse cínico ante el cambio real.
En DSTI el curso lo imparte Pr Pierre Mounier-Kuhn, historiador e investigador de la informática (CNRS; Centre Roland Mousnier, Sorbonne Université), cuyo trabajo sobre la emergencia de la informática como ciencia, y sobre el caso francés en particular, forma parte de las referencias que se listan más abajo.
08 Lecturas recomendadas
Para quien quiera ir a las fuentes en lugar de fiarse del resumen:
- Pierre-Éric Mounier-Kuhn, L’Informatique en France, de la seconde guerre mondiale au Plan Calcul. L’émergence d’une science (Presses de l’Université Paris-Sorbonne, 2010) — la historia institucional de cómo la informática se constituyó en disciplina en Francia.
- Pierre-Éric Mounier-Kuhn, Mémoires vives. 50 ans d’informatique chez BNP Paribas (BNP Paribas, 2010) — cincuenta años de informática empresarial vistos desde dentro de una organización.
- Martin Campbell-Kelly & William Aspray, Computer: A History of the Information Machine — la obra de referencia en un solo volumen.
- E. F. Codd, “A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM (1970) — el artículo que sustenta toda base de datos SQL.
- D. M. Ritchie & K. Thompson, “The UNIX Time-Sharing System”, Communications of the ACM (1974) — UNIX descrito por sus autores.
- V. G. Cerf & R. E. Kahn, “A Protocol for Packet Network Intercommunication”, IEEE Transactions on Communications (1974) — el origen de TCP/IP.
- J. H. Saltzer, D. P. Reed & D. D. Clark, «End-to-End Arguments in System Design» (1984) — por qué internet mantiene la inteligencia en los extremos.
Nota editorial. Esta es una presentación editorial del curso del BSc «History of Computer Systems» y de las razones de su lugar en el plan de estudios. Los resúmenes históricos están escritos para un público de ingeniería general y simplificados en consecuencia; la redacción editorial no se atribuye al Pr Pierre Mounier-Kuhn. Las lecturas sugeridas se listan para quien desee consultar directamente las fuentes.