Estuve en el Lambda World

Escribo estas líneas volviendo en tren desde Cádiz, una ciudad enigmática que me recuerda muchísimo a mi añorada Habana, tal vez porque la segunda se construyera basándose en la primera.

Cádiz, además de ser la ciudad que acogió la firma de la primera Constitución Española en 1812, ha acogido el pasado fin de semana el primer evento internacional de programación funcional celebrado en España, el Lambda World.

En este evento, ponentes de todas partes del mundo han venido a contarnos acerca de características de la programación funcional como mónadas, funciones puras, inmutabilidad, efectos secundarios, o sobre cómo llevar conceptos de programación funcional a programación orientada a objetos.

Para ello, hemos visto ejemplos en lenguajes como F#, C#, Java, Ruby, Swift, y, sobre todo, Scala. He aprendido muchísimo y aquí resumo algunos conceptos que me han llamado la atención y que me toca seguir estudiando.

La inmutabilidad, más complicada pero menos propensa a errores.

En programación orientada a objetos definimos clases con propiedades y comportamiento. Este comportamiento suele implicar un cambio en el estado del objeto.

Sin embargo, es justamente lo que queremos evitar en programación funcional, ya que trabajamos con objetos inmutables, con lo cual una vez creados, no cambia ninguna de sus propiedades.

Esto también se aplica a colecciones, y a los miembros de la misma, con lo cual la acción de añadir un objeto a una colección, o modificar un objeto de la misma requiere crear una nueva colección.

Con estos objetos inmutables lo que conseguimos asegurarnos que su estado no va a cambiar, y que no vamos a tener «sorpresas» cuando pasemos un objeto a un método que de repente modifique alguna de sus propiedades.

Sin embargo, aunque lenguajes como Swift, Scala o F# soportan inmutables por diseño, en el mundo clásico de la orientación a objetos, tanto para Java, C# o Ruby, es justamente al contrario, y queda de nuestra mano utilizar colecciones inmutables y definir manualmente nuestros objetos.

Las funciones puras no generan efectos secundarios, o casi

Otro concepto que se repitió bastante en el evento era el de función pura, que no es más que un método que recibe una entrada y devuelve una salida.

La magia de este concepto es que cuando lo combinamos con los objetos inmutables, conseguimos que para una entrada X tenemos la absoluta seguridad de que la salida será Y, SIEMPRE.

Esto nos permite, entre otras cosas, poder probar de manera rápida nuestras funciones si el lenguaje que estamos utilizando incorpora una consola REPL (Read Evaluate Print Loop), ya que una vez definida la función solamente tenemos que ejecutarla con los valores adecuados.

Los lenguajes funcionales no son algo solamente «académico»

Aunque los conceptos que nos muestren se acerquen bastante más a las matemáticas que a ensamblador, los ejemplos mostrados en aplicaciones móviles, sistemas cliente-servidor, arquitecturas funcionales y videojuegos, me dejaron bastante claro que la programación funcional está aquí para quedarse, y que ya estamos tardando, al menos, en aprender algunos de sus conceptos.

No tengo ni idea de lo que son las monads, creo.

Uno de los conceptos de programación funcional que se me escapa es el de las monads, que al parecer son tipos de datos con propiedades específicas, y uno de los ejemplos que veíamos en el evento era el del monad Either, que tiene dos tipos, Left o Right.

Con este monad podíamos definir el resultado de nuestra función, siendo Left un resultado de éxito, y Right una definición de un error, evitando flujos como captura de excepciones.

Este concepto tiene a su vez conceptos relacionados como monoids o functors… de los cuales tendré que leer, y mucho.

Podemos usar conceptos de programación funcional con lenguajes no puramente funcionales.

Conceptos como funciones puras u objetos inmutables son relativamente fáciles de implementar aunque los lenguajes no lo refuercen nativamente, sin embargo requiere un grado de disciplina mayor.

Sin embargo lenguajes como C# o Java van aportando cada vez más características de la programación funcional a su sintaxis, como las Lambdas y las colecciones inmutables. Aunque no es el escenario ideal para utilizar programación funcional, nos permite usar lo que ya sabemos.

Tenemos muchas maneras de empezar, aunque hay dos muy interesantes:

Por una parte tenemos lenguajes como Scala, en el que podemos desarrollar de la misma manera en la que lo veníamos haciendo hasta ahora, ya que soporta tanto tipos mutables como inmutables, e ir agregando características de la programación funcional a nuestros programas.

