Hace unos años sonaba bastante el término programador políglota para referirse a aquellos programadores que eran capaces de trabajar con varios lenguajes de programación. Hoy en día es una idea que ha perdido popularidad, al menos a la hora de rellenar posts y charlas en eventos. Es una idea que me gusta, y querría pensar que si ya no se habla tanto de ello es porque se ha convertido en algo que se da por hecho, pero en realidad creo que, simplemente, ha pasado a un segundo plano y las modas actuales van por otro lado.

En paralelo sí que veo un auge de lo que podríamos considerar proyectos políglotas, en los que se mezclan distintos lenguajes de programación, y no sólo como lenguajes auxiliares, sino como lenguajes primarios en diferentes áreas del proyecto. Aquí la moda de los microservicios tiene mucho que decir.

Por supuesto, esto no es más que una impresión personal y limitada a mi círculo de fuentes de información, así que es probable que esté equivocado. Aun así, aprovecharé para analizar ambas ideas: la del programador y la del proyecto políglota.

Las ventajas del programador políglota

En un mundo de fantasía uno aprendería a programar en un lenguaje y ya sabría programar en todos. Tan sólo es cuestión de aprender la sintaxis de cada uno y traducir de uno a otro.

¿Suena iluso? Sin duda, pero es una sensación que muchos hemos tenido. Durante mis primeros años en esto, era lo que pensaba. Cuando aprendí a programar en Pascal y luego en C, daba por hecho que era más o menos lo mismo, pero cambiando los BEGIN/END por {/}. Bueno, puede que entre Pascal y C no haya taaaaanta diferencia, pero es algo más que un cambio de sintaxis, sobre todo cuando piensas en los estilos de programación que imperan en cada uno.

Asumiendo entonces que aprender un lenguaje de programación es algo más que aprender su sintaxis, esto de aprender varios, y más si quieres tener un grado de soltura razonable con ellos, parece que va a requerir cierto esfuerzo. Además de la sintaxis, cada lenguaje viene con su paquete de herramientas, librerías, frameworks, estilos de programación y construcciones idiomáticas, y manejarse bien con todo ello son palabras mayores.

¿Merece la pena dedicar todo ese esfuerzo en conocer otros lenguajes?

Teniendo en cuenta que para muchos su trabajo en el día a día les lleva a utilizar un único lenguaje de programación (o un par de ellos), parece que lo más razonable es profundizar en ellos al máximo y ser lo más productivo posible con ellos. A fin de cuentas, es difícil que dedicando un rato a jugar con otros lenguajes alcances el grado de productividad que tienes con un lenguaje, unas herramientas y unas librerías a las que dedicas 30 o 40 horas semanales.

Sin embargo, y como ya te imaginarás puesto que estoy escribiendo este post, soy un firme defensor de aprender otros lenguajes de programación, aunque nunca llegues a dominarlos tanto como tu lenguaje «del día a día» y nunca llegues a utilizarlos «profesionalmente».

Cuando trabajas siempre con las mismas herramientas y eres productivo con ellas es muy fácil acomodarse y asumir que es lo mejor que vas a encontrar. De hecho, probablemente sea cierto y, como decía antes, en este momento ninguna herramienta te haga tan productivo como las que ya conoces.

Sin embargo, eso no deja de ser una falsa sensación de seguridad basada en tu (limitada) visión personal. Siempre hay un margen de mejora y una buena forma de conocer alternativas es aprender de otros. Al aprender otros lenguajes de programación te estás exponiendo a una forma diferente de trabajar, con sus partes buenas y sus partes malas, y tal vez descubras ideas que te sorprendan.

Esta exploración de otros ámbitos puede desembocar en que acabes cambiando de lenguaje «principal» hacia alguno de los que has aprendido. Al principio además te parecerá todo maravilloso, porque lo nuevo siempre atrae. Pasados unos años… bueno, el tiempo lo diría.

