Entrevista a Bjarne Stroustrup
El creador de C++
Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.
This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.
Bjarne Stroustrup es un destacado científico de la computación danés, nacido en 1950 en Aarhus, Dinamarca. Es ampliamente conocido como el creador del lenguaje de programación C++, que revolucionó la programación y la ingeniería de software.
Stroustrup obtuvo su doctorado en Ciencias de la Computación en la Universidad de Cambridge y posteriormente se unió a Bell Labs, donde desarrolló el lenguaje C++. Su trabajo en C++ permitió la creación de sistemas más eficientes y flexibles al combinar características de programación orientada a objetos con la capacidad de bajo nivel del lenguaje C, además de incorporar muchas otras características novedosas para su época.
A lo largo de su carrera, Stroustrup ha recibido numerosos premios y reconocimientos, incluido el premio Dr. Dobb's Excellence in Programming en 2008 y ser nombrado Doctor Honoris Causa por la Universidad Carlos III (España) en 2019. Ha sido profesor en diversas universidades, incluyendo la Universidad de Texas A&M.
El legado de Bjarne Stroustrup en la informática es innegable, ya que su creación, el lenguaje C++, sigue siendo ampliamente utilizado en la industria del software y ha influido en numerosos lenguajes de programación modernos.
Me gustaría destacar algunas de sus citas más memorables —según mi opinión— que ha dicho Bjarne Stroustrup a lo largo de su vida y que paso a enlistar:1
«C hace que sea fácil dispararte en el pie; C++ lo hace más difícil, pero cuando lo haces te vuela toda la pierna».
«Para utilizar bien C++, hay que entender las técnicas de diseño y programación».
«Si crees que es sencillo, entonces has entendido mal el problema».
«Es fácil obtener el perdón por equivocarse; tener razón es lo que te mete en verdaderos problemas».
«El diseño y la programación son actividades humanas; olvida eso y todo estará perdido».
No saben la emoción que tuve entrevistar a Stroustrup, porque C++ fue uno de mis primeros lenguajes de programación que aprendí. Con C++ me entusiasmé con la programación, me hizo entenderla bajo otros términos y, a su vez, pude enfrentarme a mis primeros retos técnicos. En suma, C++ me dio las principales alegrias, y también, los principales «infiernos».
¡Espero disfruten la entrevista!2
Versión traducida
(1) ¿Cómo surgió la idea de crear unas directrices básicas (Core Guidelines) para C++ y qué espera del proyecto en el futuro? ¿Es posible añadir «asistentes inteligentes» que puedan hacer sugerencias y revisar el código de acuerdo con las directrices básicas?
Especialmente después de C++11, mucha gente expresó su interés por saber qué era el «C++ moderno». Además, en mi trabajo en Morgan Stanley, necesitaba dar consejos para mejorar las bases de código. Obviamente, no era el único que se agarraba a esa pregunta, así que pregunté por ahí y varios de nosotros creamos el proyecto que se convirtió en «The C++ Core guidelines».
Siempre fui de la opinión de que las normas por sí solas son insuficientes. Quería —y sigo queriendo— que el análisis estático detectara vulneraciones y remitiera a las directrices pertinentes que contienen sugerencias sobre lo que se podría hacer mejor. Esto podría convertirse en un «asistente inteligente».
(2) ¿Qué características infrautilizadas del «C++ moderno» (es decir desde C++11 a C++20) podrían mejorar el código de un programador y evitar errores y aún no se utilizan ampliamente?
Cosas muy sencillas podrían ayudar, span para evitar las interfaces propensas a errores (pointer, count), vectores en lugar de arrays, punteros de gestión de recursos (unique_ptr y shared_ptr) en lugar de punteros más «desnudos» con new/delete. Uso de contenedores de rango comprobado y span.
Uso coherente de RAII y uso adecuado de excepciones.
Lo que importa no son las características individuales, sino cómo se combinan para apoyar un diseño sólido. Uso coherente del sistema de tipos. Evitar macros, moldes (casts) y void*. Eche un vistazo a The C++ Core Guidelines para obtener ideas.
(3) Desde C++11, se han incorporado más características de la programación funcional, como las expresiones lambda o std::function, que lo hacen más declarativo. ¿Hay planes para añadir más características declarativas a futuras versiones de C++?
Eso espero. Desde el día #1, he trabajado para hacer que el código sea más explícito / declarativo. Algunos ejemplos son los pares constructor/destructor que conducen a la gestión de recursos de estilo RAII y los conceptos que proporcionan una comprobación inicial del código genérico a través de una especificación más precisa. Me gustaría que la concordancia de patrones (pattern matching) al estilo funcional resolviera los problemas del código condicional y que los contratos hicieran explícitas las suposiciones. Por desgracia, no parece fácil que el comité apruebe versiones concretas de estas ideas.
(4) ¿Cuál es la estrategia recomendada para migrar una base de código C++ escrita en «C-Style» a C++ moderno dentro de un proyecto?
Por desgracia, no es fácil. Es fácil estropear un buen diseño, pero es difícil hacer que un código desordenado sea más limpio y regular. La gente suele exigir compatibilidad de errores con código desordenado antiguo, y eso no se puede tener junto con un código más limpio.
Lo primero que hay que limpiar son las interfaces.
Una vez que tengas una interfaz decente, puedes empezar a limpiar el código a cada lado de ella. Compara:
using Cmp = int(const void*, const void*);
void qsort(void *ptr, std::size_t count, std::size_t size, Cmp* comp); y
template<ranges::random_access_range R, class Comp = ranges::less> sort(R&& r);Esta última es mucho más fácil de usar y proporciona al optimizador más información para permitir un mejor rendimiento.
(5) Ha mencionado que C++ se diseñó para evolucionar desde el primer día. Tras años de experiencia, ¿hay alguna característica de C++ que le gustaría eliminar pero que ahora es inconcebible?
No hay ninguna característica importante que me gustaría eliminar, pero no se me ocurre ninguna característica importante que no pudiera hacer mejor con los conocimientos actuales. Por ejemplo, las plantillas (templates) habrían sido mejores y más sencillas si hubieran tenido conceptos desde el primer día. Lo sabía en aquel momento, pero no pude idear un diseño que ofreciera generalidad, rendimiento óptimo e interfaces bien especificadas. Podía hacer dos de esas tres cosas, pero ni yo ni nadie con quien consultara podíamos averiguar cómo conseguir las tres.
La compatibilidad con versiones anteriores —estabilidad durante décadas— es una característica importante, así que desaconsejo meterse con pequeños detalles aparentemente irrelevantes. Arreglarlos aportaría ventajas menores y probablemente molestaría a un número significativo de desarrolladores. Con millones de usuarios en todo el mundo, nunca se sabe qué se utiliza de forma crítica en algún lugar.
(6) Se habla mucho de lenguajes como Rust, Julia y Python. Sin embargo, tú has mencionado anteriormente que estos lenguajes, en particular Python, se centran en un conjunto diferente de problemas. En 2023+, ¿qué tipo de problemas requerirían que un programador utilizara C++? Lo pregunto porque puede ser un reto determinar qué herramienta es la más adecuada para una situación concreta.
Problemas que requieren un uso eficiente del hardware y cierta abstracción.
Algunos ejemplos son las principales bibliotecas utilizadas por lenguajes como Python, y sistemas como LLVM de los que dependen muchos lenguajes modernos. Sistemas embebidos complejos, como el software automovilístico y aeroespacial. Gráficos y animación. Computación científica, donde la alternativa es Fortran.
No me gustan las exageraciones.3 Se interpone en la toma de decisiones técnicas racionales y tranquilas.
(7) ¿Hay algún nuevo lenguaje o herramienta de programación que le haya sorprendido y contenga ideas que le gustaría aplicar a C++?
No tantas sorpresas, pero me encantaría contar con algún gestor estándar de paquetes y compilación para C++. Como siempre, el problema es que hay varios y es difícil elegir. Además, necesitamos mejores herramientas de análisis estático.
Original
(1) How did you develop the idea of creating C++ Core Guidelines, and what do you expect from the project in the future? Is it possible to add "intelligent assistants" that can make suggestions and review the code according to the core guidelines?
Especially after C++11, many people expressed an interest in knowing what “Modern C++” was. Also, at my job in Morgan Stanley, I needed to give advice about improving code bases. Obviously, I wasn’t the only one grabbling with that question, so I asked around and several of us created the project that became “The C++ Core guidelines.”
I was always of the opinion that rules by themselves are insufficient. I wanted – and still want – static analysis to detect violations and point to the relevant guidelines that contain suggestions about what could be done better. This could develop into an “intelligent assistant.”
(2) What underutilized "modern C++" features (from C++11 to C++20) could improve a programmer's code and prevent errors and are not yet widely used?
Very simple things could help, span to avoid the error-prone (pointer, count) interfaces, vectors, rather than arrays, resource management pointers (unique_ptr and shared_ptr) rather than pointers plus “naked” new/delete. Use of range-checked containers and span.
Consistent use of RAII and appropriate use of exceptions.
What matters is not individual features but how they combine to support sound design. Consistent use of the type system. Avoidance of macros, casts, and void*. Have a look at The C++ Core Guidelines for ideas.
(3) Since C++11, more functional language features, such as lambda expressions or std::function, have been incorporated, making it more declarative. Are there plans to add more declarative features to future versions of C++?
I hope so. From day #1, I have worked to make code more explicit/declarative. Examples are constructor/destructor pairs leading to RAII-style resource management and concepts providing up-front checking of generic code through more precise specification. I would like to see functional-style pattern matching to address problems with conditional code and contracts to make assumptions explicit. Unfortunately, it doesn’t seem easy to get concrete versions of such ideas through the committee.
(4) What is the recommended strategy for migrating a C++ codebase written in C-style to modern C++ within a project?
Unfortunately, that’s not easy. It is easy to mess up a good design, but hard to make messy code cleaner and more regular. People often demand bug-compatibility with older messy code, and you can’t have that together with cleaner code.
The first thing to clean up is interfaces.
Once you have a decent interface, you can start cleaning up code on each side of it. Compare:
using Cmp = int(const void*, const void*);
void qsort(void *ptr, std::size_t count, std::size_t size, Cmp* comp); and
template<ranges::random_access_range R, class Comp = ranges::less> sort(R&& r);The latter is far easier to use and gives the optimizer more information to allow better performance.
(5) You mentioned that C++ was designed to evolve from day one. After years of experience, are there any features of C++ that you would like to remove but are now inconceivable?
There is no major feature I’d like to remove, but I can’t think of any major feature that I couldn’t do better with today’s knowledge. For example, templates would have been better and simpler had they had concepts from day #1. I knew that at the time but couldn’t come up with a design that offered generality, optimal performance, and well-specified interfaces. I could do any two out of those three, but neither I nor anyone I consulted with could figure out how to get all three.
Backwards compatibility – stability over decades – is a major feature, so I discourage messing with apparently irrelevant small details. Fixing them would bring minor advantages and probably annoy a significant number of developers. With millions of users worldwide, you never know what is in critical use somewhere.
(6) There is a lot of hype around languages like Rust, Julia, and Python. However, you have previously mentioned that these languages, particularly Python, are focused on a different set of problems. In 2023+, what kind of problems would require a programmer to use C++? I ask because it can be a challenge to determine which tool is best suited for a particular situation.
Problems that require efficient use of hardware and some abstraction.
Examples are major libraries used by languages such as Python, and systems like LLVM that many modern languages depend on. Complex embedded systems, such as automobile and aerospace software. Graphics and animation. Scientific computation, where the alternative in Fortran.
I dislike hype. It gets in the way of calm rational technical decision making.
(7) Are there any new programming languages or tools that have surprised you and contain ideas you would like to apply to C++?
Not so many surprises, but I would dearly love some standard packaging and build systems for C++. As usual, the problem is that there are several and it’s hard to choose. Also, we need better static analysis tools.
Para entender el contexto de estas citas y conocer otras, puede remitirse a https://www.stroustrup.com/quotes.html
La traducción fue realizada usando DeepL, con pequeñas modificaciones de mi parte para que se entendiera mejor.
La frase original es «I dislike hype». No estoy seguro que «exageraciones» sea lo más adecuado para «hype».
Excelente.
C++ fue el lenguaje con que aprendí Programación en la carrera de Ciencias de la Computación. Esta entrevista me hizo recordar aquellos tiempos de 1er año en la Universidad de Oriente, Cuba. Muchísimas gracias!!!