¿ Qué propició el desarrollo de C++ ?
Necesitaba una herramienta para diseñar e implementar una versión distribuida del núcleo de Unix. En aquel tiempo, en 1979, no existía tal herramienta. Necesitaba algo que pudiera expresar la estructura de un programa, tratar directamente con el hardware, y ser lo suficientemente eficiente y portable para ser usado en la programación de sistemas serios.
Puede encontrar información más detallada sobre el diseño y evolución de C++ en mis papeles HOPL ( History of Programming Languages ) Historia de Lenguajes de Programación que puede encontrar en mis páginas , y en mi libro “Diseño y evolución de C++”.
¿ Había un problema en particular que intentabas resolver ?
Los dos problemas que tenía en la mente eran tratar de simular la infraestructura de comunicación entre procesos para un sistema distribuido o de memoria compartida ( determinar cuales servicios del sistema operativo podíamos ejecutar en procesadores diferentes ) y la necesidad de escribir los controladores de red para un sistema de esa magnitud. Obviamente como Unix estaba escrito en C también quería un alto nivel de compatibilidad con C. A inicios del 1980 en adelante, fue usado por otras personas ( ayudados por mi ) para simular varios algoritmos de protocolos de red y administración de tráfico.
¿ De donde proviene el nombre de C++ ?
Tal y como “C con clases” ( mi ancestro de C++ ) se volvió popular dentro de los laboratorios Bell ( Bell Labs ), algunas personas determinaron que ese nombre englobaba mucho para llamarlo C. Esto significaba que necesitaban calificar lo que ellos entendían cuando querían referirse al lenguaje de Dennis Ritchie, por eso usaron “Viejo C”, “C plano”, y otras variantes. Alguien halló esos calificativos como irrespetuosos a Dennis ( ni Dennis ni yo pensábamos así ) y un día recibí un pedido de los canales de administración de Bell Labs para encontrar un nombre mejor. Como resultado nos referimos a C++ como C84 por un tiempo. Eso no sirvió de mucho, por ello pedí sugerencias y elegí C++ de las propuestas. Todos acordamos que semánticamente ++C hubiera sido incluso mejor, pero pensé que crearía muchos problemas para aquellos “no geeks”.
¿ Había algún problema particularmente difícil o frustrante que hayas tenido que sortear en el desarrollo del lenguaje ?
¡¡ Muchos !! Para comenzar, ¿ cuales debieran ser las reglas de diseño fundamentales del lenguaje ? ¿ Qué debía estar dentro del lenguaje y qué no ? Muchas personas esperan un pequeño lenguaje que tenga todas las características útiles que hayan encontrado en cualquier otro lenguaje. Desafortunadamente, eso es imposible.
Después de un corto período dependiendo de la suerte y el buen gusto, me decidí por un juego de “reglas de oro” con la intención de asegurar que los programas en C++ pudieran ser simultáneamente tan elegantes ( como en Simula67, el lenguaje que introdujo programación orientada a objetos ) como eficientes para la programación de sistemas ( como en C ).
Obviamente, no todos los programas pueden ser las dos cosas y muchos ni son una, pero la intención era y es que un programador competente pudiera ser capaz de expresar cualquier idea directamente y ejecutarla con dificultades mínimas ( cero dificultades comparadas con una versión en C ).
Convencer a la comunidad de programación de sistemas del valor del chequeo de tipo fue sorprendentemente difícil. La idea de comprobar argumentos de funciones contra la declaración de una función fue resistida ferozmente por muchos, al menos hasta que C adoptó la idea de “C con clases”.
Hoy en día, la programación orientada a objetos está casi en todos los lugares, así que es difícil que las personas crean que simplemente fallé en convencer a las personas sobre su utilidad hasta que finalmente puse las funciones virtuales y demostré que eran lo suficientemente rápidas para su uso. La variante de C++ de POO ( Programación Orientada a Objetos ) era y es simplemente aquella de Simula con algunas simplificaciones y mejoras en rendimiento.
La compatibilidad con C era y es una fuente grande tanto para problemas como para fortalezas. Siendo compatible con C, los programas de C++ garantizaban un nivel de completamiento de funcionalidades que frecuentemente faltan en las primeras versiones de lenguajes nuevos y un acceso directo ( y eficiente ) a grandes partes de código, no sólo código en C, pero también en Fortran y más pq el mecanismo de las convenciones de llamadas en C eran simples y similares a lo que otros lenguajes soportaban. Después de todo, solía decir, reusen comienzos usando algo que ya exista, y no esperen para que alguien termine el desarrollo de componentes nuevos intencionados a la reutilización. Por otra parte, C tiene muchas rarezas sintácticas y semánticas y mantenerse acoplados con C a medida que se ha desarrollado no ha sido fácil.
¿ Cuáles son las diferencias principales entre el “C con clases” original y C++ ?
Muchas de las diferencias estaban en la técnica de implementación. C con clases fue implementado por un preprocesador, mientras que C++ requiere un compilador apropiado ( por eso creé uno ). Fue fácil transcribir programas en C con clases hacia C++, pero los lenguajes no eran 100% compatibles. Desde el punto de vista de un lenguaje, la mejora principal fue proveer funciones virtuales que habilitaron POO clásica. Sobrecarga ( incluso sobrecarga de operadores ) fue añadida también, gracias también a un mejor soporte de código en línea. Quizás sea importante notar que las características claves de C++ para manejo de recursos, constructores y destructores, estaban en la versión más temprana de C con clases. Por otra parte, las plantillas ( y excepciones ) fueron introducidas en una versión superior de C++ ( 1989 ). Antes de eso usamos macros para expresar ideas de programación genérica.
¿ Hubiera hecho algo diferente en el desarrollo de C++ si hubiera tenido la oportunidad ?
Esta pregunta común es un poco injusta porque por supuesto no tenía los beneficios de casi 30 años de experiencia con C++ en aquel entonces, y mucho de lo que sé ahora es el resultado del experimento con versiones anteriores de C++. También, tenía casi ningún recurso en ese momento ( sólo yo, a medio tiempo ) por eso sugiero que las funciones virtuales, plantillas ( con conceptos similares a lo que C++0x ofrece ), y el manejo de excepciones hubieran hecho de C++85 un lenguaje mucho mejor. Sugeriría no solamente algo que no supe diseñar a principios de los 80′ sino también algo que , si hubiera descubierto milagrosamente el diseño perfecto, no hubiera podido realizarlo en un tiempo razonable.
Creo que liberar una mejor biblioteca estándar con C++1.0 en 1985 hubiera sido casi factible y hubiera sido la mejora más significativa de su tiempo. Al referirme a una “mejor biblioteca” me refiero a una con una biblioteca de clases bases que incluyan una versión ligeramente mejorada del ( en aquel entonces disponible ) biblioteca de tareas para el soporte de concurrencia y un juego de clases contenedoras. Liberando aquellas hubieran propiciado el desarrollo de mejores versiones y hubiera establecido una cultura del uso de bibliotecas bases estándares y no aquellas de índole corporativas.
Más adelante hubiera desarrollado plantillas ( la clave del estilo de C++ de programación genérica ) antes de herencia múltiple ( no una funcionalidad tan aceptada como las personas la consideran ) y hubiera enfatizado un poco más en excepciones. Sin embargo, las excepciones nos traen nuevamente a un problema. Algunos de los conceptos más importantes subyacentes en el uso modernos de plantillas en C++ no existieron hasta un tanto después. Por ejemplo el uso de “garantías” en la descripción del uso seguro y sistemático de plantillas fue solo desarrollado durante el proceso de estandarización de C++ por Dave Abrahams.
¿ Cómo te sientes por el hecho de que C++ se haya estandarizado en 1998 y cómo estuviste involucrado en el proceso de estandarización ?
Trabajé duro para alcanzar ese estándar durante años ( 1989-1997 ) tanto como ahora que estoy trabajando en su sucesor : C++0x. Manteniendo un lenguaje de flujo principal lejos de su fragmentación en dialectos en disputa es una tarea dura y esencial. C++ no tiene dueño, ni mantenedor preferido para proveer fuerza de impulso, bibliotecas “gratis” o publicidad comercial. El comité de estándares ISO fue importante en el crecimiento de la comunidad de C++ y esa comunidad le debe un enorme monto a los muchos voluntarios que trabajaron y trabajan aún en ese comité.
¿ Cuál es el programa más interesante que ha visto escrito en C++ ?
No puedo elegir uno, y usualmente no veo a un programa como interesante. Me fijo más en sistemas completos, de los cuales sus partes están hechas en C++. Entre aquellos sistemas está el subsistema autónomo de conducción del “Mars Rovers” de NASA, el sistema de búsqueda de Google y el sistema de reservación de aerolínea de Amadeus. Mirando a un pedazo de código aislado, pienso que la STL de Alexander Stepanov ( los contenedores, los iteradores, y bibliotecas parte de la biblioteca estándar de C++ ) está entre los más interesantes, útiles y más influyentes que he visto.
Se siente a veces que un número grande de programadores nunca han usado en realidad las plantillas incluso sin programar en C++.
Puede que tengas razón al respecto, pero muchos al menos, creo que la mayoría están usando plantillas a través de la STL ( o bibliotecas bases similares ) y sospecho que el número de programadores que evitan plantillas están declinando rápidamente.
¿ Por qué crees que ocurra esto ?
Por miedo a usar algo que sea diferente a lo que usan, rumores de ineficiencias en el código, problemas de vinculación potenciales y mensajes de error espectaculares.
¿ Desearías que el compilador GNU C++ pudiera proveer errores de sintaxis del compilador más cortos para no asustar a los estudiantes ?
Por supuesto, pero no toda la culpa es de GCC. El problema fundamental es que C++98 no provee una vía para el programador especifique directa y simplemente los requerimientos de una plantilla en sus tipos. Ello es una debilidad del lenguaje, no del compilador, y sólo puede ser manejada a través de un cambio en el lenguaje que será parte de C++0x.
Me refiero a conceptos que permitirán que los programadores de C++0x especifiquen los requerimientos de los juegos de argumentos de plantilla y que se comprueben todos los puntos de llamada y de definición aislados al igual que cualquier otra comprobación de tipo del lenguaje. Para más detalles consulten cualquiera de los documentos de C++0x o “Concepts: Linguistic Support for Generic Programming in C++” ( Conceptos: Soporte lingüístico para programación genérica en C++ ) por Doug Gregor de OOPSLA ’06 ( disponible de mi página de publicaciones ). Una instrumentación experimental puede ser descargada desde el sitio de Doug Gregor .
Hasta que los “conceptos” estén universalmente disponibles, podemos usar “clases de restricción” para mejorar dramáticamente la comprobación. Vean los FAQ técnicos.
La STL son unas de los pocas ( sino las únicas ) bibliotecas de propósito general para los cuales los programadores pueden ver garantías de complejidad. ¿ Por qué crees que sea esto ?
La STL está por lo general adelantada a su tiempo. Es duro proveer las garantías correctas y muchos diseñadores de bibliotecas prefieren emplear sus esfuerzos en funcionalidades más visibles. Las garantías de complejidad son básicamente un intento entre muchos para asegurar calidad.
En los últimos años, hemos visto a la computación distribuida estar más disponible al programador promedio. ¿ Cómo esto afectará a C++ ?
Es difícil decir, pero antes de tratar con programación distribuida, un lenguaje debe soportar concurrencia y ser capaz de manejar con más de un modelo de memoria convencional “lineal/uniforme”. C++0x hace exactamente eso. El modelo de memoria, los tipos atómicos, y el almacenamiento local provee las garantías necesarias para soportar una buena biblioteca de hilos. En resumen, C++0x permite el uso básico y eficiente de varios núcleos. Necesitamos también modelos de concurrencia de mayor nivel para la explotación fácil y efectiva de la concurrencia en nuestras aplicaciones. Las características del lenguaje así como las “funciones objetos” ( disponible en C++98 ) y los lambdas ( una característica de C++0x ) ayudarán en eso, pero necesitamos proveer soporte más allá de la vista de concurrencia “dejar un montón de hilos sueltos en un espacio de memoria común“, la que considero necesaria como infraestructura y la peor vía de organizar aplicaciones concurrentes.
Como siempre, la aproximación de C++ es proveer primitivas y mecanismos de abstracción muy general ( y eficientes ), los que se usan entonces para construir abstracciones de mayor nivel como bibliotecas.
Por supuesto no tiene pq esperar por C++0x para hacer programación concurrente en C++. Muchos han estado haciendo eso durante años y mucho de lo que ofrece el nuevo estándar relacionado con concurrencia está disponible actualmente al igual que las formas antes del estándar.
¿ Vé que esto lleve a la creación de una nueva generación de lenguajes de propósito general ?
Muchos de los “lenguajes scripting” proveen mecanismos para manejar estados en un ambiente Web, y esa es su fortaleza real. Manipulación simple de texto es fácilmente igualada por bibliotecas como las nuevas bibliotecas de expresiones regulares de C++ ( disponible ahora en boost.org ) pero es difícil concebir un lenguaje que sea de propósito general y distribuido. La raíz de ese problema es que la programación conveniente distribuida cae en la simplificación y especialización. Un lenguaje de propósito general no puede simplemente proveer un modelo de distribución de alto nivel.
No veo una razón fundamental en contra de que un lenguaje de propósito general sea extendido con facilidades de distribución, sin embargo, he discutido que C++0x haga exactamente eso. Pienso que eventualmente todos los lenguajes mayores conocidos proveerán algún soporte para distribución a través de la combinación de soporte directo de lenguaje, soporte en tiempo de ejecución, o bibliotecas.
¿ Cree que los recursos como las bibliotecas de boost proveerán funcionalidad / accesibilidad para C++ ?
Algunas de las bibliotecas de boost, especialmente la biblioteca de redes, son un buen comienzo. Los hilos estándares de C++0x se parecen más a los hilos de boost. Si es posible, un programador de C++ debería comenzar con una biblioteca existente ( y, o herramienta ), y no construir directamente en características fundamentales y/o hilos del sistema.
¿ En su opinión, qué legado ha traído C++ al desarrollo informático ?
C++ trajo POO al flujo principal y está haciendo lo mismo con programación genérica. Si observa algunos de los códigos más exitosos en C++, especialmente relacionados con manejo general de recursos, encontrarás que los destructores son centrales e indispensables en el diseño. Sospecho que el destructor será visto como la contribución individual más importante. Todo lo demás recae en combinaciones de las características del lenguaje y técnicas en el soporte de un estilo de programación o combinaciones de estilos de programación.
Otra forma de mirar el legado de C++ es que hizo a la abstracción manejable y costeable en áreas de la aplicación donde antes las personas necesitaban programar directamente en términos de máquina, como bits, bytes, palabras y direcciones.
En un futuro, apunto a una mejor articulación de los ideales de generalidad, elegancia y eficiencia.
¿ Donde ves que se encuentra el futuro de C++ ?
Mucho de donde C++ ha tenido su fortaleza desde el primer día han sido aplicaciones con un componente informático crítico, especialmente para infraestructura. Hoy en día, todas las infraestructuras ( incluyendo la instrumentación de todos los lenguajes de alto nivel ) están en C++ o C y espero que así se mantenga. También, la programación en los sistemas empotrados es un área de mayor uso y crecimiento para C++, por ejemplo el software para la próxima generación de aviones de guerra de EEUU están en C++ ( vea reglas de codificación JSF++ en mi sitio web ). C++ provee más donde simultáneamente necesitas rendimiento y abstracciones de alto nivel, especialmente bajo restricciones de recursos. Curiosamente esta descripción se fija tanto para un iPod como para una aplicación científica a gran escala.
¿ Te ha sorprendido en alguna manera la evolución y popularidad del lenguaje ?
Nadie, con la posible excepción de Al Aho, previsó la escala del triunfo de C++. Supongo que durante 1980 yo estaba simplemente demasiado ocupado incluso para estar sorprendido: El uso de C++ se duplicaba cada 7.5 meses, calculé después, y eso fue hecho sin un departamento comercial dedicado, con casi nadie y con un presupuesto ajustado. Apunté a la generalidad y eficiencia y fue exitoso más allá de cualquier espectación.
Por cierto, ocasionalmente me encuentro con personas que asumen que, porque defiendo a C++ de sus detractores, debo creer que es perfecto. Eso obviamente es absurdo. C++ tiene muchas debilidades, y las conozco mejor que nadie, pero todo el propósito del diseño y ejercicio de la instrumentación no era no cometer errores ( eso es imposible a tan gran escala, y con restricciones de diseño tan draconianas ). La meta era producir una herramienta que, en manos competentes, sería efectiva para la construcción de sistemas de la vida real. En ello, sí tuve éxito más allá de mis sueños.
¿ Cómo responde ante críticas del lenguaje, como que ha heredado las fallas de C y que tiene muchas funcionalidades que lo hacen demasiado pesado ?
C++ heredó las fortalezas y debilidades de C y creo que hemos hecho un trabajo decente compensando las debilidades sin comprometer las fortalezas . C no es un lenguaje simple ( su estándar ISO son más de 500 páginas ) y muchos de los lenguajes modernos son más grandes aún. Obviamente, C++ como C está cargado comparado con lenguajes de juguete, pero no tan grande comparado con otros lenguajes modernos. Existen razones prácticas de porque todos los lenguajes usados para trabajo industrial serio hoy en día están cargados: las tareas para las cuales se usan son grandes y complejas.
Otra razón del tamaño tan incómodo de los lenguajes modernos es la necesidad de estabilidad. Escribí código de C++ hace 20 años que aún corre hoy en día y estoy confiado que aún compilará y correrá dentro de otros 20. Las personas que construyen proyectos de infraestructura grandes necesitan tal estabilidad. Sin embargo, para permanecer moderno y aceptar nuevos retos un lenguaje debe crecer ( o en funcionalidades o en clases bases ), pero si elimina algo rompe el código. Por tanto, los lenguajes que se construyen con preocupaciones serias para sus usuarios ( como C++ y C ) tienden a acometer funcionalidades en décadas y se vuelven cargados. La alternativa son bellos lenguajes para los cuales tienes que reescribir tu código cada 5 años.
Finalmente, C++ deliberadamente y desde el primer día soportó más de un estilo de programación y la interacción de esos estilos. Si cree que existe sólo un estilo de programación que se aplica mejor para todas las aplicaciones y todas las personas, por ejemplo POO, entonces tiene una oportunidad para simplificar. Sin embargo, creo firmemente, que las mejores soluciones, las más legibles, mantenibles, eficientes para grandes clases de problemas requieren más de uno de los populares estilos de programación, como por ejemplo POO y programación genérica. Así que el tamaño de C++ no puede minimizarse soportanto sólo un estilo de programación. Este uso de combinaciones de estilos de programación es una parte clave de mi vista de C++ y una gran parte de su fortaleza
¿ De qué te enorgulleces más en términos del desarrollo inicial del lenguaje y su uso continuo ?
Estoy orgulloso que C++ ha sido usado para tantas aplicaciones que han ayudado hacer al mundo un mejor lugar. A través de C++ he hecho una pequeña contribución al proyecto del genoma humano, a física de energías altas ( C++ se usa en CERN, Fermilab, SLAC, etc … ), exploración espacial, energía eólica. Puede encontrar una lista corta de aplicaciones hechas en C++ en mi sitio. Siempre me alegro cuando escucho del uso del lenguaje en pro del bien.
Estoy orgulloso que C++ ha ayudado a mejorar el nivel de la calidad del código en general, no sólo C++. Lenguajes más recientes como Java y C# han sido usados con técnicas que C++ hicieron aceptables para uso de la vida real y comparados con códigos desde hace 20 años muchos de los sistemas de los que dependemos hoy son increiblemente confiables y han sido construidos con un grado razonable de economía. Obviamente, podemos y debemos hacer algo mejor, pero podemos tener una medida de orgullo en el progreso que hemos hecho hasta ahora.
En términos de contribución personal directa, me alegró poder construir el primer compilador de C++: Cfront, de poder compilar programas de la vida real en 1MB en una máquina de 1MHz. Eso es por supuesto increiblemente pequeño por el estándar de hoy, pero eso es lo que requería para que lenguajes de alto nivel empezaran en las computadoras más tempranas. Cfront fue escrito en C con clases y luego transcribido a ( las primeras versiones de ) C++.
¿ A dónde ve que se dirigen los lengujes de programación en el futuro cercano ?
Es difícil hacer predicciones, especialmente acerca del futuro. Obviamente, no lo sé, pero espero que veremos lenguajes de programación de propósito general con mejores mecanismos de abstracción, mejor chequeo de tipos, y mejores facilidades para explotar la concurrencia. Espero que C++ sea uno de esos. Existirán también lenguajes e infraestructuras corporativas cargadas, existirán galerías de lenguajes específicos o de dominio específico, y existirán lenguajes como los conocemos hoy en día persistiendo sin cambios por separados. Note que estoy asumiendo una evolución significativa de C++ más allá de C++0x. Creo que la comunidad de C++ es muy grande y vigorosa para el lenguaje y su biblioteca estándar para que se convierta esencialmente estático.
¿ Tiene algún consejo para los programadores que están por venir ?
Conozcan los fundamentos de la ciencia de la computación: algoritmos, arquitecturas de máquina, estructura de datos, etc … No copie simplemente técnicas de aplicación en aplicación. Sepa lo que hace, que funciona y por qué funciona. No crea saber que la industria será como existe dentro de 5 años, o lo que hará en ese entonces, así que almacene un grupo de habilidades útiles y generales. Trate de escribir un código mejor y mejor fundamentado. Trabaje para que la “programación” sea una actividad profesional y menos una actividad de “hack” a bajo nivel ( programar es también un arte, pero no sólo eso ). Aprenda de los clásicos en el tema y los libros más avanzados, no esté satisfecho con los más fáciles “How to’s” ( Cómo se hace ), guías y documentaciones en línea, son superficiales.
Existe una sección en su sitio dedicada a “¿En realidad dijo eso?” ( Did you really say that ? ) ¿ Qué cita de ella regresa para perseguirle más ?
No me siento perseguido. Escribí esas citas porque las personas me preguntan mucho por ellas, así sentí que era mejor publicarlas. “C++ hace más difícil que se dispare en el pie, pero cuando lo hace le arranca la pierna entera” a veces se cita de manera hostil hacia C++. Eso sólo muestra inmadurez. Cada herramienta puede traerle problemas si la usa indebidamente y debe tener más cuidado con una más poderosa: puede hacer más daño ( a usted y los demás ) con un carro que con una bicicleta, con una sierra eléctrica que con un serrucho. Lo que dije en esa cita también se cumple para otros lenguajes modernos. Por ejemplo es trivial causar agotamiento de memoria en Java. Los lenguajes modernos son herramientas. Es una razón para tratarlos con respeto y para los programadores que se acerquen a sus tareas con una actitud profesional. No es una razón para evitarlos porque las alternativas de bajo nivel son peores.
Una pregunta obligatoria sobre recolección de basura, ya que estamos casi al final, y pareces recibir este tipo de preguntas a menudo. ¿ Por qué crees que las personas están tan interesadas en este aspecto del lenguaje ?
Porque el manejo de recursos es un tema muy importante, porque algunas personas erróneamente ven la recolección como una señal de programación sucia y derrochadora, y porque otras lo ven erróneamente también como una funcionalidad que distingue los buenos lenguajes de los demás. Mi vista al respecto es que puede ser una herramienta muy útil pero que no es esencial ni apropiada para todos los programas, y por tanto debería verse como algo que puede usar opcionalmente en C++. C++0x refleja ese concepto.
Mi opinión difiere de muchos en que lo veo como una última opción de manejo de recursos, no la primera, y lo veo como una herramienta entre muchas para diseño de sistemas y no una herramienta fundamental para la simplificación.
¿ Cómo recomienda que se haga el manejo de memoria en C++ ?
Mi consejo es que se vea la memoria sólo como un recurso entre muchos ( por ejemplo manejo de hilos, bloqueos, manejo de ficheros, conectores ) y representar cada recurso como un objeto de una clase. Por ejemplo, la memoria puede ser usada para almacenar elementos de un contenedor o caracteres de una cadena, por ello debemos usar tipos como un vector.
Donde sea posible recomiendo el uso de tales manejadores de recursos simplemente como variables en un ámbito. En ese caso, no hay manejo explícito de memoria en la que un programador pueda equivocarse. Cuando el tiempo de vida de un objeto no puede ser fácilmente declarado en un ámbito recomiendo otro esquema sencillo como usar punteros “inteligentes” o smart pointers ( declarados apropiadamente en C++0x ) o representar su dueño como miembro de alguna colección ( esa técnica se usa en sistemas empotrados con tiempo dracónico y requerimientos de espacio ). Estas técnicas tienen las virtudes de aplicarse uniformemente a todos los tipos de recursos y su fácil integración con un grupo de acercamientos de manejo de errores.
Sólo donde tales aproximaciones se vuelvan inmanejables, como un sistema sin una arquitectura de manejo de recursos o de errores o para un sistema lleno de operaciones de reserva explícitas, aplicaría la recolección de basura. Desafortunadamente tales sistemas son muy comunes, por ello considero esto un caso muy fuerte para la recolección aunque no se integre limpiamente con el manejo de recursos general. También, si un recolector puede ser instrumentado para reportar qué basura vaya encontrando, se convierte en un excelente detector de fugas.
Cuando se use un manejo de recursos y contenedores en un ámbito, se genera poca basura y el recolector se vuelve muy rápido. Tales preocupaciones apoyan mi opinión que “C++ es mi lenguaje recolectado de basura preferido porque genera poca basura”.
Esperaba que opcionalmente un recolector de basura se habilitara como parte de C++0x pero habían suficientes problemas técnicos que tengo que resolver de como se integra ese tipo de recolector con el resto del lenguaje si se provee. Tal como es el caso con casi todas las funcionalidades de C++0x, existe una instrumentación experimental.
Hay muchos aspectos de la recolección de basura más allá de lo que cubro aquí, pero después de todo, esto es una entrevista no un libro de texto.
En un tono menos serio, ¿ piensa que los vellos faciales están relacionados con el éxito de los lenguajes de programación ?
Creo que si lo llevamos a un nivel filosófico todo está relacionado, pero en este caso sólo tenemos el humor y la moda de los tiempos. Una generación más temprana de diseñadores de lenguajes exitosos no tenía barba: Backus (Fortran), Hopper (COBOL), y McCarthy (Lisp), así como Dahl y Nygaard (Simula y POO ). En mi caso sólo soy pragmático, mientras vivía en climas más fríos ( Dinamarca, Inglaterra y Nueva Jersey ), usaba barba; ahora vivo en un lugar muy cálido, Texas y elijo no sufrir bajo una barba. Interesantemente, la foto que usan para ilustrar un estado intermedio de mi barba no hace tal cosa. Me muestra visitando Noruega y revirtiendo a un estado de tipo frío por unos días. ¿ Quizás haya otras relaciones interesantes ? Quizás haya una entre la altura de los diseñadores y éxito de los lenguajes. Quizás haya una relación entre éxito de lenguajes y la apreciación de Monty Python. Alguien podría divertirse haciendo un poco de investigación al respecto.
¿ Por último hay algo más que quisiera añadir ?
Sí, creo que debemos considerar la articulación de las ideas y la educación. He tocado esos temas en algunos momentos antes, pero los problemas para que las personas entiendan lo que C++ debió ser y cómo usarlo era al menos tan difícil y costoso como diseñarlo e implementarlo. No tiene sentido hacer un buen trabajo técnico y no contarle a las personas al respecto. Por sí solos, las funcionalidades de los lenguajes son estériles y aburridas, para que sean útiles los programadores deben aprender como pueden ser usadas en combinación para servir algún ideal de la programación, como programación genérica u orientada a objetos.
He por supuesto, escrito muchos papeles técnicos pero muchos de mis escritos han estado encaminados a aumentar el nivel de abstracción de los programas, mejorar la calidad del código y ayudarle a entender a las personas qué funciona y por qué. Pedirle a los programadores que hagan algo sin darle una razón es tratarlo como niños pequeños, debieran ofenderse por ello. Las ediciones de “The C++ Programming Language”, D&E, “Teaching Standard C++ as a New Language”, y mis escritos HOPL están entre mis intentos de articular mis ideas para C++ y ayudar a la comunidad de C++ a que madure. Por supuesto, eso ha sido sólo exitoso parcialmente. todavía hay mucha programación de “corta y pega” que se continúa haciendo y hay bastante código en C++ pobre, pero me anima la cantidad de buen código y el número de sistemas de calidad que se están produciendo.
Últimamente me he movido desde la industria a la academia y veo los problemas educacionales desde otra perspectiva. Necesitamos mejorar la educación de nuestros desarrolladores de software. En los últimos 3 años he desarrollado un nuevo curso para estudiantes de primer año ( a menudo programadores principiantes ). Esto me ha dado la oportunidad de atender un público que antes no he conocido muy bien y el resultado es un libro de principiantes “Programming: Principles and Practice using C++” disponible en Octubre.
ter@tux 