La diferencia principal está en dónde quieres pasar tu tiempo:
Con Groovy, lo vas a pasar haciendo mil pruebas unitarias y de integración para verificar que tu código funciona bien, porque en Groovy todo compila, y por tanto todos los problemas ocurren en tiempo de ejecución.
Con Scala, si tu código compila es casi casi garantía de que va a correr bien... pero para compilar se tarda siglos, entonces vas a pasar tu tiempo esperando a que el compilador termine.
Ya un poco más en serio: según recuerdo, Scala genera getters y setters para las propiedades, pero no recuerdo cómo le haces para marcar que algo es una propiedad (ciertamente no es poniéndole ), así que todos esos getters y setters que pusiste realmente son innecesarios, incluso sin tener que convertir tu clase en case class.
Para cualquier variable reasignable en Scala se pueden realizar dos operaciones fundamentales: obtener su valor o cambiarlo con un nuevo valor. Para toda variable que no sea miembro privado de algún objeto, Scala genera un método getter y un método setter. Si, digamos, la variable es , su getter se nombra como y su setter como .
Por ejemplo, si tenemos la clase Tiempo definida como sigue:
su "código real" es algo así:
Y podemos entonces usar esas propiedades como sigue:
Submitted by wishmaster77 on Lun, 03/24/2014 - 09:25.
Solo sería bueno aclarar que la trait App, a pesar de simplificar, no inicializa los campos del objeto antes de ejecutar el método main. De hecho en la ScalaDoc viene una nota al respecto:
It should be noted that this trait is implemented using the DelayedInit functionality, which means that fields of the object will not have been initialized before the main method has been executed.
Submitted by wishmaster77 on Lun, 03/24/2014 - 09:43.
En mi caso voy más Scala ya que, aunque es muy flexible y te da demasiadas maneras de hacer una misma cosa, te obliga a cambiar un poco tu manera de plantear y analizar un problema.
Groovy, para mí, a pesar de aportar muchas cosas y de inspirarse en lenguajes que me encantan (cómo Ruby), no te obliga tanto a cambiar tu manera de pensar. Incluso conozco mucha gente que "sabe" Groovy y lo único que hacen es cambiar la extensión del archivo de .java a .groovy; por qué una gran mayoría del código que funciona en Java también funciona en Groovy. Y el punto más negativo que le veo a Ruby es el tipado dinámico, es cómodo a la hora de programar, pero, tu tiempo de pruebas se extiende mucho, luego encontrar el por qué de un error considero que es más difícil, un ejemplo sería:
En cambio en Scala cuando menos hay que especificar el tipo de los argumentos.
Hay alguna razon para
Hay alguna razon para escribir todo eso en Scala? mas bien parece Java sin punto y coma. La forma más consistente e idiomática sería:
Muy similar a lenguaje dinamico, pero con la garantía de que hay verificacion estática.
Que hay con el logo de
Que hay con el logo de Haskell?
@echan o bien:
aaah, cierto, el trait App
aaah, cierto, el trait App simplifica mas las cosas.
Ni idea que tiene que ver haskell en todo esto :)
Tiempo
La diferencia principal está en dónde quieres pasar tu tiempo:
Con Groovy, lo vas a pasar haciendo mil pruebas unitarias y de integración para verificar que tu código funciona bien, porque en Groovy todo compila, y por tanto todos los problemas ocurren en tiempo de ejecución.
Con Scala, si tu código compila es casi casi garantía de que va a correr bien... pero para compilar se tarda siglos, entonces vas a pasar tu tiempo esperando a que el compilador termine.
Ya un poco más en serio: según recuerdo, Scala genera getters y setters para las propiedades, pero no recuerdo cómo le haces para marcar que algo es una propiedad (ciertamente no es poniéndole
Propiedad... de esas de getters y setters?
Solo hay que anotar el campo con la anotacion @BeanProperty o si es booleano con @BooleanBeanProperty.
Eso es para que genere getters y setters a la usanza de Java que como tal no son propiedades sino convenciones.
Los getters y setters on generados por Scala
Para cualquier variable reasignable en Scala se pueden realizar dos operaciones fundamentales: obtener su valor o cambiarlo con un nuevo valor. Para toda variable que no sea miembro privado de algún objeto, Scala genera un método getter y un método setter. Si, digamos, la variable es
Por ejemplo, si tenemos la clase Tiempo definida como sigue:
su "código real" es algo así:
Y podemos entonces usar esas propiedades como sigue:
Scala o Groovy
Quería hacer una comparación, lo hice muy similar a como se escriben las clases en Java.
Gracias por la aclaración.
Logo de Haskell
Solo es una imagen :D
Re: Que hay con el logo de
Solo sería bueno aclarar que la trait App, a pesar de simplificar, no inicializa los campos del objeto antes de ejecutar el método main. De hecho en la ScalaDoc viene una nota al respecto:
Saludos.
Scala
En mi caso voy más Scala ya que, aunque es muy flexible y te da demasiadas maneras de hacer una misma cosa, te obliga a cambiar un poco tu manera de plantear y analizar un problema.
Groovy, para mí, a pesar de aportar muchas cosas y de inspirarse en lenguajes que me encantan (cómo Ruby), no te obliga tanto a cambiar tu manera de pensar. Incluso conozco mucha gente que "sabe" Groovy y lo único que hacen es cambiar la extensión del archivo de .java a .groovy; por qué una gran mayoría del código que funciona en Java también funciona en Groovy. Y el punto más negativo que le veo a Ruby es el tipado dinámico, es cómodo a la hora de programar, pero, tu tiempo de pruebas se extiende mucho, luego encontrar el por qué de un error considero que es más difícil, un ejemplo sería:
En cambio en Scala cuando menos hay que especificar el tipo de los argumentos.
Cuestión de perspectiva.