Scala

Lenguaje funcional sobre la JVM, orientado a concurrencia y paralelismo.

Scala: Clases "case" y pattern matching (1/2)

Las clases case (no encuentro un término adecuado en español) son uno de los mecanismos que Scala utiliza para hacer "pattern matching" sobre objetos, sin la necesidad de escribir el código de boilerplate que se requeriría si esta opción no existiera.
Pattern matching es una necesidad en la programación, y en el caso particular de la programación funcional es una técnica natural para resolver muchos problemas que hacen uso de datos recursivos con estructuras arbóreas.
Scala contribuye al pattern matching sobre objetos tratando de lograr cierta uniformidad de la sintaxis funcional y la sintaxis orientada a objetos.
Para describir las clases case y su utilización en el pattern matching necesitamos también hablar de otras cosas como las clases sealed (selladas) y del tipo Option y sus "derivados".
Utilizo aquí los ejemplos del texto de Odersky. Es un caso de estudio sencillo de comprender, y así no se pierde el tiempo. No veo necesario inventarme otros ejemplos.

Veamos primero las clases case

Scala School

Liga sobre manejo basicos de el lenguaje Scala.

http://twitter.github.com/scala_school/

El poder de Option: Más allá del pattern matching

Una de las primeras cosas a las que le tomamos gusto cuando aprende Scala, sobre todo si venimos de Java, es al pattern matching, aunque una de las cosas que desconciertan un poco es la manera en que funcionan los mapas.

En Java, si tenemos un java.util.Map simplemente le pedimos el valor para una llave, y nos devuelve el valor, o null si no lo tiene. O si el mapa acepta nulos, entonces puede devolvernos null si es que tiene null guardado bajo la llave que indicamos. ¿Cómo podemos diferenciar entre el caso en que el mapa no tiene la llave, o si tiene almacenado null bajo esa llave? Podemos verificar usando containsKey.

Entonces, tenemos los siguientes casos:

if (map.get("X") != null) {
  /* obtuvimos un valor */
} else if (map.containsKey("X")) {
  /* Tenemos null almacenado bajo la llave
} else {
  /* No existe esa llave en el mapa */

}

Concurrencia sin dolor en Java puro, parte 3

En el post anterior ya vimos una alternativa muy buena para manejo de concurrencia en Java: el modelo de STM.

En esta tercera y última parte, veremos el modelo de actores. Esto es algo que tampoco es nuevo, viene de otros lenguajes; en la JVM, Scala es un lenguaje que incluye este modelo de concurrencia. Pero gracias a una biblioteca llamada Akka, la cual fue escrita en Scala, podemos usar el modelo en Java.

Visto de una manera muy simple, un actor es un objeto que responde (o reacciona) a mensajes que se le envían, uno a la vez. Los mensajes se le pueden enviar de manera asíncrona, un mecanismo conocido como fire-and-forget, por lo que puede haber varios hilos distintos enviando mensajes al mismo actor y dichos mensajes serán encolados para que los vaya atendiendo uno por uno.

Pllugin para Grails que permite integrar código Scala

Hola,

Acabo de publicar una nueva versión del plugin de Grails que permite tener código Scala en una aplicación Grails. En breve, lo que hace este plugin es invocar al compilador de Scala con los fuentes que encuentre en el directorio src/scala y src/java de una aplicación Grails, deja los binarios en el classpath para que sean usados por artefactos Grails. Cualquier controller, servicio, taglib, etc. de Grails puede usar los binarios de Scala. La única limitante por ahora, es que desde código Scala no es posible acceder a artefactos Grails, esto debido a que no se cuenta con un joint-compiler entre Grovy/Scala. Solo existe entre Java/Scala.

Esta ultima versión, incorpora soporte para la mas reciente versión estable de Scala, la 2.9.1. Espero les sea tan útil como lo es para mi.

Ya se encuentra publicado en el repositorio oficial de plugins de Grails:
http://grails.org/plugin/scala

Los niveles de "expertisidad" en Scala

En http://www.scala-lang.org/node/8610, Martin Odersky escribe sobre los niveles de Scala para el principiante y el experto. Me parece interesante "copiar" aquí una parte referente a lo que debe conocerse y usarse según el nivel y el tipo de cosas que desarrollamos. Esto creo que puede orientar a los que están en "amoríos"con este lenguaje.

Level A1: Beginning application programmer
Java-like statements and expressions: standard operators, method calls, conditionals, loops, try/catch
class, object, def, val, var, import, package
Infix notation for method calls
Simple closures
Collections with map, filter, etc
for-expressions

