Bjarne Stroustrup es un científico en computación y Catedrático de Ciencias de la Computación en la Universidad A&M de Texas. Es reconocido mundialmente por ser el creador del lenguaje de programación C++.

Stroustrup es un cand. scient. (el equivalente danés a un máster) en matemática y ciencias de la computación (1979) por la Universidad Aarhus, Deinamarca, y Doctor en ciencias de la computación (1979) por la Univesidad de Cambridge, Inglaterra. Anteriormente trabajó a la cabeza del departamenteo de Investigación en Programación de los laboratorios Bell de AT&T, desde su creación hasta finales de 2002.

En esta entrevista, Bjarne Stroustrup nos cuenta todo sobre el diseño y desarrollo de C++, los garbage collectors, el futuro de C++ y el rol de la barba en la creación de lenguajes de programación exitosos.

Computerworld publicó recientemente esta excelente entrevista a Bjarne Stroustrup (en inglés), como parte de su serie "The A-Z of Programming Languages". A continuación una traducción al castellano con lo destacado de la nota.

¿Qué lo motivó para desarrollar C++?

Necesitaba una herramienta para diseñar e implementar una versión distribuida del kernel de Unix. En ese momento, 1979, no existía dicha herramienta. Necesitaba algo que pudiera expresar la estructura del programa, manipulara directamente el hardware, y que sea lo suficientemente eficiente y portable para programación de sistemas importantes.

Pueden encontrar más información y detalles acerda del diseño y evolución de C++ en mi notas de HOPL (Histoy of Programming Languages - Historia de los Lenguajes de Programación), las cuales pueden encontrar en mi página personal y en mi libro "El Diseño y Evolución de C++".

¿Qué problemas específicos intentaba resolver?

Los dos problemas que me vienen a la mente eran poder simular la infraestructura de comunicación inter-procesos para un sistema distribuido o un sistema de memoria compartida (para determinar qué servicios del Sistema Operativo podríamos correr en cada procesador por separado); y el escribir los drivers de red para este sistema. Obviamente, como Unix estaba escrito en C, también quería un alto grado de compatiblidad con C. Muy tempranamente, desde 1980 en adelante, fue utilizado por otras personas (con mi ayuda) para simular distintos protocolos de red y altoritmos de gestión de tráfico.

¿De dónde proviene el nombre de C++?

Mientras "C con Clases" (el ancestro de C++) se volvia popular dentro de Bell Labs, algunas personas pensaban que era un nombre demasiado largo y comenzaron a llamarlo "C". Esto significaba que tenían que aclarar a lo que se referián cuando necesitaban distinguirlo del lenguaje de Dennis Rithcie, al cual llamaban "Viejo C", "C original", y así. Algunos pensaban que era una falta de respeto hacia Dennis (ni él ni yo lo sentiamos así) y un día recibí un "pedido" de Bell Labs para que le cambiara el nombre. Como resultado, lo nombramos C84 por un tiempo. Este cambio no ayudó demasiado, así que pedí ayuda por sugerencias y elegí C++ de una lista de candidatos. Todos están de acuerdo que, semánticamente hablando, ++C hubiera sido todavía mejor, pero habría ocasionado demasiados problemas para quienes no conocen la sintaxis.

¿Hubo algún problema particularmente dificil o frustrante que hubo que superar durante la creación del lenguaje?

Montones! Para empezar, ¿cuales deberían ser las reglas fundamentales del lenguaje? ¿Qué debía estar en el lenguaje, y que debia quedar afuera? La mayoría quiere un lenguaje pequeño que brinde todas las características que encuentran útil en el resto de los lenguajes. Desafortunadamente, eso es imposible.

Luego de un corto tiempo de confiar en la suerte y el buen gusto, me decidí por un grupo de "reglas a ojo" que pretendian asegurar que los programas en C++ fueran a la vez elegantes (como en Simula67, el lenguaje que presentó la programación orientada a objetos) y efcientes para la programación de sistemas (como C). Obviamente, no todos los programas logran ambas cosas, pero la idea era (y es) lograr que un desarrollador competente pueda expresar practicamente cualquier idea directamente y lograr su ejecución con un mínimo overhead (cero overheads comparando contra una versión en C).

