08.10.2026 · Signal Titans Editorial
Bjarne Stroustrup se negó a elegir entre abstracción y velocidad
En 1979, Bjarne Stroustrup llegó a Bell Labs con un problema que todavía resulta familiar a cualquier ingeniero de software: el modelo de programación que hacía un sistema más fácil de comprender no siempre era el que permitía ejecutarlo con la velocidad necesaria. Había utilizado Simula en trabajos sobre sistemas distribuidos y apreciaba sus clases y su capacidad para organizar programas complejos, pero también quería la eficiencia, la portabilidad y el control de bajo nivel de C. En vez de aceptar esa elección, inició un experimento al que llamó primero “C with Classes”.
La restricción llegó antes que el lenguaje
Stroustrup no empezó con un manifiesto para sustituir a C. Su problema inicial estaba relacionado con la distribución de servicios de sistema operativo a través de una red. La pregunta práctica era cómo describir un sistema complejo con abstracciones más fuertes sin pagar una penalización de rendimiento que lo hiciera inútil para software de sistemas. C ya tenía compiladores, programadores, sistemas operativos y una cultura orientada a la eficiencia. Simula ofrecía una forma más clara de estructurar programas. El nuevo lenguaje tenía que convivir con ambos mundos.
Por eso resulta engañoso resumir C++ como “C con sintaxis orientada a objetos”. En los relatos del propio Stroustrup aparece una idea más profunda: quería programas eficientes y elegantes al mismo tiempo. La compatibilidad, las abstracciones sin coste innecesario y la posibilidad de implementar el lenguaje con herramientas existentes fueron presiones centrales desde el principio, no añadidos tardíos.
“C with Classes” fue un puente utilizable
La primera implementación empleaba un preprocesador que traducía las nuevas construcciones de clases a C. Más tarde, Stroustrup escribió Cfront, un front end de compilador mucho más completo que realizaba análisis sintáctico y semántico y generaba C como salida. Aquello permitió probar las ideas dentro del ecosistema de Bell Labs sin exigir que todo el entorno se reconstruyera desde cero.
A comienzos de los años ochenta, la comunidad de usuarios había crecido lo suficiente como para que mantener “C with Classes” como herramienta de investigación personal se volviera una carga. Stroustrup recordó después que debía escoger entre abandonar el experimento o convertirlo en un lenguaje más flexible y expresivo. Eligió lo segundo. El nombre C++ llegó en esa etapa y la primera versión comercial apareció en 1985, el mismo año en que se publicó la primera edición de The C++ Programming Language.
Abstracción sin abandonar la máquina
C++ incorporó comprobación de tipos más fuerte, clases, constructores, sobrecarga de operadores, funciones virtuales y, posteriormente, plantillas y una amplia biblioteca estándar. Pero la idea más duradera era el pacto que había detrás: los programadores debían poder construir abstracciones de alto nivel que se tradujeran de forma eficiente al hardware. Una abstracción no debía imponer un coste oculto simplemente por ser cómoda. Esa filosofía ayudó a que C++ encontrara espacio en sistemas, gráficos, videojuegos, finanzas, cálculo científico y otros ámbitos donde importan tanto la estructura del software como su coste de ejecución.
El pacto también tiene un precio. C++ acumuló complejidad al intentar preservar programas antiguos, permitir nuevos estilos y seguir siendo adecuado para tareas de bajo nivel. Las críticas sobre su tamaño y dificultad no son imaginarias. Sin embargo, están conectadas con la misma decisión histórica que hizo posible su continuidad: C++ fue diseñado para entrar en un mundo existente, no para obligar a ese mundo a empezar de nuevo.
La estandarización cambió quién definía el lenguaje
Cuando C++ se extendió fuera de Bell Labs, una sola implementación ya no podía definirlo para siempre. El trabajo de estandarización comenzó a finales de los años ochenta y el primer estándar ISO se ratificó en 1998. Desde entonces, el lenguaje se ha desarrollado mediante un comité internacional, múltiples compiladores, autores de bibliotecas y una comunidad enorme. Stroustrup siguió siendo una voz decisiva, pero C++ dejó de depender de una única hoja de ruta personal.
Eso ayuda a entender por qué muchas decisiones modernas de C++ parecen negociaciones. Cada nueva capacidad debe coexistir con décadas de código y con usos que van desde pequeños sistemas embebidos hasta servicios gigantescos. Frente a un lenguaje nuevo, ese ritmo puede parecer conservador. En realidad, la continuidad forma parte del problema de ingeniería.
La lección duradera es no elegir demasiado pronto
En 2018, la National Academy of Engineering concedió a Stroustrup el Charles Stark Draper Prize por conceptualizar y desarrollar C++. El premio reconoce el impacto, pero para un programador la lección más interesante sigue estando en la restricción original. Stroustrup no aceptó que las abstracciones legibles y la eficiencia de máquina tuvieran que pertenecer a lenguajes separados; intentó mover esa frontera.
Hoy existen muchas respuestas a la misma tensión: runtimes gestionados, sistemas de ownership, compilación JIT, lenguajes de bajo nivel más seguros y hardware especializado. C++ no es la única solución y con frecuencia tampoco es la más sencilla. Su importancia histórica está en demostrar que diseñar un lenguaje puede significar preservar varias restricciones a la vez. A veces la innovación que dura no es una característica concreta, sino la negativa a sacrificar una parte del problema antes de haber intentado resolverlo.
SIGNAL TITANS.jpg){kind=link}