Me gustaría hablar de los legados que nos han dejado C++ y Java. Se menciona muchas veces errores en el diseño de ambos, aunque si hacemos una retrospectiva en forma positiva podemos concluir que los dos lenguajes tuvieron un papel importante en la evolución de los lenguajes de programación y nos han dejado un legado importante y positivo.
Entonces, ¿no será muy temprano para hablar de sus legados? ¿O quizás pensamos que estos lenguajes están ya en su período de decadencia?
C++
Eckel, un miembro formado de C++ Standadrs Committee recordó la decisión tomada en relación a la compatibilidad con versiones anteriores del lenguaje con C desde el comienzo:
Para comprender porqué el lenguaje puede ser desagradable y complicado, y a la vez contar con un buen diseño, es necesario tener en cuenta la primer decisión de diseño que afecta a todo en C++: compatibilidad con C. Stroustrup deció -y al parecer de forma correcta- que la forma de hacer que la gran masa de programadores de C cambien a objetos era hacer que eso fuese transparente: permitir que ellos pudiesen compilar sus códigos en C sin tener que cambiarlos para C++.
Mientras que C++ ha tenido éxito en atraer a la mayoría de los desarrolladores de C a C++, la decisión sobre la compatibilidad tiene un severo impacto negativo en la evolución del lenguaje:
Lla compatibilidad con C fue una gran limitación, y siempre ha sido la mayor fuerza de C++ … y su perdición. Eso es lo que ha hecho que C++ fuera un éxito y eso es lo que hizo que fuese complejo de la forma que lo es.
Por ejemplo, reconoce que el operador de sobrecarga es difícil de utilizar en C++:
Quienes no entienden C++ muy bien piensan que la sobrecarga de operadores es muy difícil para que los desarrolladores la usen de forma adecuada. Lo qué es básicamente cierto en C++, porque C++ tiene ambas: reserva de pila y reserva de heap, precisamos sobrecargar los operadores para poder manejar todas las situaciones y no causar pérdidas de memoria. De hecho, eso es difícil.
Por supuesto, estas declaraciones generan un debate. Archilleas Margaritis no cree que la compatibilidad con C sea un problema:
No creo que C++ no tenga un buen diseño debido a la compatibilidad con C. ADA es compatible con C, y es un lenguaje muy bueno, con un fuerte liderazgo de su concepción de ingeniería.
Lo que está mal en C++ es el nivel de compatibilidad de código fuente con C. Para que fuese posible incluir las cabeceras de C, C++ mantiene el sistema preprocesador de C. Esto llevó a una gramática extraña y sin contexto, lo que llevó a una sintaxis extraña que se tiene que mantener compatible con C.
Michele Costabirle considera que una de las fallas de C++ fue la falta de una librería normalizada desde el principio:
Creo que una pesada carga de C++ es la falta de una librería normalizada.
Si recuerdo bien, Stroustroup escribió en “El Diseño y la Evolución de C++”, que dejó de lado una librería normalizada en favor de la herencia múltiple. Creo que hubiera sido más ventajoso de la otra manera.
Se pueden decir muchas cosas respecto a C++, pero una cosa es cierta: C++ llevó a los programadores a subir un más alto en la escalera de la programación.
Java
Hablando de un lenguaje diferente en el mismo tono, Eckel reitera algunos errores de diseño cometidos en Java:
Durante muchos años, la línea del equipo de Java fue “la sobrecarga de operadores es algo demasiado complicado”. Esta y muchas otras decisiones muetran claramente que alguien no hizo la tarea en su casa, y es el motivo por el cual tengo la reputación de criticar muchas decisiones tomadas por Gosling y el equipo de Java. …
Los tipos primitivos “tienen que ser incluidos por eficiencia.” La respuesta correcta sería la de permanecer fiel a “Todo es un objeto” y proporcionar algún truco para realizar actividades de bajo nivel cuando hay una necesidad de eficiencia (lo que es cierto para tecnologías hotspot, que hacen las cosas más eficientes de una manera transparente, como evetuamente ocurriría) . Ah, y de paso no vayamos a utilizar el procesamiento de puntos flotantes directamente para calcular funciones transcedentales (en cambio, eso se hace en el software). …
Cuando escribí acerca de qué tan malo se hizo el diseño de los generics, obtuve la misma respuesta, junto con “tenemos que tener compatibilidad con las (demás) decisiones tomadas en Java anteriormente.” Últimamente cada vez más personas han adquirido experiencia con generics para ver cómo es realmente difícil de utilizar.
Bill Venners recuerda las cosas de manera diferente:
No estoy seguro de cuando me dio la impresión de que la elección de dejar la sobrecarga de operadores de lado fue hecha porque alguien no hizo la tarea en casa. Recuerdo preguntar a Gosling en una de mis entrevistas con él porque estaba dejando la sobrecarga de operadores de lado (no creo que esta pregunta y respuesta acabaran siendo publicada). Lo que él básicamente dijo fue lo mismo que le oí decir en otros contextos: Gosling consideró que el nivel de abuso de la sobrecarga de operadores que él vio en la práctica en otros lenguajes (no estoy seguro de si se estaba refiriendo sólo a C++ pero sin duda incluía a C++) había anulado los beneficios de la misma. Eso es todo. Fue una elección subjetiva de diseño.
James Watson favorece las limitaciones deliberadamente introducidas en Java:
Lo que hizo a Java un lenguaje de fácil adopción fue su simplicidad. Sí, en cualquier lenguaje podemos escribir código que es imposible de mantener, pero tendremos que trabajar duro para hacerlo en Java. Esto es porque no se ofrecen una serie de recursos fáciles de abusar, que otros lenguajes si ofrecen.
Desde una perspectiva individual, esto es terrible. Si no quiero utilizar una funcionalidad no la uso. ¿Quién es Sun para decirme lo que debo o no debo hacer? Pero cuando se considera a todo un grupo de desarrolladores que tienen ideas diferentes spbre lo que es un buen enfoque, el juego cambia. El tener un número limitado de formas de hacer las cosas comienza entonces a tener sentido.
Noel Grandin dijo lo suyo, ampliando aún más el debate incluyendo a nuevos lenguajes:
La mayoría de los otros lenguajes atrayentes como Ruby y Scala nunca serán los principales, y es proque están todos fuertemente sesgados en favor de escribir código, en lugar de leer código.
Java es correctamente equilibrado – Java puede ser expresivo y no tener una serie de funcionalidades legadas, y es muy fácil de averiguar lo que algún código aleatorio está haciendo.
Al final, Eckel habló sobre el legado de Java:
Java acercó el mundo del garbage collection a la mayoría de los desarrolladores, también a las máquinas virtuales y un modelo consistente de manipulación de errores (especialmente, si dejamos de lado las checked exceptions, que es una que puede ser utilizada como he mostrado en Pensando en Java, 4e) . Con todas sus fallas, Java nos elevó a un nivel superior, hasta al punto donde estamos ahora, y listos para lenguajes de niveles más altos.
El factor más positivo es preparar el camino para los lenguajes del futuro:
En cierto modo, C++ fue el lenguaje principal y las personas pensaron que siempre sería así. Muchos pensaron lo mismo respecto de Java, pero Java hizo tadavía más fácil sustituirse a sí mismo, a causa de la JVM. Ahora es posible que cualquiera cree nuevos lenguajes y los ejecute con tanta eficiencia como Java. … …
Y estamos viendo ocurrir esto – con lenguajes de alto nivel como Scala, y con lenguajes dinámicos como Groovy, JRuby y Jython. … …
El beneficio no es intencional, el verdadera brillo o genialidad accidental de Java es que fue creando un camino para su propia sustitución, aunque el propio Java haya alcanzado un punto donde ya no pueda evolucionar. Todos los lenguajes del futuro tienen que aprender de eso: crear una cultura en la que pueda haber refactorización (como Python y Ruby han hecho) o permitir el crecimiento de especies competitivas.
Conclusión
Java encendió muchas controversias cuando apareció, especialmente entre los desarrolladores de C++ y los nuevos desarrolladores de Java. Las voces se han calmado desde entonces, y ahora podemos ver claramente dónde estamos y cuál es el legado dejado por los dos lenguajes.
¿O quizás todavía es demasiado pronto para hablar de su legado? Hablar de “legado” suena como si fuesen lenguajes muertos o lenguajes que están muriendo. ¿Es así? ¿Qué lenguajes evolucionará para reemplazar a C++ y Java? (las opiniones son siempre bienvenidas).
Fuente:http://www.dosideas.com/reflexiones/560-ic-y-java-casi-muertos.html
Escrito por Martin Gianni 