Convencer a la comunidad de programadores del valor del chequeo de tipos fue sorprendemente dificil. La idea de chequear los argumentos de una función contra una delcaración de la función fue resistida fuertemente - al menos hasta que C adoptó la idea.

En la actualidad la programación orientada a objetos está por todos lados, por lo que a las personas les cuesta creer que me fue imposible convencer a las personas de su utilidad hasta que finalmente agregué funciones virtuales y demostré que eran lo suficientemente rápidas para usos muy demandantes. El enfoque de C++ hacia la Programación Orientada a Objetos fue (y es) básicamente el mismo que Simula, con simplificaciones y mejores de peformance.

La compatibilidad con C fue (y es) una gran fuente de problemas y fortalezas. Al ser compatible con C, los desarrolladores de C++ tenian garantizada una gran cantidad de características que usualmente faltan en las primeras versiones de los lenguajes, y acceso directo (y efeciente) a una gran cantidad de código - no sólo código en C, sino también en Fortran y más ya que las convenciones de llamadas de C eran simples y similares a las que soportaban otros lenguajes. Después de todo, como solía decir, la reutilización comienza por utilizar algo que ya existe, en vez de esperar que alguien desarrolle nuevos componentes reutilizables. Por otro lado, C tiene varias vueltas sintácticas y semánticas, por lo que seguir a la par de C mientras fue evolucionando no es tarea fácil.

¿Cuáles son las principales diferencias entre C con Clases y C++?

La mayoría de las diferencias estuvieron en la técnica de implementación. C con Clases se implentó con un preprocesador, mientras que C++ requiere un compilador apropiado (por lo cual escribí uno). Era facil transcribir programas en C con Clases hacia C++, pero los lenguajes no eran 100% compatibles. Desde un punto de vista del lenguaje, la mayor mejora fue la incorporación de funciones virtuales, lo cual permitió la programación orientada a objetos clásica. También se agregó la sobrecarga (incluyendo la sobrecarga de operadores). Vale destacar que las características fundamentales de C++ para la gestión de recursos generales, constructores y destructores ya se encontraban en las primeras versiones de C con Clases. Por otro lado, los templates (y las excepciones) se añadieron en versiones algo posteriores de C++ (1989); antes de esto, soliamos usar macros para expresar ideas generales de programación.

¿Qué hubiera hecho diferente en el desarrollo de C++ si hubiera tenido la oportunidad?

Esta pregunta es un poco injusto porque, por supuesto, no tenía el beneficio de casi 30 años de experiencia con C++, y mucho de lo que sé actualmente es el resultado de experimentar con versiones anteriores de C++. Por otro lado, en aquel entonces básicamente no tenía recursos (sólo yo y mi tiempo libre), por lo tanto si dijera (correctamente) que las funciones virtuales, los templates (con "conceptos", tal como los ofrece C++0x) y las excepciones hubieran hecho de C++85 un mejor lenguaje, estaría no sólo sugiriendo algo que no hubiera sabido diseñar en 1980, sino también que, aunque hubiera encontrado el diseño perfecto de forma mágica, no lo hubiera podido implementar en un tiempo razonable.

Creo que hubiera sido posible lanzar una mejor librería estandard en 1985 junto a C++ 1.0, la cual hubiera mejorado mucho con el tiempo. Con "mejor librería" me refiero a una librería con clases que incluyeran una mejora versión de funciones para soportar concurrencia y un set de clases de containers.

Más tarde, hubiera desarrrolaldo templates (claves para el estilo de programación genérico de C++) antes que herencia múltiple (no una gran característica, como muchos la consideran), y hubiera hecho más énfasis en las excepciones.

¿Como se sintió cuando C++ logró la estandarización en 1998, y cómo participó del proceso de estandarización?

Trabajé duro en la estandarización durante años (1989-1997); ahora estoy trabajando en el sucesor del estándard: C++0x. Evitar que un lenguaje popular se fragmente en dialectos es una tarea dificil y esencial. C++ no tiene un dueño o un "papá rico" para brindar fuerza de desarrollo, librerías "gratis" y marketing. El comité de estandarización ISO fue esencial para el crecimiento de la comunidad de C++.

