El problema con la programación
Bjarne Stroustrup, el inventor del lenguaje de programación C++, defiende su lenguaje y examina cuál es el problema con la mayor parte del código.
En los 80 y los 90, B.S: diseñó e implementó el lenguaje de programación C++, que popularizó la programación orientada a objetos e influenció a numerosos lenguajes de programación, incluyendo JAVA.C++ permanece como el arquetipo de lenguaje de programación de “alto nivel” (esto es, preserva las características de un lenguaje natural, humano), y es todavía usado por millones de programadores. Muchos de los sistemas y aplicaciones de la era de la PC y de Internet fueron escritos en C++. Por todo esto, el lenguaje es controvertido, en gran parte porque es notoriamente difícil de aprender y de usar, y también porque el diseño de B.S. permite a los desarrolladores cometer serios errores de programación en aras de preservar su libertad.Stroustrup, por muchos años un investigador de los laboratorios AT&T Bell, es actualmente profesor de ciencias de la computación en el Depto de Ingeniería, en la Universidad A&M, cerca de Houston.
T. R.: ¿Por qué la mayoría del software es tan malo?
B.S.: Una parte del software es realmente muy bueno según cualquiera de los estándares. Piensen en el Mars Rovers, Google, y el Proyecto del Genoma Humano. ¡Es software de calidad! 15 años atrás, la mayoría de la gente, y en especial la mayoría de los expertos, habrían dichoque cada uno de esos proyectos eran imposibles. Nuestra civilización tecnológica depende del software, entonces si el software hubiera sido tan malo como su pésima reputación, muchos de nosotros estaríamos muertos en este momento.Por otro lado, mirar el código “promedio” puede hacerme llorar. La estructura es espantosa, y los programadores claramente no piensan profundamente en la corrección, los algoritmos, las estructuras de datos, o manentibilidad. Mucha gente realmente no lee código, ellos solo ven a Internet Explorer o Windows “colgado”, su teléfono celular pierde las llamadas, leen la última historia del diario acerca de los virus y se estremecen.Yo pienso que el problema real es que “nosotros” (esto es, nosotros, desarrolladores de software) estamos en permanente estado de emergencia, corriendo para tener nuestro trabajo hecho. Llevamos a cabo muchos pequeños milagros por prueba y error, excesivo uso de la fuerza bruta, y montones y montones de pruebas, pero muchas veces no es suficiente. Los desarrolladores de software se convirtieron en adeptos al difícil arte de construir sistemas razonablemente fiables a partir de partes no fiables. El problema es que a menudo no sabemos exactamente cómo lo hicimos. Personalmente, yo prefiero saber cuándo un sistema va a funcionar y por qué lo hará.
T.R.:¿Cómo podemos arreglar la confusión en la que estamos?
B. S.: en teoría, la respuesta es simple: educar a nuestros desarrolladores de software mejor, usar métodos de diseño más apropiados, y diseñar pensando en la flexibilidad y el largo alcance. Premiar a los sistemas correctos, sólidos y seguros. Castigar el descuido. En la realidad, esto es imposible. La gente recompensa a los desarrolladores que entregan software barato, desaliñado, y primero. Esto es porque la gente quiere fantásticas nuevas cosas al instante. No quieren inconvenientes, no quieren aprender nuevas maneras de interactuar con sus computadoras, no quieren demoras en la entrega, y no quieren pagar extra por la calidad (salvo que sea una mejora obvia y a menudo aún así no). Y sin cambios reales en el comportamiento de los usuarios, los proveedores de software seguramente no cambiarán. No podemos parar el mundo por una década mientras reprogramamos todo, desde nuestra máquina de café hasta nuestros sistemas financieros. Por otro lado, salir del paso a duras penas es caro, peligroso y deprimente. Se necesitan mejoras significativas, y pueden venir sólo gradualmente. Deben venir en un amplio frente, ningún cambio aislado es suficiente.
Un problema es que las “chimeneas académicas” se meten en el camino: demasiada gente promueve un área como una panacea. Mejores métodos de diseño pueden ayudar, mejores especificaciones técnicas pueden ayudar, mejores lenguajes de programación pueden ayudar, mejores tecnologías de prueba pueden ayudar, mejores sistemas operativos pueden ayudar, mejores infraestructuras middle-ware pueden ayudar, mejor entendimiento de la estructura de datos y algoritmos pueden ayudar, y así de seguido. Por ejemplo, la teoría tipo, el desarrollo basado en el modelo, y los métodos formales pueden indudablemente proveer ayuda significativa en algunas áreas, pero promovidas como la solución para la exclusión de otros abordajes, cada una garantiza la falla en proyectos de gran escala. La gente promueve lo que sabe y lo que vieron funcionar. ¿Cómo podrían hacerlo de otra forma? Pero pocos tienen la madurez técnica para balancear las exigencias y los recursos.
TR: La idea detrás de C++ fue que los programadores trabajarían más arduamente en producir códigos más eficientes. Los laboratorios Bell querían un lenguaje que poca gente realmente lista usara para escribir códigos que corrieran en computadoras como los Electronic Switching Systems (ESS) que no eran muy rápidas. Hoy en día hay un montón de desarrolladores de software y las computadoras son muy rápidas. Habrá esto viciado el objetivo de C++ ?
B.S: C++ no fue diseñado específicamente para las grandes máquinas, sino para un amplio rango de aplicaciones. Laboratorios Bell era el hogar de un increíble rango de proyectos interesantes abarcando todas las escalas y usando esencialmente toda clase de computadoras y sistemas operativos. Pero sí, el programador promedio de Laboratorios Bell era significativamente más habilidoso que la noción de la gente de un “programador promedio”, y la autenticidad y el desempeño (en ese orden) eran consideradas significativamente más importantes que en la mayor parte de otros lugares.El desempeño es todavía un tema en muchas de las aplicaciones en las que estoy interesado: la correspondencia de interfaces, el tiempo de apertura y cerrado de las aplicaciones. Los desarrolladores de software han neutralizado el desempeño asombroso del moderno hardware de las computadoras agregando capa sobre capa de abstracciones (software) superelaboradas. Nos parece que hemos rozado el límite de la velocidad lineal para el hardware, pero en muchos casos, podríamos ganar un par de órdenes de magnitud con el software. Dicho esto, C++ se ha transformado en realidad en algo demasiado “amigablemente práctico” en un momento en que el grado de educación formal efectiva del desarrollador de software promedio ha declinado. Sin embargo, la solución no es silenciar los lenguajes de programación sino usar una variedad de lenguajes y educar más expertos. Debe haber lenguajes para esos expertos y C++ es uno de esos lenguajes.
TR: ¿Restrospectivamente, al diseñar C++, no fue un error fundamental, su decisión de negociar la eficiencia y seguridad del programador y la autenticidad del software por el desempeño del tiempo de corrida?
BS: Bueno, no creo que yo haya hecho tal compensación. Yo quiero el código elegante y eficiente. Algunas veces lo consigo. Estas dicotomías (entre eficiencia versus corrección), eficiencia versus tiempo del programador, eficiencia versus alto nivel, etc.) son falsas.Lo que yo hice fue diseñar C++ en primer lugar como un sistema de lenguajes de programación. Yo quería ser capaz de escribir drivers de dispositivos, sistemas embebidos, y otros programas que necesitaban usar el hardware en forma directa. Luego, yo quería que C++ fuera un buen lenguaje para diseñar herramientas. Eso requería flexibilidad y desempeño, pero también la habilidad para expresar interfaces elegantes. Mi punto de vista fue que para hacer material de alta calidad, para construir aplicaciones completas, necesitás primero comprar, construir o tomar prestadas bibliotecas que provean abstracciones apropiadas. A menudo, cuando la gente tiene problemas con C++, el problema real es que no tienen bibliotecas apropiadas o que no pueden encontrar las bibliotecas que están disponibles. Otros lenguajes trataron de soportar de manera más directa aplicaciones de alto nivel.Eso funciona, pero a menudo ese soporte viene a costa de la specialización. Personalmente, yo no diseñaría una herramienta que pueda hacer ólo lo que yo quiero. Yo apunto a la generalización.
TR: ¿Cómo explica el hecho de que C++ es ampliamente criticado y rechazado por muchos programadores y al mismo tiempo muy ampliamente usado? ¿Por qué es tan exitoso?
BS: La respuesta sencilla es: hay 2 tipos de lenguajes, los que todo el mundo critica y los que nadie usa.
Hay más sistemas útiles desarrollados en lenguajes considerados muy malos que en lenguajes elogiados por ser hermosos, muchos más. El propósito de un lenguaje de programación es ayudar a construir buenos sistemas, dónde “buenos” puede ser definido de muchas maneras. Mi definición breve es, correcto, mantenible, y adecuadamente rápido. La estética tiene que ver, pero primero y principal, un lenguaje tiene que ser útil; debe permitir a los verdaderos programadores del mundo expresar auténticas ideas mundanas sucinta y convenientemente.La principal razón del éxito de C++ es simplemente que satisface sus limitados propósitos de diseño: puede expresar un amplio rango de ideas directa y eficientemente. C++ no fue diseñado para hacer una cosa realmente bien o para evitar que la gente haga cosas consideradas “malas”. En cambio, yo me concentré en la generalidad y el desempeño.Yo estoy seguro de que por cada programador al que no le gusta C++, hay uno al que le gusta. Sin embargo, un amigo mío fue a una conferencia donde el orador principal le pidió a la audiencia que levantando la mano indiquen, primero, a cuánta gente le desagradaba C++, y segundo, cuánta gente había escrito un programa C++. Había casi 2 veces más gente en el primer grupo que en el segundo. Expresar el desagrado por algo que uno no conoce, es usualmente conocido como prejuicio. Además, los oponentes son a menudo más ruidosos y más seguros que los que proponen. La gente razonable reconoce las fallas. Yo pienso que conozco más acerca de los problemas de C++ que ninguno, pero también conozco cómo evitarlos y cómo usar las fortalezas de C++.
Y luego, por supuesto, ustedes no esperan que los que apoyan lenguajes que perdieron en la competencia con C++ sean corteses con él. El desarrollo de software no tiene el grado de profesionalismo que yo desearía que tuviera. La ciencia es diferente en este aspecto: cuando una nueva herramienta, técnica o teoría, triunfa, la gente ve esto como un progreso. En el software, las contribuciones de los competidores y predecesores no son ampliamente reconocidas, apreciadas, o aún entendidas.
TR: En The Design and Evolution of C++, usted proclamó que Kierkegaard fue una influencia en su concepción del lenguaje. ¿Es una broma?
BS: Un poco pretencioso puede ser, pero no una broma. Mucho del pensamiento acerca del desarrollo de software está focalizado en el grupo, el equipo, la compañía. Esto a menudo es hecho hasta el punto en que el individuo está totalmente sumergido en la “cultura” corporativa sin ninguna salida para los talentos y habilidades únicos. Las prácticas corporativas pueden ser directamente hostiles para los individuos con habilidades excepcionales e iniciativa en problemas técnicos. Yo considero tal conducción de gente técnica, cruel y despilfarradora. Kierkegaard fue un fuerte propulsor del individuo contra “la masa” y tiene alguna discusión seria acerca de la importancia del comportamiento estético y ético. No pude apuntar a una característica específica del lenguaje y decir: “Vean, allí está la influencia del filósofo del siglo diecinueve”, pero esa es una de las raíces de mi reticencia a eliminar las características de “nivel experto”, a abolir abusos, y a limitar las características que soportan sólo los usos que yo sé que son útiles. Sin embargo, no soy particularmente adepto a la filosofía religiosa de Kierkegaard.
TR: ¿De qué se lamenta más?
BS: ¡Nada de lamentos! Bueno, por supuesto sueño con lo que habría debido hacer en forma diferente y mejor, pero seriamente, ¿Quién soy yo para criticar, digamos, por ejemplo al “vintage” Bjarne de 1984? El puede haber sido menos experimentado que yo, pero él no era menos vivo, probablemente más vivo, y él tenía un mejor entendimiento del mundo de 1984 del que tenía yo. C++ fue usado para construir muchos sistemas que potencian nuestras vidas, y ha sido una influencia positiva y significativa en lenguajes y sistemas posteriores. Esto es algo para enorgullecerse.
Fuente:
No hay comentarios:
Publicar un comentario