Archivo del Autor: Roberto Luis Bisbé

Acerca de Roberto Luis Bisbé

Software Developer, Computer Engineer

OT: Corriendo voy… un año después

El año pasado por estas fechas comentaba mi primera experiencia en una carrera popular, y toda la tecnología que había visto en su momento.

He de reconocer que fue agónico, tuve que parar varias veces y el resultado implicó una semana de agujetas, aunque fue suficiente para que me picara la curiosidad, empezara a correr de manera más regular y a participar en alguna que otra carrera más:

  • Rexona Street Run (5K) en la que descubrí lo divertido que es participar en una carrera resfriado, altamente recomendable. Me paré un par de veces pero logré terminarla corriendo.

  • Rock n’Roll (10K), que llegué justo y no pude dejar la mochila en el guardarropa, con lo cual me tocó correr con la bolsa, una faena, pero logré terminarla sin parar.

  • Carrera Popular Alcobendas (10K) ya en primavera, pude comprobar que el calor no perdona, y los desniveles de Alcobendas son algo intimidantes. Me tocó pararme varias veces y casi no lo consigo.

  • Proniño (10K) la última carrera que corrí en verano, todo fue perfecto, un tiempo maravilloso, un terreno plano prácticamente sin cambios de nivel, logré terminarla sin parar logrando mi mejor tiempo en 10K hasta ahora.

  • Ponle Freno (5K) he repetido este año aunque en la modalidad 5K, con la suerte de que todo ha salido bien, desde el transporte hasta el guardarropa, y he conseguido mi mejor tiempo.

Con cada carrera, he ido aprendiendo muchísimo sobre ritmos, tiempos, estiramientos, qué llevar, qué no llevar, etc, y de momento mi stack tecnológico de runner consiste en lo siguiente:

  • Fitbit Charge HR: Además de contar pasos, Detecta cuando empiezo (y termino) una actividad como correr, registrando distancia y ritmo cardiaco, lo que me permite analizar mejor los resultados tras la carrera.

  • Pebble Time: Además de poder personalizar la hora y poder leer los mensajes de Whatsapp mientras corres, permite la conexión con Endomondo, resultando muy útil para tener datos como el ritmo actual directamente en la muñeca.

  • Auriculares Bluetooth MPow Cheetah: En su momento me costaron poco más de 20€, y son extremadamente buenos para el precio que tienen, se oyen bien, resultan cómodos, aíslan del ruido y evitan los molestos cables, sin sacrificar batería. disponible en Amazon

  • iPhone 6: Hace un año tenía un iPhone 5 que luego descubrí que formaba parte de la partida con problemas de batería, tras una temporada en el mundo Android he vuelto a iOS, y la batería del 6 me permite correr sin tener que depender de baterías extra.

  • Endomondo: Mi app de referencia para todo lo relacionado con deporte, me ayuda a correr, mide las distancias y me va indicando ritmo y kilómetros por los auriculares mientras corro.

  • Spotify He de reconocer que envidio a aquellos que son capaces de correr sin música, pero yo aún no he llegado a ese nivel, ni sé si seré capaz, de momento spotify (y su opción running) me ayudan a concentrarme, aunque para la carrera opté por una lista de reproducción, ya que spotify running requiere internet y no quería depender del estado de la red mientras corría.

Dar con el equipamiento definitivo es una cuestión de prueba y error, aunque de momento creo que el que tengo me vale, lo siguiente es encontrar unas buenas zapatillas, y creo que para eso le preguntaré a los chicos de runnics.

Nos vemos en la línea de meta!

Anuncios

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.

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

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:

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:

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:

Importando el calendario de nuestro evento favorito

El próximo 27 y 28 de noviembre estaré un año más en el Codemotion, un evento que se celebra en Madrid reúne comunidades de todo tipo y del que hemos hablado en otros artículos de años anteriores.

En ellas desarrolladores de .NET, Java y la JVM, Ruby, Python, JavaScript, Objective-C, Swift, PHP y otros, se reunen para enseñarnos lo mejor de todos los mundos. Yo ya tengo mi entrada, si no tienes la tuya ya estás tardando