Lo más probable es que la exploración de otros lenguajes no se traduzca en una migración hacia ellos, pero seguramente puedas obtener nuevas ideas y formas de trabajar que influencien la forma en que utilizas tus herramientas actuales y te permita sacarles más partido. Tal vez un día te descubras evitando las clases en C#, adaptando librerías de ClojureScript a Javascript o incluso utilizando Monoides para configurar tu aplicación de Java.

Me gusta compararlo con viajar. Viajar es una actividad muy enriquecedora porque te permite conocer otras ciudades, otras personas y otra forma de ver la vida. Es poco probable que te mudes a una nueva ciudad sólo porque has estado allí unos días y te ha gustado, pero el viaje en si mismo habrá merecido la pena.

Hay quien piensa que, actualmente, con los lenguajes multiparadigma que permiten utilizar un enfoque funcional, orientado a objetos, procedural, con tipado estático, dinámico o gradual, esto de conocer varios lenguajes pierde sentido. A fin de cuentas, en mi lenguaje favorito ya tengo todo lo que necesito. No soy nada partidario de la featuritis en lenguajes de programación, pero es que además no es comparable. No se trata sólo de una cuestión de paradigmas, es también una cuestión cultural.

Siguiendo con la comparativa de los viajes, es como ir a Las Vegas. Sí, hay una recreación de la Torre Eiffel. Y de los canales de Venecia. Y pirámides, como en Egipto. Pero no es lo mismo, es sólo cartón piedra imitando el original. Incluso aunque la reproducción fuese físicamente perfecta y no pudieras distinguirla del original, lo que hay alrededor no es igual y pierdes la parte de cultura, motivaciones e historia que hay detrás.

Normalmente cuando se habla de alternativas en desarrollo siempre se acaba citado el típico The Right Tool For The Job ™, y este caso no es diferente. Si conoces varios lenguajes de programación, podrás elegir el que mejor se adapte para cada caso y, al menos en teoría, ser más feliz y productivo.

Y siguiendo este hilo de argumentación acabamos, directamente, en el siguiente punto: los proyectos políglotas.

Los peligros del proyecto políglota

Parece razonable. Si somos programadores políglotas, capaces de trabajar con soltura en diferentes lenguajes de programación, qué mejor que aplicar eso en cada proyecto para poder aprovechar al máximo las características de cada lenguaje y poder emplear en cada parte del proyecto la herramienta que más se adecúe a ella.

Es uno de los argumentos a favor de las arquitecturas basadas en servicios (micro o no). Teniendo componentes aislados obtenemos, no sólo flexibilidad en despliegue, sino también flexilibidad en desarrollo y, en concreto, en el lenguaje que queremos utilizar.

Tampoco hace falta irse a arquitecturas complejas. Muchos lenguajes permiten interoperar fácilmente con otros lenguajes. Por ejemplo, mezclar lenguajes dentro de .NET o de la JVM es bastante fácil, y casi todo los lenguajes tienen algún tipo de forma de interoperar con C. Podríamos tener partes de una aplicación desarrollada en C#, usando librerías concretas en F# y no habría problema.

Además, es muy raro encontrarse a día de hoy con un proyecto que no esté usando ya varios lenguajes, aunque sean «auxiliares». SQL para acceder a una base de datos, lenguajes de marcado (HTML, XAML, etc.) para el interfaz de usuario, Javascript (porque, como sabéis, todo acaba llevando Javascript), algún lenguaje de scripting para automatizar tareas… Podríamos decir que hoy en día casi todos los proyectos son, de alguna forma, políglotas.

Pese a esta realidad y las innegables ventajas de poder usar el lenguaje más adecuado en cada momento, esta vía tiene riestos que hay que evaluar antes de lanzarse a utilizar 12 lenguajes de programación diferentes en el próximo proyecto.

