Descubre cómo la idea del programa almacenado—a menudo vinculada a John von Neumann—permitió el software reutilizable, las computadoras de propósito general y la programación moderna.
En el corazón de la computación moderna hay una pregunta sencilla: ¿qué permitió que una misma máquina realizara muchas tareas distintas sin reconstruirse cada vez? Las primeras computadoras electrónicas podían calcular rápido, pero “cambiar el trabajo” a menudo significaba cambiar físicamente la configuración de la máquina. La idea del programa almacenado es el punto de inflexión que hizo que las computadoras fueran realmente programables.
Una computadora de programa almacenado guarda las instrucciones de una tarea (el programa) en la misma clase de memoria interna que los datos con los que trabaja el programa. En lugar de recablear el hardware o reconfigurar paneles manualmente, puedes cargar un nuevo conjunto de instrucciones en la memoria y ejecutar un trabajo distinto.
Ahora suena obvio, pero es un cambio profundo:
Esto no es sólo una curiosidad histórica. El concepto de programa almacenado explica por qué "software" existe como algo separado del "hardware", y por qué actualizar un dispositivo hoy puede desbloquear nuevas funciones sin cambiar los chips internos.
En las secciones siguientes veremos el problema al que se enfrentaban las primeras computadoras, qué cambió el enfoque del programa almacenado, las personas y documentos que clarificaron la idea (incluido el famoso informe EDVAC) y cómo el término "arquitectura von Neumann" pasó a representar un diseño ampliamente usado.
Aunque el nombre de John von Neumann está fuertemente asociado con la computación de programa almacenado, el crédito se comparte entre un equipo y una época más amplios. Muchos investigadores convergían en ideas similares mientras construían las primeras computadoras electrónicas prácticas. Este artículo mantiene ese contexto, porque entender el esfuerzo colectivo ayuda a explicar cómo la idea se difundió tan rápido y se convirtió en el modelo por defecto para la mayoría de las computadoras que siguieron.
Antes de la idea del programa almacenado, muchas computadoras tempranas no “ejecutaban software” en el sentido actual. Podían calcular a velocidades impresionantes, pero decirles qué hacer a menudo implicaba cambiar físicamente la máquina.
Un enfoque común consistía en usar paneles de clavijas, cables de conexión y paneles de interruptores. Los operadores conectaban cables entre enchufes, ajustaban filas de interruptores y, a veces, calibraban unidades de tiempo para que las señales llegaran en el orden correcto. El “programa” no era un archivo que cargar: era un diagrama de cableado temporal.
Este montaje funcionaba, pero tenía un coste oculto: cada nueva tarea era un pequeño proyecto de ingeniería. Si querías cambiar la secuencia de operaciones (sumar, multiplicar, comparar, repetir), quizá tenías que mover docenas o cientos de conexiones. Un solo cable colocado mal podía generar errores sutiles difíciles de diagnosticar, porque la lógica estaba distribuida por conexiones físicas en vez de estar escrita como pasos legibles.
Reconfigurar podía llevar horas o días, especialmente si la máquina debía apagarse con cuidado, recablearse y probarse. Eso significaba flexibilidad limitada: esas máquinas solían reservarse para un tipo de cálculo durante largos periodos porque cambiar de trabajo era muy disruptivo.
Imagina una máquina configurada para calcular tablas balísticas—cálculos largos y repetitivos con una fórmula fija. Si después se quería usar la misma máquina para resolver otro problema, como tabular resultados estadísticos de un censo, no era un "editar el programa y volver a ejecutar" rápido. El orden de operaciones, los pasos de almacenamiento intermedios y las comprobaciones condicionales podían diferir, requiriendo un rediseño completo del panel de clavijas y una nueva ronda de verificación.
Ese es el mundo del que la computadora de programa almacenado buscó escapar.
Una computadora de programa almacenado es una máquina donde las instrucciones (el programa) viven en la misma memoria de trabajo que los datos que usa el programa. En otras palabras, la computadora no trata el “qué hacer” como algo separado del “sobre qué trabajar”: ambos se almacenan como patrones de bits en la memoria.
Cuando los pioneros de la computación hablaban de memoria, se referían al almacenamiento interno rápido y de acceso directo del ordenador—lo que hoy asociaríamos más estrechamente con la RAM. Es el lugar al que el procesador puede leer y escribir rápidamente mientras se ejecuta.
Eso es distinto del almacenamiento a largo plazo como un disco duro o un SSD. Un disco es excelente para conservar archivos cuando hay corte de energía, pero no es la libreta de trabajo inmediata que el procesador usa constantemente para obtener la siguiente instrucción y actualizar resultados intermedios.
Una vez que las instrucciones están en memoria, cambiar de tarea se vuelve mucho más sencillo: puedes cargar un nuevo programa en memoria y ejecutarlo, sin reconstruir, recablear o reconfigurar físicamente el hardware. La misma máquina de propósito general puede hacer nóminas por la mañana y cálculos balísticos por la tarde, porque el “cómo” del trabajo es simplemente otro conjunto de bits que puedes reemplazar.
Imagina una cocina donde la receta y los ingredientes se guardan juntos en la misma despensa. El cocinero (el procesador) va repetidamente a la despensa (memoria) a leer el siguiente paso de la receta (instrucción) y a tomar o actualizar ingredientes (datos).
¿Quieres preparar un plato distinto? No remodelas la cocina. Solo cambias la receta—usando las mismas encimeras, horno y utensilios.
John von Neumann no “inventó la computadora”, y no creó en solitario la idea del programa almacenado. Lo que hizo—de forma brillante—fue ayudar a convertir un concepto prometedor en un diseño claramente expuesto y ampliamente compartido que otros ingenieros y laboratorios pudieron reproducir.
Von Neumann participó activamente en proyectos de computación durante la guerra y el periodo de posguerra, asesorando equipos y afinando la estructura lógica de los diseños tempranos. Tenía talento para explicar decisiones técnicas complejas en términos claros y organizados, y eso importó porque la computación electrónica avanzaba deprisa, con múltiples grupos resolviendo problemas similares a la vez.
Igualmente importante fue que escribió y difundió descripciones influyentes de cómo una computadora podía almacenar instrucciones de programa en la misma memoria que los datos. Ese enmarcado claro facilitó que otros discutieran, enseñaran y replicaran el enfoque.
Los nombres suelen pegarse no al primer autor de una idea, sino a quien presenta una descripción que se convierte en punto de referencia. Los escritos de von Neumann fueron ampliamente leídos, copiados y citados—así que los lectores posteriores asociaron naturalmente la organización de “programa almacenado” con él.
Esa etiqueta también simplificó la historia: es más fácil decir “arquitectura von Neumann” que enumerar a todos los contribuyentes y reportes. Pero la abreviatura puede difuminar lo que realmente sucedió.
La computación electrónica temprana fue un esfuerzo colaborativo y multinstitucional que involucró matemáticos, ingenieros y programadores. El concepto de programa almacenado maduró mediante discusiones, borradores, prototipos y revisiones entre equipos. El papel duradero de von Neumann fue ayudar a cristalizar y difundir la idea—acelerando su adopción—más que reivindicarla como su creación exclusiva.
EDVAC (Electronic Discrete Variable Automatic Computer) fue uno de los proyectos informáticos tempranos de posguerra cuyo objetivo era ir más allá de las máquinas “únicas”. Tan importante como el esfuerzo de hardware fue la decisión de documentar las ideas de diseño de forma clara y compartible. En aquella época, construir ordenadores seguía siendo una ingeniería experimental: el conocimiento vivía en cuadernos de laboratorio, reuniones y en la cabeza de pocos especialistas. Un informe podía convertir esos conocimientos dispersos en algo que otros equipos pudieran discutir, criticar y reutilizar.
El First Draft of a Report on the EDVAC (a menudo abreviado como “informe EDVAC”) expuso, en términos conceptuales sencillos, la idea de programa almacenado: una computadora debía guardar las instrucciones del programa en la misma clase de memoria interna que los datos. Esa memoria no es sólo un lugar para mantener números mientras se realiza un cálculo: también contiene los pasos que dicen a la máquina qué hacer a continuación.
Este planteamiento hace que una computadora se sienta menos como un dispositivo de propósito fijo y más como una máquina general que puede “reorientarse” cambiando lo que hay en la memoria. No se recablea el sistema para pasar de un trabajo a otro; se carga una secuencia distinta de instrucciones.
Más allá del propio concepto, el informe ayudó a estandarizar la forma en que la gente hablaba sobre computadoras: memoria, control, aritmética y entrada/salida como partes funcionales distintas que trabajan juntas. Tener un vocabulario compartido y una descripción ampliamente leída no solo explicó EDVAC: dio al campo un modelo mental común para construir, comparar y mejorar computadoras de programa almacenado.
Es tentador preguntar “¿quién inventó la computadora de programa almacenado?” y esperar un solo nombre. Pero la ciencia y la ingeniería rara vez funcionan así. Las ideas suelen desarrollarse en paralelo, refinarse mediante discusión y solo resultan convincentes cuando se demuestran en hardware operativo.
John von Neumann está fuertemente asociado con el concepto, pero el trabajo temprano involucró a muchas personas y grupos:
Una computadora de programa almacenado no es una sola revelación. Combina (1) el salto conceptual de que las instrucciones pueden vivir en memoria como datos, (2) la ingeniería necesaria para construir memoria y unidades de control fiables, y (3) las prácticas de programación que hacen el diseño utilizable. Diferentes personas contribuyeron a piezas distintas.
Otra razón para compartir créditos: proponer una idea no es lo mismo que construir una máquina que funcione día tras día. Los informes y discusiones iniciales hicieron el concepto más claro; los primeros prototipos y sistemas productivos demostraron su viabilidad. Una historia cuidadosa respeta ambos tipos de contribuciones, sin forzar un veredicto simplista de “primer inventor”.
Cuando la gente dice “arquitectura von Neumann”, suele referirse a un modelo simple y ampliamente enseñado de cómo se organiza una computadora de programa almacenado. No es una marca ni una máquina histórica única: es una etiqueta conveniente para un plan básico que aparece, de una forma u otra, en muchas computadoras.
A un nivel conceptual, el esquema se ve así:
La idea clave es que la CPU no tiene un lugar físico separado para “el programa” frente a “los números”. Extrae todo lo que necesita desde la memoria.
La CPU ejecuta un programa repitiendo un bucle a menudo descrito como buscar–decodificar–ejecutar:
Esta descripción es simplificada, pero captura el núcleo: el programa es una secuencia de instrucciones almacenadas en memoria, y la CPU las recorre.
Poner instrucciones y datos en la misma memoria hace que una computadora sea de propósito general de manera muy práctica:
“Arquitectura von Neumann” es mejor entenderla como un atajo para el modelo de programa almacenado con una CPU, una memoria compartida que guarda instrucciones y datos, y E/S—una idea asociada con las claras explicaciones de von Neumann, aunque la historia temprana involucró a muchos contribuyentes.
A menudo se habla de “von Neumann” y “Harvard” como si fueran filosofías en pugna. En realidad son dos maneras prácticas de disponer instrucciones y datos para que la computadora pueda obtener lo que necesita.
En un diseño al estilo von Neumann, instrucciones y datos viven en la misma memoria y normalmente viajan por la misma ruta hacia la CPU.
Eso es conceptualmente simple: un programa son solo bytes en memoria, junto a los números, textos e imágenes con los que trabaja. También facilita la computación de propósito general: el software puede cargarse, cambiarse y almacenarse usando los mismos mecanismos que los datos.
El trade-off: cuando instrucciones y datos comparten la misma “carretera”, pueden competir por ancho de banda. (A veces se describe esto como un “cuello de botella”.)
Un enfoque Harvard mantiene el almacenamiento de instrucciones separado del almacenamiento de datos, a menudo con rutas separadas para obtener cada uno.
Esa separación puede facilitar la obtención de la siguiente instrucción mientras se leen o escriben datos—útil en sistemas pequeños y previsibles. Muchos microcontroladores simples siguen este patrón, donde el código del programa vive en memoria flash y las variables en RAM.
Las CPUs modernas a menudo parecen “von Neumann” para el software (un espacio de direcciones, un modelo de programa), mientras que internamente toman ideas tipo Harvard. Un ejemplo común son las cachés separadas de instrucciones y datos (I-cache y D-cache). Para tu programa, sigue pareciendo una sola memoria, pero el hardware puede obtener código y datos con más eficiencia.
Qué recordar: no hay un ganador universal. Von Neumann enfatiza simplicidad y flexibilidad; Harvard enfatiza separación y rendimiento. Muchas máquinas mezclan ambas para equilibrar programabilidad, coste, consumo y velocidad.
Una computadora de programa almacenado no solo ejecuta cálculos: puede cargar un conjunto de instrucciones desde la memoria, ejecutarlas y luego cargar otro conjunto después. Ese cambio hizo que el software fuera reutilizable y compartible: un programa podía escribirse una vez, guardarse, copiarse, mejorarse y distribuirse sin tocar el hardware.
Cuando el programa vive en memoria, la misma computadora física puede realizar muchos trabajos distintos simplemente intercambiando las instrucciones que lee. Eso es lo que realmente significa “propósito general”: una máquina, muchos programas. La computadora deja de definirse por un único flujo de trabajo y se convierte en una plataforma.
Un ejemplo moderno fácil de entender es tu portátil, que ejecuta correo, juegos y hojas de cálculo. Bajo el capó, es la misma idea: el hardware permanece igual mientras se cargan y ejecutan distintos programas al cambiar de aplicación.
Cuando las instrucciones se tratan como datos en memoria, resulta práctico construir capas de software que ayuden a escribir software:
Estas herramientas dependen de la suposición de que los programas pueden almacenarse, moverse y manipularse como otra información. Eso convirtió al software en un ecosistema en lugar de un artefacto único ligado a un cableado particular.
Una forma útil de ver el arco histórico: los programas almacenados permitieron compiladores y sistemas operativos, que permitieron herramientas modernas de desarrollo—y hoy estamos viendo otra capa de abstracción donde puedes describir una aplicación en lenguaje natural y herramientas generan código ejecutable. Por ejemplo, Koder.ai es una plataforma de “vibe-coding” donde construyes apps web, backend o móviles a través de una interfaz de chat, apoyándose en LLMs y un flujo de trabajo basado en agentes para acelerar el camino desde la intención (“¿qué debe hacer?”) hasta instrucciones ejecutables (código fuente que puedes exportar, desplegar y revertir mediante snapshots).
El resultado sigue siendo el mismo ciclo virtuoso: los programas almacenados hicieron posibles mejores herramientas, y mejores herramientas hicieron posibles programas más ambiciosos, convirtiendo las computadoras en máquinas flexibles y de propósito general.
La idea de programa almacenado hizo las computadoras flexibles, pero también puso de manifiesto una limitación práctica que los ingenieros todavía discuten: el “cuello de botella von Neumann”. En términos cotidianos, es como un atasco de tráfico en la carretera entre la CPU (el trabajador) y la memoria (el almacén).
En un diseño típico de programa almacenado, tanto las instrucciones como los datos viven en la memoria. La CPU busca una instrucción, luego los datos que necesita, luego escribe resultados—a menudo por la misma conexión. Si esa conexión no puede mover información lo bastante rápido, la CPU acaba esperando aunque pudiera calcular mucho más rápido.
Dos factores relacionados dan forma a este cuello de botella:
Una CPU puede realizar miles de millones de operaciones por segundo, pero si la memoria no suministra un flujo constante de instrucciones y datos, el rendimiento queda limitado por el paso más lento: conseguir los bytes de ida y vuelta.
Esto es una consideración de ingeniería muy discutida, y las computadoras modernas usan varias técnicas para reducir el impacto:
Estas aproximaciones no eliminan la “carretera” subyacente, pero ayudan a mantenerla menos congestionada—para que la CPU pase más tiempo trabajando y menos tiempo esperando.
La idea del programa almacenado no es un objeto de museo: es la forma en que la computación cotidiana mantiene su flexibilidad. Tus dispositivos no necesitan “recablearse” para hacer algo nuevo; simplemente cargan distintas instrucciones en memoria y las ejecutan.
En un teléfono, tocar un icono hace que el sistema operativo cargue el código de esa app (instrucciones) desde el almacenamiento a la memoria, y la CPU lo ejecute. En un portátil, lo mismo ocurre al abrir un navegador, editar un documento o ejecutar un juego. En servidores se ve aún más: la máquina puede ejecutar miles de cargas de trabajo cambiantes—peticiones web, consultas de base de datos, tareas en segundo plano—sin cambiar el hardware.
Incluso funciones que consideramos “de hardware” a menudo se definen por software. Enrutamiento de red, rutas de decodificación de vídeo, mejora fotográfica y políticas de gestión de energía se actualizan frecuentemente mediante firmware y software de sistema—nuevas instrucciones, mismo dispositivo.
Lenguajes como Python y JavaScript suelen ejecutarse mediante un intérprete o una máquina virtual. En lugar de que la CPU ejecute directamente tu código fuente, tu programa se traduce a una forma estructurada (bytecode o instrucciones internas) que se almacena en memoria y se ejecuta paso a paso. La JVM de Java, .NET, runtimes de WebAssembly y los motores de JavaScript del navegador dependen de esto: las instrucciones se vuelven estructuras de datos que la máquina puede cargar, mover y ejecutar.
Porque las instrucciones son “solo” información, los ataques a menudo intentan introducir código malicioso a través de datos—la clásica inyección de código. Defensas como protección de memoria, firma de código y regiones no ejecutables existen para evitar que datos no confiables sean tratados como instrucciones ejecutables.
Todo esto vuelve al compromiso central del programa almacenado: flexibilidad mediante software—nuevo comportamiento en el mismo hardware.
Cuando mires una computadora (o leas una especificación), estas preguntas te ayudan a identificar el modelo básico:
Si quieres más artículos de tono accesible como este, explora /blog.
Nota: Si experimentas con formas modernas de convertir “instrucciones” en sistemas en ejecución—ya sea escribiendo código directamente o usando plataformas de construcción guiadas por chat como Koder.ai—considera documentar lo que aprendes. Koder.ai también ofrece un programa para ganar créditos por contenido publicado y referencias, lo que puede ser una forma práctica de financiar más experimentos y tutoriales.
Una computadora de programa almacenado mantiene las instrucciones del programa en la misma memoria interna que se usa para los datos sobre los que actúan esas instrucciones. Para cambiar la tarea, cargas un conjunto diferente de instrucciones en la memoria en lugar de recablear o reconfigurar el hardware de la máquina.
Antes de los programas almacenados, muchas máquinas se “programaban” con paneles de clavijas, cables y posiciones de interruptores. Cambiar la secuencia de operaciones podía implicar horas o días de recableado y nuevas pruebas, y una sola conexión errónea podía introducir errores difíciles de localizar.
En este contexto, “memoria” significa el almacenamiento de trabajo rápido del ordenador (lo más parecido a la RAM moderna) que la CPU puede leer y escribir constantemente durante la ejecución. Es diferente del almacenamiento a largo plazo (como discos/SSD), que sirve para conservar programas y archivos cuando la energía está apagada.
El informe EDVAC describió claramente la organización donde instrucciones y datos comparten la memoria interna, y aportó un vocabulario útil para hablar de las partes del ordenador (memoria, control, aritmética, entrada/salida). Esa claridad ayudó a que otros equipos discutieran, compararan y construyeran sistemas similares más rápidamente.
Su nombre se asoció al concepto en gran medida porque sus descripciones fueron ampliamente difundidas y fáciles de citar, no porque fuera el único contribuidor. El enfoque de programa almacenado surgió de una comunidad más amplia (ingenieros, matemáticos y primeros programadores) que trabajaron en problemas relacionados simultáneamente.
“Arquitectura von Neumann” suele referirse a un modelo con:
Es una etiqueta didáctica conveniente para la organización de programa almacenado, no una reivindicación de una única máquina histórica o de un único inventor.
En un diseño al estilo von Neumann, instrucciones y datos comparten una memoria (y a menudo la misma vía hacia la CPU). En un diseño al estilo Harvard, el almacenamiento de instrucciones está separado del almacenamiento de datos (frecuentemente con caminos independientes).
Muchos sistemas modernos combinan ambas ideas: por ejemplo, un modelo de memoria único para el software visto desde la capa alta, pero cachés separadas de instrucciones y datos internamente.
El “cuello de botella von Neumann” es el límite de rendimiento que puede producirse cuando la CPU y la memoria comparten un camino restringido para mover tanto instrucciones como datos. Mitigaciones habituales incluyen cachés, prefetching (precarga) y paralelismo (por ejemplo, múltiples núcleos), que reducen la espera pero no eliminan la restricción subyacente.
Como los programas son simplemente información que puede cargarse en memoria, puedes actualizar el comportamiento cambiando el software en lugar de cambiar los chips. Por eso el mismo teléfono o portátil puede ejecutar muchas apps diferentes, y por qué actualizaciones de firmware/SO pueden añadir funciones sin rediseñar el hardware.
Dado que las instrucciones se representan como datos en memoria, los atacantes a veces intentan engañar al sistema para que trate datos no confiables como código ejecutable (p. ej., inyección de código). Las defensas modernas incluyen protección de memoria (regiones no ejecutables), firma de código y otros controles que separan “datos que se pueden leer” de “código que se puede ejecutar”.