Por otra parte tenemos lenguajes F#, que nos permite lanzarnos al vacío, con una sintaxis que nos podría recordar cuando encadenamos la salida de distintos procesos en una shell de unix, que nos permite aprender programación funcional más «pura» y su interoperabilidad con C# nos permite agregar componentes funcionales a nuestro proyecto.

En resumen

Tenemos características como la inmutabilidad y las funciones puras que nos evitan sorpresas en nuestro código, podemos empezar migrando poco a poco a funcional o tirarnos a la piscina con lenguajes que solamente implementan este paradigma, y tenemos algo de soporte en nuestros lenguajes del día a día de algunos conceptos como las lambdas. Ha sido una experiencia muy enriquecedora, y espero veros en la siguiente edición de Lambda World

Scala desde la perspectiva de C# y JavaScript, desde la Mindcamp

Este fin de semana he tenido la oportunidad de dar una charla en la Mindcamp sobre las características de Scala que he ido aprendiendo durante estas últimas semanas.

Aunque queda aún mucho por aprender, esta charla resume los temas que hemos ido viendo en los artículos anteriores de esta serie, así como algunos ejemplos donde podemos ver:

  • Hola mundo y diferencias de sintaxis con Java o C#
  • Clases, objetos, y funciones como ciudadanos de primera clase.
  • Sintaxis iterativa VS Sintaxis funcional.
  • Traits como manera de tener interfaces con implementación.
  • Case classes para realizar pattern matching y separar la interfaz de la implementación.

Los ejemplos están disponibles en este repositorio de Github: Mindcamp7-Scala.

Como parte de la charla, puse una lista de una serie de características que se quedaron fuera y que quedan como idea para futuros artículos, como son:

  • Frameworks como Play y Scalaz
  • Testing con ScalaTest
  • Integración con herramientas
  • La línea de comandos (REPL) de Scala
  • Interoperabilidad con Java.
  • La herramienta Activator de Typesafe
  • Scala Build Tool

Además, algunos recursos, muchos de los cuales ya hemos listado anteriormente en el blog, como son:

Finalmente, un par de libros que me recomendó el gran Jorge Barroso (@flipper83) sobre programación funcional:

Las diapositivas están disponibles en mi SlideShare: Scala desde C# y JavaScript

La semana próxima estaré en la LambdaWorld, un evento que reúne en Cadiz a lo mejor de la programación funcional, y habrá, por supuesto, Scala. Nos vemos allí!

Scala desde la perspectiva de C# y JavaScript, tercera parte

En los artículos anteriores de esta serie, veíamos una pequeña introducción a Scala, y hacíamos una kata para comprobar que habíamos entendido la sintaxis. En este artículo veremos dos construcciones del lenguaje que resultan bastante interesantes, llamadas traits y case classes.

Traits

Podemos entender los traits como una mezcla entre interfaces y clases abstractas, ya que podemos definir un contrato como haríamos con una interfaz, y por otra parte podemos definir también una implementación.

A diferencia de Java, Scala nos permite implementar varias traits, y podemos utilizarlas para agregar características adicionales a nuestro código. Veamos un ejemplo.

En este caso vamos a definir una clase base llamada Employee, que tiene un salario, y luego vamos a definir varios traits, algunos solamente con valores, y otros con pequeñas comprobaciones.

  • El trait Temporary calcula el mes final del contrato
  • El trait Authority nos permite saber si un empleado tiene gente a su cargo
  • El trait Remote nos permite establecer una localización y una zona horaria
  • Finalmente, el trait InOffice nos permite establecer un despacho.


abstract class Employee {
def salary: Int
}
trait InOffice {
def desk: String
}
trait Remote {
def location: String
def timeZone: String
}
trait Temporary {
def startDate: Int
def stay: Int
def endDate(): Int = (startDate + stay) % 12
}
trait Authority {
def directReports: Array[Employee]
def hasDirectReports() :Boolean = directReports.length != 0
}

view raw

traits.scala

hosted with ❤ by GitHub

Con estos cuatro traits podemos componer las clases que forman a nuestros empleados, donde tenemos a Developer, a Manager y a Intern:


class Intern (salary_param: Int, desk_param: String, startDate_param: Int) extends Employee with InOffice with Temporary {
val salary = salary_param
val desk = desk_param
val stay = 6
val startDate = startDate_param
}
class Developer (salary_param: Int, desk_param: String) extends Employee with InOffice {
val salary = salary_param
val desk = desk_param
}
class Manager (salary_param: Int, location_param: String, reports: Array[Employee]) extends Employee with Remote with Authority {
val salary = salary_param
val location = location_param
val directReports = reports
}

