ViveCodigo ataca de nuevo con una emisión doble sobre Scala

Me complace nuevamente anunciar que ViveCodigo.org el podcast con screencast, ha publicado un nuevo episodio en el cual entrevistamos a Julio Carlos Sanchez (@TheGeekInside) que nos habla sobre Scala. Fue una entrevista muy interesante ya que ademas platicamos de la creación de una empresa llamada TypeSafe (http://typesafe.com) que se va a encargar del desarrollo de Scala y Akka (libreria de actores para Scala y Java). La platica se puso muy buena, tanto que tuvimos que partir el episodio en 2 partes, en le primer parte es la entrevista y la segunda un screencast de introducción a Scala.

Aqui la entrevista

Acá la parte practica de introducción a Scala.

Acá podrán ver todas las ligas que comentamos, así como el código fuente del screencast: http://vivecodigo.org/2011/05/18/podcast-2-de-la-temporada-0/
Muchas gracias por ver el podcast, esperamos sus comentarios.
Saludos

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 rodrigo salado anaya

Cool

Están geniales las entregas de VivieCodigo, muchas gracias por difundir de esta manera la información. Ver este tipo de podcast me influye mucho :D, empezare tomando me una 'Lion' antes de programar.... :|

Saludos : )

Imagen de Sr. Negativo

Buena plática

Yo me tomaría unas dos tazas de café...ja ja ja . No en serio, buen aporte.

Me gustaria que hablaran sobre los problemas de usar los Frameworks.

Imagen de Jvan

Buenísimo!!!

Es una gran idea ViveCodigo, me encanta la idea de hacerlo tipo charla entre camaradas, lo que le da un toque más fresco y no tan estricto. Esperemos sigan aportando de esta manera. La calidad de los temas es muy buena.

Como ya lo había dicho

Como ya lo había dicho antes... Cuidado con las chelas porque esto puede terminar como los poetahuevos pero ahora en versión geek

Saluuuud!!

Al fin tuve tiempo para ver

Al fin tuve tiempo para ver el code cast.

Antes que nada muchas felicidades por la iniciativa está muy padre y como dice Rodrigo, es inspirador.

Acá van algunas observaciones y dudas sobre el 2do video, que no son más que eso, observaciones, no pretendo que sean como crítica "destructiva" ( si tal cosa existiera) sino como retroalimentación ( crítica simplemente ).

Por cierto hacer un video así de corrido y hacerlo tan ágil el mismo tiempo es bastante difícil y muestra la experiencia del que habla. Kudos!!

trait Application

Leí hace tiempo que no es recomendado usar el triat Application, sucede que el código se ejecuta cuando el objeto se está instanciando y nunca termina de instanciarse hasta que termina la aplicación.

object Hola extends Application {
   // empieza la construcción
   .
   .
   .
   // apunto de terminar la consutrcción
}

Y había otras razones, pero en ese entonces no estaba en posición de entenderlas.

object

object No es en realidad un singleton, en el sentido que Scala no dice: "object es un singleton" y además quizá en programación funcional ni siquiera haga sentido hablar de Singleton, etc. Pero si es un singleton en su implementación ( en bytecode pues ) y a los ojos de Java, pero esto es más como hablar de los detalles de la implementación que del concepto ( como aquello de hacer referencia a la interfaz y no a la implementación ).

Scala no tiene miembros de clase ( static ) y los companion objects cubren ese rol.

Inferencia de tipo
Typeless : No es que NO tenga tipo, Scala es un lenguaje de tipeo fuerte y además estático ( Ruby por ejemplo es de tipeo fuerte y dinámico, JavaScript tiene tipeo débil y dinámico ) en realidad eso se llama "Inferencia de tipo" ( type inference ) . La inferencia de tipo esta muy bien hecha en Haskell, que también es un lenguaje de tipeo fuerte y estático.

Métodos

