17/03/2008
17/09/2008
11/06/2008
21/02/2008
10/03/2008
26/03/2008
Leo en dzone que Rogério Pereira ha publicado la segunda parte de su experiencia en el uso de JRuby con JSF. Aunque ya existían otras experiencias de integración (sobre todo el gem de ActiveRecord con JDBC) esta es una de las primeras veces que se pone a prueba la capacidad de JRuby para trabajar con partes del estándar JEE.
La experiencia se queda en poco más que un experimento de cocina, con pocas aplicaciones en la vida real (es muy tedioso, exige crear interfaces para los beans de respaldo, hay que definir los get/set para la clase en Ruby -algo que se hace con una sola línea en Ruby-, se emplea JSF -cuando ActionView en Rails es vastamente más flexible-, la integración con ActiveRecord es mediante DAO's, etc) pero una cosa llama la atención: JRuby está totalmente a la altura de las circunstancias y no presenta problemas de ninguna clase.
Con el lanzamiento del JSE 7 -que vendrá con nuevos bytecodes para apoyar los lenguajes dinámicos- la velocidad de JRuby será similar a la de Java (actualmente su velocidad es ya superior a la implementación oficial en C). Si actualmente ya es un ciudado totalmente adaptado al ecosistema Java (en el ejemplo emplea la nefasta implementación de JSF y la integración la hace con Spring) ¿Qué os parece la llegada de este compañero de Java (con Python y muchos otros viniendo después)? Si en vuestra empresa lo permiten, ¿creeis oportuno ir por este camino?
Yo ya uso algun lenguaje dinamico para algunas cosas, aunque de momento todavia en piezas reemplazables por algo más "tradicional" si surgiera la necesidad, y estoy contento. Lo unico que le veo a esta tendencia es que si ya el "mundo Java" es extenso y algo abrumador por el numero de opciones, ahora va a ser la repanocha.
Es perfecto desde el punto de vista de libertad de elección, pero hay algunos ambientes donde la tanta libertad se traduce en duda e incertidumbre. Pero como todas las cosas, seguro que habra gente que abusará y hara desastres, gente a la que le irá como un guante... y muchos temas para libros, artículos, productos...
Tienes razón greeneyed. Estamos perdiendo el norte.
No me gustan las integraciones tipo Struts+Spring + no se que todo junto......que peligro..... y si encima le sumamos un nuevo lenguaje tipo Rub....pues me da orticaria............
Me gustaría volver a los 80's , cuando la informática era más sencilla y te tenias suficiente con comprarte un libro y dejar volar tu imaginación.
Como esto siga así, yo me bajo de este tren........Me siento perdido..........exceso de información......mi cabeza va a explotar!!!!!
En mi trabajo para aplicaciones Web el uso de Java ni se plantea. En mi opinión, con experiencia en ambos campos (a decir verdad menos en ruby), es absurdo comenzar ahora una aplicación Web usando tecnologías de lenguajes tipados y tan "del pasado" como java usando jsf, struts o el framework que quieras.
Usando Rails crearás la misma aplicación pero de una forma mucho, pero que mucho, más mantenible y con una rapidez del orden (sin exagerar en serio) 2 a 5 veces más rápido (el valor dividiendo, si). Ahora siempre tendremos a gente que intentará atacar a ruby (y pronto a python que entra también en el mundo Java) solo por no querer aprender cosas nuevas, por comodidad. Pero me gustaría saber si alguien que realmente conoce rails piensa que es siquiera minimamente inteligente pretender hacer una aplicación Web de nuevo con tecnologías como struts o jsf.
Las aplicaciones web están continuamente evolucionando y cambiando, se require un lenguaje dinámico, y si encima detrás tienes un framework como rails, la discusión acaba siendo en una broma.
Ahora si que quede atonito, no c que hago programando en java, no c mucho de ruby pero es multiplataforma? y otra cosa tienes algun manual o tutorial para ver si aprendo ruby
Saludos.
Ya faltaba alguien teniendo que promover su solucion a base de llamar a los demas, "ni minimamente inteligentes". Pues nada, para ti el premio por ser el primero.
Mi opinión: lo que parece claro es que el legado de Java no va a ser el lenguaje sino la máquina virtual (que es simplemente fantástica). Java es el heredero natural de C, que es un lenguaje de sistemas. Esto es algo totalmente lógico porque Java se pensó para sistemas embebidos. No está muy orientado hacia lo que se busca hoy en día. La verdad está ahí fuera: tenemos pseudo lenguajes para los descriptores de Spring, para los scripts de construcción de Ant, para la navegación en JSF, extensiones para programación orientada a aspectos (simple metaprogramación en Ruby), etc. Java está sensacional, pero no para lo que lo estamos empleando.
La claridad del código en Rails y su potencia y velocidad vienen de su facilidad de crear DSLs internos (lo que hace que sea una gozada leer código en RnR, incluso después de mucho tiempo. Quien no ha vivido esto no sabe lo que se está perdiendo) y quizá su legado no sea el lenguaje en si mismo o Rails como framework sino como está forzando a la gente a pensar en términos de DSL y esto está ayudando a cambiar las cosas. Java ahí compite un poquito con las anotaciones, pero no llega. El ejemplo más brillante es Gavin King con Seam que está en el filo de la navaja de lo que es distorsionar Java (para bien) para acercarse a algo parecido a un DSL, simplificar el desarrollo y aumentar la legibilidad.
Sun se ha dado cuenta del enorme valor que tiene la VM en sí y en vez de cerrarse en banda con un lenguaje, la está abriendo para todos. Kudos para Sun por no ser cerrada de mollera :)
Como decía un anónimo arriba, para un proyecto web si tuviesemos en cuenta sobre todo la claridad del código y la velocidad de desarrollo, Rails juega en una liga superior a los frameworks existentes en la actualidad para Java.
Ahora imaginaos esa misma claridad de código con toda la potencia y el arsenal de librerías de Java -comenzando por algo tan simple como drivers JDBC para cualquier base de datos imaginable-. Imaginaros poder emplear toda la base de código que ya existe en una empresa pero permitiendo ampliarla con un lenguaje y, quizá, con un framework mucho más limpio y sencillo -y una productividad muy, muy superior-
Joer, sabe como a... como a futuro :)
Sabe a Grails, ya puestos.
Bueno ya desde hace meses escucho sobre Ruby /Groovy Rails/Grails, bla bla bla..en ese tiempo para mi todavia estaba todo confuso, pero ahora se van aclarando las cosas, yo creo que ya me llego la hora de empezar a dar algunos pininos con algun lenguaje dinamico para desarrollo web que es lo unico en donde me interesaria utilizar lenguajes dinamicos, pero mantenimiento mis cores en Java. Como siempre he estado aconstumbrado a probar antes de creer, entonces tocara probar Ruby y Groovy por separado para ver con cual me va mejor, pero creo que la eleccion logica para un programador Java para empezar seria Groovy, por el parecido, pero como todavia no hay soporte potente para Netbeans entonces sera por Ruby.
Una pregunta un poco offtopic: Como estan de interoperabilidad con cosas nativa Ruby y Groovy??
Saludosss
Venga, a montar el flame, que hoy tengo tiempo libre ;-)
Lo que no entiendo de los apologetas es que:
a) Tengan que hacer apología de algo que es lo suficientemente bueno como para no necesitar que lo venda nadie.
b) Utilizen los términos "lenguaje dinámico" y "lenguajes tipados" con tanta soltura y por "modernez" (ánimo jovenes y dinámicos!, yuhu), más que por sentar las bases de una discusión técnica interesante (o no).
Sobre el primer punto no hablo (para eso cada uno tiene la intimidad de su hogar para pensar en sus motivaciones), pero sobre lo segundo... me meto.
De un tiempo a esta parte vengo oyendo esos términos malinterpretados o usados como arma arrojadiza, asi que he decidido estudiar lo que dice la wikipedia (que aunque no es mi fuente predilecta), para el caso puede valer:
Lenguaje Dinámico: Dynamic programming language is a term used broadly in computer science to describe a class of high level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all.
Dynamic languages and dynamic typing are not identical concepts, and a dynamic language need not be dynamically typed, though many dynamic languages are dynamically typed.
Espero que con esta simple definción se vea el absurdo de algunos cuando no consideran a Java un lenguaje dinámico (desde la aparición del compilador Just In Time, cumple la definición) o cuando les da por traducir lenguaje dinámico como de tipado dinámico (Groovy es un lenguaje dinámico que puede tener tipado dinámico, si se ejecuta como script, o estático, si se compila). Lo curioso del tema es que siguiendo las definiciones de la wikipedia:
Dynamic_typing : A programming language is said to use dynamic typing when type checking is performed during run-time (also known as "late-binding") as opposed to compile-time.
The presence of static typing in a programming language does not necessarily imply the absence of dynamic typing mechanisms. For example, Java uses static typing, but certain operations require the support of runtime type tests, which are a form of dynamic typing.
De nuevo vemos que Java, SI tiene ciertos mecanismos de tipado dinámico (algunos dicen que si usas sólo la clase Object, ya tienes un tipado dinámico ;-)). ¿Por lo tanto que quieren decir estos apologetas? ¿Que significa lenguaje "tipado"? ¿Acaso Ruby no tiene un tipado fuerte (si, como lo oyes, haz una busqueda en google sobre el concepto de tipado fuerte, que comparte con Java, y tal vez lo acabes entendiendo), con chequeo de tipos dinámico (tal vez a esto se quieran referir como contrapunto a Java)?
Pues por lo visto en este hilo: lenguaje dinámico es aquel que te permite hacer las cosas rápido :-), y los lenguajes tipados son lenguajes del pasado :-) Para luego pasar a recomendarnos lenguajes de tipado fuerte, que por tanto son lenguajes tipados :-). Malísimos apologetas para un lenguaje tan interesante como Ruby o Python o Groovy... hay perdon, Groovy no, que "huele" a java y no queda tan cool hablar de él :-D Por no decir que no mencionan a Javascript, eh venkman ;-), que tampoco queda muy "modelno" ;-)
Salu2
Fuentes: http://en.wikipedia.org/wiki/Type_system
@ibon
'Apologetas' lo entiendo como un término despectivo y ese es el tono de tu post. En cualquier caso es un ataque a la persona en vez de al contenido. No voy a ir por ese camino porque no aporta nada excepto generar mal rollo. Más comentarios de este tipo serán ignorados.
Lenguaje dinámico tiene una acepción muy clara en la comunidad, tan sólo tienes que buscar "dynamic language support jvm" para ver como desde sitios de noticias hasta los blogs de todo el mundo hablan de lo mismo. Tu definición puede ser tan precisa como inútil.
El contenido de tu post aporta aproximadamente 0 a la noticia.
@greeneyed
No he seguido el desarrollo de Groovy y Grails. Si has tenido ocasión de usarlos frente a Ruby, ¿podrías comentar un poquito tu impresión? Sobre todo sería interesante tu visión subjetiva, que 'feeling' te producen.
@Marioko
Te puedo responder por JRuby. Hay dos cosas separadas, uno es el uso de librerías y otro el de frameworks que necesitan recibir llamadas de Java. El soporte de las librerías es simplemente sensacional, y no es frecuente tener problemas. Las clases y paquetes se importan de forma transparente. Mucha gente hace la integración con Spring y desde la versión 2 ya se puede inyectar código en Ruby en beans de Java sin problemas. Esto hace que sea muy modular (tienes las cosas que te interesan en Ruby y si surgiera la necesidad podrías cambiar esa clase sin problemas por una java). Esto te da paz de espíritu por si algo fallase o fuese problemático.
Otra cosa es integrar los frameworks que ya existen y que quieras emplear clases en Ruby para recibir las llamadas del framework. Aquí no he probado nada. La sensación que da es que mientras hagas la integración con Spring y crees un interface para estas cosas, todo debería ir bien. Pero la verdad es que es más trabajo para hacer lo mismo que con Java (fíjate en el código del artículo, tiene que definir el interfaz, mas clases en ruby, mas declarar los get/set al estilo java en la clase de Ruby cuando con sólo java llegaría la clase del bean de respaldo)...
Juanmp: no entiendo porque saltas, cuando evidentemente no hablaba contigo, sino con el anónimo que hablaba de "lenguajes tipados" frente a "lenguajes dinámicos", lo cual es una soberana estupidez. Respecto a mis fuentes, la he escogido precisamente porque NO era MI definición, para demostrar como alguien "neutral" puede incluir a java como lenguaje dinámico (aunque sea traído por los pelos).
Reconozco que "lenguaje dinámico" ha venido a sustituir como término a "lenguaje de script" (tal vez por que este ultimo termino ha sido utilizado despectivamente, como si fueran juguetes), pero usarlo como contraposición, o como arma arrojadiza me parece estúpido. Por ejemplo: ¿Que sería Groovy cuando se compila a bytecode? ¿Dejaría de ser un lenguaje dinámico porque en runtime hace uso de los mismos mecanismos de la VM que Java?
Por cierto, no te he visto "defender" a nadie cuando el anónimo ha llamado estúpido a todo aquel que no prefiera hacer aplicaciones web con rails. Y por supuesto, si aparte de afearme la conducta hubieras puesto simplemente 1 único argumento técnico contradiciéndome, tu segunda opinión si que valdría algo en este hilo.
Respecto a tu primer comentario, nada que objetar, y desde luego recomendarte encarecidamente que estudies Groovy y le eches un vistazo a Grails, porque viene a cubrir exactamente lo que pides en ese post. Llevo varios meses con ellos, y desde luego no se me ocurre llamar idiota a nadie (como hace el anónimo) por no usarlos.
Salu2
@Juanmp,
Yo he utilizado Grails y Rails (este último muy poco), no en aplicaciones extremadamente complejas pero si he echo mis pinitos. Por lo que voy a dar mi opinión.
Todas las aplicaciones web que hacia antes de conocer a Grails eran con Spring MVC. Con el tiempo y con experiencia la creación de formularios, controllers, etc la verdad es que desarrollaba con un ritmo bastante aceptable.
Salió Graills, lo probé y me quedé. Tengo menos experiencia con Grails que con Spring MVC y la verdad es que voy mucho más rápido con Grails que con Spring MVC.
Estoy seguro que RoR le da vueltas a Grails, por su madurez, por su experiencia, por la cantidad de plugins, por soporte, etc, pero estoy convencido que Grails es el camino correcto para crear aplicaciones web sino se quiere salir del campo Java. La productividad que puedes ganar con un margen de tiempo relativamente corto es considerable.
Ahora a esperar que se vaya mejorando el soporte con el IDE y se vayan mejorando ciertos bugs, etc.
¿A partir de ahora todas las apliaciones web con Grails? No, pero la verdad es que se gana mucha productividad.
@anonimo 19/03/2008 16:57
"Las aplicaciones web están continuamente evolucionando y cambiando, se require un lenguaje dinámico, y si encima detrás tienes un framework como rails, la discusión acaba siendo en una broma."
A mi me importa el tiempo y mi comodidad, si con JSP a pelo voy más rapido que con Rails/Grails/JanderPonderPower no tengas duda que iré con JSP.
Saludos, les habla una broma :)@greeneyed
No he seguido el desarrollo de Groovy y Grails. Si has tenido ocasión de usarlos frente a Ruby, ¿podrías comentar un poquito tu impresión? Sobre todo sería interesante tu visión subjetiva, que 'feeling' te producen.
Con permiso, la polémica me la salto :). En cuanto a lo de "huele a Grails" lo decia por que cuando he liedo lo que habias escrito de usar todas las librerias de Java facilmente, reutilizar el codigo ya escrito, etc. etc. pues lo que me ha venido a la mente es Groovy, por que una de las cosas que mas me gusta es precisamente eso. Cuando piensas en "librerias para Groovy", excepto las cosas que han simplificado con closures como GSQL, puedes pensar en "librerias para Java" y se usan tal cual, exactamente como ya sabias usarlas. Y he dicho Grails en vez de Groovy por que lo estabamos comparando con RoR, mas que con Ruby.
No he usado ni RoR ni Grails, pero si he probado JRuby y ya trabajo con Groovy. No dire que Ruby sea malo ni nada parecido, pero viniendo de Java la sintaxis de Groovy me ha sido mas sencilla de aprender y puedo mezclar los dos lenguajes sin problemas por que son totalmente compatibles. Y por eso lo prefiero, YO. Cada uno tendra su preferencia y respeto las elecciones de los demas, mientras respeten las mias.
S!
Escribe tu comentario