Como vemos en el ejemplo, podemos utilizar los traits para definir características adicionales a nuestras clases, y podemos también agregar lógica dentro de las mismas, mezclando los conceptos de interfaz y clase abstracta.

Case classes

La otra cara de la moneda son las Case Classes, que podemos encontrar cuando definimos jerarquías, pero sobre todo las podemos encontrar cuando tenemos un número específico de entidades y lo que realmente cambia es lo que hacemos con ellas. Recuperando el mismo caso de empleados, becarios y managers, vamos a redefinirlo como Case Classes:


abstract class Employee
case class Manager(startYear: Int, direct: Array[Employee]) extends Employee
case class Dev(startYear: Int) extends Employee
case class Intern(stay: Int) extends Employee

En este caso hemos simplificado la manera de definir los diferentes datos, y solamente utilizaremos la fecha inicial para Dev y Manager, y el tiempo total de estancia para Intern. En este caso, podemos asumir que nuestro conjunto de datos está fijo.

Sin embargo, ¿qué pasaría si necesitáramos agregar información de nóminas a nuestra aplicación? Si recurriéramos a la herencia, deberíamos implementar un método “salary” o similar, para cada una de las clases, sin embargo, como estamos usando “case classes” podemos crear un único método que las compruebe todas, y se comporte de manera consistente:


object Payroll {
def printSalary(employee: Employee) {
val currentYeay = 2001
employee match {
case Intern(stay) =>
println(stay * 300)
case Dev(startYear) =>
println(1000 + (currentYeay – startYear) * 500)
case Manager(startYear, direct) =>
println(1000 + (currentYeay – startYear) * 500 + direct.length * 20)
}
}
}

view raw

payroll.scala

hosted with ❤ by GitHub

En este caso, el método nos devolverá distintos resultados en función de la clase que estemos aplicando y los datos que contenga la misma, permitiendo una separación entre las clases que contienen los datos de los métodos para manipularlos.

Este enfoque tiene sus inconvenientes, y es que si tenemos que agregar un nuevo tipo de dato (por ejemplo, External) tendremos que cambiar todos los métodos auxiliares para soportar el nuevo caso, así que se reduce a elegir en función de las necesidades de nuestro proyecto.

Conclusiones

Construcciones como Case Classes o Traits nos permiten establecer restricciones de una manera sencilla, las traits nos permiten mezclar conceptos de interfaces y clases, y las case classes nos permiten separar los datos de nuestra clase de las transformaciones que hacemos con los mismos.

En C# tenemos a nuestra disposición los métodos de extensión, con los que podemos lograr un comportamiento similar que con las case classes, y que hemos visto con anterioridad en este artículo «Clases abstractas VS interfaces + métodos de extensión«.

En el próximo artículo de la serie veremos más construcciones y, como siempre, más ejemplos.

Para más información:

Scala desde la perspectiva de C# y JavaScript, segunda parte

En la primera parte de esta serie vimos una primera introducción a Scala como lenguaje de programación definiendo algunas características de su sintaxis. En esta segunda parte pasaremos a la práctica utilizando una Code Kata.

En las artes marciales, se denomina kata a una representación, individual o colectiva, de un conjunto de movimientos. En disciplinas como el Karate se suelen enseñar en exhibiciones. El objetivo de las mismas es repetir los movimientos una y otra vez hasta que los mismos surjan de manera natural.

En programación, denominamos code kata a una definición de un problema relativamente simple, que resolvemos una y otra vez cuando estamos aprendiendo un lenguaje o una técnica como TDD. En este caso elegiremos una kata llamada Karate Chop, que define lo siguiente:

Dada una lista ordenada y un número, devolver la posición del mismo en la lista o -1 si no se encuentra, utilizando búsqueda binaria para ello.

El objetivo en este caso era ver si podía aprender lo mínimo necesario para poder escribir una solución a esta Kata utilizando Scala y utilizando la sintaxis de programación estructurada o orientada a objetos a la que estoy acostumbrado. Tras varias iteraciones agregando tests y condiciones, llegué al siguiente resultado:


def chop (target: Int, searchBox: Array[Int]) : Int = {
val size = searchBox.size
if (size == 0) {
return -1
}
if (size == 1){
if(searchBox(0) == target){
return 0
} else {
return -1
}
}
val pointer = searchBox.size / 2
val searchResult = searchBox(pointer)
if(searchResult == target){
return pointer
}
if (searchResult < target){
val partialResult = chop(target, searchBox.slice(pointer, size))
if(partialResult == -1)
return -1
return pointer + partialResult
}
if (searchResult > target){
return chop(target, searchBox.slice(0, pointer));
}
return -1
}

