TypeScript, un lenguaje diseñado para las herramientas

En las últimas semanas se ha armado bastante revuelo en twitter y blogs sobre TypeScript, el último lenguaje presentado por Microsoft. No me quiero perder la oportunidad de meter mi cuota de ruido en la discusión, aunque en lugar de mostrar lo que puede hacer TypeScript, prefiero centrarme en otros aspectos.

Las herramientas en el desarrollo

Hace tiempo que en el desarrollo de software no podemos considerar un lenguaje de programación como una herramienta de forma aislada. En cuanto un proyecto adquiere una cierta complejidad, contar con un editor de texto y un compilador no basta y necesitamos herramientas adicionales que nos ayuden a gestionar la complejidad del proyecto.

Para mantener la productividad en unos niveles aceptables necesitamos aplicaciones que nos faciliten el control de los distintos ficheros que forman parte del proyecto (código fuente, ficheros de recursos, etc.), depuradores, herramientas de refactorización, etc.

Este ecosistema de aplicaciones, junto con las librerías y la documentación existente, pueden suponer la diferencia entre que una tecnología tenga una gran aceptación o quede relegada a unos pocos entusiastas.

Los que solemos trabajar en entornos Microsoft estamos más que acostumbrados a eso: hay ejemplos recientes como el de ASP.NET MVC, cuya adopción fue relativamente rápida y barrió a frameworks más maduros (en su momento) como Castle Monorail, o en el terreno de los ORMs el de Entity Framework frente a NHibernate.

En ambos casos se trata de librerías que empezaron con versiones muy inferiores a las alternativas existentes, pero que contaron con el poder de comunicación de Microsoft y con un conjunto de herramientas muy potente desde el primer momento (asistentes, editores gráficos, …), lo que facilitó mucho la entrada para gente sin experiencia.

A veces incluso da la sensación de que mucha gente tiene una dependencia excesiva de las herramientas y no es capaz de comprender lo que pasa más allá del wizard de turno.

TypeScript y el tooling

OJO: Todo lo que diga sobre TypeScript se basa en un análisis superficial y en las primeras impresiones que me ha causado. NO he usado TypeScript más allá de hacer un par de pruebas rápidas. Por otra parte, eso me deja en la misma posición que la mayoría de la gente que ha escrito sobre él hasta ahora :-)

TypeScript es un nuevo lenguaje anunciado por Microsoft hace poco más de un mes que se puede compilar a Javascript, lo que permite ejecutarlo en un browser, en node.js y, en general, en cualquier cosa que sea capaz de ejecutar código Javascript.

Es un superconjunto tipado de Javascript, lo que quiere decir que amplía Javascript con una nueva sintaxis que permite, entre otras cosas, añadir información de tipos a las funciones y definir clases e interfaces, manteniendo además compatibilidad total con el código Javascript existente. Todo programa Javascript válido es a la vez un programa TypeScript válido.

Según sus creadores, TypeScript nos permite usar Javascript para crear aplicaciones grandes y aparentemente el aspecto crítico para permitirlo es la inclusión de un sistema de tipado en el lenguaje.

¿Por qué es tan importante disponer de tipos? Por las herramientas.

Para poder ofrecer muchas de las herramientas a las que estamos acostumbrados los desarrolladores de .NET es necesario disponer de información de tipos que permitan mostrar intellisense, comprobar errores en tiempo de compilación o realizar refactorizaciones de forma segura.

Desde mi punto de vista, lo que aporta TypeScript es, ni más ni menos, eso: el tooling. Un conjunto de herramientas para acabar generando código javascript en un entorno que resulte familiar al desarrollador medio de entornos Microsoft.

No lo digo como algo negativo, ya he dicho al principio de este post que las herramientas son muy importantes, pero la propuesta de TypeScript se queda un poco corta como para resultarme atractiva.

Como lenguaje de programación no me parece que incorpore conceptos demasiado novedosos para alguien procedente de C#. En ese sentido, me parece más interesante lo que estoy viendo sobre kotlin, que mezcla ideas de Java, Scala y Groovy, y también puede compilarse a Javascript.

Por otra parte, al trabajar con lenguajes dinámicos existen otro tipo de herramientas para mejorar la productividad que no dependen de tener información de tipos, algunas de ellas específicas de lenguajes dinámicos y otras comunes a lenguajes estáticos.

Al no tener que compilar se puede sacar partido del bucle read-eval-print que nos permite probar rápidamente el código que vamos escribiendo. El uso de tests automatizados ayuda a controlar problemas de interacción entre componentes, supliendo un poco la misión del compilador de verificar que los parámetros con los que se invoca una función son los adecuados, pero además comprobando también que el funcionamiento es correcto.

Entonces… ¿merece la pena aprender TypeScript? Aprender cosas nuevas siempre merece la pena, lo que pasa es que el tiempo es finito y es necesario priorizar.

Si estás acostumbrado a programar en C#, creo que es mejor aprender directamente Javascript porque te expone a unos paradigmas de desarrollo diferentes a los que sueles utilizar y te va a aportar más que aprender TypeScript.

3 comentarios en “TypeScript, un lenguaje diseñado para las herramientas

  1. Estoy de acuerdo, hay que priorizar y ahora mismo TypeScript no lo veo una prioridad. Sin embargo, sí veo una prioridad aprender Javascript. Muy acertada la visión del tooling.

  2. uno que pasaba dijo:

    Estoy de acuerdo pero solo en parte.

    Lo que facilita la escalabilidad en el desarrollo de aplicaciones grandes es el paradigma de orientación a objetos basado en clases, y de manera estricta (que te obligue a ello). Ya que la orientación a objetos basada en prototipos y sobre todo lo poco estricto que es javascript (por decirlo de alguna manera) facilita mucho el código espagueti. Al final en lugar de desarrollar en javascipt de manera «ordenada» (orientado a objetos) acabas teniendo un montón de archivos «.js» con varias funciones esparcidas por ellos.

    Lo del tipado estatico solo ayuda a la hora de detectar algunos errores en tiempo de compilación (que no es poco).

    Te pongo éste enlace donde da un punto de vista sobre las traducciones de un lenguaje a otro, que tiene que ver con el articulo.
    http://www.cforcoding.com/2009/10/lost-in-translation-or-why-gwt-isnt.html

  3. Estoy completamente de acuerdo en que hay mucho código javascript muy mal escrito y organizado, pero no creo que sea problema del tipo de lenguaje. He visto muchísimo código en C# pésimamente estructurado, con aplicaciones enormes desarrolladas en el code behind de las páginas aspx sin ningún tipo de criterio.

    Detectar errores en tiempo de compilación es una herramienta muy valiosa, pero no creo que sea un requisito indispensable para escalar el desarrollo de aplicaciones grandes. En todo caso, puede ser útil para poder tener muchos programadores «no muy espabilados» siguiendo ciegamente una arquitectura rígida y (en demasiadas ocasiones) sobrecargada.

Comentarios cerrados.