Una cosa que nunca me ha quedado muy clara hasta la fecha es ¿por que algunas definiciones tienen Unit = { y otras no.

Ejemplo:

   def unMetodo() {
   }
   def otroMetod() : Unit = {
   }

Alguién puede explicar la diferencia?

Repeated parameters +1 Por esa aclaración, yo les decía aún "var args", pero el nombre que le da Scala como bien dice Juan Carlos es precisamente "repeated parameters"

Traits

Más que ser una forma de inyección de dependencias ( que de nuevo así es como se ve por debajo y de cara a Java, pero no es en realidad el concepto que Scala le pretende dar) un trait ( rasgo o característica ) tiene como finalidad darle más funcionalidad a una clase sin esta tener que reenviarle el mensaje.

trait Saludador {
   def hola() = "Hola hola, hola"
}
trait Despedidor {
   def  adios() = "Adios, adios, adios"
}
class X extends Saludador with Despedidor {
}

En Scala como en Java no existe la herencia múltiple, pero si se puede crear una clase que tenga la funcionalidad de varios traits. Es más similar a la composición que a la inyección de dependencias porque la clase X tiene disponible los métodos hola() del trait Saludador y adios() del trait Despedidor

val x = new  X();
x.hola() // Hola hola, hola
x.adios() // Adios, adios, adios

Conclusión

De nuevo está muy padre el concepto, es increíble la cantidad de información que se puede transmitir y obtener en 40 minutos comparandolo con TOOODO el tiempo que toma aprenderlo de forma autodidacta. Por ejemplo, nunca había podido ( querido ) ver un ejemplo de los Actores y los mensajes y ahora que lo vi con uds. me despejaron muchas dudas.

Seguiré atento al siguiente emision de ViveCodigo y de los contenidos del Scala MUG.

Saludos.

Unit

Leyendo Programming in Scala ,dado que Scala se inspira en su parte funcional mucho en haskell , Unit se debe indicar si hay una iteracion con el mundo real o side effect (efecto colateral), en haskell seria el tipo () o tupla vacia o tambien conocido como unit ,es muy parecido a void en java incluso cuando llamas metodos void en java son traduccidos como Unit.

Usar unit si tu metodo tiene un efecto colateral.

P.D Me gusto mucho tu explicacion de Object.

Re: Buena plática

Dudo que hablen sobre los problemas de usar frameworks. De entrada son miembros de Spring Hispano, cómo cosas alternas usan Groovy y siendo programadores web usan Grails...En lugar de hablar de los problemas creo que hablarían más de las ventajas.

Re: Al fin tuve tiempo para ver

Con los traits, podemos decir que son cómo las interfaces no recuerdo si en smalltalk o en haskell...En donde podías tener una implementación estándar y usandola dentro de una clase podías modificar o no dicha "pre-implementacion"...Por ejemplo:

trait Greetings{
----def hola(nombre:String, message:String);

----def holaEspanyol(nombre:String){ println("Hola " + nombre); }
}

//Y ya en una clase implementamos los necesarios
//y el método holaEspanyol es opcional implementarlo.
class Saludar extends Greetings{
----def hola(nombre:String, message:String){
--------println("Bonjour " + nombre);
----}
}

Respecto a las traits se explican de manera entendible (aunque no profunda) en la documentación de Scala.

Con lo de los métodos porqué a veces tienen "= {}" y otras veces son sólo "(){}", es porqué uno conlleva a efecto colateral y no es (se me fue la palabra) "mandatorio" el return:

//Suponiendo que estamos dentro de una clase o companion object
def esMayor(obj : Any){
----return obj.val > this.val
}

def esMayorSideEffect(obj:Any) : Boolean = {
----obj.val > this.val //este es el valor que será "retornado" al llamar objeto.esMayorSideEffect(otroObjeto)
}

Imagen de domix

No veo la relación de las

@wishmaster77
No veo la relación de las cosas que nos gustan hacer y de los problemas que tenemos todos los días en el trabajo, pero, en general nada es perfecto, IMHO prefiero entender un framework, conocerlo a fondo para poder salir de los problemas. En mi formación profesional y experiencia me he dado cuenta que muchas personas prefieren hacer las cosas a su modo, no usar herramientas; no los critico, jamas los hare cambiar de opinión. Pero he aprendido que es mejor aprovechar la experiencia de los demás para resolver problemas, sin dejar a un lado aprender las bases. Yo prefiero mantenerme del lado positivo de las cosas, si alguna vez haz escuchado alguno de los podcast que hacíamos sobre Spring y Groovy; muchas veces critique varias cosas, de nuevo nada es perfecto.

Re: No veo relación de las

Al parecer me lo has tomado a mal o no interpretaste cómo debiera.

El punto es que creo que alguien cómo tú (o cómo yo) en lugar de enfocarnos en los problemas, dificultades o desventajas de un framework (cualquiera que este sea); nos enfocamos más en las ventajas...Cómo bien dices, ver lo positivo. Si bien sé que usan Spring, Groovy y Grails, y que son sus herramientas de día a día; con lo que podemos deducir, que han encontrado más ventajas que desventajas.

Cómo bien dices nada es perfecto, pero si hay cosas que ayudan mucho, aunque cómo bien dices siempre tenemos que echar mano de las bases, por ejemplo en caso de Java: OOP, algunos patrones de diseño, el lenguaje mismo, etc. Y cómo bien comentas, no hay nada perfecto, sólo algo que va mejor con cada quien.

Imagen de bferro

Excelente plática y uno de mis comentarios

Felicidades otra vez a los que organizan Vive Código. Fue una buena introducción a Scala, mostrando algunas de las bondades de un lenguaje que ha sabido meter muchas cosas de la programación funcional en un lenguaje orientado a objetos.
Mis comentarios a los comentarios sobre esta plática.
Acerca de object Name { ..... } y class Name {.....}. Sí son singleton objects
Scala es un lenguaje orientado a objetos puro en el sentido que todo es un objeto y todo objeto es un valor. Eso incluye a las funciones que son instancias de clases y a otras cosas.
En Scala el método básico de computación es "enviar mensajes a objetos" quien dispone de métodos para resolver esos mensajes.
No puede entonces Scala permitir el uso de miembros de clases, o como los conocemos miembros estáticos en el mundo de Java.
Eso no quiere decir que podamos prescindir de lo que los miembros de clase resuelven y por esa razón aparecen los objetos singleton, que en ocasiones son companion objects, pero que en ocasiones no lo son. El caso en que no lo son es cuando no definimos a su companion class, y entonces se usa el término standalone object.
Así lo define Odersky en su libro:
Singleton object. An object defined with the object keyword. Each singleton object has one and only one instance. A singleton object that shares its name with a class, and is defined in the same source file as
that class, is that class’s companion object. The class is its companion class. A singleton object that doesn’t have a companion class is a standalone object.

Es singleton en el sentido que solamente existe una instancia del mismo que acompañará a todos los objetos que se instancien de su clase companion. Al ser el mismo objeto, todos los miembros de él son compartidos por todos los objetos de su clase companion, logrando una de las cosas que persiguen los miembros estáticos en Java.
La implementación que se usa para la JVM es definir una clase interna de la clase companion para describir ese singleton object.
Hay otras cosas muy interesantes con los singleton objects. Una vez que lo inventan, le sacan entonces provecho para usarlos como fábricas de objetos de su clase companion inclusive con uso de la herencia.
También se aprovechan de la ázucar sintáctica para crear objetos sin el operador new y otras chuladas más.

Con respecto a la instanciación, Scala considera que la definición con object { ..... } es lazy. El objeto no se creará hasta tanto no sea usado.

Imagen de bferro

El tipo de retorno a veces no se puede inferir

La inferencia de tipos en Scala establece que para algunos casos el tipo de retorno no se puede inferir. Esos casos son:
Cuando de forma explícita se llama a return, inclusive como última línea del método.
Esta línea no compila:
 def metodo()=return ();
Es necesario escribir el tipo de retorno:
 def metodo1():Unit=return ();  //Ahora sí compila. () es el único valor del tipo Unit

Cuando un método es recursivo
Esta línea no compila:
def metodo2()=metodo2();
Es necesario escribir el tipo de retorno:
def metodo2():Unit=metodo2(); //Ahora sí compila pero NO LO HAGAS

Cuando un método se sobrecarga y uno de los métodos llama a otro. El que llama necesita escribir su tipo de retorno.
La segunda línea no compila:

def metodo3()=metodo();
  def metodo3(i:int)=metodo3; //Error de compilación

Es necesario escribir el tipo de retorno para metodo3(int)

def metodo3()=metodo();
  def metodo3(i:Int):Unit=metodo3; //Error de compilación

Cuando el tipo de retorno inferido podría ser más general del que esperas.
Este es un caso atípico, pues es un bug del programador. Lo tomo del libro Programming in Scala

Lo siguiente compila:

  def makeList(strings: String*) = {
    if (strings.length == 0)
      List(0) // El programador se equivoca y cree que esto es una lista vacía.
    else
      strings.toList
  }

Al realizar esto :

val list:List[String]=makeList();

se produce un error que esconde el bug.

type mismatch;
found : List[Any]
required: List[String]

Aunque he usado Unit como tipo de retorno, lo anterior aplica para cualquier tipo

Singleton.

Aclarado está, singleton pues.

Aprovechando aquí hay dos referencias de lo que dice @bferro ( si es que te refieres al libro "Programming in Scala" )

http://www.artima.com/pins1ed/classes-and-objects.html#4.3

http://www.artima.com/pins1ed/glossary.html#g775061748

Yo había sacado de aquí: http://www.scala-lang.org/docu/files/ScalaReference.pdf y acá Video talk on Scala by Martin Oderski mi referencia y no vi llamarle así al object pero dadas las referencias digamosles así. A mi me gusta más pensar en el lado funcional, donde estos objetos son "valores".

Por cierto, otro asunto de nomenclatura son los métodos "estáticos" que en Java son llamados "oficialmente" ( vaya si le hacemos caso a la especificación del lenguaje ) métodos de clase: A method that is declared static is called a class method. Supongo que no había mejor parabra reservada que "static". No me imagino:

class Main {
   public class-level void main( String [] args ) {
   }
}

:) :)

