 |
From: Carlos Rico <crico.a...@gmail.com>
Date: Thu, 14 Jun 2012 09:36:50 +0200
Local: Thurs, Jun 14 2012 3:36 am
Subject: RE: [grailsEnCastellano] Presentacion y consulta
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.
--
El jueves 14 de junio de 2012 a las 00:57, Alfredo Casado escribió:
> 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?
> El 14 de junio de 2012 00:19, Carlos Rico <crico.a...@gmail.com (mailto:crico.a...@gmail.com)> escribió:
> > --
> > El miércoles 13 de junio de 2012 a las 23:07, Alfredo Casado escribió:
> > > 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.
> > > El 13 de junio de 2012 21:55, Carlos Rico <crico.a...@gmail.com (mailto:crico.a...@gmail.com)> escribió:
> > > > 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.
> > > > Saludos!
> > > > --
> > > > El miércoles 13 de junio de 2012 a las 19:37, Aitor Alzola escribió:
> > > > > 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.
> > > > > [1] http://docs.codehaus.org/display/GROOVY/2012/05/07/Static+compilation...
> > > > > 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, > > > > > --
> > > > > --
> > > > --
> > > --
> > --
> --
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||