¿Cuál fue el programa más interesate que escribió en C++?

No puedo elegir uno, y en general no pienso en los programas como "interesantes". Me fijo más en los sistemas completos, de los cuales algunas partes están escritos en C++. Entre estos me vienen a la mente el sub-sistema de manejo autónomo del Mars Rover de la NASA, el motor de búsqueda de Google, y el sistema de reservas de vuelos de Amadeus. Mirando el código aislado, creo que la librería STL de Alexander Stepanov (containers, iteradores, y librerias parte de la librería estándard de C++) está entre las porciones de código más interesantes, útiles e influeyentes para C++ que haya visto.

¿Alguna vez vio al lenguaje utilizarse para algo que no fue originalmente planeado?

Diseñé C++ para la generalidad. Es decir, las características que tiene fueron deliberadamente diseñadas para hacer cosas que no me podía imaginar. Además, las facilidades de abstracción de C++ (por ejemplo, clases y templates) fueron diseñadas para ser rápidas cuando son usadas en hardware convencional, de forma que las pesonas pudieran construir las abstracciones básicas que necesitaran para un área de aplicación determinada (como ser números complejos y manejadores de recursos) dentro del lenguaje.

Entonces, si, vi utilizar a C++ para muchas cosas que no hubiera pensado, y ser usado de muchas formas que no anticipé, pero en general no estoy completamente sorprendido.

Muchas veces me desespera ver los intentos de forzar C++ en un molde que no encaja simplemente porque alguien no se molestó en aprender lo básico de C++. Por supuesto, las personas que hacen esto no creen que están actuando irracionalmente; en cambio, piensan que saben cómo programar y que no hay nada nuevo o diferente acerca de C++ que requiera que cambien sus hábitos y aprendan "trucos nuevos". Estas personas estructuran su código como lo harían, por ejemplo, para C o para Java, y luego se sorprenden cuando C++ no funciona como esperan. Algunos hasta se enojan mucho, aunque no entiendo porqué deberían enojarse al darse cuenta que tienen que tener más cuidado con el sistema de tipos en C++ que en C, o que no hay una companía brindando librerias "gratis" y "estándard" para C++ como lo hay en Java. Para usar C++ bien se tiene que utilizar el sistema de tipos, y se tienen que buscar librerias. Intentar construir una aplicación directamente con C++ a secas, o usando sólo las librerías estándard, es una pérdida de tiempo y esfuerzo.

Parece que una gran cantidad de programadores nunca usaron los templates, incluso aunque sean programadores C++

Puede ser cierto esto, pero yo creo que al menos la mayoría utilizan los templates a través de STL (u otras librerías similares), y que la cantidad de programadores que evitan los templates va en disminuación.

¿Por qué cree que ocurre esto?

Por miedo a algo que es diferente a lo que ya conocen, rumores de complicaciones en el código, problemas de linking, y mensajes de error espectacularmente malos.

¿Alguna vez deseó que el compilador GNU C++ hubiera mostrado errores de compilación más cortos, para que no ahuyentara a estudiantes?

Por supuesto, pero no es todo culpa del GCC. El problema fundamental es que C++98 no tiene una forma para que el programador indique de manera directa los requerimientos de un template en los tipos de argumentos. Esta es una debilidad del lenguaje, no del compilador, y sólo puede resolverse completamente con un cambio en el lenguaje, el cual será parte de C++0x.

Me estoy refiriendo a los "conceptos", los cuales serán parte de C++0x. Para más detalles, vean mis notas sobre C++0x. Hasta que los "conceptos" estén disponibles para todos, se pueden usar "constrains classes" para mejorar los chequeos; vean mi FAQ técnico para más información.

En los últimos años se está viendo que el procesamiento distribuido está más al alcance del programador promedio. ¿Cómo afectará esto a C++?

Es dificil de saber, pero antes de entrar en la programación distribuido un lenguaje tiene que soportar concurrencia y poder tratar más que el modelo de memoria tradicional "plano/uniforme". C++0x hace exactamente esto. El modelo de memoria, tipos atómicos, y el almacenamiento local de hilos brindan las garantías básicas para soportar una buena librería de hilos. En resumen, C++0x permite un uso eficiente de multi-núcleos.

