Me ha tocado recientemente refactorizar componentes de una aplicación que tiene parte en C# y parte en Javascript, y como era de esperar, el sistema de tipos estático de C# ha supuesto una ayuda, lo que me ha llevado a preguntarme hasta dónde podría ayudarme un sistema de tipos más potente (como el de Haskell, por ejemplo).

Al hilo de esto, creo que merece la pena dar a conocer lo que puede hacer por ti un sistema de tipos más allá de la clásica guerra entre tipado estático y dinámico. Hoy en día muchos desarrolladores acostumbrados a lenguajes como C# o Java tienen que tratar con Javascript, y percibir las diferencias entre el tipado estático y dinámico resulta fácil, pero también es cierto que muchos de ellos desconocen lo que se puede hacer con sistemas de tipos más potentes, por lo que creo que es una buena excusa para dedicarle un post a este tema.

OJO: No soy un experto en sistemas de tipos (para eso tengo a mis expertos de cabecera), por lo que la exposición que voy a hacer en este post en un poco de andar por casa. Con suerte, te servirá para interesarte por las posibilidades que ofrecen otros lenguajes.

Aclarando un par de conceptos

Antes de empezar, vamos a aclarar un par de puntos:

• Tipado estático frente a tipado dinámico: este es un concepto relativamente fácil de entender. En un lenguaje con tipado estático, el tipo de una variable o función queda definido en el momento de declararla y no puede ser modificado, mientras que en un lenguaje dinámico, este tipo puede cambiar durante la ejecución del programa. Los lenguajes con tipado estático permiten realizar comprobaciones de tipos en tiempo de compilación, lo que ayuda a detectar errores antes, mientras que los lenguajes de tipado dinámico ofrecen (en teoría) más flexibilidad en estados intermedios del desarrollo porque nos permite generar programas parcialmente erróneos (o indefinidos) pero ejecutables (Javier Neira dixit).
• Tipado fuerte frente a tipado débil: en un lenguaje con tipado fuerte, en general, no es posible realizar conversiones entre tipos, o al menos no es tan sencillo convertir de unos tipos a otros a menos que se hayan definido las conversiones explícitamente. En los lenguajes con tipado débil se realizan conversiones de unos tipos a otros de forma más automática, lo que permite escribir código más terso a costa de arriesgarnos a cometer errores motivamos por conversiones inesperadas.

Es importante tener en cuenta que ambos ejes son ortogonales. Podemos tener lenguajes estáticos con tipado fuerte, como C# y lenguajes estáticos con tipados más débiles, como C, donde podemos convertir casi cualquier cosa en un booleano o cambiar de un tipo a otro mediante casts a void*. En el otro extremo, tenemos lenguajes dinámicos de tipado débil, como Javascript, en donde casi cualquier tipo se puede convertir a otra cosa, dando lugar a situaciones curiosas (podéis empezar a jugar con el operador +, strings y números y verlo vosotros mismos), pero también tenemos lenguajes dinámicos con tipado fuerte, como clojure, donde no hay conversiones implícitas entre distintos tipos de datos (aunque, al ser un lenguaje dinámico, los errores los obtendremos en tiempo de ejecución).

Ahora que tenemos clara esta parte, vamos a ver algunas de las características que podemos encontrar en otros sistemas de tipos pero que no están disponibles en lenguajes como C# o Java.

No más null

Empezamos por lo más básico, el error del billón de dólares. Parece razonable que alguien se haya preocupado de evitar este error desterrando (o al menos controlando) el temible null. En lenguajes como Haskell no existe el concepto de null, o al menos no existe como un valor válido para todos los tipos, cosa que sí ocurre en C# (excepto para structs) y en Java (excepto para tipos primitivos).

Es cierto que tanto Java como C# cuenta con facilidades para tratar con null, desde el uso del tipo Maybe /Optional, hasta operadores como ?. en C# que ayudan a lidiar con null, pero no es lo mismo y tienen sus propios problemas.

Existen lenguajes, como por ejemplo Kotlin o Swift, en los cuales puedes declarar una referencia como no nullable, y el compilador se encarga de garantizar que nunca, jamás, contendrá un valor null.

Por ejemplo, en Kotlin tendríamos:

// Por defecto, las variables no puede valer null
val name : String = "Lucas"
name = null // esto genera un error de compilación

// Los tipos nullables, obviamente, permiten null
val maybeName : String? = null

//... pero esto genera un error de compilación porque
// el valor podría ser null
maybeName.length()

// ...necesitamos asegurarnos de que el valor no es null
// antes de invocar el método para que el programa compile 
val length = if (maybeName != null) maybeName.length() else -1

// ... o propagar el posible null: maybeLength tiene tipo Int?
var maybeLength = maybeName?.length() 

Tipos algebraicos

Los tipos algebraicos nos permiten definir tipos suma y tipos producto.

Un tipo suma consiste en una enumeración de distintos valores posibles para un tipo. A simple vista, podría parecer que es equivalente a un tipo enumerado, pero resulta más potente porque los valores enumerados puede contener “parámetros” (en realidad, cada caso de la enumeración es un constructor).

Por ejemplo, en Haskell podemos definir la información de contacto de una persona como:

data ContactInfo = None
                 | Phone String
                 | Email String

De esta forma, indicaríamos que la información de contacto puede no ser ninguna (None), un número de teléfono con el número concreto (Phone String) o un email con la dirección concreta (Email String).

En general, esto suele ir asociado con pattern matching que nos permite trabajar cómodamente con los tipos suma y extraer la información almacenada en ellos:

send :: ContactInfo -> String -> IO()
send None msg = putStr "No hay forma de contactar"
send (Phone number) msg = sendSms  number msg
send (Email address) msg = sendEmail address msg

Los tipos producto nos permiten construir un producto cartesiano entre los valores de dos tipos distintos. El caso más frecuente son las tuplas, que están formadas por una serie ordenada de valores de tipos concretos y que, nuevamente, encajan muy bien con la filosofía del pattern matching.

En lenguajes como Java o C# es fácil simular tanto tipos suma como tipos producto, pero la forma de tratarlo resulta mucho menos cómoda que en lenguajes que están preparados para ellos y suelen requerir bastante más código, tanto para definirlo como para tratarlos posteriormente. Un ejemplo de esto son los tipos enumerados de Java que podemos también simular en C#.

Tipado estructural

Todos los que hemos trabajado con lenguajes como Javascript conocemos el Duck Typing. Es una idea sencilla, si tenemos un objeto sobre el que podemos realizar ciertas operaciones, nos da igual el tipo real que tenga, sólo nos importa que podemos realizar esas operaciones: si camina como un pato y grazna como un pato, es un pato.

En los lenguajes como C# o Java, para conseguir algo parecido necesitamos recurrir a interfaces, y eso nos obliga a definir a priori de qué formas podemos ver el tipo que estamos definiendo. Si tengo un tipo que implementa un método void Serialize(XmlWriter writer), pero no implementa el interface ISerializer, no podremos usarlo como tal, aunque tengamos un método perfectamente válido para ello.

El tipado estructural consisten en poder aplicar la misma lógica, pero en tiempo de compilación. Existen otros lenguajes, como Go y Scala que son capaces de hacer esto, por lo que no es tan necesario definir a priori los “interfaces” que implementa un tipo. Mientras tenga métodos compatibles con lo que necesitamos, servirá, y en caso de que no los tenga, el compilador nos avisará.

Por ejemplo, en scala podemos tener la siguiente función para calcular el área de prismas regulares:

def getVolume(prism: { def getBaseArea(): Int; def getHeight(): Int }) : Int = {
  prism.getBaseArea() * prism.getHeight()
}

class Cube(val s: Int) {
  val size = s
  def getBaseArea() : Int = size * size
  def getHeight() : Int = size
}

val c = new Cube(5)
val v = getVolume(c)
println("volume is %d".format(c))

Al definir la función, indicamos que el parámetro prism debe tener métodos para obtener el área de la base y la altura, pero no obligamos a que implemente ningún interfaz o herede una clase concreta. Cualquier objeto que exponga esos dos métodos, por ejemplo una instancia de la clase Cube podrá ser utilizado como argumento al invocar la función.

Type Classes y Protocolos

El concepto de Type Classes de lenguajes como Haskell y, en menor medida, los procolos de lenguajes como Clojure, permiten una forma de polimorfismo muy potente y flexible.