view raw

chop.scala

hosted with ❤ by GitHub

Para hacer las pruebas se suele usar un framework como ScalaTest, o recurrir a JUnit o TestNG de Java, que, como hemos mencionado anteriormente, son compatibles. En mi caso me limité a crear una pequeña función auxiliar que simplemente comparaba el resultado de la función y escribía por pantalla si había discrepancias:


def assert(expected: Int, actual: Int){
if(expected == actual){
println("OK");
}
else {
println("Error, expected: " + expected + " actual: "+ actual);
}
}

Finalmente, para comprobar que el código «funciona» he usado el siguiente conjunto de casos de prueba:


def main(args: Array[String]){
test(-1, 2, Array.emptyIntArray)
test(0, 1, Array(1,2,3,4,5))
test(2, 3, Array(1,2,3,4,5))
test(2, 3, Array(1,2,3))
test(0, 1, Array(1))
test(4, 5, Array(1,2,3,4,5))
test(3, 4, Array(1,2,3,4,5))
test(1, 2, Array(1,2,3,4,5))
test(-1, 0, Array(1,2,3,4,5))
test(-1, 7, Array(1,2,3,4,5))
}
def test(expected: Int, target: Int, searchBox: Array[Int]): Unit ={
assert(expected, chop(target, searchBox))
}

Escribiendo esta función aprendí varias cosas sobre Scala:

  • No necesitamos escribir el tipo de dato, ya que tenemos las palabras reservadas var para variables y val para objetos inmutables. Scala infiere el tipo de dato en tiempo de compilación por nosotros de la misma manera que lo hace C#, de manera que tenemos un sistema de tipos sólido y más sencillo de escribir.

  • Como curiosidades de sintaxis, el tipo de respuesta de una función lo definimos al final de la misma, en la definición de los parámetros también se declara primero el nombre y después el tipo, y el acceso a arrays se realiza mediante paréntesis en vez de corchetes.

#Conclusiones

Lo más importante que podemos ver en este ejemplo, es que no necesitamos cambiar nuestra manera de programar para comenzar a usar Scala, y que podemos ir agregando características funcionales de lenguaje a nuestro código poco a poco.

En el siguiente artículo de la serie volveremos a la teoría, retomando por donde lo habíamos dejado, viendo características como las Case Classes, el reconocimiento de patrones, y otros ejemplos de código, más funcionales que podemos encontrar en GitHub.

Mientras tanto, aquí están algunos enlaces sobre coding katas que he usado para hacer este artículo:

Scala desde la perspectiva de C# y JavaScript, primera parte

Hace unos días me estuvieron hablando de las ventajas y maravillas de Scala, un lenguaje multiparadigma con un fuerte enfoque funcional que funciona sobre la máquina virtual de Java, es 100% compatible con el mismo en ambas direcciones, y también por ello es multiplataforma.

Tras echarle un vistazo a algo de documentación me pareció suficientemente interesante como para intentar escribir algo de código, y algunos artículos, usando la perspectiva de otros lenguajes como C# o JavaScript.

Historia

Scala es un lenguaje que llegó a nosotros desde el mundo académico por parte de Martin Odersky en el año 2003. Odersky, quien había trabajado anteriormente en javac, creó el lenguaje combinando ideas de diferentes lenguajes funcionales.

Como curiosidad, destacar que en sus primeras versiones estuvo disponible tanto para la plataforma Java como para .NET, aunque el soporte para el último fue perdiendo popularidad con los años y desde 2012 no está soportado oficialmente.

No es ni mucho menos el único lenguaje funcional que nos encontramos para la JVM, ya que existen alternativas como Haskell o Clojure, pero sin duda Scala es uno de los más potentes y veteranos, usado actualmente por empresas como LinkedIn, Twitter o FourSquare.

¿Qué tiene de especial?

Sintaxis simple

Basta con echar un vistazo a un «Hola mundo» para ver que la sintaxis es algo más simple que en java:

object HelloWorld {
	def main(args: Array[String]){
		println("Hello world")
	}
}