Sobre ": Type = {"

Ah vaya eso tiene sentido.

Me vuelve loco que al escribir algo en Scala, no saber cuando le lengo que poner " : Type = {" y cuando no.

Por ejemplo según yo ( y corrijanme por favor ) esto iguala el método a un "objeto" creado al vuelo ( on la literal { } )

   def algo() : Type  = {
   }

Y yo lo que intentaba es no usar esa literal sino como normalmente se haría ( y acá empezamos a tocar los límites de lo que se considera "normal" :) :) )

   def otro() : Type {
   }

Me vuelve loco cuando no entiendo cuando usar uno u otro. Ahora volveré acá cuando me vuelva a salir ese error de compilación.

Byte!

Imagen de bferro

def f(i:Int) = {i+1} no es lo mismo que def f(i:Int) {i+1}

Las funciones en Scala se definen con def, seguida por la lista de argumentos, seguido por el signo = y seguido por el cuerpo de la función.
Si se omite el signo igual, la función devuelve Unit y por supuesto realiza el cálculo que escribes en el cuerpo de la función pero hace caso omiso al resultado. En realidad no es una función que devuelve un valor.
Ejemplo:

scala> var foo=1
  def f(i:Int)= {
    foo=foo +1
    println(foo)
    i+1
  }
  def g (i:Int) {
    foo=foo +1
    println(foo)
    i+1
  }