Por supuesto que no es necesario esperar a C++0x para hacer programación concurrente en C++. Las personas hicieron esto durante años, y la mayor parte de lo que el nuevo estándard ofrece ya existe actualmente en otras formas.

¿Ve esto como una tendencia a la creación de una nueva generación de lenguajes de propósito general?

Muchos de los lenguajes "de scripting" brindan utilidades para manipular el estado de entorno Web, y allí reside su verdera potencia. La manipulación simple de texto se logra bastante facilmente con librerias, como las nuevas librerías de expresiones regulares de C++ (disponibles hoy en boost.org), pero es dificil concebir un lenguaje que es tanto de propósito general como distribuido. La raíz del problema es que los lenguajes distribuidos prácticos utilizan la simplificación y la especialización. Un lenguaje de propósito general no puede proveer un único modelo distribuido de alto nivel.

No veo una razón importante que impidan que un lenguaje de propósito general crezca con utilidades para distribución. Sin embargo, yo sostengo (sin éxito) que C++0x debería hacer exactamente esto. Creo que eventualmente todos los principales lenguajes van a proveer algún tipo de soporte para la distribución, a través de una combinación de soporte directo del lenguaje, soporte en tiempo de ejecución, o librerias.

En su opinión, ¿qué aporte perdurable en el tiempo le dio C++ al desarrollo de sistemas?

C++ llevó la programación orientada a objetos al público general, y está haciendo lo mismo para la programación genérica.

Si se mira a algunos de los programas más exitosos de C++, especialmente los relacionados a la gestión de recursos, se tiende a encontrar que los destructores son fundamentales e indispensables en su diseño. Creo que los destructores serán vistos como la contribución más importante - todo lo demás depende en una combinación de características del lenguaje y técnicas para soportar un estilo de programación, o combinación de estilos.

Otra aporte del legado de C++ es que hizo que la abstracción sea manejable y posible de realizar en áreas aplicativas donde las personas necesitan programar en lenguaje de máquina directamente, como con bits, bytes, words y direcciones.

En el futuro, apunto a lograr una mayor integración entre la orientación a objetos y la programación genérica, y una mejor articulación entre los ideales de generalidad, elegancia y eficiencia.

¿Por dónde cree que pasará el futuro de C++?

Por la misma parte en la que C++ tuvo su mayor fuerza desde el primer día: aplicaciones con componentes críticos de sistema, especialmente la provisión de infraestructura. Actualmente, casi todas las infraestructuras (incluyendo la implementación de lengujaes de más alto nivel) están bajo C++ (o C), y creo que seguirá siendo así. También, la programación de sistemas embebidos es una área importante de crecimiento para C++; por ejemplo, el software para la próxima generación de aviones de combate de Estados Unidos está escrito en C++ (vean las Reglas de codificación JSF++ en mi página). C++ brinda lo mejor cuando se necesita simultáneamente alta performance y alto nivel de abstracción, especialmente bajo retricciones de recursos. Casualmente, esta descripción encaja tanto para el iPod como para una aplicación científica de gran escala.

¿Lo sorprendió la evolución y popularidad del lenguaje?

Nadie, con la posible excepción de Al Aho, pudo prever la magnitud del éxito de C++. Supongo que durante los años '80 estaba demasiado ocupado para sorprenderme: el uso de C++ se duplicaba cada 7.5 meses, como calculé más tarde - y todo esto se logró sin un departamente de marketing dedicado, casi sin personas, y un presupuesto prácticamente nulo. Apunté a lograr generalidad y eficiente, y tuve éxito más allá de cualquier expectativa.

Por cierto, cada tanto me encuentro con personas que asumen que, porque alago de C++ y lo dfiendo de sus detractores, pienso que es perfecto. Esto es obviamente absurdo. C++ tiene un montón de debilidades - y las conoczco mejor que nadie - pero el objetivo de realizar el diseño y la implementación no era no cometer errores (esto es imposible en un proyecto tan grande, y bajo tales restricciones Draconianas). El objetivo era crear una herramienta que, en manos competentes, sea efectiva para la construcción de sistemas importantes para el mundo real. En esto, creo que tuvo éxito más allá de mis mayores expectativas.