Si guardamos este código en un fichero HelloWorld.scala, podemos compilarlo usando scalac HelloWorld.scala y ejecutarlo ejecutar utilizando el comando scala -classpath . HelloWorld, con lo cual solamente necesitamos un bloc de notas (o Sublime Text/Atom/Vim/Emacs) y una línea de comandos para empezar a jugar.

Una de las cosas que primero nos llama la atención es la palabra reservada object. Al usar esta palabra reservada definimos la clase como Singleton y el compilador nos genera una instancia con el nombre de la clase, de tal manera que podríamos llamar al método HelloWorld.main desde cualquier punto de nuestra aplicación. Usando la palabra reservada class podemos utilizar las clases a las que estamos acostumbrados en otros lenguajes como C# y Java.

Todo es un objeto

A diferencia de Java, Scala no tiene el concepto de tipos básicos, como pudieran ser enteros, floats, o booleanos, sino que todos ellos son objetos, de la misma manera que lo podemos encontrar en C#. Como objetos, se pasan por referencia y no por valor, y simplifican tanto la lectura como la escritura, ya que no tenemos que estar trabajando con conceptos como boxing o unboxing.

Sin embargo, Scala va un paso más allá, y las funciones también pueden ser objetos, con lo cual las podemos pasar por referencia a otras funciones. Si hemos trabajado anteriormente con JavaScript, esto nos sonará mucho a los callbacks de métodos asíncronos, donde podemos pasar una función por parámetro, y si venimos de C# podemos conseguir el mismo efecto utilizando Delegates.

Veamos un ejemplo:

object Timer {
	def oncePerSecond(callback: () => Unit){
		while(true) {callback(); Thread sleep 1000 }
	}

	def callback(){
		println("Ping..."))
	}

	def main(args: Array[String]){
		oncePerSecond(callback)
	}
}

En este ejemplo podemos ver cómo utilizamos un callback que ejecutamos una vez cada segundo. Como curiosidad de sintaxis podemos ver que al llamar al método sleep no usa la sintaxis Thread.sleep(1000) a la que podíamos estar acostumbrados, que también es válida, lo que se denomina sintaxis infija.

Clases y constructores.

Siguiendo con la filosofía de no escribir más código del necesario, podemos definir nuestras clases en Scala directamente con el constructor en la definición de la misma, como muestra el ejemplo:

class Complex(real: Double, imaginary: Double){
	def re() = real
	def im() = imaginary
}

En este caso en la definición de la clase definimos además dos métodos que nos permiten recuperar el resultado de los valores. En caso de que necesitemos más de un constructor, Scala lo soporta mediante el uso de «this», como muestra el siguiente artículo: Alternate constructors in Scala

La opción de definir los parámetros del constructor era algo que originalmente estaba previsto para C# 6, pero que se retiró de la especificación por su complejidad, aunque es posible que la veamos en C# 7 como muestra el hilo en CodePlex

Es importante destacar que Scala, a diferencia de JavaScript, es estáticamente tipado, con lo cual el tipo de dato de respuesta del método re, será de tipo Double, y se calculará en tiempo de compilación. Podríamos además, quitar los paréntesis tanto a los métodos re como im, y obtendríamos propiedades como las de C#

Resumen y siguientes pasos

Scala es un lenguaje multiparadigma, esto es, que podemos seguir programando de manera orientada a objetos, o podemos incorporar alguna de las características de la programación funcional. Utiliza la JVM y es compatible con Java en ambas direcciones.

En la segunda parte de esta serie, veremos características como las Case Classes, el reconocimiento de patrones, y algunos ejemplos de proyectos reales que podemos encontrar en github. Mientras tanto, aquí están algunas fuentes que he usado para hacer los artículos de esta serie, así como algunos vídeos recomendados:

Vídeo y enlaces del hangout sobre programación funcional

El pasado 11 de marzo tuve la oportunidad de moderar hangout sobre algunas de las ventajas que nos aporta la programación funcional con experiencias en F#, Scala y Clojure con estos cracks

El vídeo del evento está disponible aquí:

Además, compartimos algunos enlaces sobre la diferentes herramientas, y he recopilado estos enlaces en la siguiente lista:

Haskell

F#

Scala

Clojure

La lista está disponible además en github , así que puedes contribuir y agregar tus propios enlaces mediante Pull Requests.

Nos vemos en el siguiente!

Hangout: Programación funcional #hablafuncional

Tengo el placer de invitarte a un nuevo hangout el próximo 11 de Marzo a las 20:00 (GMT+1) donde hablaremos de programación funcional tanto con F# como con otros lenguajes como Scala o Clojure, continuando la conversación de la pasada DotNetSpain Conference.

