Re: [grailsEnCastellano] Presentacion y consulta

[Dani Latorre]

Buenas!

Yo no le daría vueltas, si quieres tipado fuerte para que el compilador "se queje" no uses groovy/grails, tienes alternativas en java (a bote pronto spring roo o play) que siguen filosofía similar.

Lo que llamas "relajación" de sintaxis y el ejemplo que pones no es más que tipado débil. Hay cosas más dinámicas que un lenguaje como java no puede permitir (imagínate algo como GORM en java). Hay quien se siente cómodo y hay quien no con lenguajes debilmente tipados, cuestión de gustos.

De todos modos en groovy el tipado es opcional y puedes hacer:

MiClase objetoDeMiClase = new MiClase() ;

objetoDeMiClase = 1 ; // <-- peta

objetoDeMiClase.miMetodo()

Aún así sólo te aseguras que un objeto es de una clase, no que tenga o no ciertos métodos, porque una clase/objeto puede modificarse en tiempo de ejecución.

Aunque debo decir que me sorprende que en un sector "donde se mueve dinero de verdad", se considere una perdida de productividad hacer tests unitarios. Al menos en mis desarrollos con groovy (o ruby, o python, o javascript), los problemas habituales vienen de bugs en el código, no de problemas con los tipos de mis objetos.

Personalmente le pegaría un ojo también a play, que es el segundo framework web de la plataforma java que más me llama la atención. Y en lenguaje java el primero, claro.

El 13 de junio de 2012 10:16, jmiguel rodriguez <jmiguel....@gmail.com> escribió:

Hola a todos!

Siendo mi primer mensaje por aqui querria presetarme y hacer una primera consultilla.  Mi nombre ya lo pone en el "De:" asi que lo obviaremos :-).  Llevo mas de 25 (oops!) años programando (practicamente todo programas empresariales aburridos) en unos cuantos lenguajes, algunos de ellos ya muertos, y desde hace mas de 10 sobre todo en Java. Linuxero y Sysadmin activo (mis hijos no saben que es eso de Windows que tienen los abuelos ;-)) y pirado por la tecnologia, la musica y los aviones.  

Desde la pasada Spring I/O descubrí que habia vida detras del JDK standard y estoy intentando mover tecnologicamente mi empresa hacia 'otros sitios' con la ayuda de un colega. Uno de los lugares posibles donde movernos es, claro, Groovy & Grails, aunque no acabo de verlo del todo claro. Otro destino posible tal vez fuera Spring MVC. Y todo ello, entiendo, bañado con hibernate. 

En las ultimas semanas, en ratos libres, estamos intentando mirar por nuestra cuenta un poco todos estos temas. Tenemos 'en recámara' la posibilidad de hacer algun curso de formacion con (creo que no pasará nada por decirlo) Salenda. Estamos valorándolo pero entre que nuestro presupuesto es reducido y que si lo hacemos nos gustaria tener ya algun mínimo conocimiento para 'saber que preguntar', de momento estamos por nuestra cuenta, la otra persona mas orientada a Grails y yo a hibernate. 

La consulta: tras mirar un poco Groovy, mi percepcion ha sido un poco .... ¿decepcionante?. Si, creo que es la palabra.  Me gustan closures, me gusta la libertad para hacer ciertas cosas, la simplificación al escribir declaraciones o expresiones de forma mas simple. Me encantan los parseadores de XML y JSon.  No entiendo la chorrada de no tener que poner ; en las sentencias. 

Pero lo que me ha parecido una (con perdon) cagada como un piano es la 'relajación' de sintaxis que hacer que el compilador no pueda hacer su trabajo. Si: ya se. El compilador no puede saber que me he equivocado al escribir ese método porque tal vez se defina luego en tiempo de ejecución. Tampoco me gusta el 'dinamismo' en los cambios de tipos de variables:

def objetoDeMiClase = new MiClase() ;

objetoDeMiClase = 1 ;

objetoDeMiClase.miMetodo()   --> error porque ahora, resulta que objetoDeMiClase es int