¿Qué le responde a las críticas del lenguaje, como que heredó todas las falencias de C y que tiene una enorme cantidad de caracertísticas que lo hacen "complicado"?

C++ heredó las debilidades y fortalezas de C, y creo que hicimos un buen trabajo en compensar las debilidades sin comprometer las fortalezas. C no es un lenguaje simple (el estándard ISO tiene más de 500 páginas), y la mayoría de los lenguajes modernos son más grandes aún. Obviamente, C++ (como C) es "complicado" comparado con otros lenguajes de juguete, pero realmente no es tan grande al compararlo con otros lenguajes modernos. Hay razones prácticas y sólidas de porqué todos los lenguajes actuales que se usan para trabajo industrial serio son "complicados": las tareas que deben resolver son enormes y de una complejidad más allá de la imaginación.

Otra razón para el tamaño "incómodo" de los lenguajes actuales es su necesidad de ser estables. Escribí código en C++ hace 20 años que aún hoy corre, y estoy seguro que seguirá compilando dentro de otros 20 años. Quienes construyen proyectos de infraestructura grandes necesitan esta estabilidad. Sin embargo, para mantenerse modernos y poder enfrentar nuevos desafios, los lenguajes deben crecer (tanto en características del lenguaje como en librerías base), pero si quitás algo, rompés el código. Por lo tanto, los lenguajes que se construyen pensando en serio en los usuarios (como C++ y C) tienden a mantener características durante décadas, y tienden a "complicarse". La alternativa son lenguajes hermosos para los cuales hay que re-escribir el código cada 5 años.

Por último, C++ soportó explícticamente y desde el primer día más de un estilo de programación, y una interacción entre estos estilos. Si pensás que existe un único estilo de programación que es el mejor para todas las personas y aplicaciones (por ejemplo, la programación orientada a objetos), entonces ahí tenés una oportunidad para lograr simplificación. Sin embargo, yo creo fervientemente que la mejor solución (la más legile, mantenible, eficiente, etc) requieren más de un estilo de programación. Por lo tanto, el tamaño de C++ no puede ser reducido mediante el soporte de un único estilo de programación. El uso combinado de diferentes estilos es clave en mi visión de C++, y una gran parte de su fortaleza proviene de aquí.

¿De qué está más orgulloso, en términos del desarrollo inicial del lenguaje y su uso continuado?

Estoy orgulloso de que se haya utilizado a C++ para tantas aplicaciones que hicieron del mundo un lugar mejor. A través de C++ pude realizar una pequeña contribución al proyecto del Genoma Humano, a proyectos de física (C++ se utiliza en el CERN, Fermilab, SLAC, etc), exploración espacial, energía eólica, etc. Pueden ver una pequeña lista de aplicaciones C++ en mi página. Siempre me pone feliz cuando escucho que el lenguaje está siendo usado para algo bueno.

Segundo, estoy orgulloso de que C++ haya ayudado a mejorar la calidad del código en general, no sólo dentro de C++. Los lenguajes más nuevos, como Java y C#, utilizan técnicas que C++ hizo que fueran posibles para el uso en el mundo real, y comparado con el código de 20 años atrás muchos sistemas en los que dependemos actualmente son increiblemente confiables y fueron construidos bajo un presupuesto restringido. Obviamente, podemos y debemos hacer mejor, pero podemos sentirnos orgullosos del camino que recorrimos hasta ahora.

En términos de una contribución directa y personal, estoy contento de haber escrito el primer compilador C++, Cfont, para poder compilar programas para el mundo real en máquinas de 1MHz con 1MB de memoria. Esto es increiblemente pequeño hoy en día, pero esto fue lo que se necesitó en su momento para comenzar con los lenguajes de alto nivel en las primeras PC. Cfront fue escrito en C con Clases y luego pasado a C++.

¿Hacia dónde le parece se encaminan los lenguajes de programación en el futuro?

