Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

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.

Comentarios
1 esaiz
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.


2 blaxter
21 marzo 2009, 16:54

Todas las discusiones sobre los lenguajes son absurdas y a la vez importantes.

La evolución en el desarrollo de software es constante, y puedes plantearte dos estrategias, casarte con una tecnología y ser ineficiente o evolucionar con el tiempo. La segunda es la óptima, pero claro, la primera es mucho menos costosa.

Una aplicación nueva, ahora mismo ni se plantea escribirla en COBOL, lo mismo se puede aplicar con Java en, actualmente, la mayoría de contextos y próximamente en la totalidad.


3 toloto
21 marzo 2009, 18:01

Wow, que parcialidad. Disimulada, pero parcialidad brutal.


4 zalete
21 marzo 2009, 18:53

Holap!,

No nos fijemos en los lenguajes. No perdamos mas tiempo con las guerras religiosas… esas cosas separan y matan las posibilidades…

Pasado un punto de madurez, son una cuestión de gusto ;)… y hay que darle a la gente gusto ;)… si no el trabajador del conocimiento se aburre y eso es malo ;)…

Sergio, en tus puntos te falto el c) La experiencia emocional con el lenguaje ;) (osea, el sexo!!)

Diversidad…

El tema es más profundo… ¿como podemos hacer para que trabajando de manera diversa, lleguemos a crear mas valor y conectarnos para trabajar de manera coordinada? -> + sexo ;)

Pues basandonos en convenciones y estandares, buscando arquitecturas que nos conecten, no tecnologías que nos separen…

Eso si, basandonos en estandares libres, neutros y a ser posible “sencillos”… (contraejemplo: CORBA)

Ejemplos: FTP, HTTP, LDAP, REST :)…

y a “mashupear” :)…

Lo de la sencillez es importante. Eso no significa que no se puedan hacer sistemas muy complejos… lo que significa es que deben estar formados de unidades conectadas de una manera lo mas uniforme posible. Java, por ejemplo, suele pinchar con la ley de Gall [1]

A mi me encanta que pueda seguir usando sistemas en COBOL (lo he hecho) simplemente haciendoles un conectorcito en REST… conectado con modulos en Perl, Ruby, sistemas peludos en Java y PHP

Direis (como estoy cansado de oir) que eso complica los sistemas y que es mejor saber bien un solo lenguaje, cada vez estoy mas convencido que eso es la madre de muchisimos problemas. El que solo tiene un martillo, todo le parece un clavo…

Que cada palo aguante su vela, y si es software libre, siempre encontraras quien te mantenga la parte que corresponda… y si le pagas, ya es la poll… pero por lo menos esta abierta la posibilidad :)

—-

[1] Gall’s Law is a rule of thumb from John Gall’s Systemantics: How Systems Really Work and How They Fail:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” (p. 71)

(http://en.wikipedia.org/wiki/Gall%27s_law)


5 Rafa
21 marzo 2009, 19:33

Hombre….

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.

Varias cosas:

– El leguaje es ruby y el framework RoR. No tiene nada que ver lenguaje con la plataforma. – RoR es un framework para desarrollo de aplicaciones web así que supongo que te estarás refiriendo a Java+JSF o servlets vs. Ruby+Rails – En cantidad de asistentes de generación de código personalmente creo que RoR gana por goleada. Por ejemplo, una tontería como generar lo que es una migración de Active Record en Java me cuesta sudor y lágimas de hacer en Hibernate. Una aplicación siguiendo REST en Java no es ni mucho menos tan trivial como tirar de la herramienta de generación de Rails.

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.

El 90% de la escalabilidad de una aplicación depende de su diseño, no de la plataforma en la mayoría de los casos. A no ser que diseñes Twitter o Barrapunto los problemas de dimensionamiento los tienes tú, no la plataforma.

El lenguaje no importa, el programador si.

Muy bonito de decir pero gracias a Dios no programamos aplicaciones web en LISP. Si el lenguaje da igual. ¿Por que la industria cambia de tendencias?

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.

Esto si que no lo entiendo.

El entorno J2EE nunca a acabado de funcionar bien, ni en rendimiento ni en disponibilidad

Tampoco me queda muy claro, el enlace no está bien.

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.

Tampoco entiendo muy bien porque Java + PHP ;) ¿Por que no Java+Ruby que para algo existe JRuby? O Java+Python que para algo está Jython o Java+Groovy… ¿No será PHP el que peligra de verdad?