Level A2: Intermediate application programmer
Pattern matching
Trait composition
Recursion, in particular tail recursion
XML literals

Level A3: Expert application programmer
Folds, i.e. methods such as foldLeft, foldRight
Streams and other lazy data structures
Actors
Combinator parsers

Level L1: Junior library designer
Type parameters
Traits
Lazy vals
Control abstraction, currying
By-name parameters

Level L2: Senior library designer

Lenguaje para scripting: Scala o Groovy?

Ultimamente que he estado descubriendo varias de las bondades de Scala, me puse a pensar si también sería una buena opción para hacer scripting. Por "scripting" me refiero simplemente a hacer programas sencillos que se ejecutan una vez en la vida, o de manera muy esporádica, o como tarea periódica no interactiva.

Hay ocasiones en que los scripts de bash no son suficientes. El ejemplo típico es cuando te piden leer un archivo de texto en cierto formato, comparar los datos con lo que tengas en una base de datos, hacer un archivo de resultados y enviarlo por correo a ciertas personas. Sobre todo si ya tienes varias partes de esta lógica implementadas en un sistema que tienes hecho en Java.

Hacer scripting en Java es extremadamente tedioso. Para empezar, estrictamente lo que se dice scripting pues no se puede hacer. Obviamente puedes hacer una clase con un main y desde ahí invocar el código que necesitas, procesar datos, etc etc pero pues hay que compilarlo y luego ejecutarlo y para eso hay que ponerle un classpath probablemente bastante largo y es una lata. Simplemente el tener que estar compilando ya te lleva a que uses alguna herramienta para llevarlo como proyecto y, sin importar que uses Gradle/Ant/Maven/Ivy, ya se complicó demasiado el asunto.

Integración entre lenguajes JVM

En 2007 hice una biblioteca de software llamada j8583 y desde entonces la utilizo, actualizándola de vez en cuando con algunas optimizaciones o características nuevas.

Una de estas características nuevas se la agregué cuando comencé a utilizar j8583 en Groovy. Resulta que Groovy tiene azúcar sintáctica para realizar algunas operaciones, por ejemplo:

arreglo.add(elemento); //Java
arreglo << elemento //Groovy

outputStream.write(datos); //Java
outputStream << datos //Groovy

arreglo.get(5); //Java
arreglo[5] //Groovy

//Java
mapa.get("llave");
mapa.put("llave", valor);

//Groovy
mapa['llave']
mapa["llave"] = valor

Scala ahora sobre .NET

Miguel García, que forma parte del grupo de Scala de la EPFL, se ha esforzado por hacer que la productividad de Scala quede a disposición de los desarrolladores. NET también. En un proyecto financiado por Microsoft, que ha alcanzado un hito importante en la entrega de esa capacidad. En esta entrevista Miguel le dice cómo ahora se puede utilizar Scala en .Net y da una idea de cómo se ha logrado este ambicioso proyecto y la dirección futura.

¿Por qué la gente necesita en Scala. Net?

Miguel:

Hay muchas razones por qué esto es atractivo tanto para los desarrolladores y empresas en general. Scala es un lenguaje de programación conciso y altamente productivo. Mediante el uso de Scala. NET, los desarrolladores pueden producir aplicaciones más rápidamente y tienen la posibilidad de desplegar a través de las dos plataformas importantes de la industria, la JVM y .Net.

HolaMundo en Scala III: Mensajes síncronos, patrones

Sigo estudiando algo de Scala, de manera muy empírica aún, leyendo varias referencias y fuentes de información de todo tipo, y sigo aprendiendo bastante.

He seguido orientándome más a la parte de multiprocesamiento, que a la parte de programación funcional. Sigo jugando con el ejemplito del servidor holamundo; ahora le puse manejo de excepciones, condiciones de salida y he estado viendo algo del pattern matching que parece ser una parte importante de Scala, para varias cosas distintas (desde usarse en vez de un simple cast que haríamos en Java, hasta manejo de excepciones, y por supuesto los mensajes entre actores).

Condiciones de salida

Primero que nada, ya le agregué una condición de salida a la clase Servidor, para que dependiendo de algún mensaje recibido por un socket, se pueda terminar con el ciclo que estaba previamente definido como infinito. Para ello agregué un nuevo método con la intención de que lo invoque un actor desde otro proceso, y el debido manejo de una excepción que esta secuencia de salida genera. Con esto ya podremos apreciar algo del manejo de excepciones, que es ligeramente distinto a Java. Queda así al final:

Distribuir contenido