Por una parte, tenemos un problema directo de necesidad de conocimiento. Si el proyecto utiliza varios lenguajes, con distintos estilos de programación, distintas librerías y distintas herramientas, tenemos dos opciones: o tenemos especialistas en cada área, o tenemos gente capaz de manejarse en todas.

La primera opción, tener especialistas en cada área/lenguaje, requiere que el equipo tenga un cierto tamaño como para poder diferencias bien los roles, y disminuye la tolerancia a fallos del equipo porque contribuye a crear silos de información.

La alternativa, contar con gente capaz de manejarse en todos los lenguajes, supone una mayor dificultad para incorporar gente al equipo y para formarla. Incluso teniendo la gente formada, estar haciendo constantemente cambios de contexto al pasar de un lenguaje a otro puede ser un inconveniente (aunque también podría ser un aliciente para evitar la monotonía, todo hay que verlo).

Este problema «humano» es importante, pero existe un problema técnico que, en mi opinión, puede acabar pensado más: el incremento del número de dependencias.

Pocas dependencias hay más fuertes en un proyecto que el lenguaje de programación elegido. A partir del lenguaje irán surgiendo las demás dependencias: herramientas, librerías, gestores de paquetes, etc.

Si trabajas con lenguajes de programación cercanos, que compartan plataforma, habrá dependencias que puedas reutilizar. Por ejemplo, si optas por C# y F#, puedes trabajar con Visual Studio, utilizar NuGet como gestor de paquetes (o, aun mejor, Paket) y ejecutar ambos sobre el CLR. Aun así, para poder explotar al máximo las características de cada lenguaje probablemente acabes con algunas dependencias «duplicadas» para disponer de la solución más idiomática en cada caso.

Si empiezas a desarrollar una web en C#, interactuando con servicios en Go y un frontend en Javascript… bueno, te lo vas a pasar mejor manteniendo runtimes para cada una de las cosas, compiladores para todas y librerías específicas.

Este escenario no tendría por qué ser tan terrible. En un proyecto grande, de larga duración, dedicar tiempo a montar toda esta infraestructura puede compensar con el teórico incremento de productividad asociado a disponer de lenguajes mejores para cada tarea concreta.

Desgraciadamente, cada vez es más difícil ver esto como una inversión inicial, y el ritmo al que avanza todo hace que sea complicado mantener el montaje inicial mucho tiempo. Tendrás que mantener actualizadas las librerías de cada lenguaje. Adecuarte a los cambios de versión de sus plataformas. A las nuevas herramientas y formas de trabajo que se hayan puesto de moda y que, si quieres usar las versiones nuevas de las librerías, no te queda más remedio que usar.

Todo esto suele ser, en el sentido más estricto de la expresión, una pérdida de tiempo. Son cosas que aportan muy poco a los usuarios de tu aplicación, pero que no te queda más remedio que hacer. Si en lugar de un lenguaje y una plataforma tienes 3 o 4, la pérdida de tiempo se multiplica, por lo que es fundamental estar seguro de que las ventajas que obtienes por utilizar varios lenguajes, compensa este incremento de tiempo de mantenimiento.

Conclusión

Nunca hay que dejar de viajar, digo, de conocer otros lenguajes de programación. Aparte de que suele ser divertido, es una forma muy buena de aprender cosas diferentes que puedes luego trasladar a tu día a día. Como mínimo, te permitirá afrontar los problemas con más herramientas y otros puntos de vista, y eso ya es positivo per se.

Además, este mundo cambia muy rápido y nunca se sabe si uno de esos lenguajes de programación que hoy aprendes por curiosidad se acabará convirtiendo en tu próxima oportunidad profesional (o en tu salvación cuando tu lenguaje favorito caiga en el olvido).

Con lo que tenemos que tener cuidado es con abusar de ese nuevo conocimiento e intentar mezclar muchos lenguajes de programación en un mismo proyecto. Es algo que puede resultar tremendamente útil y productivo, pero que tiene unos riesgos y costes asociados que hay que considerar cuidadosamente antes de lanzarse a ello.