Although, Ruby is the rising star if you look back 1 year, it is not growing more the last couple of months. Even worse, since April it is slightly declining. If this appears to be the new trend, then also Ruby does not become the "next big programming language.
Una vez dicho esto, la verdad es que me parece un análisis bastante sensacionalista. Tanto como el título de este tópico :-) Simplemente no se puede pronosticar la tendencia de un lenguaje a partir de sus resultados en los dos últimos meses, especialmente cuando el lenguaje es tan joven, y es totalmente normal que esté sujeto a altibajos. No siempre va a mantener la espectacular subida del último año.
Incluso en el caso de que Ruby mantuviese la tendencia y se quedase estancado, sería algo absolutamente normal. Hay que pensar que a corto plazo el objetivo de Ruby es llegar a la línea marcada por PHP, no a la línea marcada por Java. Ruby no tiene todavía calado empresarial como para plantearse siquiera ese objetivo. Ruby ha estado subiendo a costa de restar desarrolladores especialmente a lenguajes de programación como Java, pero realmente lo que le debe hacer subir es el restarle programadores a su competidor directo.
A todo esto, hay que sumar que determinados proyectos en Java deben haber contribuido a frenar el avance de Ruby. Mucha gente seguro que prefiere utilizar JRuby o Grails ahora que el soporte de el modelo Ruby on Rails es mucho mejor y más estable, simplemente porque pueden seguir aprovechando todo lo que ya existe sobre Java.
Eventualmente, y en el hipotético caso de que esta tendencia se mantuviese, entonces estaríamos ante la definitiva prueba de madurez de la comunidad Ruby. Significaría que ha alcanzado su base de usuarios estable, y obligaría a toda la comunidad a crear nuevos productos bandera que como Ruby on Rails permitan dar un nuevo salto hacia arriba, y eventualmente acercarse más al mundo de la empresa.
Así que resumiendo mi opinión, estoy seguro de que Ruby todavía tiene cosas que decir.
comments
9 Respuestas a "¿Está Ruby en decadencia?"16:46
Está claro que ruby no debería "enfrentarse" a Java más bien debería ir aprendiendo de sus errores e intentar no tomarlo como rival inmediato.
De todas formas con el tiempo veremos que ocurre enfentando a un modelo como el de ruby, frente al modelo de java, con sun por detrás como progenitor.
18:39
A propósito de todo esto, ¿qué os parecen los lenguajes dinámicos (ruby, python, perl...) como alternativas a los java/C#? Me refiero a los lenguajes en sí, y no a las plataformas, librerías, servidores de aplicaciones, etc...
21:59
De todas maneras no creo que utilizar JRuby sea frenar el avance de Ruby, sino aprovechar las ventajas de ambos mundos. En cuanto a Grails, parece que puede aportar algo para frenar a Ruby, aunque aún creo que le queda camino por recorrer. Aún y todo, está claro que de momento no es rival para Java, al menos no hasta que cuente con un respaldo empresarial respetable, que habrá que ver si es compatible con el caracter de la comunidad Ruby y Rails.
23:07
Aitor, en efecto utilizar JRuby es aprovechar las ventajas de ambos mundos. Mi análisis es puramente respecto al gráfico, es decir no pretende decir que JRuby o Grails se creasen para parar a nadie. En resumen que si sumamos en ruby probablemente restemos (o simplemente no sumemos) en grails y JRuby, y viceversa.
Raúl, en mi opinión es complicado y depende del entorno. Aunque yo no tengo mucha experiencia en este tipo de lenguajes (te recomiendo el blog de Aitor, está claro que estos lenguajes están pegando ahora mismo fuerte en la web, pero yo todavía no los veo como alternativa a java/C#.
Aitor, da en la clave, falta de soporte empresarial. Pero a mayores, una de las cosas que muchas veces no se tiene en cuenta es que estos lenguajes añaden una complejidad enorme a lo que son pruebas de unidad, integración, etc. En estos lenguajes todo es dinámico. Todo puede cambiar en tiempo de ejecución. Lo que en una invocación a un método es A, en la siguiente es B. Esto añade una presión muy importante en la parte de QA, lo que es un lastre importante a la hora de afrontar proyectos realmente grandes con este tipo de lenguajes.
De todos modos es algo que debería mejorar con el tiempo.
11:26
Me parece demasiado desmedido el comentario. No creo se pueda hablar de decadencia a partir de estos datos, ni tan siquiera que sirva como medida absoluta de la "popularidad", como muchos interpretan. Recuerdo que algo similar pasó en su día con python, pero ahí sigue dentro de los 10 lenguajes principales.
No creo que JRuby quite a Ruby nada. El índice tiobe debería agruparlos bajo el mismo epígrafe, tal y como hace con el Basic.
En cuanto a si los lenguajes dinámicos son alternativa a java/c#, no creo que se deba pensar así; más bien se complementan (daría para hablar largo y tendido). Pero lo que no es del todo cierto es que los lenguajes dinámicos no aseguren la Calidad. Aún es más, las prueba unitarias de los lenguajes dinámicos se están extendiendo a los lenguajes estáticos. Por poner un ejemplo, se empieza a testear el cumplimiento ANSI de los compiladores C/C++ mediante scripts hechos en pyunit.
11:58
Chema, como puedes ver el post dice exactamente lo que comentas tú. Que es demasiado desmedido lo que se está diciendo por Internet, así que básicamente creo que estamos de acuerdo.
Respecto a la calidad. Fíjate que yo no digo que Ruby no asegure la calidad. Simplemente afirmo que es más complejo probar un sistema dinámico que uno estático, pero no en cuanto a herramientas, ni técnicas, ni nada parecido. Simplemente es cuestión de que el número de caminos a seguir en un programa escrito en un lenguaje dinámico es mucho mayor que el de un programa escrito en un lenguaje estático donde todo está muy predeterminado.
Esta variabilidad inevitablemente añade complejidad a la hora de probar y asegurar la solidez de un gran sistema (siempre refiriendose a millones de líneas de código), simplemente porque las posibilidades a cubrir son mucho mayores.
12:42
No creo que exista manera alguna de asegurar un sistema de millones de líneas de código; pero sí que existen "metodologías ágiles" que ayudan bastante a que un sistema se comporte dentro de unos límites marcados. Piensa que no siempre puedes controlar tu entorno de ejecución, bien porque empleas multihilo o bien porque tu aplicación tiene que "interoperar" con otras aplicaciones cuyo funcionamiento desconoces. La cuestión es que tu aplicación funcione como se espera. Tiempo habrá más adelante para limitar grados de libertad.
12:53
Hace dos años decidi cambiar de PHP a Ruby on Rails, un framework que es el que está tirando de ruby. La tecnologia AJAX estaba en pañales y Ruby on Rails parecia que llevaba ventaja en innovación
Fue duro cambiar de lenguaje, poca documentación, poca información, pero la popularidad creciente del lenguaje me animó
Programé varios proyectos en ruby on rails, estaba contento, pero la libreria javascript que trae integrada script.aculo.us avanzaba muy poco.
Pienso que pierden mucho tiempo en escribir en blogs, gozar de su popularidad y asistir a eventos
Script.aculo.us lleva meses parada, apenas sacando algunas revisiones. Un framework que sus propiedades más útiles son la integracion con una libreria javascript tiene que potenciar el desarrollo de esta
Hace un par de meses, empece a probar otra libreria en Javascript, mootools, completamente open source, 'lightweight', muy bien estructurada y con una comunidad bastante grande, unos foros y wikis muy activos y sobre todo un desarrollo intachable, dia a dia van sacando nuevas versiones, corrigiendo bugs, etc
Con este cambio me di cuenta que no necesitaba la lentitud y pesadez de Ruby on Rails. Volvi a PHP y aqui estoy, contento de haber tomado la decisión de volver a PHP y lamentando haber perdido tanto tiempo con ROR
Mi conclusión es que tienen dos opciones para no decaer:
1 - Potenciar mucho más el desarrollo de script.aculo.us
2 - Abrir su codigo e implementar librerias paralelas como mootools u otras
15:10
Daniel, realmente interesante. Gracias por compartir tu experiencia.
Publicar un comentario