Kotlin y Programación Funcional con Alejandro Serrano

Pues bienvenidos a otro programa más de Codeadores. Hoy he invitado a que nos acompañe a Alejandro Serrano, que vi en su perfil que programa y está muy ligado a la comunidad de Kotlin, pero también me ha llegado una grata sorpresa de que colabora bastante estrechamente con LambdaWorld y la comunidad de la programación funcional. Así que voy a dejar que te presentes, Alejandro, pero también engancho con la primera pregunta. Porque siempre me gusta preguntar que cómo fue el momento en el que tú decidiste que la programación era para ti. O sea, ese primer contacto con la informática que te hizo pensar de quiero dedicarme a la programación.

Primero, encantado de estar aquí. Pues nada, si te cuento un poco mi historia, vamos, yo empecé, supongo que mucha gente, yo Allá por el año, poco antes de los 2000 o algo así, mis padres decidieron que era un buen momento para traer un ordenador a casa porque parecía que eso de los ordenadores iba a ser importante en el futuro. Así que trajeron el típico ordenador, un 486, que recuerdo. Y nada, yo al principio lo usaba sobre todo para lo típico, para jugar y verla en carta. Las maravillas. Y nada, no sé, de repente llegué, llegué en contacto con HTML, que era como, o sea, para mí fue como el paso mágico de decir, pues hablo, abro el bloc de notas, escribo aquí una cosa y de repente aparece, aparece en el navegador, ¿no? Y es como algo con lo que puedes jugar muy, muy fácilmente, porque si sabes, en ese momento recuerdo, pues eso, pues hacer una cosa y que sea grande y que parpadee o algo de eso, era como que de repente un poder que no creías que tenías, ¿no? Era como que la gente que hace los ordenadores son gente muy, muy, muy, muy, muy lista, que tiene ahí su, no sé, tiene que ir poco menos que eligiendo los bits que pone. Y de repente no, no es eso. Tú abres algo, lo pones, de repente empieza a funcionar algo. Y a partir de ahí empecé como a mirar cosas. Y yo creo que también un poco por suerte, en la librería de mi barrio había una sección de informática con estos libros que había por aquel entonces. No sé si sigue habiendo estos, que son como que eran todo grises. Y entonces decidí coger uno de Visual Basic 6. Porque me llamaba y de algún modo tenía acceso a ello. La verdad es que no sé muy bien por qué llegué a tener acceso a eso, pero nada, y empecé a— y eso era también otro entorno de estos muy visual en los cuales tú ponías el botón y hacías doble clic, entonces te aparecía directamente en el IDE una cosa para escribir el botón. Y a partir de ahí pues como que empecé a engancharme a la idea y un poco a aprender por mi cuenta usando pues esos libros que encontraba, los de la biblioteca y tal. Hasta que bueno, ya digamos, pues no sé en qué momento tuve internet en casa y ya pues eso es como fue ya como el acceso a toda la información de aprender a hacer cosas. Y no sé, a partir de ahí un poco empecé a empecé a ver que me gustaba lo de la programación. Y no sé, como es algo a lo que te puedes dedicar, pues también ya pues llegó el típico momento de cuando acabas instituto de decidir qué haces. Y decidí estudiar informática. Y a partir de ahí es un poco que ya me metí más a aprender todas esas cosas. Pero como que me ha gustado desde, pues eso, no sé cuántos años tendría que empecé, pero en la adolescencia. A partir de ahí, pues en la universidad tuve la suerte de encontrar unos cuantos amigos que también como que les gustaba todo el tema de la programación en sí, o sea, todo el tema de los lenguajes de programación y tal. De hecho, llegamos a montar ahí en la universidad una serie de charlas que dábamos nosotros mismos porque nunca conseguíamos convencer a nadie que viniese, pero como para explorar diversos lenguajes porque nos parecía que que no sé, en la carrera enseñaban Pascal al principio, enseñaban C, nos enseñaban Java de forma opcional, pero que había muchísimo más que ahí. O sea, siempre, no sé, en ese momento que exploras, de repente, cuando todo lo que conoces es C, que de repente aparezca algo como Lisp o como Erlang, que era como las cosas que veíamos, es completamente diferente porque es como una cosa tan completamente distinta Y no sé, como nos parecía que eso faltaba, así que nos intentábamos nosotros mismos buscar cosas, buscar profesores que a lo mejor supiesen y no daban, no había ninguna asignatura, pero nos pudiesen contar cosas. Y sobre todo me fui metiendo y me gustó sobre todo todo el tema de la programación funcional. Empecé a ver cosas de Lisp, muchas cosas de Haskell y tal. Y nada, en cierto momento, en cuarto, decidí que quería aprender más programación funcional de la que me daban, porque realmente no sabíamos mucho. Y lo que hice fue irme de Erasmus a la Universidad de Utrecht, que es donde vivo ahora, de hecho, porque allí tienen un un currículo en el cual daban programación funcional desde, desde el principio y tenían cursos más avanzados y tal. Y dije, me voy a meter ahí. Y básicamente fui de Erasmus a hacer todos los cursos de programación funcional que daban. Aprendí un montón de Haskell y tal. Y ahí fue como que ya me metí, tuve todo el tiempo del mundo para, para un poco aprender todo eso. Y a partir de ahí, pues es un poco lo que, lo que siempre me ha gustado hacer. Pues volví a Madrid, que es de donde soy, a terminar la carrera. Pero después de un tiempo decidí que me gustaba, me gustaba el tema, y lo que hice fue ir a Utrecht, venirme a Utrecht a hacer un doctorado. Estuve ahí, estuve, porque me comprendí además yendo ahí que ya no es que solo me guste la programación, es que me gustaba todo el tema de compiladores, sistemas de tipos, todo ese tipo de cosas que hay detrás de cómo es el lenguaje de programación. Es algo que me llamaba, que yo nunca había estado en contacto mucho, pero en Utrecht hay como un grupo grande de investigación sobre el tema y ahí entré en contacto con ese tema. Entonces decidí, bueno, voy a dedicarme a estudiar esto durante unos años y nada, y acabé pues haciendo un doctorado allí y luego trabajando de profesor un par de años. Hasta que ya me fui más del mundo académico y lo que hice fue empezar a trabajar en una consultora, 47 Degrees, que de hecho es una consultora española. Ahora ya no existe porque ha sido absorbida por otra más grande y tal, pero en ese momento estaban haciendo un montón de cosas de Haskell, de escala mucho más funcional. Y de hecho me cogieron para intentar ver si Haskell tenía cabida en lo que estaban haciendo, que sobre todo era escala. Desgraciadamente, Haskell no ha sido nunca el lenguaje más, más usado. Hay un par de empresas que lo usan y tal, y poco a poco lo que fui haciendo fue como meterme más en las cosas que usaban en la empresa. Eran Scala y también estaban en ese momento intentando meter, meter más Kotlin. En ese momento además cuando estaba lo de Scala Scala 2 estaba como bajando porque Scala 3 estaba empezando a— entonces como que no estaba muy claro y también querían pues como ver. Y yo decidí aprender Kotlin. Y de hecho había, nuestra empresa estaba, estaba gente que colaboraba en todo un proyecto que se llama Arrow, que ahora yo estoy como mantenedor, pero en aquel momento lo estaban haciendo ahí, que es como la idea era traer todo el tema de programación funcional a Kotlin porque era un lenguaje como que tenía muchas posibilidades, pero la gente, o sea, como que el mindset no era muy de programación funcional y faltaban ciertas cosas, ciertos tipos de datos estilo Either que no estaban y todavía no están en la librería estándar. Pues como que entonces como que al final acabé trabajando un montón con la gente que hacía Kotlin, con la gente que hacía programación funcional en Kotlin, y Y ahí estuve, estuve aprendiendo y haciendo cosas hasta que curiosamente hace año y medio en JetBrains, que es la empresa que está detrás de hacer Kotlin, abrieron un puesto de estamos buscando a alguien para hacer desarrollo de lenguajes en Kotlin, o sea, para el equipo. Y nada, yo había estudiado Hacía tiempo que había estudiado cosas de desarrollo de lenguajes de programación y sabía un montón de Kotlin por esta experiencia, con lo cual me venía, me venía muy bien. Y es donde estoy trabajando ahora. Ahora estoy básicamente en el equipo, dentro del equipo de Kotlin es muy grande y hay desde básicamente desde el equipo en el que estoy yo, que se llama Evolución del Lenguaje, que básicamente pensamos nuevas features o pensamos cómo a lo mejor hay que cambiar ciertas cosas que están en el lenguaje porque sus objetivos originales no se han cumplido y tenemos que modificar cosas. Pero está hasta mis compañeros que lo que saben es de generar el bytecode Java y todas las, y luego todas las partes intermedias de la gente que va implementando las cosas. Es un equipo bastante grande. Yo estoy como al principio de toda la cadena, los que se encargan de buscar cómo el lenguaje evoluciona y tal.