Será por viejo, pero este tipo de cosas me parecen completamente inaceptables: si el compilador no puede hacer su trabajo, todos estos problemas te los encontraras en ejecución. ¿La solucion son pruebas unitarias?.  En ese caso estaré perdiendo mucho del tiempo que me ahorro usando Groovy, y para eso tal vez me merezca la pena seguir usando Java con.... ¿Spring MVC?.  Peor aún si los problemas me los encuentro en produccion real donde se mueve dinero de verdad (por ejemplo, algun programa que tenemos para aseguradoras)

En fin, que me gustaria que alguien me "vendiera" Groovy para poder decidir si es un camino adecuado o no pasa de ser (de momento) un juguete interesante. 

Gracias por todo!

 saludos,  

 jmiguel

 

 

--
Has recibido este mensaje porque estás suscrito al grupo "grailsEnCastellano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/grailsencastellano/-/2_rwvT4polEJ.
Para publicar una entrada en este grupo, envía un correo electrónico a grailsenc...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a grailsencastell...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/grailsencastellano?hl=es.

--
Daniel Latorre
My website: http://www.danilat.com/

[Aitor Alzola]

Hola, 

estoy con Dani en que si considerar la compilación imprescindible y que te indique determinados errores en tiempo de compilación, va a ser complicado que Groovy te llene. De todas maneras algunos apuntes:

- La versión 2.0 de Groovy vendrá (aún está en beta) con compilación estática [1], que creo que es lo que quieres. 

- Que una clase compila significa eso, que compila, no que hace lo que debe. Podemos equivocarnos al asignar un entero a un string y en alguna cosa más, habrá que probarlo de alguna manera. O ejecutas o haces pruebas automáticas. En Java después de compilar también hacemos algo de esto, creo.

- Al hilo de las pruebas automáticas, para mi que Grails las tenga integradas es una ventaja (aunque hoy en día todos los frameworks las tienen) y creo que no son una perdida de tiempo. Discutir eso nos puede llevar una vida, pero si creo que es conveniente mirarse el tema un poco. (Igual lo has hecho y no te ha convencido)

[1] http://docs.codehaus.org/display/GROOVY/2012/05/07/Static+compilation+in+the+new+Groovy+2.0+beta

Saludos!!

Será por viejo, pero este tipo de cosas me parecen completamente inaceptables: si el compilador no puede hacer su trabajo, todos estos problemas te los encontraras en ejecución. ¿La solucion son pruebas unitarias?.  En ese caso estaré perdiendo mucho del tiempo que me ahorro usando Groovy, y para eso tal vez me merezca la pena seguir usando Java con.... ¿Spring MVC?.  Peor aún si los problemas me los encuentro en produccion real donde se mueve dinero de verdad (por ejemplo, algun programa que tenemos para aseguradoras)

En fin, que me gustaria que alguien me "vendiera" Groovy para poder decidir si es un camino adecuado o no pasa de ser (de momento) un juguete interesante. 

Gracias por todo!

 saludos,  

 jmigue

--
Aitor Alzola

[Carlos Rico]

Estoy de acuerdo con los comentarios anteriores. 

Así que voy a resumir un poco mi punto de vista:

- Groovy/Grails vino a cubrir un hueco que había en las tecnologías Java.

- Groovy no es la panacea y resuelve un problema concreto, gracias a sus características (closures, tipado débil, …); y cambiarlas no tendrían sentido.

- Groovy/Grails seguramente no es la mejor opción para solucionar ciertos problemas (como por ejemplo tema banca, seguros, etc), pero para otros (ecommerce, portales, …) si que aporta ventajas sobre Java.

- ¿Test Unitarios? Siempre! sea el lenguaje que sea.

Saludos!

-- 

Un saludo,

Carlos Rico

Enviado con Sparrow

--
Has recibido este mensaje porque estás suscrito al grupo "grailsEnCastellano" de Grupos de Google.

[Alberto Vilches]

Lo que tu llamas inaceptable no es un fallo, sino una característica completamente intencionada. Si nunca has usado un lenguaje dinámico, es normal que te asalten esas dudas y te coja por sorpresa. En el ejemplo que pones, piensa que "def" equivale a Object, por lo que puedes asignarle cualquier cosa.

Como todo, puede costar al principio. Dale otro intento y si ves que en un tiempo los beneficios no superan la perdida del lenguaje estaticamente tipado, entonces déjalo. Pero tienes que convencerte tu mismo, no vale con que te contemos una peli ;)

2012/6/13 jmiguel rodriguez <jmiguel....@gmail.com>