"Es dificil realizar predicciones, en especial sobre el futuro". Obviamente, no lo sé, pero espero ver lenguajes de programación generales con mejores mecanismos de abstracción, mejor controles de tipos, y mejores facilidades para utilizar concurrencia. Espero que C++ sea uno de estos lenguajes. Van a existir infraestructuras y lenguajes corporativos complicados; va a aparecer toda una serie de lenguajes para dominios específicos, y existirán lenguajes tal como hoy que persisten sin cambios en algunos nichos. Nótese que estoy asumiendo una evolución importante de C++, más allá de C++0x. Creo que la comunidad de C++ es demasiado grande y activa como para que el lenguaje y su librería estándard se queden estáticas.

¿Tiene algún consejo para los futuros programadores?

Conozan las bases de la ciencia de la computación: algoritmos, arquitectura de máquinas, estructuras de datos, etc. No copien técnicas a ciegas de aplicación a aplicación. Sepan lo que están haciendo, cómo y porqué funciona. No crean que van a a saber cómo será la industria en 5 años o qué estarán haciendo entonces, así que creen y ármanse un portfolio de habilidades generales y útiles. Intenten escribir mejor código. Trabajen para hacer de la programación una actividad más profesional y menos de "hacking" de bajo nivel (la programación también es un arte, pero no sólo es un arte). Aprendan de los libros clásicos en el área y de manuales más avanzados; no se conformen con las simples guías de "cómo hacer" y la documentación online: en general, no es profunda.

Hay una sección en su página dedicada al "¿Realmente dijo eso?". ¿Qué frase de ahí lo persigue más?

No me siento perseguido. Posteo estas frases porque me siguen preguntando por ellas, así que prefiero aclarar la situación directamente. "C++ hace que sea más dificil dispararte en el pie, pero cuando lo hacés te vuela la pierna completa", generalmente se cita como una frase hostil hacia C++. Esto es llanamente inmaduro. Todas las herramientas poderosas pueden causar problemas si se usan mal, y se debe tener más cuidado que con herramientas menos potentes. Se puede realizar más daño (a uno y a otros) con un auto que con una bicicleta, con una sierra electrica que con un serrucho, etc. Esto es también cierto para otros lenguajes modernos: por ejemplo, es trivial causar problemas de memoria con Java. Los lenguajes modernos son herramientas potentes. Esta es la razón por la cual hay que tratarlas con respeto, y los programadores deben encarar sus tareas de manera profesional. Y no es un motivo para evitarlas, ya que las alternativas "más simples" son peores aún.

Llegó el momento para la pregunta obligada sobre los garbage collectors (GC). ¿Por qué las personas están tan interesadas en este aspecto?

Porque la gestión de recursos es la tarea más importante, porque algunos personas piensan (incorrectamente) que un GC es un signo de programación descuidada, y porque algunos personas piensan (incorrectamente) que los GC distinguen a los lenguajes buenos de los inferiores. Mi opinión sobre los GC es que pueden ser una herramienta muy útil, pero no son necesarios ni apropiados para todos los programas, por lo que un GC debería ser algo que se pueda utilizar opcionalmente en C++. C++0x refleja esta visión.

Mi visión de los GC es que yo creo que son la última aternativa para la administración de recursos, no la primera, y que es una herramienta más entre tantas otras para el diseño de un sistema, y no una herramienta fundamental para simplificar la programación.

¿Cómo recomienda que se administre la memoria en C++?

Mi recomendación es ver a la memoria como un recurso más entre otros (hilos, bloqueos, archivos, sockets), y representar cualquier recurso como un objeto de dicha clase. Por ejemplo, la memoria puede ser usada para mantener elementos de un container o caracteres de un string, por lo que debemos usar tipos como vector en lugar de hacernos lio con estructuras de bajo nivel (como ser un array de punteros a arrays terminados con cero) y manejar explíticamente la memoria. Aquí, tanto el vector como los string pueden ser manipuladores de recursos que automáticamente administran el recurso.