Y por último creo que el error del enfoque del artículo es de concepto. Estás comparando churras con meninas. Una plataforma J2EE no está pensado para que desarrolles un calendario personal y una plataforma RoR no está pensado para que desarrolles la gestión de pasajeros de los aeropuertos de un país.

Mientras escribo esto le comento al posteador de antes de mi:

Para interconectar sistemas “extraños” nada mejor que un ESB. ;)


6 Ricky
22 marzo 2009, 02:03

Son absurdos estos debates… así que creas uno. ¿Sabes cuál es la razón principal de todas estas charlas? Que cada uno tira para su bando con la esperanza de convencer al mundo mundial y dar más valor a la propia experiencia. Y desde luego, esta vez no iba a ser la excepción.


7 dagi3d
22 marzo 2009, 03:51

Por cierto, lo de la frase de Bill Gates sobre la memoria RAM es una leyenda urbana que ya ha desmentido unas cuantas veces


8 Sergio Montoro Ten
22 marzo 2009, 10:30

Gonzalo: coincido en que el factor emocional juega un papel en ocasiones igual de importante que cualquiera de los demás. Gracias por la cita de John Gall, la había leído hace años en el magnífico libro The Design and Evolution of C++ de Stroustrup pero no recordaba que fuese de Gall.

A muchos programadores simplemente les gusta instalarse cosas y probarlas. Es por eso que amenudo se exceden metiendo cambios y cacharradas técnicas novedosas. Aunque, en el fondo, tal proceso de evolución es beneficioso, porque si no existiese, como dice Jesús, seguiríamos programando en COBOL.

Borja: no sabía que la cita de Gates fuese apócrifa. Acaba de caer un mito, ¿en qué vamos a creer ahora? :-D)

Rafa: sobre el tema de los frameworks Java, coincido en que algunos de los más afamados pueden añadir más complejidad de la que ocultan. En particular, a mi no me gusta Hibernate. Y meter algo como JBoss me parece la re-ostia de complicado, e innecesario en la mayoría de los casos.

Ricky: las polémicas absurdas son un componente del progreso. A cualquiera que plantea una nueva idea casi siempre lo toman por lunático. Por dónde evolucionen las plataformas no es tema baladí, dado que tiene profundas repercusiones económicas y organizativas. En general (y esto no tiene nada que ver con Java, ni Ruby ni PHP) los programadores noveles tienen tendencia a evaluar las herramientas con criterios mayormente técnicos y a proponer que se usen las últimas novedades lo más rápidamente posible. La exploración es necesaria, pero hay que hacerla con cuidado, porque puedes meter un huevo en la nave espacial que resulte ser el bicho de Alien, y cuando te das cuenta tienes una peli de miedo montada en la aplicación, con arañas asesinas corriendo por todas partes.


9 Ismael Olea
22 marzo 2009, 11:16

No tenéis ni idea ninguno. La única alternativa es Drupal. Y sé que en el fondo todos lo sabéis.


10 Ricky
22 marzo 2009, 23:34

Sergio, no he sido yo quien dijo que estas polémicas sean absurdas, ¿recuerdas? Yo lo que te he dicho es la razón de que existan, y ésta en concreto. El hecho de que se te note es mala noticia si pretendes de verdad analizar la cuestión objetivamente. ¿Sientes que Ruby es una amenaza contra Java? La hiperbólica analogía con Alien parece corroborarlo.