Hola a todos!

Siendo mi primer mensaje por aqui querria presetarme y hacer una primera consultilla.  Mi nombre ya lo pone en el "De:" asi que lo obviaremos :-).  Llevo mas de 25 (oops!) años programando (practicamente todo programas empresariales aburridos) en unos cuantos lenguajes, algunos de ellos ya muertos, y desde hace mas de 10 sobre todo en Java. Linuxero y Sysadmin activo (mis hijos no saben que es eso de Windows que tienen los abuelos ;-)) y pirado por la tecnologia, la musica y los aviones.  

Desde la pasada Spring I/O descubrí que habia vida detras del JDK standard y estoy intentando mover tecnologicamente mi empresa hacia 'otros sitios' con la ayuda de un colega. Uno de los lugares posibles donde movernos es, claro, Groovy & Grails, aunque no acabo de verlo del todo claro. Otro destino posible tal vez fuera Spring MVC. Y todo ello, entiendo, bañado con hibernate. 

En las ultimas semanas, en ratos libres, estamos intentando mirar por nuestra cuenta un poco todos estos temas. Tenemos 'en recámara' la posibilidad de hacer algun curso de formacion con (creo que no pasará nada por decirlo) Salenda. Estamos valorándolo pero entre que nuestro presupuesto es reducido y que si lo hacemos nos gustaria tener ya algun mínimo conocimiento para 'saber que preguntar', de momento estamos por nuestra cuenta, la otra persona mas orientada a Grails y yo a hibernate. 

La consulta: tras mirar un poco Groovy, mi percepcion ha sido un poco .... ¿decepcionante?. Si, creo que es la palabra.  Me gustan closures, me gusta la libertad para hacer ciertas cosas, la simplificación al escribir declaraciones o expresiones de forma mas simple. Me encantan los parseadores de XML y JSon.  No entiendo la chorrada de no tener que poner ; en las sentencias. 

Pero lo que me ha parecido una (con perdon) cagada como un piano es la 'relajación' de sintaxis que hacer que el compilador no pueda hacer su trabajo. Si: ya se. El compilador no puede saber que me he equivocado al escribir ese método porque tal vez se defina luego en tiempo de ejecución. Tampoco me gusta el 'dinamismo' en los cambios de tipos de variables:

def objetoDeMiClase = new MiClase() ;

objetoDeMiClase = 1 ;

objetoDeMiClase.miMetodo()   --> error porque ahora, resulta que objetoDeMiClase es int

Será por viejo, pero este tipo de cosas me parecen completamente inaceptables: si el compilador no puede hacer su trabajo, todos estos problemas te los encontraras en ejecución. ¿La solucion son pruebas unitarias?.  En ese caso estaré perdiendo mucho del tiempo que me ahorro usando Groovy, y para eso tal vez me merezca la pena seguir usando Java con.... ¿Spring MVC?.  Peor aún si los problemas me los encuentro en produccion real donde se mueve dinero de verdad (por ejemplo, algun programa que tenemos para aseguradoras)

En fin, que me gustaria que alguien me "vendiera" Groovy para poder decidir si es un camino adecuado o no pasa de ser (de momento) un juguete interesante. 

Gracias por todo!

 saludos,  

 jmiguel

 

 

--
Has recibido este mensaje porque estás suscrito al grupo "grailsEnCastellano" de Grupos de Google.

Para ver este debate en la Web, visita https://groups.google.com/d/msg/grailsencastellano/-/2_rwvT4polEJ.

Para publicar una entrada en este grupo, envía un correo electrónico a grailsenc...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a grailsencastell...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/grailsencastellano?hl=es.

--
Un saludo.

Alberto Vilches

http://albertovilches.com

Twitter: @albertovilches

[Alfredo Casado]

No entiendo porque grails no es adecuado para temas como banca o seguros, ¿por el tipado?. Un error en una aplicación de e-commerce (amazon?) puede hacer perder mucho más dinero que una aplicación de banca. Y si de lo que hablamos es de hacer aplicaciones libres de bugs, el tipado es totalmente insuficiente.

Si quieres seguridad y código libre de bugs tienes que hacer pruebas automáticas (unitarias, de integración etc,etc) y da igual que estes en java, en groovy o en C++. El tipado no aporta gran cosa en cuanto a la seguridad de que un programa funcione. 