Y cuando empezaste en el tema de la programación, es decir, no sé si crea debate con lo de si HTML es un lenguaje de programación o no, pero el primer lenguaje con el que tuviste contacto fue BASIC entonces, con Visual Basic. Que no sé si lo tocaste mucho, pero yo recuerdo mi etapa de Visual Basic 6, que era sobre todo la parte visual y muy poquito de código, porque tampoco lo requería mucho. Y ya cuando pasas a otro lenguaje en la universidad, habías dicho Pascal, C, ¿qué fue lo que te dio más fricción a la hora de entrar en estos lenguajes?

De forma intermedia entre una cosa y otra, también aprendí un poco de C#, porque Básicamente yo cuando lo cogí estaba Visual Basic, pero esta era la época que estaban pasando a todo .NET. Entonces aprendí como Visual Basic .NET, pero la gente decía Visual Basic .NET no es el futuro, hay que aprenderse #C#, no sé cómo se diría en español la verdad. Y aprendí un poco de ahí. Y pero nada, o sea, lo que a mí siempre me resultaba cuando aprendí en la universidad es que aprenderse estaba muy bien, teníamos que aprender toda la movida de punteros y tal. Pero al final llegó un punto, después de 3 o 4 cursos, que era como, esto, esto estamos aquí haciendo punteros de punteros de punteros porque no sé qué. Y claramente yo sé que existe esta movida de la programación orientada a objetos que hace las cosas mejor que todo esto. O sea, que no tenemos que estar viendo, que yo no tengo que estar manejando mi memoria. Que quiero decir, que yo sé que existe la recolección de basura. Bueno, eso sabía que se llamaba en ese momento, pero yo sabía que si tú haces BASIC o o tú haces C#, tú no te dedicas a andar ahí cogiendo punteros y tal. Y siempre pensaba cuando aprendía esto que está muy bien para entender cómo funciona, quiero decir, yo quiero entender qué está ocurriendo en todo mi sistema, pero claramente con lo que me están enseñando yo no puedo hacer una aplicación grande porque yo no me imagino, o sea, no lo imaginé. Además sabía que no estaba, yo no me imagino a un equipo de gente que estén, yo qué sé, los ingenieros de Amazon pensando en qué momento tienen que liberar el puntero. Eso no, claramente no podía ser así. Entonces, como que a mí esa parte me da mucha ilusión porque al final el juego muchas veces, al menos en mi caso, de pasar una práctica no era tanto entender, no era tanto implementar, era conseguir que no te petase el programa porque no tenías Porque habías conseguido, ¿no?, coger la memoria, devolver la memoria en el momento correcto. Me da un poco de coraje en el sentido de, bueno, yo estoy aquí para aprender, digamos, pues yo qué sé, lo que, cómo funciona un árbol de estos que se auto, auto balancean y tal, pero al final no estoy aprendiendo esto. Lo que estoy aprendiendo es cómo hacer que se auto balanceen sin petarlo. Paso más tiempo en la otra cosa. Eso es lo que, lo que más, no sé, así a nivel de lenguaje, lo que más, lo que más me llamaba la atención, eso es la diferencia entre lo que creo que nos daban y lo que ya claramente estaba establecido en la industria, que era otro tipo de lenguajes más alto nivel donde lo importante ya es nivel arquitectura, donde ya no estamos hablando de cómo implemento este entero, sino cómo concibo las clases, cómo necesito interfaces, qué patrones hay, todo ese tipo de cosas que al menos en mi caso no eran la parte más importante del currículo. O sea, lo podías, lo podías dar, lo podías aprender, pero era como al final, ya como venga, ya, ya te dejamos que aprendas estas cosas.

Y en el grupo este que montaste en la universidad, cuando surgía hablar del lenguaje, ¿había siempre algún lenguaje que destacase, que fuese el más querido por todo el grupo, o cada uno tenía lo suyo e iban variando?

Sí, yo creo que cada uno tenía el suyo. Yo creo que eso sobre todo eran, eran algunos que tuviesen algo extraño. O sea, yo recuerdo en ese momento que para mí, o sea, lo más, lo más increíble eran los Lisp, porque era como esto de las macros y que yo en el propio, en el propio lenguaje cambio el lenguaje. Para mí eso me parecía O sea, completamente como, no sé, otro nivel de pensamiento ahí avanzado tal. Pues había compañeros que, por ejemplo, lo que le llamaba más la atención era sobre todo todo el tema que he comentado de Erlang, porque era como, bueno, vale, pero resulta que puedo hacer que todo esto sea distribuido fácilmente. O sea, no, no es una cosa compleja, esto de algún modo lo hace. Entonces como que Iban variando, cada uno teníamos nuestras cosas y tal, pero siempre era que tuviesen algo raro. O sea, o Haskell, que era porque bueno, estaba esto de los, de los funtores y los tipos y los tipos de tipos, que era como también otro nivel respecto al C donde tienes el int, int asterisco y poco más. O sea, todo, todo son eso, las estructuras.

Y entonces ya a través de prácticamente a raíz de esto, la programación funcional fue lo que más te fue llamando. Hasta podemos catalogar Kotlin como un lenguaje funcional o casi funcional.

Pues uno de estos lenguajes modernos en los cuales tiene todas las cosas funcionales casi y todas las cosas orientadas a objetos puestas juntas. O sea, ya es como que yo creo que ha llegado el momento en el cual lo de programación tener lenguajes solo funcionales ya no se tiene mucho, o tener lenguajes donde no haya algo funcional ya no se ve. O sea, todos los lenguajes modernos, sea Kotlin, sea Swift, sea tal, al final tienen el 90% de lo que podríamos llamar funcional. Y de hecho, yo creo que de esto Kotlin está como navegando incluso más a todo el tema de la inmutabilidad, que muchas veces es como lo que más O sea, de todas las ideas de programación funcional pura que siempre había, ves los maps y todas estas, todas las funciones de alto orden, las ves en todos los sitios. Yo creo que lo que falta sobre todo es todo el, la cosa de mutabilidad, y Kotlin también está yendo hacia allá, pero vamos, o sea, no es eso. Lenguajes como Scala, lenguajes como Swift, que son más modernos, lo tienen. Incluso Java como que ya está llegando a tener todas esas cosas, porque yo creo que ya como que ya no se concibe un lenguaje de programación donde tú no puedas hacer map en una lista. O sea, es como que ya todo el mundo sabe que eso es la forma correcta de hacer una lista para ir de otra lista, en vez de tener que hacerte tú tus movidas con un bucle y hacerte tu propia lista y todo eso. Todo eso ya creo que ya no se hace, ya está ya hemos pasado como esa barrera.

Entonces, dentro de Kotlin se intenta siempre tener un pequeño sabor funcional como en otros lenguajes como Python. Bueno, incluso creo que a raíz de todo lo que se fue haciendo con Clojure, Scala e incluso Kotlin, se ha ido influenciando la evolución de la Java Virtual Machine.

Sí, sí, vamos a ver, no sé muy exactamente cuál será la historia exactamente, pero claramente que estos lenguajes existiesen han hecho que Java cambie muchas cosas. Y de hecho, ahora se está planteando cosas a raíz de Kotlin que durante mucho tiempo no se planteó, o sea, cosas como que Java tiene ahora pattern matching. Si tú se lo hubieses dicho a alguien hace 10 o 15 años, les parecería impensable. Y ahora mismo es como, necesitamos pattern matching, esta cosa parece, parece interesante.

¿Y cómo se ve la competencia entre Java y Kotlin desde dentro de Kotlin?

Pues es un hecho curioso porque, o sea, Kotlin como que básicamente, al final Kotlin mejora Java. Al principio empezó como un competidor de Java y tiene muchas cosas que son como muy, o sea, como que a nivel superficial cada vez las diferencias son menores, pero luego cuando te metes dentro hay muchas cosas que siguen siendo, o sea, como que Kotlin tiene todavía esa ventaja. Es un ejemplo, por ejemplo, es que en todo el tema de concurrencia Kotlin tiene como cosas en todo el lenguaje para trabajar con concurrencia, que Java están intentándolo hacer pero todavía no ha llegado. Pero Kotlin lo tiene desde hace 5 años o algo así, no sé cuánto. Y entonces es como que para nosotros siempre nos cuesta decir, bueno, estamos mejorando el lenguaje, pero es que ya hay como un largo trecho entre lo que es Kotlin y lo que es Java, todas las cosas que se han ido haciendo en los últimos años Yo quiero pensar que en ciertos casos nuestras decisiones son mejores que las de Java, o al menos no estamos influenciados tanto por el pasado. O sea, el típico ejemplo aquí es que Java va a tener, y siempre va a tener, su cosa esta de que tiene int e Integer con mayúscula la I, porque antiguamente era muy importante que sea el tipo primitivo, no sé qué. Y Kotlin es un lenguaje en el cual el compilador se encarga de eso. El compilador se encarga de que sea lo más óptimo, porque como que las veces tú nunca quieres usar la versión menos óptima, excepto que te lo obligue de algún modo el runtime. Pues el compilador de Kotlin lo sabe hacer, y para ti todo esto es invisible. Entonces ese tipo de cosas siempre van a pesarle a Java porque Tiene mucho, tiene, creo que se cumplen ahora 30 años ya desde que sacaron la versión 1, y Kotlin puede mejorar en eso.

Recuerdo una charla que tuve con Camilo Chacón, que es un árduo defensor de que ya no existen ni lenguajes funcionales ni lenguajes orientados a objetos, sino que son casi como características que se van introduciendo dentro del lenguaje, tal y como has dicho tú al principio, que ya casi como lenguajes funcionales, pues bueno, queda Haskell porque es muy puro, pero incluso puede tener un poco de orientación a objetos ahora u otras características. ¿Crees entonces que, por ejemplo, algo como el LambdaWorld puede estar abierto a todos los lenguajes, no a lenguajes específicos?

Sí, o sea, de hecho, si ves los últimos años, incluso lo que es funcional también se ha ido ampliando. Por ejemplo, en la última edición también había mucha gente que lo que hacía era lenguajes de estos de procesamiento de arrays paralelos. ¿Por qué no? Porque es una cosa en la cual también los lenguajes funcionales han tenido mucho tirón, todo lo que es el procesamiento paralelo de datos en las GPUs y tal, porque como que el modelo funcional es mucho más dado a eso, porque al final es mucho procesamiento, pero todo es como puro. Y a partir de ahí como que se ha ido extendiendo a gente que ha ido combinando todo lo funcional con lo que antes era el procesamiento de arrays, que parecía muy lejano, pero está que están bastante cercanos. O sea que al final va, sí, o sea, va ganando, va ganando. Y de hecho muchas, muchas de las cosas que al final ves es, vale, si tú intentas coger esta idea de otro lenguaje cómo se ve eso en un lenguaje más estándar, por ejemplo. O sea, una vez he dado charlas y creo que a la gente le parece interesante es el decir, vale, Haskell tiene todas estas ideas de functor y monad y no sé qué. Y es cierto que en un lenguaje como Kotlin tú no puedes coger y no son el mismo lenguaje, no puedes definirlo exactamente igual, pero tú puedes coger ideas de cómo hacer las cosas en Haskell y ver en Kotlin o en el lenguaje que sea, es decir, Oye, estos patrones son interesantes en general, no es porque sean de Haskell. Luego habrá otros que no, que son específicos de ese lenguaje. Igual que tú tienes, yo qué sé, en Java tienes el típico patrón de Visitor que en Kotlin no tiene sentido porque en Kotlin lo defines de otra manera. Pero hay cosas más genéricas, sobre todo yo creo todas las que tienen que ver con estos conceptos como más matemáticos o más como de de los más abstractos, como que todos acaban siendo buenos patrones de diseño en cualquier lenguaje. Creo que es interesante ver cómo en cada lenguaje eso se aplica. O la otra idea que comentaba antes, todo el concepto de la inmutabilidad, es un concepto que en un lenguaje como Haskell, que es puro, viene de serie, pero que es completamente aplicable a cualquier lenguaje de programación. O sea, tú decir ¿Cómo hago mi código de manera que la inmutabilidad sea lo que hago por defecto? Lo puedes hacer ahora mismo en, yo creo, en cualquier lenguaje puedes marcar ya las cosas como readonly o final o como sea, y traer todas esas ideas que al final cambian, como, o sea, al final tienes que hacer el código de otra manera, pero da igual que lo hagas en Haskell o en Kotlin, la manera al final es la misma. Es diferente hacerlo mutable, pero si lo haces inmutable es igual en todos los sitios.

Teniendo esto en mente, entonces, es decir, la conferencia de LambdaWorld que se centra en dar a conocer capacidades de programación funcional, ¿sería casi una forma de enseñar el cómo hacer cosas específicas que aún no están disponibles en todos los lenguajes o que lo están pero no son muy populares?

Sí, o sea, es en parte, o sea, en parte uno de los objetivos es ese, es como servir de enlace entre la gente que a lo mejor ha cogido esos conceptos de otro lenguaje y la gente que está programando al final en su día a día, en su trabajo y tal, y ver cómo se puede aplicar. O sea, es parte de lo que se persigue con la conferencia, o sea, Es como decirlo, poner en contacto entre los que han acogido estas, normalmente, porque al final siempre suelen venir otros lenguajes de programación que llevan adelanto. O sea, quiero decir, la gente de la comunidad Haskell sabe de esto y no creo que sean más listos o menos, simplemente llevan, llevan 30 años haciendo solo programación funcional pura, con lo cual han tenido que sacar inventar patrones para ellos poder hacer software. Y cuando nosotros llegamos, intentamos aplicar las mismas restricciones o las mismas características que tiene Haskell, no es de extrañar que cojas y digas, oye, los mismos patrones no siguen valiendo. Pero al final es muchas de las cosas que perseguimos. De hecho, si ves en ediciones anteriores, muchas, muchas de las charlas muchas veces es como yo planteo este mismo problema pero lo planteo desde un modo funcional porque te permite ver cómo es. Según una charla el año pasado, creo que era cómo convertir números a cómo se leen en japonés, que debe ser una movida muy grande. Y eso, el fin de la charla no era tanto, no era tanto el explicarte el problema, que algún programador puede solucionar ese problema seguramente. La cosa es, vale, cómo te lo planteas. Y ahora me lo planteo desde el punto de vista funcional, y eso al final es O sea, en LambdaWorld muchas de las charlas son de ese estilo. Resolvamos el problema, sabemos resolverlo, pero vamos a resolverlo siguiendo estos conceptos, siendo muy estrictos. Ya en el trabajo es el momento en el que no se necesita, pero aquí seamos muy estrictos e intentamos ver cómo desarrollar ese punto de vista más funcional para resolver los problemas.

¿Y tiene en mente, porque siempre hay partes de lenguaje específico, O sea, Haskell es un ejemplo y creo que han mencionado algunas cosas que tienen algunas características que son catalogadas de esto es muy funcional, es muy buena idea, pero no es fácilmente transportable a otro sitio.

Hablando de características, maestro, yo creo que la mayor cosa que todavía no han cogido muchos lenguajes de lenguajes como Haskell es su sistema de tipos hiper. Complejo. O sea, lo que tú puedes hacer en Haskell usando pues clases de tipos estilo functor, que donde el argumento ya no es un tipo sino una otra a su vez, otro constructor de tipos, y hacer cosas de estas, eso no está disponible nada más que yo sepa así más mainstream, si podemos decirlo, sería en Scala, si consideramos Scala mainstream, que ya es como Hay un trecho. Yo creo que es una parte, esa parte está más, más por explorar. No creo que no esté explorada, sino que yo creo que no es realmente, creo que no es tan claro cuál es el beneficio en la mayor parte de los casos para lo que es el desarrollo de software en general. Es interesante Tiene ventajas, pero nosotros, o sea, por ejemplo, cuando hemos hecho lo de arrow para Kotlin, lo que hemos hecho es decir, bueno, pues cada tipo tiene un map, pero nosotros usamos functor como un patrón de diseño más que como esa implementación. O sea, que podamos definir eso en tipos es la parte que todavía falta. Y yo además, personalmente, yo creo que tampoco es algo muy necesario. Otras cosas más interesantes que vienen de otros lenguajes que son No sé, a mí me resultan más útiles. Mi caballo de batalla siempre es el, yo qué sé, que lenguajes de programación sean capaces de algún modo recordar cuál es la longitud de las listas, y entonces tú no puedas tener lo típico de referenciar un índice que está, que está fuera del este. Hay lenguajes que pueden hacerlo, hay muchas cosas en la academia Si te interesa el tema Haskell, por ejemplo, está Liquid Haskell, que es como un añadido a Haskell que hace ese tipo de cosas. A mí me parece que esos son cosas mucho más interesantes a explorar en ese aspecto que todo el tema de estas features tan grandes. Y yo creo que incluso va a llegar antes que estos sistemas de tipos. No recuerdo cuál era la pregunta original.

La dificultad de introducir ciertas características funcionales dentro de otros lenguajes que no son tan funcional.

Sí, o sea, al final yo creo que lo otro que ha costado mucho pero que ya se ha aceptado es todo el tema de la inmutabilidad. Porque digamos que las funciones que toman funciones muy rápido, o sea, cuando se pasó, yo creo que eso ya estaba muy, nos sentimos a lo mejor 20 años, estaba muy cerca de estar. O sea, tú puedes ver que Java no lo tenía, Pero luego llegó C# y C# tenía los delegates, que no son eso, pero son casi eso. Y entonces como que poco a poco la gente lo veía, porque además es algo como claro, o sea, el tú querer hacer una misma acción varias veces o querer guardarla es como algo muy natural. Si te pones, se ponen las gafas de puedo guardar cualquier cosa, ¿por qué no guardar una acción? Lo de la inmutabilidad, yo creo que eso sí que ha tardado mucho más, sobre todo hasta todo el tema que hay ahora de frameworks visuales, porque toda la parte de interfaces gráficas siempre ha sido como muy, muy, muy, muy mutable. No tenías el botón y al botón le cambiabas el color hasta que ha llegado todo el Compose, el SwiftUI y el React, que dicen, hombre, si esto puede ser una función que cada vez la reejecutamos. O sea, que eso es lo que a partir de ahí ya no necesitas realmente mutabilidad en tu, en lo que es tu aplicación. Porque si tú piensas, por ejemplo, en un servidor web, un servidor web tú coges la cosa, devuelves la respuesta y no tiene por qué haber mutabilidad ahí, puede ser bastante inmutable. Entonces yo creo que en el momento que las interfaces gráficas ya han dado el paso, ya como que lo mismo de mutabilidad está aceptado. Como decía, yo creo que lo que falta de las típicas cosas cuando pensamos en web funcionales es los tipos. Los tipos súper increíbles que te evitan poder, o sea, que ya escribes el código, ya no necesitas tests. Eso es como lo que muchas veces prometen. Yo creo que esa parte no está ahí. Lo que decía antes, no creo que tampoco llegue a corto plazo porque como que el ratio entre el beneficio y lo que complica tu lenguaje es tan alto que al final encontramos una manera maravillosa de hacerlo más sencillo, o la gente no lo va a aceptar tan a priori.

En ese sentido, ¿ves tú que en el desarrollo de Kotlin y lo que se va proponiendo del lenguaje de programación haya otras vertientes además de la funcional o la orientada a objetos que se esté tomando ahora?

Yo creo que lo que se está ahora, al menos en Kotlin, trabajando mucho, creo que muchos lenguajes están explorando ahí, es todo, es qué pasa cuando nos tomamos la concurrencia en serio. Porque la actual, la concurrencia siempre ha sido, bueno, abro un thread y lo pongo, pero todo es muy manual, todo, qué pasa si algo falla, qué pasa, cómo, o sea, básicamente tomas las cosas como se la toma Erlang, que es el que se lo toma, siempre se lo ha tomado en serio todo el tema de la concurrencia, está llegando más Entonces Kotlin hace unos años metió todo lo que es concurrencia estructurada, así se llama. No sé, la idea que todo tiene como un padre y tal. Entonces si algo falla, el padre puede decidir qué hago, cancelo los hijos, todo este tipo de cosas, meterlos en el lenguaje es como— Y ahora se ve que, por ejemplo, Swift en la última versión, en Swift 6, ha metido un tema directamente de actores en el propio lenguaje. Yo creo que, yo creo que tengo la sensación de que por ahí van, van a ir los tiros ahora, que todo esto como que, que al final se basa en los anteriores pasos, ¿no? Porque al final, para tener una buena, una app interesante para ese tipo de cosas, siempre necesitas funciones de alto orden, porque al final es como que le tengo que decir qué hacer, y eso de forma natural es como algún tipo de función que le paso, algún tipo de función anónima o lo que sea. Y luego muchas veces también necesitan toda la parte que comentaba de inmutabilidad, porque si estoy con varias cosas, la forma más fácil de asegurarme de que estos dos, de que estas dos tareas no se solapan, no tienen conflicto, es si dividimos la, o sea, decimos que son inmutables. O lo que está intentando hacer Swift, que es interesante, es como que cada actor controle cierta parte de su estado Con lo cual sabemos que dos funciones que viven en distintos actores, esto de nuevo Swift lo tiene como parte del lenguaje, no pueden acceder a los mismos datos a no ser que lo declaren como que son compartidos. Siempre uno le tiene que pedir al otro con algún tipo de llamada, oye, cámbiame este dato. Y yo creo que ese tipo de ideas que de nuevo hace poco eran como impensables van a venir más y más. O sea, la gente se va a realmente empezar a plantear. Tenemos ordenadores con 28 millones de núcleos desde hace 20 años y nosotros seguimos programando como si lo que tuviésemos fuese un solo procesador, todo hacia adelante, y de vez en cuando un nuevo thread, pero ese thread, la API que tenemos es pésima. O sea, si tú piensas en la API que te da un thread de Java, es lo creas, hace cosas y lo puedes cancelar. No puedes saber cómo está, no puedes saber, no te puede dar un resultado. Entonces yo creo que ahí se va a trabajar más y se está viendo en muchos lenguajes que lo meten en el propio lenguaje.

¿En Kotlin se ha pensado algo específico que extienda la concurrencia más allá y se encargue también de la distribución?

O sea, lo que es en el lenguaje no hay nada. O sea, es como que Básicamente, punto de vista es un poco más que al final Kotlin intenta ser algo como que se integra con otras plataformas, sobre todo, o sea, con Java, con JavaScript, que es un poco donde se integra más. Entonces, como que intenta reusar esto. Hay cosas que está haciendo el JetBrains, hay un equipo que hace una cosa que se llama kotlin.rpc, que es como básicamente lo que comentabas de gRPC. Yo creo que es incluso el mismo protocolo, el gRPC, y exponerlo con lo típico, con llamadas a métodos y tal. Pero no llega al, o sea, creo que yo sepa nada llega al nivel de Erlang donde la distribución es casi completamente invisible. O sea, tú sabes que algo puede fallar, pero puede fallar sea en local o sea afuera. Aquí siempre tienes todavía la barrera en que si yo estoy haciendo una llamada a un método que no es local, algo, en algo se ve, o sea, algo diferente ocurre, algo de algún modo tengo que hacer la llamada diferente. O sea, yo creo que a ese nivel todavía no hemos llegado.

Y si tuvieses que reseñar lo que más te gusta de Kotlin, ¿qué aspecto sería?

Siempre a mí hay una pequeña cosa que me encanta que tiene Kotlin, se llama, según lo veas, lo llaman smart casting o flow typing o tal, básicamente Es la idea de que si tú haces una operación que te dé más información sobre el tipo de una variable, el compilador lo toma en consideración automáticamente. El típico ejemplo que siempre pongo es que tú tienes la típica clase que es mascota y tienes perro y gato, vale. Solo el perro ladra, el gato maúlla. Si tú en Kotlin tienes una cosa que es de tipo mascota y le dices si mascota is perro, o sea, si la mascota es de tipo perro, dentro del bloque ese automáticamente el tipo de mascota, de la variable mascota pasa a ser perro, o sea, puedes llamar al método ladrar y todo esto es automático. Y Kotlin usa esta idea que se llama smart casting, Creo que académicamente se llama flow typing. Es como que los tipos dependen del flujo del programa para un montón de cosas. Por ejemplo, en Kotlin ahí están los tipos nulables. Puedes poner int? y eso es que puede ser cualquier entero o null. Pero si tú dices si esto no es null, automáticamente dentro de ese bloque ya el tipo de esa variable ya no es int?, es solo int. Y lo usa para un montón de cosas. Es una idea relativamente simple, pero que creo que, si no me falla, creo que excepto TypeScript no hay ningún otro lenguaje que tenga esto. Incluso cuando Java ha introducido algo muy similar, tú tienes que darle un nuevo nombre. O sea, es como que te evita dar nombres todo el rato, sino que si tú ya has comprobado cosas, ¿por qué el lenguaje no va a tener esto en consideración para tipar tu programa? Es una de esas ideas, sobre todo porque eso no está en ningún otro sitio, que yo conozca, al menos no está en ningún otro sitio en la que haya también tipos estáticos. Porque digo, está, creo que está en TypeScript, pero al final TypeScript es como una cosa muy dinámica y un poco loca sobre todo lo que tiene que ver con tipos. Y no sé, me gusta bastante porque es una idea que en sí no es muy complicada. Es eso, es si yo hago un chequeo dentro, eso es verdadero, Pero al integrarse con todas las cosas que Kotlin mete en tipos, como que tiene muchas ramificaciones. Eso es, para mí es la feature como diferente que hace que para mí escribir Kotlin sea mucho más interesante que escribir pues incluso Scala, Haskell o Java, porque me permite acortar mucho el tipo de chequeos que hago.

Y ahora, yendo al lado contrario, ¿cuál sería una de las características que no te gustan o que te incomodan un poco de Kotlin?

No quieras que me despidan del trabajo, pero que no me gusta, hay una cosa que no me gusta de ahora mismo, no sé si es del lenguaje, es más sobre la librería. Base, pero Kotlin sigue teniendo excepciones. Entonces eso hace que muchas veces tengas en el lenguaje como dos versiones de la misma función: la que si no está bien peta y la que te devuelve null. Por ejemplo, si tú tienes un parseInt, tienes la versión parseInt que en la librería, que si no es un entero te lanza una excepción de ilegal no sé qué, O la versión parseIntOrNull, que te devuelve null si no es esto. A mí eso no me gusta. Me gustaría, porque al final tenemos toda la librería base está como duplicada, y me gusta, me encantaría que hubiese algo en el lenguaje que me permitiese como decidir en cada momento lo que yo quiero. Imagínate que digo, bueno, esta función tiene dos versiones, la llamo con una exclamación peta, si la llamo con una interrogación me devuelve null. Eso me falta, eso me falta en el lenguaje. Me incomoda cuando escribo porque nunca sé lo que va a ocurrir, nunca sé si estoy llamando. Además, es una cosa que por cómo está, por de dónde viene Kotlin, que sea algo null está en los tipos, pero que lance una excepción no está en los tipos. Con lo cual, si no, si no, no, como que no sabes a priori qué está ocurriendo, no puede fallar. O puede fallar con una excepción. Esa parte hay que darle una— bueno, no se puede hacer ahora, pero es una cosa que no me gusta del diseño. Me gustaría que el lenguaje entendiese un poco más como que el mismo problema— en mi mente es como que hay un problema, ¿no? Esta función, o sea, este parsing, esta cadena no es un entero. Y tengo 3 opciones, o sea, puede ser que resulta que yo ya había comprobado antes que sí que es un entero, entonces esto es un invariante, que es que si no funciona hay algo mal en mi código, hay algo que tenía que ser un invariante, una propiedad de mi cadena que no se ha cumplido, pero puede ser que eso yo quiera que lance una excepción por la razón que sea, y tratarla a más alto nivel. O puede ser que yo realmente lo que quiera sea la capacidad de responder, de decir, bueno, pues la quiero validar. O sea, la parseo pero con el fin de validarla, digamos. Y que en ese caso quiero devolver null. O incluso, si me voy más, incluso me encantaría que me diese información, oye, en el punto, en el carácter 4 no me da. Entonces yo creo que hay muchas cosas en todo lo que es el manejo de errores que ahí se podría como que trabajar mejor, ¿no? O sea, decir, vale, ¿qué quieres decir en este caso? ¿Cómo tengo que tratar este error? Y sobre todo, y que la solución no sea la que tenemos ahora, que es decir, bueno, pues créate dos funciones, parseIntOrThrow, parseIntOrNull, y llama a la correcta. Ok, bueno, si copiamos y pegamos código es que algo nos falta en el lenguaje.

Y si tuvieses que recomendar alguna forma de adentrarse en el lenguaje Kotlin para alguien que que viene de otro lenguaje o incluso que quiere empezar desde cero, ¿cuáles serían esas recomendaciones que darías de mira, ten cuidado con esto, empieza de esta forma?

Hace tiempo que no sabría cómo decir a alguien cómo empezar desde cero. Sé que hay un libro bastante bueno que se llama Coding in Action, que es como lo que solemos recomendar para que la gente aprenda, pero la verdad es que no sé hasta qué punto es para alguien que sabe cero programación. Si quiere aprender, está la página web. Tiene unos cuantos tutoriales que mis compañeros de Un Poco Más Allá se dedican a escribir para introducir a la gente en el lenguaje, que están bastante bien. Y tienen la típica cosa esta de que puedes ir resolviendo los ejercicios según tienes el tutorial. La otra cosa que está bastante bien es que si lo que te apetece es aprender cosas de interfaces de usuario, hay muchos libros que te enseñan a la vez Kotlin y Compose, como la cosa que para hacer aplicaciones Android, pero que ahora es multiplataforma, así que también puedes hacer la misma aplicación pero en iOS y todas estas cosas. Hay bastantes libros como que enseñan las dos cosas a la vez y a mí me parece interesante, ya te digo, porque ya ves cómo las cosas ya aplicadas a algo en vez de— o sea, es que a mí nunca me han gustado los libros que durante los 7 primeros capítulos lo que haces es imprimir algo por consola porque quién usa la consola ahora mismo en estos, en estos días. Así para empezar, no es como, o sea, no que no la uses, sino reformulo, o sea, más como que normalmente tú aprendes a usar la consola cuando estás aprendiendo a programar, es como parte de lo que tienes que aprender. Pero estos libros es como, no, si tú ya usas la consola, obviamente, obviamente tú tienes tu, así que lo primero que vas a hacer es imprimir por pantalla. Y dices, esto Dime una persona que no sea programadora que use la consola de forma habitual. No creo que haya muchos.

La verdad es que ha sido una charla bastante interesante. Creo que me he quedado con un buen, o sea, una buena impresión de Kotlin, porque era un lenguaje que a mí me habían dicho que era casi como escribir Java pero con otra síntaxis, y ya veo que es un lenguaje mucho más completo y y que tiene su avance y su diferencia con respecto a Java. Y es una, bueno, si vas a utilizar la Java Virtual Machine, pues otra opción bastante interesante a considerar. Si quieres decir algo para despedirte.

Nada, pues el típico, el típico momento del anunciante. Si alguien está interesado en aprender Kotlin de forma adicional, he escrito un libro sobre el tema. Si a la gente le interesa la intersección de las dos cosas. Sí, aparte de eso, como tú mismo has comentado lo de LambdaWorld, yo estoy involucrado en el comité de programa y bueno, todo lo que sea que venga más gente a aprender del tema es genial. O sea, que animo a todo el mundo a que a que se informe y venga un poco a compartir las experiencias sobre el tema o aprender experiencias de otros. Y además es en octubre en Cádiz y hace bueno, que para mí que vivo en los Países Bajos me da el poquito de vitamina D que necesito en invierno.

Pues muchas gracias, Alejandro, por haberte pasado. Pondremos todos los enlaces de lo que has dicho en la descripción del podcast. Y nada, si quieres seguirnos en otro programa, nos vemos en el siguiente. Muchas gracias por habernos escuchado.