miércoles
feb152006
Brevísima revisrión de Ruby on Rails
miércoles, febrero 15, 2006 at 12:56PM
Por javaHispano últimamente se ha gastado mucha tinta con el asunto Ruby on Rails vs Java a partir de las declaraciones de su autor-estrella.
Ciertamente el mundo Java es inquieto, demasiado quizýs, buena muestra son los innumerables frameworks web, la continua innovacrión en todos los ýreas: persistencia, visualizacrión, gestrión de la configuracrión, AOP etc etc, mientras TheServerside.com nos ha saturado con 11 noticias el mundo TheServerside.net con 0 noticias parece que vive ajeno al "nuevo paradigma". Pero de repente un David amenaza al gran Goliath: Ruby sobre todo con su Rails.
Antes de dejarte llevar por la marea del nuevo týrmino de moda (que sin duda los escritores y las editoriales desean) hay que hacer unas cuantas consideraciones... týcnicas la mayorýa.
Ruby tiene unos cuantos problemillas, digamos que David dista mucho de parecerse a la famosa estatua de Miguel Angel, y Java-Goliath quizýs no sea tan feo como se le ha pintado. Para ser justos Java un dýa tuvo el rol respecto a C++ que tiene ahora Ruby+Rails.
Algunos problemas de Ruby + Rails:
* Es un lenguaje no tipado: los lenguajes no tipados no aprovechan la herramienta más poderosa de test: el compilador. A partir de un cierto nýmero de clases/estructuras se hace inmanejable un lenguaje no tipado.
* Ruby está solo: es apenas un lenguaje, sin apenas plataforma, sin apenas librerýas, apenas existen vías de integracrión con el resto del "mundo", por eso su "ýxito" es hoy dýa la gestrión de bases de datos por web. PHP aprendrió la leccrión de que no es conveniente reinventar más ruedas y permite la integracrión con ActiveX e incluso con Java.
* Es más sucinto en su sintaxis: ýventaja? a perl no le ha ido muy bien en parte por esa misma "cualidad" (hay quien encuentra bastante parecido), la claridad de la programacrión es hoy mucho más relevante que unos cuantos "trukis", podýamos vivir sin las simplificaciones de java 1.5.
* No hay nada nuevo en Ruby respecto a otros lenguajes dinýmicos. Por no hablar de AOP.
* Tiene una sintaxis no derivada de C: la sintaxis basada en C es tan poderosa (C,C++,Java,C#,JavaScript,PHP...) que supone un problema importante de aprendizaje. Quizýs el chino sea la lengua del futuro pero en un mundo dominado por el inglýs no lo tendrý fýcil por su "impedancia" linguýstica con las lenguas occidentales.
* Rails necesita un servidor web propio o un plug-in FastCGI. Aparte de los problemas de hosting comercial existe el serio problema de **no tener sesiones** y el riesgo de que cualquier extensrión ha de hacerse via C.
* Rails genera el modelo de clases a partir de la base de datos. Olvídate de la herencia en ese primer modelo. ¿Es esto una revolucrión?
* Las clases del modelo en Rails derivan de ActiveRecord::Base: la herencia de clases de utilidad en un modelo siempre se ha considerado una týcnica "intrusiva" ýporque la gestrión de la persistencia y no la visualizacrión del objeto?. Hibernate, JDO, EntityBeans, EJB3... han tenido que hacer virguerýas (interfases, reflection, proxies dinýmicos, IOC, bytecode enhancement) para dejar el modelo lo más intacto posible, lo más "POJO" posible.
* La persistencia de la herencia es en la misma tabla: muchos a partir de aquí dejarýn de leer. ýSi nuestro modelo tiene una clase base y tres derivadas y de cada derivada derivan otras tres? menuda tabla resultarý.
* Rails býsicamente es una herramienta de generacrión de código y de HTML para una aplicacrión týpica CRUD. Una aplicacrión Rails no es muy diferente a una vista de la BD con phpMyAdmin o JDBCManager ocultando lo más posible lo referente al SQL. La aplicacrión que genera Rails vale poco más que para mostrar el contenido de la base de datos de una forma rýgida dirigida totalmente por el modelo de la base de datos. El infierno está en los detalles: ýsi tu visualizacrión mezcla datos de diferentes tablas a la vez?, ýnavegacrión peculiar? al final el verdadero trabajo es "manual" teniendo que domar un modelo de visualizacrión preconcebido al margen de los requisitos. Los asistentes/generadores etc te hacen creer que has ganado la batalla cuando apenas ha comenzado la guerra, ese es quizýs el espejismo Ruby: un asistente generador de código.
* Rails no es muy diferente de un JSP a pelo o un JSP+Struts+JDO/Hibernate/EJB3 y sý mucho más rýgido (y plataforma mucho más pobre), y si sutituyes Struts por Wicket más simple arán y por JSF más visual aún.
* No hay opciones a la escalibilidad, a la programacrión distribuida etc, no hay nada parecido a J2EE.
Algunos enlaces: The Emperor's Old Clothes, Hibernate vs Rails, Ruby on Rails and J2EE: Is there room for both?, Ruby off the rails
Nota: se que esto deberýa ser un artículo, pero si no lo escribo y lo pongo ahora no lo escribo.
Ciertamente el mundo Java es inquieto, demasiado quizýs, buena muestra son los innumerables frameworks web, la continua innovacrión en todos los ýreas: persistencia, visualizacrión, gestrión de la configuracrión, AOP etc etc, mientras TheServerside.com nos ha saturado con 11 noticias el mundo TheServerside.net con 0 noticias parece que vive ajeno al "nuevo paradigma". Pero de repente un David amenaza al gran Goliath: Ruby sobre todo con su Rails.
Antes de dejarte llevar por la marea del nuevo týrmino de moda (que sin duda los escritores y las editoriales desean) hay que hacer unas cuantas consideraciones... týcnicas la mayorýa.
Ruby tiene unos cuantos problemillas, digamos que David dista mucho de parecerse a la famosa estatua de Miguel Angel, y Java-Goliath quizýs no sea tan feo como se le ha pintado. Para ser justos Java un dýa tuvo el rol respecto a C++ que tiene ahora Ruby+Rails.
Algunos problemas de Ruby + Rails:
* Es un lenguaje no tipado: los lenguajes no tipados no aprovechan la herramienta más poderosa de test: el compilador. A partir de un cierto nýmero de clases/estructuras se hace inmanejable un lenguaje no tipado.
* Ruby está solo: es apenas un lenguaje, sin apenas plataforma, sin apenas librerýas, apenas existen vías de integracrión con el resto del "mundo", por eso su "ýxito" es hoy dýa la gestrión de bases de datos por web. PHP aprendrió la leccrión de que no es conveniente reinventar más ruedas y permite la integracrión con ActiveX e incluso con Java.
* Es más sucinto en su sintaxis: ýventaja? a perl no le ha ido muy bien en parte por esa misma "cualidad" (hay quien encuentra bastante parecido), la claridad de la programacrión es hoy mucho más relevante que unos cuantos "trukis", podýamos vivir sin las simplificaciones de java 1.5.
* No hay nada nuevo en Ruby respecto a otros lenguajes dinýmicos. Por no hablar de AOP.
* Tiene una sintaxis no derivada de C: la sintaxis basada en C es tan poderosa (C,C++,Java,C#,JavaScript,PHP...) que supone un problema importante de aprendizaje. Quizýs el chino sea la lengua del futuro pero en un mundo dominado por el inglýs no lo tendrý fýcil por su "impedancia" linguýstica con las lenguas occidentales.
* Rails necesita un servidor web propio o un plug-in FastCGI. Aparte de los problemas de hosting comercial existe el serio problema de **no tener sesiones** y el riesgo de que cualquier extensrión ha de hacerse via C.
* Rails genera el modelo de clases a partir de la base de datos. Olvídate de la herencia en ese primer modelo. ¿Es esto una revolucrión?
* Las clases del modelo en Rails derivan de ActiveRecord::Base: la herencia de clases de utilidad en un modelo siempre se ha considerado una týcnica "intrusiva" ýporque la gestrión de la persistencia y no la visualizacrión del objeto?. Hibernate, JDO, EntityBeans, EJB3... han tenido que hacer virguerýas (interfases, reflection, proxies dinýmicos, IOC, bytecode enhancement) para dejar el modelo lo más intacto posible, lo más "POJO" posible.
* La persistencia de la herencia es en la misma tabla: muchos a partir de aquí dejarýn de leer. ýSi nuestro modelo tiene una clase base y tres derivadas y de cada derivada derivan otras tres? menuda tabla resultarý.
* Rails býsicamente es una herramienta de generacrión de código y de HTML para una aplicacrión týpica CRUD. Una aplicacrión Rails no es muy diferente a una vista de la BD con phpMyAdmin o JDBCManager ocultando lo más posible lo referente al SQL. La aplicacrión que genera Rails vale poco más que para mostrar el contenido de la base de datos de una forma rýgida dirigida totalmente por el modelo de la base de datos. El infierno está en los detalles: ýsi tu visualizacrión mezcla datos de diferentes tablas a la vez?, ýnavegacrión peculiar? al final el verdadero trabajo es "manual" teniendo que domar un modelo de visualizacrión preconcebido al margen de los requisitos. Los asistentes/generadores etc te hacen creer que has ganado la batalla cuando apenas ha comenzado la guerra, ese es quizýs el espejismo Ruby: un asistente generador de código.
* Rails no es muy diferente de un JSP a pelo o un JSP+Struts+JDO/Hibernate/EJB3 y sý mucho más rýgido (y plataforma mucho más pobre), y si sutituyes Struts por Wicket más simple arán y por JSF más visual aún.
* No hay opciones a la escalibilidad, a la programacrión distribuida etc, no hay nada parecido a J2EE.
Algunos enlaces: The Emperor's Old Clothes, Hibernate vs Rails, Ruby on Rails and J2EE: Is there room for both?, Ruby off the rails
Nota: se que esto deberýa ser un artículo, pero si no lo escribo y lo pongo ahora no lo escribo.