Sin embargo hay algo que sigo sin entender. Al igual que en otros eventos, tenemos disponible la agenda completa en la web, y probablemente el primer día nos entregarán una copia EN PAPEL que acabará en una papelera varios días después del evento, si no lo perdemos antes.

No sería mucho más conveniente poder tener el calendario oficial del evento en un formato que lo pudiera entender nuestro Google Calendar, Outlook, iCal o cliente que utilicemos, y poder usar nuestro móvil para orientarnos por el evento? Pues bien, eso es lo que he hecho, y es lo que veremos en este artículo:

Primer paso, obtener los datos

Para obtener los datos originales tenemos muchas maneras. Una de ellas es utilizar un servicio como Kimono que nos permite crear una API REST a partir de una página ya existente, lo cual nos puede resultar muy útil para extraer información.

Otra opción consiste en investigar un cómo, y qué datos carga la página. En el caso de Codemotion, la agenda se carga de manera asíncrona, así que tras investigar el panel de red de Chrome podemos ver un fichero en formato JSON que contiene, para nuestro disfrute, la agenda completa a nuestra disposición, así que, misión cumplida.

Segundo paso, comprender el formato de salida

Para poder generar un fichero que sea compatible con los diferentes clientes de email, una de las opciones es utilizar el formato icalendar, que define un evento de la siguiente manera:

BEGIN:VEVENT
SUMMARY:Document like a hero using Asciidoctor
DTSTART:20151127T160000Z
DTEND:20151127T164500Z
DESCRIPTION:In 2013, the Spring team decided to migrate the Starting Guides on spring.io ...
END:VEVENT

Analicemos los diferentes componentes, dejando de lado las cabeceras begin y end del evento:

  • Summary: Título que se mostrará en la cita del calendario
  • Dtstart: Fecha y hora de inicio de la cita en la zona horaria UTC, en el siguiente formato: Año Mes Día (T) Hora Minutos Segundos (Z)
  • Dtend: Fecha y hora de fin de la cita, en el mismo formato anteriormente comentado
  • Description: Detalles del evento

Si hemos utilizado el calendario de manera corporativa echaremos de menos temas como invitados, alarmas, etc, aunque todos ellos forman parte del estándar y podemos utilizarlos sin problemas. Para reunir varios eventos en un fichero iCalendar hemos de establecer unas cabeceras y un pie de página de la siguiente manera:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
...
END:VCALENDAR

En este código, definimos nuestro fichero iCalendar, la versión del mismo, y el identificador del generador (que en este caso lo he tomado directamente del ejemplo de la wikipedia). Cerramos el fichero con el marcador End.

Con esta información, ya podemos generar nuestro calendario.

Tercer paso, generar el calendario

Para este ejemplo, como utilizaba un fichero en formato json, me pareció mucho más sencillo utilizar JavaScript y Node.js para generar el fichero ics.

Una de las cosas que nos aporta JavaScript, es que, al ser dinámicamente tipado, podemos abstraer la consola en un objeto creado por nosotros, y asignarlo o no a la consola en función de nuestra necesidad.

Como detalle a tener en cuenta está el uso de saltos de línea, ya que hemos de utilizar \n, de otra manera, se generará una nueva línea en el fichero de texto resultante y tendremos un error al importarlo.

Además, aunque parezca obvio, podemos tener más de un evento en un mismo fichero ics.

Cuarto paso, probarlo

Por último, y no por ello menos importante, es necesario confirmar que nuestro calendario se ha generado correctamente, para lo que podemos utilizar servicios como iCalendar validator. Finalmente recomiendo utilizar alguna aplicación de escritorio (como iCal en Mac) para hacer un par de importaciones y comprobar que todos los eventos se generan correctamente.

Conclusiones

Podemos generar un calendario utilizando el formato ics y teniendo una fuente de origen de datos. Si nuestra fuente está en formato json, podemos utilizar JavaScript de manera sencilla para movernos por el mismo, y generar nuestro fichero de resultado, que, por cierto, tienes disponible públicamente en Github.

Yo ya tengo mi calendario, y tú?

Enlaces adicionales:

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:

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:

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

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: