Todas las discusiones sobre lenguajes son absurdas
A los partidarios de Ruby on Rails les gusta decir que Java es como COBOL (por aquello de que lo usan los bancos). Y quienes usan un lenguaje compilado tienden a menospreciar a los “programadores de scripting”, esos que escriben código guarro sin objetos ni declaración de variables ni nada. ¿Qué hay realmente detrás de todas estas enconadas discusiones?
por Sergio Montoro Ten, 21 marzo 09
Todas las discusiones sobre qué lenguaje de programación es mejor o más productivo están fuera de lugar. Ya en 2005 Joel Spolsky se preguntaba ¿Porqué tanto ruido con Ruby on Rails?
Las discusiones suelen ser absurdas porque se basan casi siempre en dos factores que casi nunca importan nada:
a) la productividad del lenguaje
b) la eficiencia en runtime
La productividad de un lenguaje se correlaciona directamente con la cantidad de líneas código necesarias para escribir un algoritmo. En base a eso, un lenguaje como RoR debería ser mucho más productivo que Java ¿o no? Pues no necesariamente, por dos motivos: primero porque casi ningún programador de Java escribe el código directamente sino mediante asistentes que lo generan; y segundo porque sólo una fracción del código son los algoritmos, habiendo un elevadísimo porcentaje del mismo que son rutinas de control de errores y otras cosas. Es decir, la cantidad de líneas de código necesarias para resolver un problema no es tan relevante como el tiempo real necesario para producirlas y mantenerlas con las herramientas adecuadas.
Sobre la eficiencia en runtime se suele argumentar que el precio del ciclo de CPU es ridículamente bajo, mientras que la hora de trabajo de un programador es terriblemente cara. De modo que hay que cambiar todas las horas de programador por horas de CPU ¿o no? Pues tampoco necesariamente, porque la hora del programador, por cara que resulte, se paga una sola vez y luego se amortiza en forma de un programa que funciona felizmente sin problemas, pero un programa lento y mal hecho nunca deja de ser una caja de bombas. Puede que funcione bien con 100 usuarios o con 1.000 pero ¿qué pasa si entran 10.000? Los informáticos tenemos tendencia a cometer errores de estimación de uno o dos órdenes de magnitud (las famosas 640Kb de RAM de Bill Gates) y es una muy mala idea depender de un entorno que no escala bien en tales situaciones de incertidumbre en el dimensionamiento.
¿Qué cosas importan realmente en un lenguaje pues?
1ª) La disponibilidad de buenas herramientas y librerías. VisualBASIC 6.0 era un entorno superior para desarrollar aplicaciones cliente/servidor no porque el lenguaje fuese una maravilla, sino porque con el editor de formularios drag’n drop te hacías una aplicación chula en tan sólo una semana.
2ª) La estabilidad de la plataforma. En un software de servidor cualquier bug o agujero de seguridad puede ser fatal.
3ª) La garantía de soporte a largo plazo. Como los buenos satélites, el buen software tiene tendencia a sobrevivir más tiempo del que nunca imaginaron sus creadores (COBOL es la prueba). En tal escenario es menester preguntarse ¿funcionará este software y tendrá soporte en las plataformas hardware y sistemas operativos de dentro de 20 años?
4ª) La disponibilidad de mano de obra cualificada. Cualquier software es tan bueno como la persona que lo escribió. El lenguaje no importa, el programador si.
5ª) La interoperabilidad y compatibilidad con otro software. En una infraestructura de sistemas compleja hay que pensárselo dos, tres y hasta diez veces antes de meter una nueva pieza de software heterogéneo. Es típico ver cómo los usuarios que empiezan algo nuevo desde cero tienen tendencia a usar PHP o Ruby on Rails porque es lo más fácil, mientras que los que ya tienen una infraestructura Java o .NET tienen tendencia a mantenerla. Esto tiene toda la lógica del mundo, una vez que te casas con una plataforma, es muy dificil divorciarse de ella.
¿Qué diferencias reales hay entre Java y Ruby?
Java, pros y contras:
o Hay muchísimos programadores Java.
o La Comunidad Java produce una enorme cantidad de materiales y librerías.
o Java es un entorno maduro y estable, y una elección bastante segura a largo plazo.
o Java escala muy bien, se ha aprendido de una larga experiencia en entornos muy grandes y complejos.
o Java ofrece múltiples opciones donde elegir.
• El entorno J2EE nunca a acabado de funcionar bien, ni en rendimiento ni en disponibilidad
• La Comunidad y el soporte de PHP ha crecido hasta igualar o superar el de Java, incluyendo grandes fabricantes como IBM, que presta servicios sobre PHP de febrero de 2005.
• Java se está debilitando. Con la aparición de nuevos lenguajes: Ruby, Python, Groovy, Scala, etc. cada vez se va diluyendo más el uso de Java lo mismo que pasó con el de C++ a finales de los noventa.
• Java es complicado. En particular la rama de EJB y Servicios Web tiene una dura curva de aprendizaje.
Ruby, pros y contras:
o Ruby es como el lenguaje de programación que a uno siempre le hubiera gustado diseñar: combina buenas ideas de Perl y Smalltalk, Python, Lisp, Dylany CLU.
o Ruby ofrece mejor productividad medida en líneas de código necesarias para desarrollar una funcionalidad.
o Curva de aprendizaje suave. Un equipo de programadores bien organizado y motivado puede estar produciendo aplicaciones Ruby on Rails en menos de dos semanas de formación.
o Muchos visionarios de la industria apoyan Ruby, incluyendo al mismísmo James Duncan Davidson, creador de Tomcat, y David Geary, diseñador de JavaServer Faces.
• El primer problema de Ruby on Rails es que aún está en riesgo de morir a manos de la pinza PHP+Java, lo cual podría hacer que la mano de obra cualificada fuese difícil de encontrar.
• No hay ni la décima parte de instalaciones corrriendo sobre Ruby que sobre Java o PHP. Por consiguiente, existen menos pruebas definitivas e irrefutables sobre su estabilidad y escalabilidad. Todas las pruebas empíricas indican que Ruby on Rails es significativamente más lento que J2SE aunque quizá no tanto en comparación con J2EE
• Aunque las librerías básicas existen (correo, parsers XML y HTML, clientes FTP) La Comunidad de Ruby no es tan grande como la de Java, lo cual implica menos componentes y frameworks disponibles gratuitamente como la miriada Java que se puede encontrar en Apache.
• Ruby está menos estructurado que Java y posee menos funcionalidades para proteger a las aplicaciones de los abusos.
Concusión
Ni Java va a desaparecer de la noche a la mañana, ni podemos pasarnos la eternidad escribiendo código con los mismos lenguajes, o seguiríamos en la era de ALGOL.
21 marzo 2009, 16:31
Personalmente creo que existen más factores a la hora de elegir un lenguaje, además de ampliar su rango a otros además de Java o Ruby, por descontado.
En todo caso, creo que cada problema tiene un lenguaje que se ajusta más a sus necesidades y a la destreza del equipo de desarrollo, a pesar de que prácticamente todos los lenguajes pueden dar soluciones a todos los problemas.