Y aún si no haces testing automático los problemas de tipado se hacen evidentes en la primera prueba de tu aplicación a manubrio, es dificil que se te cuele algo de este tipo si ejecutes tu código al menos una vez aunque sea a mano. Y con grails y la recarga dinamica en tiempo de ejecución los problemas se pueden detectar y arreglar sin recargas de la aplicación en instantes.

En resumen:

- si vas a la chapuza rapida, con grails ganas tiempo y de seguridad andas más o menos igual.

- si quieres hacer las cosas bien, cuesta menos porque el framework integra muy bien el testing automatico. (comparado con alternativas java).

[Alfredo Casado]

Se me olvidaba, un post de robert martin sobre tipado estatico y dinamico de 2003 (anda que no ha llovido :P ), donde ya decía algo como que el testing automatico hacía redundante la comprobación de tipado del compilador

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

Aparte del mini-articulo, el hilo de discusión es muy bueno, con comentarios de gente como Chad fowler.

[Carlos Rico]

Más que al tipado me refería a la madurez del lenguaje, quizás los ejemplos no fueron acertados. Lo que está claro, es que las pruebas son imprescindibles, ahí estoy totalmente de acuerdo contigo.

-- 

Un saludo,

Carlos Rico

Enviado con Sparrow

[Alfredo Casado]

La madurez esta en la JVM, esta en las librerías del JDK, esta en la multitud de librerías del ecosistema java, y groovy se sustenta en todas estas cosas. 

Precisamente el punto más flaco de java (lenguaje) es su "madurez" y la necesidad de seguir siendo compatible con decisiones de diseño tomadas hace 10 años. La dificultad para implementar closures por ejemplo o la implementación incompleta de templates son un par de buenos ejemplos de esto. En cuanto a las librerías estándar la "madurez" que esta muy bien en cuanto a cuestiones de rendimiento y ausencia de errores supone por otro lado un problema por la dificultad de evolución para mantener la compatibilidad hacia atras, vease el api de colecciones mismo.

De todos modos no me gustan los argumentos basados en generalidades como "java es más maduro" o "java es más robusto", me parece como cuando alguien dice que los madrileños somos chulos o los catalanes agarrados, algo tendrá de verdad, pero tiene más de topico y leyenda urbana que otra cosa. Prefiero discutir con cosas concretas. ¿porque características concretas prefieres java frente a groovy para un proyecto digamos de riesgo?

[Alvaro Sanchez-Mariscal]

Me alegra ver que el Maestro Casado está totalmente convertido :D.

Un par de anotaciones sobre lo que habéis comentado:

1) Precisamente en banca y seguros, Groovy tiene muchos casos de éxito en Francia y EEUU. Hay proyectos en los que ha participado personalmente Guillaume Laforge cuando trabajaba en Octo, en aplicaciones de esas que llaman de misión crítica, haciendo DSL's y cosas así en Groovy.

2) En mi opinión personal, la compilación estática en Groovy se está realizando (entre otras cosas) para seguir en la cresta de la ola del hype de las comparativas de lenguajes de la JVM, los benchmarks y este tipo de cosas. Pero a la mayor parte de los desarrolladores no les importa especialmente.

Un saludo.

2012/6/14 Alfredo Casado <casado....@gmail.com>

--
Alvaro Sanchez-Mariscal
alvaro.sanc...@gmail.com
twitter.com/alvaro_sanchez

[Aitor Alzola]

Sin estar familiarizado, supongo que la compilación estática elimina el dinamismo, ¿no? En ese caso sólo será útil en ciertos casos... 

Aitor Alzola

[Carlos Rico]

Alfredo, creo que tienes razón en lo que dices y me redimo de mis palabras. Cuando hablaba de madurez estaba pensando concretamente en Grails y en que llevo usándolo desde las primeras versiones y me he topado con múltiples bugs que en otros frameworks "más maduros" no hubiese tenido, pero es el pago que hay que realizar por utilizarlo.

Respecto a Groovy, creo ciertamente que el problema no está en el lenguaje, ya que como bien dices este se fundamente sobre JDK. No sabía que tuviese casos de éxito en banca/seguros, me alegra oír eso.

-- 

Un saludo,

Carlos Rico

Enviado con Sparrow