Para los pesimistas, hay poco valor en la exploración de nuevos lenguajes. Después de todo, la mayoría de los lenguajes de hoy en día cumplen completamente con las leyes de Turing — puede implementarse con ellos todo lo que sea implementable — entonces, ¿cuál es el objetivo de aprender uno nuevo? Para una auto-confesada geek de lenguajes como yo — había aprendido cinco de ellos antes de terminar la universidad — esa línea de argumentos olvida el objetivo fundamental. Siempre hay algo de interesante y emocionante en encontrar un nuevo lenguaje que me permite expresarme con más claridad.
Los lenguajes son parte integral del campo de la tecnología. Es por eso que tenemos todo un cuadrante para ellos en el Radar Tecnológico de Thoughtworks — nuestra guía de opiniones sobre las tecnológicas de vanguardia. Y a medida que nos acercamos al volúmen 20 del Radar, quise explorar los cambios y evolución de los lenguajes durante ese período.
Dicho esto, cuando Thoughtworks publicó su primer Radar Tecnológico, no era un momento particularmente interesante para los lenguajes de programación. Esencialmente, era una de las tres opciones: Java, C# ó C++ — Esto abarcaba a la vasta mayoría de las aplicaciones corporativas.
Entonces lo más notable sobre los primeros radares es que inicialmente teníamos un cuadrante llamado simplemente “lenguajes”. Pronto nos dimos cuenta que los ecosistemas alrededor de los lenguajes pueden ser tan importantes como el lenguaje en sí. Lo vimos primeramente con C++, seguido de Java y C#, y lo vemos hoy en día con Kotlin. Luego nuestro cuadrante se convirtió en “lenguajes y plataformas” para poder reflejar esta importancia.
En noviembre del 2010, publicamos “Fin de la vida del lenguaje Java” en nuestro anillo de Evaluar — estábamos realmente preocupados que la innovación en Java se hubiera paralizado y queríamos enviar una señal a nuestros compañeros desarrolladores.
Ahora, pudieras decir que fue una equivocación nuestra. Después de todo, Java no murió. Pero en aquel momento, nuestras preocupaciones eran muy reales. Esto fue cuando Oracle había completado su adquisición de Sun Microsystems, y no habíamos visto nuevos lanzamientos de Java en años.
Una cosa en la que definitivamente tuvimos razón pero que le tomó al resto de las personas tiempo para entender, fue el llamar la atención de “Javascript como lenguaje de primera clase”.
Los lenguajes de primera clase tienen las herramientas, como pruebas unitarias, y enfoques, como refactorización, que esperarías para ambientes de producción. Hemos visto a JavaScript siendo utilizado para algunos proyectos empresariales importantes. En aquel momento, sentimos que descartándolo como un lenguaje scripting puro no le daba el valor correcto. Ha tomado un poco de tiempo, pero hoy pueden ver a las personas tratar a JavaScript como un lenguaje importante.
Casi al mismo tiempo, pusimos en Adoptar que las personas deberían preocuparse por los lenguajes. Esta idea surgió porque comenzamos a ver el desarrollo de innovaciones en los lenguajes construidos sobre la JVM. En este punto, como desarrollador, te enfrentas con la decisión de cuál lenguaje era apropiado utilizar para construir algo. No es únicamente el caso de “Yo trabajo en la tienda de Java así que voy a codificar en Java”. ¿Cuándo es apropiado utilizar algo como Clojure o Javascript?
Recuerdo en aquel momento estar exponiendo a colegas en Bangalore, India — ellos estaban llenos de entusiasmo sobre Clojure, y querían ser el primer equipo en Thoughtworks que entregara un proyecto en Clojure. En ese mismo viaje, fui a nuestras oficinas en Pune y la historia fue la misma allí — excepto que ellos estaban considerando Scala.
En ese momento no estaba claro cuál ganaría. Quizás todavía no lo está. Ambos brindan el poder de los lenguajes funcionales a las grandes compañías — sólo tomaron enfoques bien diferentes. Clojure estaba en el paradigma funcional únicamente; Scala estaba intentando facilitar el camino, utilizando una sintaxis que fuera familiar a los programadores de Java. Scala estaba más avanzando de alguna manera en los ecosistemas a su alrededor, como el framework Play, pero eso cambió pronto.
El otro lenguaje funcional notable en aquel tiempo era F# — como la contribución primaria de Microsoft a los lenguajes funcionales, era imposible de ignorar. O al menos debió serlo. F# nunca se movió de nuestro anillo de Evaluar al de Probar — lo cual significa que fue algo que vimos interesante explorar, pero nunca tuvimos equipos que lo utilizaron exitosamente en producción. A pesar de que teníamos clientes utilizando ecosistemas de Microsoft, nunca llegamos allí con F#.
Lo que hemos visto más recientemente es que hay aspectos de Scala que lo hacen un poco más problemático. La idea de diseño de hacerlo parecer a Java significa que podrías tener a personas escribiendo en la misma aplicación y a la vez estar utilizando estilos idiomáticos de Scala bien diferentes.
Tratamos de capturar esta idea en el Radar. Tuvimos un blip llamado “Scala, las partes buenas”. Y creo que esto advierte cuestiones fundamentales sobre qué constituye una buena opción para los lenguajes de programación: Puede que haya o no una respuesta correcta; cualquiera sea la decisión que tomes como equipo, necesitan acordar cómo usar ese lenguaje, y cómo enfocar problemas similares. No vas a querer un desarrollador resolviendo un problema de una manera y otro tomando un enfoque completamente diferente.
Una persona con la que hablé en ese momento pensó que era una abominación. Incluso sugirió que la persona creadora de Go debió haberse quedado dormida por más de una década y despertar justo antes de crear el lenguaje — porque el tipo de decisiones tomadas en Go estaban repitiendo el tipo de cosas que habíamos estado haciendo en aquella época lejana. Mientras tanto, otra persona con la que hablé amaba a Go. Amaba las cosas que el lenguaje le daba y que lo hacía tan increíblemente fácil de usar.
Ambas de estas personas eran expertos en programación de lenguajes, y sólo demuestra cómo dos personas pueden tener experiencias totalmente diferentes cuando utilizan un lenguaje. Lo cual sucede porque tu experiencia en un lenguaje no está sólo relacionada con lo que el lenguaje te proporciona como desarrollador de software sino cómo tú ves a dicho lenguaje. Todos pensamos en los problemas en formas diferentes. Así que no te sorprendas si seleccionas un nuevo lenguaje y te tornas ampliamente entusiasta sobre utilizarlo, pero descubres que tus colegas no comparten el mismo entusiasmo.
En Thoughtworks pensamos que esto es un error. Algunas veces hay cosas que puedes expresar más claramente en un lenguaje y que tendrías conflictos de realizar con otro. Y una de las cosas más importantes que debes hacer como desarrollador es escribir código que sea fácil de entender.
Pero también hemos visto que la anarquía de los desarrolladores — donde cada desarrollador es libre de decidir sobre cuál lenguaje escoger — lo cual es una receta para conseguir problemas, o al menos selección tecnológica guiada por reanudaciones constantes. Lo cual conlleva a una pregunta interesante: ¿cuál es el número correcto de lenguajes para tu organización? Nosotros utilizamos la frase programación políglota para capturar la idea de que deberíamos juiciosamente expandir nuestras decisiones de cuáles lenguajes usar en función de los diferentes espacios de problemas.
Es difícil prescribir una solución única, pero pensamos que promover unos pocos lenguajes que para diferentes ecosistemas es importante para las grandes compañías, ya que las habilita en acelerar los procesos de lanzamientos y entregas. Mientras tanto, los desarrolladores se benefician de tener las herramientas correctas para resolver los problemas a mano.
Traducción al español realizada por: Ana Telleria y María José Lalama
Los lenguajes son parte integral del campo de la tecnología. Es por eso que tenemos todo un cuadrante para ellos en el Radar Tecnológico de Thoughtworks — nuestra guía de opiniones sobre las tecnológicas de vanguardia. Y a medida que nos acercamos al volúmen 20 del Radar, quise explorar los cambios y evolución de los lenguajes durante ese período.
Dicho esto, cuando Thoughtworks publicó su primer Radar Tecnológico, no era un momento particularmente interesante para los lenguajes de programación. Esencialmente, era una de las tres opciones: Java, C# ó C++ — Esto abarcaba a la vasta mayoría de las aplicaciones corporativas.
Entonces lo más notable sobre los primeros radares es que inicialmente teníamos un cuadrante llamado simplemente “lenguajes”. Pronto nos dimos cuenta que los ecosistemas alrededor de los lenguajes pueden ser tan importantes como el lenguaje en sí. Lo vimos primeramente con C++, seguido de Java y C#, y lo vemos hoy en día con Kotlin. Luego nuestro cuadrante se convirtió en “lenguajes y plataformas” para poder reflejar esta importancia.
¿Fin de la vida de Java?
También invertimos muchas de las ediciones tempranas del Radar reflexionando sobre el destino de Java. Como hemos mencionado, era uno de los grandes lenguajes en aquel momento — lo cual no significaba que estuviéramos siempre confiados de su futuro.En noviembre del 2010, publicamos “Fin de la vida del lenguaje Java” en nuestro anillo de Evaluar — estábamos realmente preocupados que la innovación en Java se hubiera paralizado y queríamos enviar una señal a nuestros compañeros desarrolladores.
Ahora, pudieras decir que fue una equivocación nuestra. Después de todo, Java no murió. Pero en aquel momento, nuestras preocupaciones eran muy reales. Esto fue cuando Oracle había completado su adquisición de Sun Microsystems, y no habíamos visto nuevos lanzamientos de Java en años.
Una cosa en la que definitivamente tuvimos razón pero que le tomó al resto de las personas tiempo para entender, fue el llamar la atención de “Javascript como lenguaje de primera clase”.
Los lenguajes de primera clase tienen las herramientas, como pruebas unitarias, y enfoques, como refactorización, que esperarías para ambientes de producción. Hemos visto a JavaScript siendo utilizado para algunos proyectos empresariales importantes. En aquel momento, sentimos que descartándolo como un lenguaje scripting puro no le daba el valor correcto. Ha tomado un poco de tiempo, pero hoy pueden ver a las personas tratar a JavaScript como un lenguaje importante.
Casi al mismo tiempo, pusimos en Adoptar que las personas deberían preocuparse por los lenguajes. Esta idea surgió porque comenzamos a ver el desarrollo de innovaciones en los lenguajes construidos sobre la JVM. En este punto, como desarrollador, te enfrentas con la decisión de cuál lenguaje era apropiado utilizar para construir algo. No es únicamente el caso de “Yo trabajo en la tienda de Java así que voy a codificar en Java”. ¿Cuándo es apropiado utilizar algo como Clojure o Javascript?
¿Scala o Clojure?
Durante el tiempo que hemos estado publicando el Radar, hemos visto también emerger la llamada ola funcional. Por supuesto, los lenguajes como Lisp y Haskell han estado con nosotros literalmente por décadas — lo que realmente ocurrió fue que comenzamos a ver a las grandes compañías interesarse en los lenguajes funcionales.
Recuerdo en aquel momento estar exponiendo a colegas en Bangalore, India — ellos estaban llenos de entusiasmo sobre Clojure, y querían ser el primer equipo en Thoughtworks que entregara un proyecto en Clojure. En ese mismo viaje, fui a nuestras oficinas en Pune y la historia fue la misma allí — excepto que ellos estaban considerando Scala.
En ese momento no estaba claro cuál ganaría. Quizás todavía no lo está. Ambos brindan el poder de los lenguajes funcionales a las grandes compañías — sólo tomaron enfoques bien diferentes. Clojure estaba en el paradigma funcional únicamente; Scala estaba intentando facilitar el camino, utilizando una sintaxis que fuera familiar a los programadores de Java. Scala estaba más avanzando de alguna manera en los ecosistemas a su alrededor, como el framework Play, pero eso cambió pronto.
El otro lenguaje funcional notable en aquel tiempo era F# — como la contribución primaria de Microsoft a los lenguajes funcionales, era imposible de ignorar. O al menos debió serlo. F# nunca se movió de nuestro anillo de Evaluar al de Probar — lo cual significa que fue algo que vimos interesante explorar, pero nunca tuvimos equipos que lo utilizaron exitosamente en producción. A pesar de que teníamos clientes utilizando ecosistemas de Microsoft, nunca llegamos allí con F#.
Lo que hemos visto más recientemente es que hay aspectos de Scala que lo hacen un poco más problemático. La idea de diseño de hacerlo parecer a Java significa que podrías tener a personas escribiendo en la misma aplicación y a la vez estar utilizando estilos idiomáticos de Scala bien diferentes.
Tratamos de capturar esta idea en el Radar. Tuvimos un blip llamado “Scala, las partes buenas”. Y creo que esto advierte cuestiones fundamentales sobre qué constituye una buena opción para los lenguajes de programación: Puede que haya o no una respuesta correcta; cualquiera sea la decisión que tomes como equipo, necesitan acordar cómo usar ese lenguaje, y cómo enfocar problemas similares. No vas a querer un desarrollador resolviendo un problema de una manera y otro tomando un enfoque completamente diferente.
Cuida tu lenguaje
Puedo ilustrar por qué el acuerdo entre desarrolladores es tan importante cuando miramos a Golang. Comenzamos a adquirir emoción alrededor de Go en el 2014. Go como lenguaje, intenta proporcionar una alternativa a los lenguajes de programación C. Sin embargo, también creó conflictos entre las personas que realmente les importaba los lenguajes por largo tiempo, más que ningún otro que yo pueda recordar.Una persona con la que hablé en ese momento pensó que era una abominación. Incluso sugirió que la persona creadora de Go debió haberse quedado dormida por más de una década y despertar justo antes de crear el lenguaje — porque el tipo de decisiones tomadas en Go estaban repitiendo el tipo de cosas que habíamos estado haciendo en aquella época lejana. Mientras tanto, otra persona con la que hablé amaba a Go. Amaba las cosas que el lenguaje le daba y que lo hacía tan increíblemente fácil de usar.
Ambas de estas personas eran expertos en programación de lenguajes, y sólo demuestra cómo dos personas pueden tener experiencias totalmente diferentes cuando utilizan un lenguaje. Lo cual sucede porque tu experiencia en un lenguaje no está sólo relacionada con lo que el lenguaje te proporciona como desarrollador de software sino cómo tú ves a dicho lenguaje. Todos pensamos en los problemas en formas diferentes. Así que no te sorprendas si seleccionas un nuevo lenguaje y te tornas ampliamente entusiasta sobre utilizarlo, pero descubres que tus colegas no comparten el mismo entusiasmo.
¿Un único lenguaje para triunfar sobre todo?
Lo mencioné al comienzo, que algunas personas no ven valor en el desarrollo de nuevos lenguajes. Lo cual está estrechamente alineado con la idea de que deberías utilizar una única opción de lenguaje para realizar con él todo tu trabajo de desarrollo.En Thoughtworks pensamos que esto es un error. Algunas veces hay cosas que puedes expresar más claramente en un lenguaje y que tendrías conflictos de realizar con otro. Y una de las cosas más importantes que debes hacer como desarrollador es escribir código que sea fácil de entender.
Pero también hemos visto que la anarquía de los desarrolladores — donde cada desarrollador es libre de decidir sobre cuál lenguaje escoger — lo cual es una receta para conseguir problemas, o al menos selección tecnológica guiada por reanudaciones constantes. Lo cual conlleva a una pregunta interesante: ¿cuál es el número correcto de lenguajes para tu organización? Nosotros utilizamos la frase programación políglota para capturar la idea de que deberíamos juiciosamente expandir nuestras decisiones de cuáles lenguajes usar en función de los diferentes espacios de problemas.
Es difícil prescribir una solución única, pero pensamos que promover unos pocos lenguajes que para diferentes ecosistemas es importante para las grandes compañías, ya que las habilita en acelerar los procesos de lanzamientos y entregas. Mientras tanto, los desarrolladores se benefician de tener las herramientas correctas para resolver los problemas a mano.
¿Entonces qué sigue?
Somos optimistas y pensamos que la ola de innovación en los lenguajes de programación y frameworks continuará. Espera mucha más noticias en este cuadrante a medida que continuamos navegando en los próximos 20 radares.Traducción al español realizada por: Ana Telleria y María José Lalama
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.