Tenéis una buena explicación en el post sobre protocolos en Clojure, pero para simplificar, la idea es que puedes definir un interface y su implementación para tipos ya existentes, sin necesidad de modificar la declaración de los tipos, y a partir de ese momento, siempre que necesites una instancia de ese interface, puedes utilizar una instancia de esos tipos, como si lo hubiesen implementado desde un principio.

Por ejemplo, en Haskell, podemos definir la clase de los tipos cuya área se puede calcular y hacer que tipos definidos previamente “implementen ese interfaz”:

-- Este es un caso claro para usar un tipo suma, pero para el ejemplo
-- vamos a dejarlo como tipos completamente independientes

data Square = Square Float Float
data Circle = Circle Float

class Area a where
    area = a -> Float

instance Area Square where
    area (Square width height) = width * height

instance Area Circle radius where
    area (Circle radius) = pi * radius * radius

En el momento de definir los tipos Square y Circle no hemos indicado para nada que tendrán pertenecerán a la clase de tipos Area, pero podemos hacerlo a posteriori.

Nuevamente se trata de algo que podemos resolver en lenguajes como Java o C# recurriendo a patrones de diseño clásicos como adapter, pero resulta más incómodo y menos flexible.

Tipos dependientes

Esto es algo bastante más avanzado que no muchos lenguajes implementan. El más popular posiblemente sea Idris, y seguramente muchos no hayáis oído hablar de él en la vida.

Hoy en día muchos de los lenguajes más populares, entre ellos C# y Java, soportan tipos genéricos, que nos permite tener “tipos de orden superior” a partir de los cuales construir otros tipos. Podemos tener un tipo List<T> que luego podemos parametrizar para construir el tipo List<int> o List<string>.

Una limitación de esto es que sólo podemos tener tipos que dependen de otros tipos, pero no que dependan de valores. Los tipos dependientes (y aquí invoco a los expertos, porque hay partes que se me excapan), permiten definir tipos que dependen de valores concretos y no sólo de otros tipos.

Para no complicarlo mucho (podéis ver un ejemplo real en Idris) vamos a ver un poco las implicaciones de esto. Si tenemos un tipo Vector en el que indicamos, en el momento de su construcción, la longitud y el tipo de elementos, por ejemplo Vector 10 Int para indicar un vector de 10 elementos de tipo Int, podríamos declarar una función con una signatura parecida a ésta:

concat :: Vector n a -> Vector m a -> Vector (n + m) a

Es decir, en la propia signatura de la función estamos codificando que, si concatenamos dos vectores de longitudes n y m, ambos con elementos de tipo a, el vector resultante tendrá que tener, necesariamente, longitud n + m y contener elementos de tipo a.

Si lo pensáis un poco, la potencia de un sistema de tipos de estas características es enorme, porque podemos incluir muchos de los invariantes de las operaciones en la propia definición de los tipos de las funciones.

La parte mala es que estos lenguajes de programación llevan asociada una gran complejidad que hace que aprender a manejarse con ellos y sacarles partido no sea una tarea trivial.

Conclusión

Como decía al principio, este post no pretende ser una introducción seria a lo que son los sistemas de tipos, y tampoco se trata de un listado exhaustivo de lo que pueden hacer otros lenguajes, pero creo que puede ayudar a hacerse una idea de lo que se puede conseguir con otros sistemas de tipos.

Todos tienen su parte buena y su parte mala, e igual que hay mucho (pero mucho) software construido con lenguajes dinámicos como Ruby, PHP, Python o Javascript, se puede trabajar perfectamente con sistemas de tipos más simples como el de C# o Java sin necesidad de disponer de todas estas herramientas más potentes.

A veces parece tentador añadir a nuestro lenguaje favorito estas características, igual que se ha hecho con C# añadiendo cosas como dynamic o en scala o kotlin añadiendo casi todo lo que se les ha ocurrido, pero la featuritis en lenguajes de programación es un problema como ya comentamos en su día.

También es importante tener en cuenta que esto más allá de la sintaxis. No se trata simplemente de que en unos lenguajes resulte más o menos cómodo hacer cierto tipo de construcciones (que también es importante), sino de que hay cosas que, directamente, no se pueden hacer en determinados lenguajes sin reimplementar gran parte de otros sistemas de tipos.