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 魅影直播 鈥 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 魅影直播 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 鈥渓enguajes鈥. 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 鈥渓enguajes y plataformas鈥 para poder reflejar esta importancia.
En noviembre del 2010, publicamos 鈥淔in 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 鈥淛avascript 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 鈥淵o 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 魅影直播 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 魅影直播 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 魅影直播 鈥 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 魅影直播 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 鈥渓enguajes鈥. 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 鈥渓enguajes 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 鈥淔in 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 鈥淛avascript 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 鈥淵o 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 魅影直播 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 魅影直播 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 魅影直播.