Cuando sea posible, recomiendo usar estos "manipuladores de recursos" como variables con alcance (scope) restringido. En este caso, no hay un uso incorrecto de gestión de memoria que el programador pueda hacer mal. Cuando la vida de un objeto no puede ser acotada, recomiendo otros esquemas simples, como el uso de punteros "inteligentes" (provsitos en C++0x), o representar la propiedad como miembro de una colección. Estas técnicas tienen la ventaja de que aplican uniformemente a todo tipo de recursos, y se integran bien con varios y distintos enfoques para administrar errores.

Sólo cuando estos enfoques se torna inmanejables, utilizaría un GC. Desafortunadamente, estas situaciones también son comunes, por lo que un GC sería una muy buena opción aunque no se integre limpiamente con la gestión de recursos generales. También, los GC se puede convertirse en un excelente detector de leaks si se les indica que informen sobre la basura encontrada.

Cuando se usa una gestión de recursos acotada y containers, se genera muy poca "basura" y un GC se torna en algo rápido. Este asunto está detrás de mi opinión "C++ es mi lenguaje de GC favorito porque genera muy poca basura".

Esperaba que un GC pudiera ser opcionalmente habilitado en C++0x, pero hubo muchos problemas técnicos así que tuve que conformarme con una especificación sobre cómo debería integrarse un GC al lenguaje, si fuera provisto. Como con casi todo respecto a C++0x, existe una implementación experimental.

Hay muchos más aspectos de GC más allá de los mencionados aquí, pero bueno, esto es una entrevista, no un libro.

En un lado ya menos serio, ¿cree que la barba está relacionada con el grado de éxito de los lenguajes de programación?

Supongo que si lo miramos filosóficamente todo está relacionado de alguna manera, pero en este caso fueron sólo el humor y la moda de esa época. Toda una generación anterior de diseñadores de lenguajes exitosos usaban barba: Backus (Fortran), Hopper (COBOL), y McCarthy (Lisp), como también Dahl y Nygaard (Simula y la Programación Orientada a Objetos).. En mi caso, soy pragmático: mientras vivía en climas más frios (Dinamarca, Inglaterra y New Jersey) usaba barba; ahora vivo en lugares cálidos, Texas, y decido no sufrir con una barba.

Por último, ¿hay algo más que quisiera agregar?

Si, creo que debemos considerar la relación entre las ideas y la educación. Toqué este tema más arriba, pero el problema de enseñar C++ a las personas y cómo usarlo bien resultó ser un tema tan dificil como diseñar e implementar el lenguaje. No tiene sentido hacer un buen trabajo técnico y no contarle a las personas. Por si mismas, las características de un lenguaje son estériles y aburridas; para que sean útiles, los programadores tienen que aprender cómo se pueden usar estas características de forma de cumplir algún ideal de programación, como ser la orientación a objetos o la programación generica.

Por supuesto que llevo escritos muchos documentos meramente técnicos, pero mucho de mi trabajo está apuntado a elevar el nivel de abstracción de los programaas, a mejorar la calidad de código, y a explicarle a las pesonas cómo funcionan las cosas, y porqué. Pedirle a un programador a que haga algo sin explicarle el motivo es tratarlo como si fueran chicos: deberían sentirse ofendidos por esto. Mis ediciones de "The C++ Programming Language", D&E, "Teaching Standard C++ as a New Language", y mis notas HOPL, son todos mis intentos de relacionar mejor mis ideales para C++, y de ayudar a madurar a la comunidad de C++. Por supesto que esto fue tan sólo exitoso en parte: todavía hay mucha programación de "cortar y pegar", código C++ de baja calidad, pero me siento alentado por la cantidad de buen código y la calidad de los sistemas producidos.

Últimamente, me fui desplazando de la industria hacia la academia, y ahora veo a los problemas educativos desde otro ángulo. Necesitamos mejorar la educación de nuestros desarrolladores de software. En los últimos 3 años, desarrollé un nuevo curso para principiantes (estudiantes de primer año, a menudo programadores por primera vez). Esto me dio la oportunidad de llegarle a una audiencia que antes no conocia. El resultado de esto es el libro "Programming: Principles and Practice using C++", que estará disponible en Octubre.

Traducido de la entrevista a Bjarne Stroustrup en Computerworld.