foo: Int = 1
f: (i: Int)Int
g: (i: Int)Unit

scala>println(f(0))
2
1
scala>println(g(0))
3
()
scala>

Imagen de thegeekinside

Aclaraciones

Oscar muchas gracias por tu retro, es muy importante para mi tener criticas pues me ayudan a mejorar.

Por otro lado hay algunas cosas que me gustaría aclarar:

  • Typeless
  • Lo que comenté en la charla es que de alguna manera es Typeless al momento en que estás codificando pues no tienes que preocuparte por ponerle un tipo a tus variables o funciones ya que el compilador lo infiere en muchos de los casos, sin embargo Scala es un lenguaje Strongly Typed pues en tiempo de compilación se revisa que todas las variables, funciones, parámetros, etc. tengan el tipo con el que fue declarado o en su caso inferido por el compilador.

  • Uso del trait App
  • El uso del trait App conocido como Application hasta la versión 2.8.x, no se recomienda en la práctica pues tiene algunos problemas que son mencionados en la documentación de dicho trait:


    In practice the Application trait has a number of serious pitfalls:

    • Threaded code that references the object will block until static initialization is complete. However, because the entire execution of an object extending Application takes place during static initialization, concurrent code will always deadlock if it must synchronize with the enclosing object.
    • As described above, there is no way to obtain the command-line arguments because all code in body of an object extending Application is run as part of the static initialization which occurs before Application's main method even begins execution.
    • Static initializers are run only once during program execution, and JVM authors usually assume their execution to be relatively short. Therefore, certain JVM configurations may become confused, or simply fail to optimize or JIT the code in the body of an object extending Application. This can lead to a significant performance degradation.

  • Traits
  • Como bien comentas un trait no solo es para inyección de dependencias, de hecho se define como: Una unidad fundamental de código reusable, un tema que quería exponer con el uso de traits es el patrón Cake que es una manera de modularizar el código y usar un tipo de inyección de dependencias, quizá ahí es donde se creo la confusión.

De nuevo gracias por tus comentarios.

Saludos.

Hay problemas sin duda...

@Sr. Negativo
Podríamos comentar problemas de frameworks o de lenguajes como Groovy en mi caso, de hecho he tenido un par de problemas con Groovy debido al gran dinamismo que tiene y a veces es un poco difícil detectarlos especialmente hablando de Metaprogramación, pero conociendo más el lenguaje o el Framework se pueden resolver, sin duda, aunque Groovy, Spring, Hibernate, jQuery u otros frameworks o herramientas ofrecen muchas ventajas también tienen talones de aquiles o situaciones con no abarcan, sin embargo, es agradable ver que en el mundo de Open Source tenemos opciones...
De una de las cosas que a veces me gusta hablar a mi es de los posibles errores que a todos nos tienen que aparecer y con los que nos tenemos que enfrentar, como caso de ejemplo, pongo una solución que escribí en los foros de SpringSource cuando cualquier desarrollador trataba de combinar Hibernate y Spring con Maven y el conflicto que causaban las dependencias de CGLIB por las versiones que usaba cada uno...
http://forum.springsource.org/showthread.php?26713-Spring-2.0-AOP-ASM-De...
Es simple, pero son cosas con las que nos topamos y sin lugar a duda se pueden platicar...