La productividad es la productividad. Si un lenguaje es más productivo, es que lo es. No es que un lenguaje sea más productivo porque sea menos productivo y además otras cosas que no tienen nada que ver con la productividad. Esa forma de razonar se parece peligrosamente a los bonos basura de los que tanto se habla últimamente.

Ruby lleva bastante poco en el mercado y ha demostrado algunas cosas espectaculares. A mí sigue sin convencerme según para qué tipo de proyecto. Pero menos me convence tu forma de razonar de talla única. El mundo aquí fuera es más grande y diverso. El hecho de que Java tenga una representación mínima en ciertos nichos debería hacerte reflexionar.


11 Alfredo
23 marzo 2009, 13:41

Decir que la productividad de los lenguajes no importa es un disparate de los gordos.

Y los asistentes no generan código sino que ayudan a escribirlo.

Lo que pasa es que la mayoría de los lenguajes más populares son muy parecidos porque unos son copias de otros con cuatro cambios, y tienen una productividad tan parecida que la diferencia es poco relevante.

Pero por ejemplo la diferencia entre escribir una consulta en SQL y en ensamblador es abismal.

Lo de la disponibilidad de la mano de obra tampoco es muy importante porque como dices en como mucho dos semanas se puede ser productivo en un lenguaje si se conocen otros parecidos.


12 Sergio Montoro Ten
23 marzo 2009, 14:09

La productividad obviamente importa, de lo contrario seguiríamos en los años 70. Mi argumento era más bien sobre la diferencia de productividad entre entornos.

Las cosas hechas rápidamente son justamente eso: cosas hechas rápidamente. Lo mismo con un framework para un lenguaje de scripting “quick’n dirty” que si te has pillado Castor para generar automáticamente chorrocientas mil clases Java con las que parsear un fichero XML con tal de no tener que hacer el esfuerzo de tirar directamente del API de un parser XML.

Los bichos alienígenas existen en todas las plataformas, Java está plagado de ellos, algunos incluso muy famosos.


13 Alfredo
23 marzo 2009, 15:39

En realidad seguimos en los años 70. No ha habido ningún avance importante en los lenguajes de programación desde esa época.

Y el que no esté de acuerdo que nombre alguno :-)

Respecto a la generación de código: es una señal de mal diseño.

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell

Si se puede generar código automáticamente eso quiere decir que también se podría haber resuelto el problema directamente.

En donde si puede haber diferencia entre los lenguajes estáticos y dinámicos es en la propensión a errores, que también es un factor importante.


14 bellz
23 marzo 2009, 15:40

Intentar justificar la superioridad de uno u otro lenguaje sin situarse en un escenario concreto nunca nos hará llegar a un resultado concreto y mucho menos significativo, mas bien depende del enfoque a escenarios determinados y/o requisitos para el desarrollo. En base a esto creo que habrá lenguajes que escalen mejor, que permiten desarrollar en mas o menos tiempo, con un costo superior o inferior de mantenimiento… etc.

Creo que también depende del cristal a través del cual se mire y por supuesto, en programación, al igual que en automoción, ropa, etc, también hay modas.

Saludos.


15 Antonio de las Nieves
8 abril 2009, 19:22

A corto plazo y al menos en los entornos en los que se mueve mi empresa, el futuro es J2EE.
La mayor parte de aplicaciones ECM y CMS están hechas en J2EE si son serias y buenas, y algunas también en PHP.. que suelen ser lo que Sergio comenta: menor curva de aprendizaje, peores desarrollos = mayor coste de mantenimiento que los sistemas hechos en Java como Nuxeo, Alfresco, OpenCMS o Hipergate ;-)
Yo pienso que a Java le pasará como a Cobol (de hecho ya le pasa, porque lleva muchísimos años con nosotros) y dentro de 20 años seguirá habiendo ofertas de trabajo para programadores JAVA.

Love.


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.