Esta vez, además, contamos con un panel de auténtico lujo, en el que repite (como no podía ser de otra manera) mi buen amigo Juan Quijano (@jc_quijano) como moderador, además de los siguientes invitados:

  • Alex Casquete (@acasquete): Coordinador del Meetup de F# en Barcelona.
  • Alfonso García (@alfonsogcnunez): Coordinador del Meetup de F# en Madrid.
  • Juanma Hernandez (@gulnor): Desarrollador de software con mucho interés en Clojure.
  • Javi Pacheco (@javielinux): Desarrollador Android y Scala en 47 Degrees.
  • Francisco Díaz (@francisco_dr): Desarrollador Android y Scala en 47 Degrees.
  • Juan Pedro Moreno (@juanpedromoreno): Desarrollador Senior Scala en 47 Degrees.
  • Juan M Gomez (@_jmgomez_): Desarrollador F#.

Durante un par de horas intentaremos responder a las siguientes preguntas (y todas las que tengas a través del hashtag #hablafuncional):

  • ¿Qué aporta (en general) la programación funcional?
  • ¿Cómo podríamos dar nuestros primeros pasos para pensar en funcional?
  • ¿Cuan sencillo resulta interoperar con otras plataformas, C# en el caso de F# y Java en el caso de Scala/Clojure?
  • ¿Qué requisitos adicionales tenemos para agregarlo a nuestro proyecto?

Inscríbete aquí: Programación Funcional con F# – Google Hangouts

Desde aquí un agradecimiento a todos por su interés en participar, a todos los que se han interesado vía Twitter, , en especial a Alex Campos por ponernos en contacto con los chicos de 47 Degrees para dar otra perspectiva a la programación funcional.

Los lenguajes de la web, resumen y materiales

El pasado viernes 13 de abril estuve en la UAM hablando de otros lenguajes de programación y marcado que podemos encontrar en la web dentro del marco de las Jornadas de desarrollo web 2012.

La web no deja de ser una inmensa torre de babel, con muchos lenguajes y mucha gente que programan desde CGIs hasta aplicaciones en Rails, y es bastante útil conocer qué tecnologías y qué lenguajes mueven la web hoy.

Dejando de un lado los pesos pesados como PHP, Java EE o .NET, que (bajo mi opinión) debería de ser obligatorio su conocimiento a gran escala en la carrera de informática, en la charla me centré en algunos menos conocidos pero a su vez muy usados: Ruby, Python, Javascript y Scala:

Javascript, el lenguaje que nos permite hacer páginas bonitas, y que no tiene nada que ver con Java, tiene además una versión de lado de servidor llamada node que permite hacer acciones como servir una web evitando el coste de generar un nuevo proceso. Soporta de una mejor manera la concurrencia y podemos usarlo para procesos con un alto grado de interacción (como un sistema de chat).

Python, la navaja suiza, un poco más a alto nivel que la BASH de unix y más a bajo nivel que un lenguaje de programación tradicional, permite hacernos nuestras utilidades para el procesamiento de información. Es un lenguaje de programación multiparadigma, que permite usar programación estructurada, funcional u orientada a objetos, dependiendo del tipo de proyecto. Permite, además, el uso de varias bibliotecas matemáticas, así que para aplicaciones científicas en base web, es nuestra herramienta.

Ruby, un lenguaje mágico, con un elevado nivel abstracción, se ha ganado un puesto entre los grandes por la facilidad de su aprendizaje, por su sistema de gestión de paquetes llamados gemas, y por frameworks como Sinatra o Rails, que permiten el desarrollo rápido de aplicaciones (o RAD).

Scala, feo, funcional, e increiblemente potente, tiene una curva de aprendizaje considerablemente mayor que los otros lenguajes vistos, pero sin embargo, la compensa con la posibilidad de interactuar con clases de Java (ya que se ejecuta sobre la JVM) y con un rendimiento muy bueno para análisis de datos (por ello lo usan en Twitter para manejar el tráfico constante de información que tienen).

Como aparte, vimos un par de lenguajes de marcado, Haml, que permite sustituir el html por una manera más simple de definir las marcas, y Razor, que hace todo lo contrario, aprovechar el HTML que tenemos (estático) e introducir la información dinámica de manera poco invasiva.

Cerramos la charla hablando de JSON, por qué es popular, y cómo se diferencia de XML en la transmisión de datos, como se puede ver en los siguientes ejemplos usando la API de Twitter:

Aquí dejo la presentación original: