¿Groovy o Scala?

class Vehiculo{
   int puertas
   String color
}

static main(args){
  def miVehiculo= new Vehiculo(puertas:4,color:"Rojo")
  println "no. de puertas: $miVehiculo.puertas"
  println "color: $miVehiculo.color"
}

class Vehiculo(val _puertasx:Int=2,val _colorx:String=null){

  private var _puertas:Int=_puertasx
  private var _color:String=_colorx
 
  def puertas = _puertas
  def puertas_= (value:Int):Unit = _puertas = value
 
  def color=_color
  def color_=(value:String):Unit=_color=value
 
}

object EjemploScala{

        def main(args: Array[String]): Unit = {
          val miVehiculo=new Vehiculo(4,"Verde")
          Console.println("no. puertas: "+miVehiculo.puertas)
          Console.println("color: "+miVehiculo.color)
        }
       
       
}

Link:
Groovy o Scala esa es la cuestión

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de echan

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:

 case class Vehiculo(val puertas:Int, val color:String)

 object EjemploScala{

        def main(args: Array[String]): Unit = {
           val miVehiculo = Vehiculo(4, "Verde")
           println  s"no. puertas:  ${miVehiculo.puertas}"
           println  s"color:  ${miVehiculo.color}"
        }
 }  

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:

case class Vehiculo(val puertas:Int, val color:String)

object Main extends App {
   val miVehiculo = Vehiculo(4, "Verde")
   println  s"no. puertas:  ${miVehiculo.puertas}"
   println  s"color:  ${miVehiculo.color}"
}

Imagen de echan

aaah, cierto, el trait App

aaah, cierto, el trait App simplifica mas las cosas.

Ni idea que tiene que ver haskell en todo esto :)

Imagen de ezamudio

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 private), así que todos esos getters y setters que pusiste realmente son innecesarios, incluso sin tener que convertir tu clase en case class.

Imagen de ElderMael

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.

Imagen de bferro

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  var x, su getter se nombra como x y su setter como x_.
Por ejemplo, si tenemos la clase Tiempo definida como sigue:

class Tiempo {
    var hora =12
    var minuto =0
}

su "código real" es algo así:

class Tiempo {
    private[this] var h = 12
    private[this] var m =0
    def hora: Int =h
    def minuto:  Int =m
    def hora_=(x:Int) {h =x}
    def minuto_= (x:Int) {m=x}
}

Y podemos entonces usar esas propiedades como sigue:

val t = new Tiempo
t.hora =20
val minuto = t.minuto
Imagen de Sr. Negativo

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.

Imagen de Sr. Negativo

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:

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.

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:

def myMethod(x){
  somethigElse(x) + x
}

En cambio en Scala cuando menos hay que especificar el tipo de los argumentos.

Cuestión de perspectiva.